[번역] 아마존 주문 리디자인 연습—파트 1: 내비게이션

※ 의/오역 있음, 문제 시 삭제합니다.

[주문 프로세스 리디자인하기]

아마존 닷컴의 비회원 주문 As-Is
- UI 일관성 부족
- 현 단계를 나타내는 프로세스 헤더 있음
- 주문 단계 페이지 간 이동 불가

아마존 닷컴의 비회원 주문 To-Be
(1) 계산서 중심
- 한 화면에서 모든 정보에 접근, 편집 가능
- 프로세스에 따른 모든 화면에 도달하지 않아도 됨

(2) 프로세스 기반
- 프로세스의 선/후가 명확함
- 목차를 통해 프로세스 전반을 인지, 이해 가능

Amazon Checkout Redesign Exercise —Part I: Navigation

---

주목: 이것은 연습입니다. 이 연습의 목적은 비즈니스 솔루션을 제시하는 것이 아니라, 가정된 환경에서 솔루션 제시를 연습하는 것입니다. 추측의 힘은 비즈니스 목표와 측정 기준metics를 형성하기 위해 적용됩니다.

이 기사의 마지막에 프로토타입과 다른 파트의 연습이 (만약 그것들이 작성되었다면) 링크된 것을 찾을 수 있을 것입니다.

목표

아마존은 하루에 수백만의 주문을 훌륭하게 처리하고 있습니다. 하지만 항상 개선의 여지가 있습니다. 더 높은 고객 만족도, 성공적인 업셀링, 결제 구독으로의 전환 등.

다음 활동을 통해, 우리는 계산서 프로세스를 더 작은 경험으로 쪼갤 것입니다. 그리고 우리가 그것을 하나씩 개선할 수 있는지, 내비게이션을 시작으로 살펴볼 것입니다.

주어진 것

아마존의 체크아웃은 여러 단계로 되어있습니다. 다음은 비회원이 주문하기 위해 거쳐야 하는 단계입니다.

아마존 닷컴에서의 비회원 주문 플로우

이 워크플로우에서의 실제 성과 지표를 알 수 없을지라도, 우리는 여기서 가장 명백한 문제를 발견할 수 있습니다. UI 일관성이 부족해 보입니다.

• 대부분의 화면들은 고유한 레이아웃과 스타일을 가집니다. 따라서 당신은 확신을 갖고 인터렉션을 시작할 수 있기 전에, 모든 화면을 숙지해야 할 것입니다.
• 화면들은 다른 맥락을 가집니다. 쇼핑 카트 화면(1)은 일반적인 UI의 일부입니다. 하지만 나머지 화면들은 끝마칠 단계들을 보여주는 특별한 헤더를 동반합니다.
• 계산서 프로세스 전반의 내비게이션은 일방통행입니다. 대부분의 경우 당신은 이전 단계로 돌아갈 수 없습니다. 헤더는 진행상태를 나타냅니다. 하지만 그 역할을 잘 수행하지는 않습니다. 당신은 3가지 다른 화면(3-5)의 배송과 결제에서 막힐 것입니다. 그리고 기프트 옵션은 대부분의 경우에서 스킵됩니다.

계산서 프로세스는 다양한 UX 문제로 인해 복잡합니다. 그리고 나는 당신이 직접 문제를 해결해 나가고 다른 사람들이 하는 것을 지켜보길 추천합니다. 솔루션을 연습하는 것은 수천 개의 이미지보다 더 가치 있습니다.

지금부터, 우리의 임무는 내비게이션을 개선하는 것입니다.

스케치

낙서Doodling은 UI 디자인 탐험을 위한 훌륭한 툴입니다. 브레인스토밍과 유사하게, 당신은 품질과 디테일을 자유와 솔루션 생산의 속도로 맞바꿀 것입니다. 그리고 만약 당신이 나에게 묻는다면, 첫 번째 반복에서 가장 중요한 것은 자유와 속도입니다freedom along with speed are what matters most for the first iteration.

낙서의 산물: 못생기고 혼란스럽고 인사이트가 가득합니다.

몇 시간이 지난 후, 내비게이션의 두 가지 접근으로 수많은 아이디어가 요약됩니다myriads of ideas boil down to either of the two approaches in navigation:

첫번째는 계산서 중심입니다. 우리는 일반적으로 계산서 프로세스의 마지막 화면이 무엇인지에서 시작합니다. 정보를 편집하기 위해, 사용자는 각각의respective 화면을 열어야 합니다. (배송, 결제와 같은 화면)

두번째는 프로세스 기반입니다. 이는 아마존의 현재 디자인과 유사하지만, 몇가지 예외가 있습니다. 장바구니가 전체 계산서 워크플로우의 일부이고, 우리는 또한 사용자가 과정의 단계를 자유롭게 탐색하게 할 수 있기를 원합니다.

이제 우리는 두 가지 시작점을 위한 스케치를 가졌습니다. 우리는 디자인 탐험의 다음 레벨로 갈 수 있습니다. 물론 목업이 아닙니다.

프로토타이핑

손그림 낙서에서 좀 더 디테일을 추가하기 위해 스케치와 피그마에서 목업을 그리는 것 대신, 동작 가능한 디자인을 즉시 만드는 것을 시작하기 위해 우리는 vue.js를 사용할 것입니다.

