[코드스테이츠 PMB 13기] W4D3_와이어프레임, 프로토타입
이전 과제에서 쿠팡이츠의 아쉬운 UX에 대해 이야기했고, 아래와 같이 우선순위를 설정해봤다.
(참고로 우선순위는 변경됐다.)
1. 하나의 가게만 카트에 담을 수 있다. (Feat. 배민, 요기요)
카트에 담을 수 있는 가게는 오직 하나뿐이다. 이 문제는 배달의 민족과 요기요도 마찬가지다.
만약 여러 가게에서 음식을 주문하고 싶은 사람이나, 여러 음식점을 둘러보면서 주문할 음식을 정하는 사람들에게 불편한 부분이다.
2. 메뉴 별 리뷰보기(Feat. 배민)
내가 주문하고 싶은 메뉴의 리뷰만 빠르게 확인하고 싶다.
리뷰를 확인하는 이유 중에 하나는 내가 주문할 음식이 음식점에서 올려놓은 대표 이미지랑 비슷한지 또는 실제로 주문했던 사람들의 평이 어떤지 알고 싶어서이다.
3. 카페 음료: 여름에는 ICE, 겨울에 HOT 고정 (Feat. 배민, 요기요)
음료 주문할 때 미처 HOT, ICE 옵션을 확인하지 못한 경험이 있다. 그래서 더운 여름날 뜨거운 아메리카노를 마셨었다. 심지어 우리 가족 모두..
이런 경험을 방지하기 위해 여름에는 ICE, 겨울에는 HOT을 기본 값으로 설정해 놓는다.
사실 이 경우는 쿠팡이츠보다는 배달의 민족을 떠올리고 쓴 내용이라 오늘 과제에서는 제외했다.
쿠팡이츠의 UX 개선 순위
① 하나의 가게만 카트에 담을 수 있다
② 메뉴 별 리뷰보기
③ 카페 음료:여름에는 ICE, 겨울에는 HOT으로 고정
쿠팡이츠에서 불편을 겪는 고객의 상황을 두 가지로 나눠서 생각해봤다.
① 고객은 친구들과 함께 모여 여러 가지의 배달음식을 시켜 먹으면서 놀고 싶다!
② 고객은 카트에 여러 음식점의 음식들을 담고 비교해서 가장 맛있는 음식을 배달시켜 먹고 싶다!
1번 고객의 상황을 생각해보자.
쿠팡이츠에서 카트에 담을 수 있는 음식점의 개수는? 하나이다.
만약에 넷 이상의 친구들과 함께 모여서 두세 가지의 음식을 먹고 싶다면?
각자 주문을 하거나, 한 명이 주문하고, 가게를 찾고 카트에 담고 주문하고, 또다시 주문할 가게를 찾고 메뉴를 카트에 담고 주문해야 한다. 정말 번거로운 일이다!
이번에는 2번 고객의 상황을 생각해보자.
떡볶이가 먹고 싶어서 '떡볶이'를 검색해서 스크롤을 내려가며 음식점을 둘러보고 있다.
이때 마음에 드는 떡볶이집을 눌러 메뉴를 보고 리뷰를 확인한다. 근데 뭔가 아쉬워서 일단 패스했다.
그리고 또 스크롤을 내리다가 다시 괜찮은 떡볶이집을 발견했다! 메뉴를 둘러보고 리뷰가 괜찮아 일단 카트에 담았다.
근데.. 더 괜찮은 떡볶이집이 있을 것만 같아서 스크롤을 내리다가 또! 괜찮아 보이는 집을 발견했다.
메뉴와 리뷰를 보고 다시 생각해보니 첫 번째 집이 제일 마음에 드는 것 같다.
하지만 가게 이름이 생각이 나지 않는다.. 다시 스크롤을 올려가며 첫 번째 음식점을 찾아야 한다.
이것도 정말 번거롭다!!
위 두 명의 고객과 같은 불편함을 겪는 고객을 위해 카트에 여러 음식점의 메뉴를 담을 수 있게 프로토타입을 그렸다.
현재 쿠팡 이츠는 아래와 같이 기존 카트에는 한 군데의 매장 메뉴만 카트에 담을 수 있다.
따라서 아래와 같이 카트에 여러 매장의 음식을 선택할 수 있는 드롭 다운 박스를 추가했다.
드롭 다운 박스를 누르면 고객이 카트에 담아 뒀던 매장을 선택할 수 있다. 원하는 매장을 선택하면 사용자가 카트에 담았던 메뉴가 자동적으로 보인다. 매장 1의 음식을 주문하고 바로 다시 카트로 돌아가 매장 2의 음식 주문이 가능해졌다.
고객은 리뷰를 보고 내가 주문할 음식에 대한 평가를 확인하여
지금 제일 맛있는 음식을 배달시키고 싶다!
쿠팡이츠에서 내가 원하는 메뉴의 리뷰를 확인하기 위해서는 리뷰 화면에서 내가 원하는 리뷰가 나올 때까지 찾는 방법밖에 없다. 만약 고객이 원하는 메뉴가 인기 메뉴가 아니라면, 해당 메뉴의 포토 리뷰를 찾는 것에 어려움을 겪을 것이다. 따라서 메뉴 별로 리뷰를 모아볼 수 있는 개선안을 생각해봤다.
메뉴 별로 리뷰를 모아 보는 기능을 아래와 같이 두 가지로 생각해봤다.
① 메뉴를 보는 화면에서 제공
② 리뷰 보는 화면에서 제공
쿠팡 이츠의 등록된 매장들은 대부분 최소 20여 개 이상의 메뉴를 판매하고 있다. 따라서 ② 리뷰 화면에서 원하는 메뉴를 선택해 리뷰를 모아 보는 기능은 고객의 입장에서 메뉴를 찾는 것이 더 불편할 것이라고 판단했다. 오늘은 ① 메뉴를 보는 화면에서 리뷰를 모아볼 수 있게끔 아래와 같이 포로토타입을 작성했다.
다음 단계는 내가 만든 페이퍼 프로토타입으로 팀 내부 이해 관계자들과 회의를 진행한다.
회의에서 내가 그린 프로토타입 기능들을 개선하기로 결정이 됐다.
그 이후의 과정은 개발자, 디자이너에게 개발 및 디자인을 요청하는 단계이다.
이때 개발자에게 '우리 이거 개선할 거니깐, 카트에 이거 추가해주시고요. 메뉴 상세 페이지에 이것도 추가해주세요!'라고 말하면 개발자는 이해할 수 없어서 커뮤니케이션 비용과 시간이 많이 들 것이다
.
따라서 우리는 개발자와의 원활한 커뮤니케이션을 하기 위해 적절한 문서를 주면서 개발 요청을 해야 한다.
그 문서가 요구 사항 정의서이다.
페이퍼 프로토타입을 그리려고 오랜만에 손글씨를 써보고 깜짝 놀랐다! 내가 봐도 내 글씨 못알아 보겠는데?
오늘은 페이퍼 프로토타입과 와이어프레임, 각종 문서들에 대해 학습했다. 오늘도 아직 명확하게 개념이 잡히지는 않았다. 특히! 요구 사항 정의서를 작성할 때 '이렇게 하는 게 맞나?' 싶었다. 그래도 오늘을 마무리했으니깐, 일단 자자. 내일의 내가 잘 해내기를..
참고 자료