Maze가 뭔가요?
Maze 공식 홈페이지에서 퍼온 글
Maze is a user testing platform that turns your prototype into actionable insights from real users, bringing confidence to the design process.
Maze makes it easy to gather user insights by integrating into your existent design and prototyping workflow.
Maze는 프로토타입을 통해 프로덕트의 사용성을 검증하는 테스팅 툴입니다. 물론 메이커들의 직관도 중요하지만, 가설에 논리적인 힘을 실어주는 건 아무래도 정량적인 데이터가 아닐까 생각합니다. 우리가 만든 인터페이스를 사용자가 어떻게 사용하는지, 어떤 부분에서 헤메는지 알 수 있는 툴이라고 생각하면 쉽습니다.
리디의 UX 디자인 팀은 이전부터 Maze를 이용해 사용성을 실험하고 검증했습니다. 저도 사용자의 입장으로 팀원들이 Maze로 만든 테스트에 참여한 경험이 있었는데, 제가 직접 검증하고 반영한 건 이번이 처음이라 간단한 사용기를 적어보려 합니다.
무엇을 검증했나요?
리디의 연재 작품은 작품 전체 리뷰뿐만 아니라 화별로 댓글을 등록할 수 있습니다. 이 기능은 ridibooks.com에서 볼 수 있는 웹 뷰어에 한정되어 있었고, 이번 업데이트에 이 화별 댓글을 안드로이드 앱 내에서도 볼 수 있도록 지원하려 준비하고 있었습니다. 여러 이유로 화별 댓글은 ID당 하나씩만 달 수 있는 정책을 가지고 있는데, 이 때문에 한 게시물에 여러 댓글을 달 수 있는 일반적인 댓글 UI를 그대로 적용하기 어려웠습니다.
댓글 남기기 전
댓글 남긴 후
처음엔 웹 뷰어처럼 내 댓글을 남기면 그 댓글 내용이 하단 바, 즉 text input에 그대로 남는 UI를 그대로 차용했습니다. 하지만 웹 뷰어에 익숙하지 않은 사용자라면 댓글 등록 후에도 그대로 남는 동작이 조금 어색하게 느껴질 수도 있겠다는 의견이 나왔고, 이에 공감해 이 부분을 조금 더 개선해 보기로 했습니다.
2개 정도의 시안을 가지고 다시 디자인 리뷰를 했는데, 확실하게 어느 시안이 낫다고 할 수 없는 상황이었고, 결국 직관이 아닌 Maze를 이용해 시안을 검증해보기로 했습니다.
검증 준비하기
검증할 부분은 크게 세 가지 항목으로 이루어집니다.
1.
하단 댓글 등록 창을 통해 댓글을 잘 등록할 수 있는지
2.
내 댓글은 등록 시간와 상관 없이 항상 상단에 고정됨을 사용자가 알 수 있는지
3.
내 댓글을 등록한 후 수정하거나 삭제하기 쉬운지
개선된 댓글을 남기는 과정 1
개선된 댓글을 남기는 과정 2
개선된 댓글을 남기는 과정 3
검증을 위해선 세 가지의 액션이 필요합니다.
1.
댓글을 등록해야 함 (이 때 2번을 검증하기 위해 스크롤을 하단으로 내려서 등록함, 스크롤을 내리는 동작을 자연스럽게 하기 위해 가장 하단의 댓글에 좋아요를 누르는 액션을 요구함)
를 누르는 액션을 요구함)2.
상단에 등록된 내 댓글을 찾기 위해 스크롤을 올리거나 내 댓글 바로가기 버튼을 누름
3.
내 댓글의 수정 버튼을 탭해 댓글 내용을 수정함
이 UI에선 댓글 등록 후 내 댓글을 찾고 수정/삭제하는 일이 쉬워야 하는게 관건이라 3번이 가장 중요한 항목입니다. 하지만 이를 수행하기 위해 1~2번을 선행하는 맥락도 중요하기 때문에 세 개의 액션은 하나의 플로우로 이어지도록 설계했습니다.
시나리오가 완성되었으니 Figma를 이용해 프로토타입을 만들 차례입니다. (Maze는 Figma뿐만 아니라 Sketch, Invision, Marvel도 지원합니다.) 리뷰했던 화면과 Maze로 Import할 화면이 섞이지 않도록 검증할 아트보드에는 prefix로 Maze 라는 단어를 붙여놓았습니다. 나중에 Maze에서 필요 없는 화면은 선택적으로 삭제할 수 있기 때문에 플로우만 섞이지 않는다면 다른 화면이 섞여도 괜찮습니다.
프로토타입의 링크를 Maze의 Create Project에 붙여 넣습니다. 링크로 Import하기 때문에 프로젝트가 생성된 이후에도 프로토타입을 수정할 수 있습니다. (refresh하는 데 시간이 좀 걸리지만)
프로젝트가 생성되면 이런 화면을 마주하게 됩니다. 왼쪽에 보이는 Block은 미션의 단위라고 생각하면 쉽습니다. 한 블럭 안에 2개 이상의 화면이 필요하고, 가운데 패널에 수행할 일과 그에 대한 설명을 적어야 합니다. 상황에 따라 하나의 미션은 여러 path로 구성될 수 있습니다.
예를 들면 이렇습니다. 테스터가 수행할 태스크의 제목을 쓰고 그를 설명하는 디스크립션을 작성합니다. 너무 구체적인 설명이나 힌트는 정확한 데이터를 수집하는 데 방해가 될 수 있기 때문에 ‘답정너’가 되지 않도록 주의하며 작성합니다.
앞에서 path는 하나의 미션을 성공하는데 수행할 수 있는 여러 선택지라고 소개했는데, 예시 화면에서는 내 댓글을 찾는 방법이 2개의 path로 나눠집니다. 내 댓글 바로가기 버튼을 누르거나, 사용자가 직접 상단으로 스크롤하는 방법입니다. 이 방법들을 각각 하나씩의 path로 설정해놓습니다.
테스트 후 결과 살펴보기
모든 미션이 세팅되면 프리뷰를 통해 확인하고, Start testing을 눌러 Live 시킵니다. 테스트 링크를 공유하면 테스터들은 설정해놓은 Block의 내용대로 미션을 수행하게 되며, 미션을 성공할 수 있는 클릭 수를 어느 정도 넘어가게 되면 Give up 버튼으로 다음 미션을 수행할 수 있습니다.
Maze에서 가이드해주는 테스터 모수는 최소 5명 이상입니다. 이 테스트는 정량적인 성격이 강해 사내의 이해 관계자가 아니더라도 테스팅을 부탁드렸습니다. (테스터는 오히려 이해 관계자가 아닌 게 좋기도 합니다.) 열 세 분정도 참여해주셨고, Level 1 수준의 테스터를 모집할 수 있었습니다. 기간이 여유롭다면 테스터는 되도록 많이 모으는 게 좋긴 하지만, 너무 많은 시간과 비용을 쏟을 필요도 없습니다.
테스트 결과는 block 단위나 테스터 단위로 쪼개져 결과를 확인할 수 있습니다. 디자이너가 유도한 방향대로 잘 따라온 결과를 Direct Success, 유도한 방향과 조금은 다르지만 어쨌든 미션을 성공한 Indirect Success, 포기 버튼을 누르거나 테스트를 이탈한 Give-up / Bounce로 나누어집니다.
각 화면마다 Heatmap도 확인할 수 있습니다. 사용자가 미션을 수행하기 위해서 화면의 어느 곳을 건드렸는지, 어느 경로로 시도했는지 힌트를 얻을 수 있는 결과물입니다. 다만 화면 스크롤 후 클릭 액션이 있을 땐, 스크롤 되기 전의 구역을 클릭하는 것으로 인식하므로 이 경우 정확도가 다소 떨어질 수 있습니다.
두 개 path로 나누었던 테스트는 결과 값도 두 개로 보여집니다. 3번 Block의 경우, Give up한 한 명의 테스터를 제외하고는 90% 이상의 테스터가 어떤 방법으로든 내 댓글을 찾아 수정을 완료했습니다. 직접 스크롤을 올려 내 댓글을 찾은 사용자라도 추후 학습을 통해 내 댓글 바로가기 버튼을 찾을 확률이 높으니, 이 UI로 배포되어도 큰 문제가 없다고 예측됩니다.
마치며
이렇게 검증하는 과정을 거쳐도 막상 배포하고 실제로 사용하다 보면 많은 변수가 튀어나오기 마련입니다. 다만, 아무도 모를 배포 전 상황에서 내 디자인에 확신과 근거를 가지기엔 좋은 도구가 될 수 있습니다. 직관보다는 작은 데이터라도 확인하고 싶은 디자이너라면 한 번 쯤 Maze를 살펴봐도 좋지 않을까 생각합니다.
