우리 팀은 매일 '항해일지'를 기록한다.
8월에 진행하기로 한 Cycle에서는 '많은 사람들에게 먹힐' 뭐 이런 거 빼고,
정말 우리가 필요한, 우리가 좋아서 만드는, 우리만의 Product를 빠르고 간단하게 만들어보기로 했다.
낙점된 것은 '항해일지'. 준의 제안으로 얼떨결에 시작했지만 모두 애용하고 있고 장점을 더 많이 느끼던 바였다.
항해일지는 우리 팀의 구글 공유드라이브에 있는 엑셀 파일로, 매일 본인이 학습하거나 일한 것들을 기록한다. 공유하고 싶은 자료는 링크를 걸기도 하고, 다른 사람의 칸에 낙서를 하기도 하고, 남은 어떤 공부를 하나 훔쳐보기도 한다. :) 엑셀 파일이라 가볍다는 장점이 있지만 각자 조금씩 불편한 점도 느끼고 있었던 차이기에, 우리끼리 만들어서 우리끼리 직접 사용해볼 수 있는 product를 만들겠다는 목표를 세웠다. 기간은 2주로 (평일 기준 10일), 기획 4일, 디자인 2일, 개발 4일의 일정이다.
pre-kickoff 회의에서 내가 'UX 디자인 7가지 비밀' 中 태스크 분석의 필요성과 이를 위한 card sorting 기법에 대해 소개하자, 한번 태스크 분석을 진행해보게 되었다.
이렇게 두 번 분류를 진행해보았는데 아직 태스크 분석에 대한 이해도 제대로 진행되지 않았고, 서비스 방향성에 대한 명확한 합의도 진행하지 않고 태스크 분석을 진행한 탓인지 뭔가 오묘한 혼란을 지울 수 없었다. pre-kickoff 라서 다행이다. 그날은 그렇게 마무리한 후 본격적인 kickoff 때는 스쿠버 그리고 산 이 기획회의를 고민해와서, (디자인씽킹 방법론들을 여러 개 고민한 모양인데 결국 너무 많은 툴들을 하자고 제시하지 않고 한 가지만 셀렉해왔다) value map과 customer profile의 관점에서 이야기를 나눴다.
'Customer Jobs(고객 활동)'에 들어갈 부분은 이미 그전날 진행되었던 Card Sorting에서 의견을 많이 냈었기 때문에 이를 바탕으로 Gains와 Pains에 집중해 포스트잇을 붙였다. 팀원들 5명 각각의 항해일지를 향한 관점들을 이해할 수 있었다.
'프로젝트의 성공적 달성'이라는 목표는 지나치게 모호할 뿐 아니라, 우리는 항해일지만 쓰는 게 아니라 슬랙도 쓰고, 카톡도 쓰고, 공유 드라이브도 있고, 만나서 오프라인으로도 다양한 소통을 한다. Customer Profile에 적힌 다양한 Gain Point, Pain Point들은 이런 우리 팀원들의 복합적인 바람/고민들이 섞여 있다. 그래서 '슬랙도, 카톡도 아닌 <항해일지>의 gain, pain들을 추리자', 'tool로 해결될 문제가 아닌 것은 거르자' 등 몇 가지 기준을 가지고 Gains/Pains를 정리했다. 연관/인과관계에 있는 요소들은 화살표로 정리하고 같은 색으로 분류해 메인 이슈들을 한눈에 알아볼 수 있도록 했다. 이렇게 정리한 후에는 '이 Gain(/Pain)을 강화(/해결)해 주기 위해서는 어떻게 하면 될까?'라는 질문을 던지면서 Value Map의 Creator(/Reliever)을 작성했다. 주요하게 대응되는 이슈와 같은 색으로 표시할 뿐 아니라, 여러 gain/pain을 동시에 강화시켜줄 수 있다면 화살표로 여러 개 연결했다. 우리가 만들고자 하는 Service가 고객의 다양한 Needs를 어떻게 충족시켜줄 수 있을지 보다 명확하게 정리할 수 있었다.
고객을 이해하고 우리 서비스의 방향성을 다함께 확인했으니, 이제 기능에 대한 이야기를 꺼내도 좋을 타이밍이 되었다. 바로 IA나 기능명세 단계로 넘어가기에는 혼란이 있을 것 같아서, User Needs와 Function을 연결할 Bridge가 필요할 것 같았다. 그래서 검색을 좀 했는데, 라이트브레인 블로그에서 참고할 만한 포맷을 발견했다. (http://blog.rightbrain.co.kr/?p=2465)
바로 이 사진.
서비스가 가지는 큰 기능 카테고리와, 사용자의 행위를 한 눈에 담을 수 있는 점이 마음에 들었다. 우리는 '기능 설계'를 위해서 '사용자의 태스크 플로우'를 연결짓고 정리할 필요가 있었기 때문이었다.
또, 설이 가져와준 포맷 (이름이 기억이 안 난다 ㅠㅠㅠ) 은 이 제품에 대해 이야기할 이슈들을 기재하고 수행 방안의 후보들을 표에 정리해 넣을 수 있다는 점이 좋아 보였다! 그래서 두 포맷을 합쳐서 우리를 위한 기획 포맷을 설계해보았다.
라이트브레인의 사진 + 설이 가져온 포맷을 합친 후, Task Analysis의 ver.2와 위의 value proposition map을 참고하면서 task flow 표를 만들어보았다. 요런 건 인터넷에 안 나와 있으니까 내 오리진이라고 해도 되겠지..? 내가 이름 붙여도 되겠지..?ㅋㅋㅋㅋㅋ 그럼 나는 'Task-Function Matching Map(태스크-기능 매칭 맵)'이라고 이름붙이겠다. 유저가 하는 '태스크'와 서비스가 제공하는 '기능Function'의 매칭을 확인하기 위해서 사용하는 포맷이기 때문이다. 우리처럼 태스크 분석을 먼저 진행하고 그 뒤에 이에 맞춰 기능을 설계하고자 할 때 사용하면 유용할 것 같다. 뿌듯.
(잠깐! 태스크와 기능이 뭐가 다른지 모르겠다면? 더 알아보기 ▼)
- 'UX 디자인 7가지 비밀' 中 (사서 보세요! 검색하면 저자분이 쓴 논문 있는데 거기서도 자세히 나옴! 나중에 추가할게요~)
사용자가 처음 사용하는 제품의 작동 방식을 예측할 때 도입하는 사전 경험이 바로 태스크 지식. 태스크를 분석해야만 우리의 사용자에게 특화된 인터랙션을 설계할 수 있고, 그래야만 비로소 구체적이며 특화된 인터페이스를 디자인할 수 있다. 또 특정 기능을 포함할 것인지 아닌지는 그 기능이 어떤 태스크를 수행하는 데 필요한 기능인지, 그 태스크는 다시 어떤 목적을 달성하는 데 필요한 태스크인지 고려해서 결정해야 한다. 이처럼 태스크 절차는 인터페이스의 기능구조, 정보 구조, 제어 흐름을 설계하는 근거가 된다.
목적 Goal : 사용자가 제품을 사용해서 달성하기 원하는 것
(사용자가 제품을 사용하는 이유에 해당) ex. 싼 가격으로 상품 구매하기
태스크 Task: 이 목적을 달성하기 위해서 사용자가 현실에서 수행하는 일
(상위에 있는 목적 달성을 위해 필요한 것) ex. 전단지에 실린 특가 상품 구매, 쿠폰 이용 가격 할인 받기
기능 Function: 사용자가 이 태스크를 수행하는 것을 돕기 위해서 제품이 제공하는 것
(ex) 장바구니. 쿠폰...
사용자 유형에 따라 달성하고자 하는 목적이 달라질 수 있어서 태스크를 분석할 때는 사용자 유형을 먼저 도출한다. 서비스 사용 방법에 있어 각기 다르게 특화시킬 만한 사용자 특성을 기반으로 도출해내고, 나눈 후 이 특성들을 적절하게 포함하는 대표적인 사용자 유형을 정의하는 것이 필요하다.
태스크 분석은 인터랙션 디자이너가 전문 사용자 수준으로 태스크를 잘 알 수 있게 도와준다. 인터랙션 디자인은 실제 상황에서 사용자가 태스크를 수행하는 과정을 관찰하는 것에서 시작되어야 한다.
태스크 분석 시 주의점: 제품에 종속되는 기능은 태스크 분석에 포함시키지 X. 제품으로부터 독립적인 태스크 수행 절차를 기술해야 함 > 설계자가 태스크를 기초로 다양한 설계 대안을 도출할 수 있게 하려는 것. ※ 벤치마킹은 제품의 ‘기능구조’밖에 알 수 없을 뿐, 어떤 태스크 구조로부터 도출된 것인지 전혀 알 수 없는 것이 벤치마킹의 한계. //벤치마킹이 도움이 안 될 수 있음
카드 소팅은 눈에 보이지 않는 문제의 구조를 드러낼 때 사용되는 유용한 도구이다. 그룹핑 작업을 반복적으로 수행해 드러나는 계층적 구조가 문제의 구조다. 상향식으로 목적을 도출하고, 하향식으로 생각하지 못했던 새로운 태스크들을 발견해나간다. 이를 통해 태스크 분석의 완전성Completeness를 달성시키는 게 카드 소팅의 힘이다.
태스크 지식을 바탕으로 태스크 시나리오를 작성하고, 이를 통해 설계 요구사항이 나오게 된다. 이것이 기능구조로 변환되게 된다.
Task-Function Matching Map은 '고객이 이 태스크를 수행할 때, 어떤 방법으로(Function) 수행하게 할까?'를 결정하기 위해 그 전 단계에서 만드는 것이다. 고객이 수행할 수 있어야 하는 태스크는 Value Proposition Map을 통해서 어느 정도 도출했고, 그 Task를 수행하는 데 사용할 수 있는 기능은 무수히 많은데, 그걸 동시에 기능부터 보려고 하면 혼란스럽기 때문에 이 포맷을 먼저 작성해서 고객의 숨은 Needs를 머릿속에 두고 Function을 결정할 수 있도록 했다.
Task-Function Matching Map 상세설명
1) 단계:
우리 서비스를 이용할 때 고객(우리)이 할 수 있어야 하는 태스크들을 카테고리로 분류했다. 영어로 썼을 때 더 명확한 느낌.
2) 고객의 행동(Task):
고객이 할 수 있어야 하는 Task이다. (Gain Creator/Pain reliever, Customer Jobs와 연계!)
3) 고객의 Needs:
이 Task를 수행할 때 고객은 어떤 Needs를 가지고 있었는지 염두에 두기 위해 기재한다. (Pain/Gain과 연관)
4) 기존 방법:
기존의 방법으로는 어떻게 수행할 수 있는지 표시한다. 우리 서비스가 어디서 차별점을 갖는지 확인할 수 있다.
5) 이야깃거리:
해당 Task를 수행가능한 Function을 제안할 때, 어떤 점을 고려해 제안하면 좋은지 기재한다.
6) 기능:
해당 Task를 수행하게 할 수 있는 Function의 가능성들을 구체적으로 제시한다. '리서치 분담'에 해당 기능을 맡은 사람을 기재해서, 빼먹은 Task 없이 기능 레퍼런스 조사가 될 수 있도록 한다. 벤치마킹할 레퍼런스를 조사한 후에 다함께 다양한 Function 후보들을 살펴보면서 최적의 기능 설계가 가능하도록 한다.
7) 구현 방안, 실행 방안:
Function이 실현가능한지에 대한 조사를 할 때 활용하도록 하는 칸이다.
8) 우리가 제공하고자 하는 가치:
적어도 되고 안 적어도 좋다. 일단 우리만의 차별점, 우리만의 가치에 대해 out of 안중 되지 않도록 만들기 위해 칸만 만들어놓았다.
다음 미팅(8/4 화)까지 각자 맡은 내용을 리서치해서 ‘방법(기능)’에 기입하기 (다른 팀원들이 잘 이해할 수 있도록 레퍼런스 잘 링크시켜두기) 로 했다! 이 map이 곧 User의 Needs를 반영한 설계 요구사항이니, 이제 회의를 통해 전체적인 기능을 설계하면 된다. '통일성 있는 서비스 설계'를 위한 방법이 있을지도 더 공부하면 좋을 것 같다. 화이팅 :>
'All Originals Are Special' 카테고리의 다른 글
| AOAS ep#4. 항해일지 리뉴얼 프로젝트, 멘땅에 헤딩! 우당탕탕 기획의 길 (0) | 2020.08.23 |
|---|---|
| AOAS ep#2. 첫 한 달의 기록: 앤젤핵AngelHack에 도전하다 (0) | 2020.07.23 |
| AOAS ep#1. 첫 한 달의 기록: 팀 빌딩부터 SKT 행복 인사이트까지 (0) | 2020.07.23 |
