[코드스테이츠 PMB 8기] Figma, 디자인 툴
갑자기 봄여어어어름 갈겨어어어어울이되면서 부랴부랴 겨울옷을 꺼내고 드라이 맡겼던 코트들을 꺼냈다. 가을 옷은 제대로 입지도 못했는데,,, 갑자기 바뀐 날씨 탓인지? 옷을 사고 싶어졌다. 자연스럽게 '지그재그'앱을 켰다. 사실 나는 지그재그보다 29CM 같은 앱이나, 인스타에 팔로우해둔 쇼핑몰들 더 자주 보지만 내가 지그재그를 지울 수 없는 이유가 있다.
나는 고등학생, 20살부터 아주 오랫동안 '위드윤'이라는 쇼핑몰을 이용해왔다. 이 쇼핑몰을 이렇게 오랫동안 이용한 이유는 내가 사장님 스펙과 비슷해서이다. 사실 이곳저곳 다른 곳에서 사봤지만, 위드윤 바지만큼 나한테 잘 맞는 게 없었다. 사실 지그재그에는 위드윤 말고도 다른 쇼핑몰도 많이 있지만, 거의 위드윤을 보기 위해서 사용한다고 해도 과언이 아니다. 분명 위드윤 앱도 있는데 나는 왜 지그재그를 통해 위드윤을 보게 될까?
바로 지그재그의 '찜한 아이템 폴더별로 모아보기' 기능 때문이다. 지그재그를 정말 초반부터 이용해온 사용자로서 이 기능이 처음 생겼을 때 J를 위한 기능이라는 생각이 들었다. 나처럼 충동구매보다는 이것저것 비교해 보고 사는 사람들에게는 정말 없어선 안 되는 기능이다. 지그재그의 찜한 아이템 폴더별로 모아보기 기능을 User Story와 Wireframe과 함께 더 자세히 알아보자.
지그재그는 다양한 쇼핑몰이 입점해 있는 이커머스 플랫폼이다. 쇼핑몰 수가 많은 만큼 상품 수도 어마 무시하다. 사용자는 많은 상품들을 둘러보다 마음에 드는 상품을 발견하게 된다. 대부분 사용자는 마음에 드는 상품을 바로 보고 구매하지 않는다. 오픈마켓에서는 더더욱 사람들이 자신이 마음에 드는 상품들 중 가격, 형태 등을 비교해 보고 더 마음에 드는 것을 사게 된다. 하지만 일반적인 '찜하기' 기능은 하나의 페이지에서 찜 한 모든 상품들을 봐야 한다는 문제가 발생한다. 사용자는 마음에 드는 상품들 중 아우터는 아우터끼리, 가방은 가방끼리, 혹은 여행을 위해 사는 옷 등 마음에는 상품들 안에서도 각자의 방식대로 분류해서 비교하고 싶어 하기 때문이다. 그래서 지그재그는 '찜한 아이템 폴더별로 모아보기' Task를 이용해 찜 한 모든 상품을 하나의 페이지에서 비교하기 어렵다는 문제를 해결하고자 한다.
유저스토리는 보통 애자일 프로세스에서 사용된다. 유저 스토리를 작성하는 목적은 고객의 요구 사항을 바탕으로 제품팀의 '공유된 이해'를 만드는 것이다. 즉 고객이 요구 사항을 가지게 된 맥락과 배경을 팀원 전체가 이해하고, 그 요구 사항을 통해 동일한 결과물을 떠올리는 것이다.
유저 스토리에는 다음과 같은 내용이 들어가야 한다.
1. 고객과 사용자의 묘사 - 제품을 사용하는 사용자의 모습이 담겨있어야 한다.
2. 사용자가 제품을 사용하는 시나리오 - 제품의 기능을 왜 원하고, 왜 사용하는지에 대해 명시해야 한다.
[찜한 아이템 폴더별로 모아보기] Task를 사용하는 유저 스토리는 어떻게 작성되어야 할까?
유저스토리는 '고객(사용자)은 / 목적(목표)을 위해서 / 필요(욕구)를 원한다'의 형식으로 작성할 수 있다.
바로 구매하지 않고 옷을 고민하며 사고 싶은 고객은
아이템들을 서로 비교해 보기 위해서
나만의 방식으로 아이템들을 분류하길 원한다.
이러한 유저스토리를 해결하기 위한 핵심 기능은 '찜하기(하트 누르기)'와 '폴더 선택' 기능이다.
이러한 기능들로 구성된 Flow는 다음과 같은 순서로 진행된다.
홈 → 상품 페이지(모아보기) → 찜하기(하트 누르기) → 폴더 선택 → 폴더 생성 →확인→ 뒤로 가기 → 메뉴에서 찜한 아이템 선택
이러한 화면 흐름을 간단하게 Lo-Fi Wireframe으로 그려보았다.
Wireframe는 화면 설계서, 화면 청사진이라고도 불린다. 실제 GUI 디자인이 입혀지기 전, 페이지의 골격을 확인하기 위해 만드는 시각적 산출물이다. 텍스트만으로 디자이너와 개발자와 커뮤니케이션한다면 서로 다르게 이해하는 부분들이 발생하게 된다. 그래서 이런 오류와 불필요한 커뮤니케이션 비용이 발생하는 것을 방지하기 위해 와이어 프레임을 그린다.
잘 만들어진 와이어 프레임은 초기 피드백을 수집하기가 매우 용이하다. 그리고 기능, 정보 구조, UX, 사용자 흐름, 사용자 상호 작용, 기능의 유용성 등 사용자가 사용 시 디자인에 가려져 보지 못했던 것들에 집중할 수 있게 해 준다. 또한 개발 코드 및 디자인 툴 없이 필요한 수정을 빠르게 적용할 수도 있다. 즉 서비스를 개발하기 전에 모든 팀원이 보다 명확하게 커뮤니케이션하고, 실제 개발 전 서비스의 형태를 확인하고 문제를 미리 발견하기에 와이어 프레임을 그리는 것이다.
위에서 손으로 Lo-Fi로 그린 와이어 프레임을 'Figma'라는 프로그램을 이용해 Mid-Fi로 그려보았다.
Figma 툴을 이용해 각 프레임들 간에 인터렉션을 설정해 프로토타입 형태로 만들어보았다.
지그재그의 찜한 아이템 폴더별로 모아보기 중 [5. 확인]에서 [6. 뒤로 가기]를 눌러야지 하단 메뉴바가 나타난다. 즉 사용자는 [모아보기 - 아우터 화면]을 나가야지만 찜을 누를 수 있는 하단 메뉴바가 나타난다. 사용자가 이후 다시 [모아보기 - 아우터 페이지]를 가게 된다면 상품페이지를 자신이 보던 위치부터 보는 것이 아닌 다시 처음부터 봐야 한다. 이를 개선하기 위해서 상품페이지를 스크롤해서 내리면 자연스럽게 아래 하단 메뉴가 나오도록 개선했다. 개선된 UX에서 사용자는 하단 메뉴에서 어디로 이동하던 기존에 보던 상품페이지 위치 그대로 볼 수 있어 사용자가 옷을 고르기 더 수월해진다.
변경된 내용에도 인터렉션을 설정해 프로토타입 형태로 만들어보았다.
피그마로 와이어 프레임과 프로토타입을 직접 제작해 보니 왜 커뮤니케이션을 위해 피그마를 사용하는지 알 수 있었다. 스토리보드만으로 팀원들과 소통한다면 분명 저 부분에서 서로 오해하는 부분들이 생겼을 것이다. 하지만 스토리보드와 함께 피그마를 통해 구현되는 모습을 시각적으로 보여주면, 이해도 쉽고 서로 빠른 피드백도 주고받을 수 있을 거란 생각이 들었다. 만약 지그재그가 내 개선된 프로토타입을 보게 된다면, 바로 내 마음을 이해할 수 있겠지?
건축을 설계하다 서비스까지 설계하는 본 투 비 설계자의 PM도전 프로젝트