유저 플로우 그리다 킹 받을 땐
해피패스를 그려봐요
프로덕트 디자이너에게 해피패스란
몇 달 전에 플로우차트와 해피패스에 대해 작성했던 글을 날려먹고 전의를 상실한 뒤로, 한동안 유저 플로우에 대한 글은 쓰고 싶지 않았는데, 또다시 플로우에 대해 고민하는 상황을 맞닥뜨리게 되어, 기억을 끄집어내어 쓰는 글
유저의 경험은
어디까지 고려해야 할까?
프로덕트 디자이너들은 종종 기획자 혹은 PM이 없는 환경에서 일한다. 아무도 어떤 화면을 어떻게 그리라고 알려주지 않는다.(어떤 화면이 필요하다고 말해주는 경우는 그나마 양반이다) 그렇다면 디자이너는 유저의 경험을 어디서부터 어디까지 고려해야 하는 걸까?
유저 플로우를 그리다 보면 이런저런 고려해야 할 상황들이 늘어난다. 거미발처럼 늘어나는 플로우차트를 보고 있자니, 지금 단계에서 이런 것까지 고려하는 게 맞나? 이게 과연 지금의 문제를 해결하기 위한 적확한 솔루션일까? 아니, 그에 앞서서 지금 이 단계에서 이 문제를 고민하는 게 맞는 걸까? 어차피 개발 우선순위 밀려서 백로그로 들어갈 텐데 괜한 시간 낭비하는 것은 아닐까? 하는 생각에 머릿속이 뒤죽박죽 된다.
그럴 땐, 우리가 생각하는 가장 이상적인 흐름인 해피패스를 그려보자. 해피패스를 그리다 보면 정말 필요한 기능들만 자연스레 추리게 되고, 우리 팀이 가장 중요하게 생각하는 목표나 유도하고자 하는 행동에 집중할 수 있다.
순서는 1)유저 플로우를 먼저 그리고 2)해피패스를 그리는 것을 선호한다. 하지만 결국 두 개를 나란히 펼쳐놓고 번갈아가며 완성도를 함께 높여가게 된다. 하지만, 유저 플로우도 해피패스도 문제의 해결방법을 찾기 위한 도구에 지나지 않는다. 따라서 자칫하다 이것들 자체의 완성도를 높이기 위해 지나치게 많은 시간을 쓰는 일은 경계하는 게 좋다.
(좌) 해피패스 / (우) 유저 플로우문제를 명확히 파악할 수 있다.
여하튼 유저 플로우던 해피패스던 그리다 보면 그 과정에서 해결하고자 하는 문제를 더 명확히 파악할 수도 있고, 더 나은 솔루션이 떠오르기도 한다.
하나의 프로젝트를 수행하기 위해 다양한 이해관계자들의 의견이 오고 가기 마련이다. 이 경우에, 각자가 머릿속으로 다른 그림을 그리게 되는 경우가 종종 생기는데, 이때 유저플로우나 해피패스를 활용하면 서로가 생각의 싱크를 맞추는데 도움이 된다.
더군다나 사업부에서 받게 되는 피드백은 실제 사용자와 밀접하게 연결되어 있을 뿐 아니라, 비즈니스에 대한 이해도 측면에서도 많은 도움을 받을 수 있기 때문에 좋은 UX를 그려내기 위해선 그들의 의견이 꼭 필요하다.
더 나은 UX를 설계할 수 있다.
당연한 이야기지만 문제를 명확하게 파악할수록 제대로 된 사용자 경험을 그려낼 수 있다. 다 개발된 기능이 배포 직전에 '지금 이게 왜 필요한 거죠?'라는 이야기를 듣는 것은 정말 곤란하다. 최종적으로 유저가 보게 되는 화면을 그리는 것은 디자이너다. 디자이너가 문제에 대한 이해도가 높을수록 문제해결에 더 많은 기여를 할 수 있는 화면을 그릴 수 있다.
시간이 부족한 상황에서는 핵심만 간략하게 그려서 커뮤니케이션 도구로 활용하기도 한다.핑퐁이 중요합니다.
'자, 이제 유저 플로우를 완성했으니까, 해피패스를 그려볼까'라던지, '이미 완성된 해피패스라 수정하는 것은 곤란해'하는 식으로 흘러가지 않는다. 보편적으로 유저 플로우를 먼저 펼쳐 놓고 해피패스를 그리겠지만, 중간에 다시 유저 플로우로 갔다가 해피패스로 돌아오는 등 왔다 갔다 하며 완성도를 높여가는 것이 좋았다.
더군다나 상황이 시시각각으로 변하는 경우에는 더더욱 넓은 시야와 유연한 사고를 필요로 하기 때문이다. 사방에서 치고 들어오는 변수들에 일일이 스트레스받아서는 나만 힘들더라. 누군가 이야기했다. 모든 초안은 걸레라고.
아무튼 유저 플로우 그리다 킹 받으면 해피패스를 그려보자
끝.