프로토타입에는 프로토타입 매니저가 설치되어 있어 구현 버전과 반복 작업을 빠르게 전환할 수 있을 것입니다.

프로토타입 매니저

계산서 중심 디자인

다음의 아이디어는 마지막 계산서 화면을 시작점으로 만들고, 모든 다른 하위 화면들(편집 가능한)을 만들기 위함입니다.

복잡한 화면의 부분으로써 장바구니를 보여주는 것은 그저 무엇이 있는지 보기를 원하거나 몇가지 물건을 삭제하려는 사람들에게 좋은 생각이 아닙니다. 그래서 비록 그것이 메인 화면이 아닐지라도, 편집 가능한 장바구니 화면을 과정의 시작점으로 설정하는 것이 합리적입니다.

얼마간의 코딩하는 시간이 지난 후, 우리는 첫 방문 사용자가 이 탐색 구조를 겪는 단계를 시뮬레이션하는 프로토타입을 가졌습니다.

최초의 테스트와 관찰은 이러한 접근에 대한 좋은 인사이트를 주었습니다.

• 첫 방문 사용자를 위한 메인 플로우는 가입된 회원과 같습니다. 장바구니-계산서 (추가적으로 배송/결제 정보 수정). 이러한 패턴은 특정한 환경 아래에서 조용하게 몇 단계를 스킵하곤 하는 단계 기반의 탐색과 비교하여 단순합니다.
• 주어진 상황에서, 프로세스 내에서 당신이 정확히 어디에 있는지, 어떻게 그곳에 도착했는지, 버튼이 어디로 데려갈 것인지 알려주는 것은 쉽습니다. 이러한 편안함은 버튼 그 자체가 선형의 단계별 프로세스 제거의 결과인, 모든 수상한 '계속' 과 '진행' 버튼을 제거함으로써 획득했습니다. 여기서 사용자들은 대응하는 버튼을 누름으로써 모든 화면에 도달하기 위해 의식적으로 선택해야 합니다.

이러한 접근에 대한 나쁜 인사이트는 다음과 같습니다.

• 당신은 놓친 정보에 들어가기 위해 스스로 선택해야 합니다. 당신이 진행하기 전에 모든 필요한 양식을 하나씩 보여주는 단계 기반의 디자인과 달리, 여기서는 놓친 부분을 위해 '편집' 버튼을 눌러야 합니다.
• 가장 바쁜 화면이 시작하자마자 보여집니다. 당신이 주문하기 버튼을 누르기에 편안하게 만들기 위해 모든 정보를 전시해야 하는 요약 화면에서 얻을 수 있는 것은 없습니다. 하지만 과정의 본거지처럼 그것을 여기는 것은 사용자를 압도할지도 모릅니다.

다음은 스스로 프로토타입을 테스트 할 수 있는 방법입니다. Prototype A.1. 배송과 결제에 정보 입력하는 것 때문에 귀찮아하지 마세요. 그저 "저장" 버튼을 누르는 것으로 지금은 넘길 수 있습니다.

프로세스 기반 디자인

이 구조는 탭으로 탐색하는 것과 매우 유사합니다. 하지만 탭 대신 우리는 프로세스를 가졌고, 대부분은 과정 중에 채워야 하는 양식을 노출합니다. 이러한 패턴은 설치 마법사로 소프트웨어 패키지를 설치하기에 충분할만큼 운이 좋은 누군가에는 익숙해 보일 것입니다.

프로토타이핑 단계의 첫 번째 반복 중, 목차the table of contents 역시 내비게이션과 정보 요약의 역할을 할 수 있다는 것이 분명해졌습니다.

우리가 발견한 좋은 인사이트는 다음과 같습니다.

• 프로세스가 명확하게 진행됩니다. 한 번에 하나의 화면을 보여주고, 다른 하나가 즉시 이어집니다. 당신은 한 번에 오직 하나의 액션 버튼을 볼 수 있고, 다음에 무엇을 해야할지 궁금해하지 않을 것입니다.
• 목차가 내비게이션과 주문 요약의 역할을 하는 더 유용한 UI의 일부로 바꿀 수 있습니다. 사용자들에게 그들의 노력의 결과를 보여주는 것은 보통 프로세스에 대한 이해를 전반적으로 향상시킵니다.

이러한 접근의 나쁜 인사이트는 다음과 같습니다.

• 다양한 유스케이스에 따라 플로우가 다릅니다. 가입된 회원이 마지막 단계로 이동되는 동안, 첫 방문 사용자는 모든 단계를 진행합니다. 그리고 많은 사람들이 아마 두 가지 케이스를 경험할 것입니다.
• 우리의 첫 번째 접근과 같이, 가입된 사용자는 바쁜 화면으로 시작할 것입니다. 이러한 케이스는 입력할 정보가 없기 때문에 보여줄 단계가 없다는 것은 거의 불가피합니다.

다음은 스스로 프로토타입을 테스트 할 수 있는 방법입니다. Prototype A.2.

결론

두 접근 사이에 명확한 승자는 없습니다. 왜냐하면 두 가지 모두 강점과 약점이 있기 때문입니다. 교환 이후에 많은 수리가 진행될 것입니다. 분명 앞으로 수행할 더 많은 사용자 테스트가 있지만, 이 역시 나중에 진행됩니다. 내비게이션은 테스트하기 위한 진짜 주제여야 하는 더 큰 경험의 일부일 뿐입니다.