토스 증권 매수 기능 프로토타입 만들기
[코드스테이츠 PMB 11기] 토스 증권 - UX 개선/개발
오늘 포스팅은 지난 포스팅에서 만든 MVP를 구체화시키는 내용입니다! 위 링크를 통해 지난 포스팅을 보고 오시기를 추천드립니다*.*
1. 기능 정의 (백로그 작성)
지난 포스팅을 통해서 해결해야 할 문제점을 '가격, 수량 수정 과정에서 터치포인트가 너무 많다'라고 정의했고, 이를 해결하기 위한 MVP 와이어프레임을 위 이미지와 같이 만들었다. 오늘은 내가 만든 MVP 와이어프레임의 기능을 더 구체화시켜 요구사항 정의서, 정보구조도(IA), 와이어프레임, 스토리보드까지 작성해보고자 한다.
요구사항 정의서(Mini ver.)
위에 내가 만든 MVP를 기준으로 만든 요구사항 정의서이다. 아마 현업에서는 더 디테일하게 적어야 할 테지만... 오늘 과제에서 스토리보드까지 만들 예정이기 때문에 간단하게 기능들과 기능 설명을 적어 미니 버전으로 만들었다. 각각의 서비스를 크게 분류하면 다음과 같이 분류할 수 있다.
1. 가격 설정: 현재 가격으로 구매, 최대한 빨리 구매하기, 호가에서 가격 선택, 직접 가격 설정
2. 수량 설정
3. 구매하기: 구매하기, 구매 확인 팝업
4. 기타: 뒤로 가기
우선순위는 내가 정의한 문제에 대한 개선방안이 새롭게 추가되는 기능이 아닌, 기존에 있었던 꼭 필요한 기능이기 때문에 대부분이 1순위로 설정되어있다. 그중에 호가에서 가격 선택만 2순위인 이유는 지난 포스팅의 마지막 부분에 나와있듯이 꼭 구매하기 과정을 통해 진행하지 않고, 호가 확인창에서도 호가 매수를 할 수 있도록 되어있었기 때문이다.
2. 정보 (계층) 구조도 설계
(IA, Information Architecture)
내가 정보(계층) 구조도를 이해를 못 해서 아주 오랜 시간이 걸렸지만, 결과론적으로 아직도 이해를 못 했다.(...) 일단 아래 참고자료의 2개의 블로그를 통해 정리를 해보려 한다.
웹기획자 이정기 님의 표현을 빌리자면에 IA는
1. 인포메이션 체계 내의 내비게이션 체계, 레이블링, 조직화
2. 콘텐츠에 직관적으로 접근하고, 업무 처리가 용이하게 정보 공간을 설계하는 것
을 의미한다고 한다. 즉, 웹사이트, 제품에 뼈대를 만드는 작업이다. 그래서 IA 짤 때의 기준은 무엇인가? 에 대한 답은 ‘유저가 잘 이해하는가를 살펴보는 것’, ‘내가 전하고 싶은 것을 잘 전달했는가’가 잘 짜인 IA의 기준이라고 한다.
이렇게 생긴 계층형 패턴은 IA의 표준이라 할 수 있다. 인덱스 페이지와 여러 개의 서브페이지로 구성된다. 데스크톱 웹사이트 구조를 따라 모바일앱 구조를 설계한다면 계층형 IA를 택하는 것이 적합하다고 한다. 하지만 토스 증권 같은 경우에는 모바일 앱으로 계층형 패턴과는 적합하지 않다고 생각되었다. 그럼 무슨 패턴일까?
내가 비슷하다고 생각한 패턴은 hub and spoke 패턴이다. 중심부에 인덱스 페이지를 두고 사용자가 각 요소를 선택하여 다른 화면으로 빠져나갈 수 있도록 설계하는 방식이다. 중심 화면(Hub) 없이 다른 화면(Spoke) 사이를 오갈 수 없다(=멀티태스킹 불가)는 단점이 있지만 동시에 사용자가 지금의 TASK에 집중할 수 있도록 돕기 때문에 결제 과정 등 모바일앱에서 자주 사용되고 있다고 한다.
그렇게 하여 내가 만든 토스 증권의 ia인데 허접 그 자체라 눈물이 날 지경이다.(ㅠㅠ) 일단 첫 화면인 토스 증권과 노란색으로 되어있는 종목정보 이 두 화면이 허브가 되고 나머지는 스포크가 된다고 생각하고 만들었다. 그런데 이렇게 나눠놓고보니 새로운 의문만 가득하게 되었는데... 토스 증권에서 종목 정보까지 가는 과정도 허브 앤 스포크 패턴이라고 볼 수 있는가? 그냥 이 구조가 맞긴한가?(...)
IA를 짤 때 기준은 유저가 잘 이해하는가? 라고 했는데, 일단 내가 토스 증권의 유저로서 이해가 안된다...이 부분은 추후에 공부를 더 해서 꼭 수정하도록 하겠다...
3. 화면 디자인 (Wireframe)
원래는 페이퍼 와이어프레임으로 먼저 흐름을 그린 후, 피그마를 이용해서 mid-fi 이상의 와이어프레임을 그려야 한다. 하지만 저번 과제에서 이미 포토샵으로 한 번 와이어프레임을 만들었던 상태여서 페이퍼 와이어프레임은 생략하고 바로 피그마를 통해 와이어프레임을 만들고 플로우(flow)를 화살표를 이용해 표시했다.
Figma를 이용하여 만든 프로토타입
4. 스토리보드 작성
이제 와이어프레임 한 화면들을 진짜 팀원분들(개발자, 디자이너)에게 전달하기 위한 스토리보드를 작성해보자. 위의 흐름을 보여주기 위한 와이어프레임에서는 화면이 여러 개 인 것처럼 보였지만, 팝업과 중복 화면을 제외하니 수정해야 할 화면은 2개의 화면이 나왔다.
스토리보드... 정말 세밀하게 적는다고 노력했지만, 사실 특정 상황에 대한 경고 팝업 같은 것도 필요할 것 같은데 흐린 눈으로 마무리했다... 페이지 자체는 2개여서 괜찮을 것 같다고 생각했지만, 그 안에 버튼 하나 기능하나 추가하는데 이렇게 많은 디스크립션이 필요하다는 사실이 너무나 충격적이었다. 실제 토스의 기능을 다 담지 못하는데도 이 정도인데 다 담는다면...? 사용자 중심의 ui/ux를 위해서 디테일까지 신경 쓴다는 것이 이런 곳에서 빛을 낸다는 사실을 몸소 깨달은 것 같다.
참고자료
