멋진 프로덕트를 만든다는 것은 기존의 경험과는 완전히 다른 경험을 제공해주는 것이다. 에릭슈미츠는 기존과 비슷한 상품을 낼 것이라면 만드는 의미가 없다고 했다

If …..wasn’t going to be dramatically different and better and faster than the traditional…..on the market, there was no point in moving ahead.

• Eric Schmidt

하지만 완전히 다른경험을 제공해주는 것은 생각보다 굉장히 어려운 일이다. 왜냐하면 비슷한 유저의 문제를 풀다보면 비슷한 유저 경험, 비슷한 디자인이 나오는 경우가 많기 때문이다.

그렇다면 어떻게 하면 “완전히 다른” 경험을 주는 멋진 프로덕트를 만들 수 있을까?

내가 많은 시도와 실패를 통해 알게 된 것은 바로

유저에게 뼛 속까지 공감(Emphathize)

하는데서 시작해야한다는 것이다.

이 글을 쓰기 시작하며 “공감”의 어떤 측면에 대해 글을 쓸지 많은 고민을 했다. 유저에게 문제에 공감하기 위해 사람들이 고안해낸 많은 기법(Empathy map, Persona, User Journey map…)에 대해 소개를 할까? 아니면 유저 문제를 공감하는데 성공하여 멋진 프로덕트를 만들어낸 기업들의 사례를 소개할까? 아니면 한 가지 기법에 대해 내 경험을 소개할까? 여러 고민 끝에 나는 내가 직접 해보았던 것들 중 가장 도움이 되었던 몇 가지만 추려서 소개를 해봐야겠다는 생각이 들었다. 그래서 나에게 실제로 도움이 되었던 기법들을 세 가지 카테고리로 나누어 소개해 보고자 한다.

.…시작!

2. 유저에게 “공감”하기 위한 여러 방법 소개

1. 흐릿한 “문제”를 선명하게 만드는 툴

프로덕트를 디자인한다는 것은 “문제를 해결한다는 것”이다.

하지만 어떻게 해결할 지 말고도 일단 어떤 문제를 해결할 지를 명확히 정의하는 것은 생각보다 쉬운일이 아니다.

하지만 좋은 답은 좋은 질문으로부터 나온다고 했던가.

좋은 프로덕트를 만드는 것은 흐릿한 문제를 선명히 만드는 것부터 시작한다.

흐릿한 문제를 선명히 만들고 싶을때 다음과 같은 세 가지 툴이 유용했다.

• Problem Statement - 문제 요약 / User Interview - 유저인터뷰 / Empathy map - 공감맵

1-1 Problem Statement

가끔 살다보면 왜인지 모르게 머릿 속이 괜히 복잡할 때가 있다. 그럴 때 노트에 떠다니는 생각들을 글로 적어보면 갑자기 정리가 되곤 하는데 유저의 문제 또한 마찬가지였다.

나는 디자인의 시작을 문제 요약(Problem statement)를 적는 것으로 시작하는데, 문제가 모호할 때, 아니면 심지어 모호하지 않다고 생각하고 있을 때에도, 문제를 구체적으로 적어보는 것이 큰 도움이 되곤 한다.

Problem statement에는 다음과 같은 내용이 들어간다.

• ________ will help people who _________ by _________ unlike ________ who because we have _____
  • 프로덕트 - 제품명이나 제품 요약을 적는다
  • 타겟 유저 - 제품을 사용할 대상이 누구인지 적는다
  • 솔루션 - 어떻게 도와주는지 적는다.
  • 대표경쟁제품 - 대표적인 경쟁 제품에 대해 적는다
  • 불편점 - 경쟁제품(현재 시장)의 문제점을 적는다
  • 차별점 - 경쟁사의 제품에 비해 차별점을 적는다.
• 예시
  • react2app will help people who wants to make an app using react by providing the easiest 5 minute solution unlike capacitor who 어려운점 because we have 1.UX 2.DX 3.Design components

문제 정의를 명확하게 하는 것은 머릿 속에 둥둥 떠다니는 내 아이디어를 혼자서 간단하게 요약하는데 도움이 된다. 팀원들이나 다른 사람들에게 공유할 때 상당히 유용한 아마존의 PRFAQ라는 기법도 있는데 이 기법은 기회가 되면 다른 글에서 소개하겠다.

1-2 User Interview

또 흐릿한 문제를 선명하게 만드는 또 한 가지 방법은 그 대상에게 문제가 무엇인지 직접 물어보는 것이다. 만약 자신의 문제라면 머릿 속으로 생각하면 되겠지만, 만약 “있을 거”라고 생각하는 문제의 경우, 유저 인터뷰를 하는 것은 문제를 명확히 정의하는데 많은 도움이 된다.

사실 유저 인터뷰는 프로덕트를 막 만들기 시작했거나, 만들었거나, 만들어서 운영하고 있거나 그 단계에 상관없이 중요한 업무이다. 유저로부터 원하는 대답을 얻기란 꽤 어려운 일이고, 게다가 그 대답이 질문자의 실수로 인해 답변 내용이 오염되기도 쉬움으로 유저인터뷰를 할 때는 여러가지를 조심해야한다.

인터뷰를 할때 흔히 하는 실수는 다음과 같다.

- 내 아이디어에 대해서 얘기한다.
    - ⇒ 안된다! 유저의 문제로부터 유용한 정보를 추출하는게 인터뷰의 목표다.
- 가정을 얘기한다. 만약 A 만들면 좋을까요?
    - ⇒ 안된다! 실제 유저 삶의 문제를 이해해야한다.
- 듣지 않고 얘기한다.
    - ⇒ 안된다! 유저의 삶과 얘기를 들어야 한다.

<div class="notion-empty-line" aria-hidden="true"></div>

좋은 질문은 다음과 같다.

- X를 하는데 가장 어려운 것은 무엇이었나요?
    - ⇒ 좋다! 나로부터가 아닌 유저의 삶,문제로부터 시작한다.
- 마지막으로 문제를 겪은게 언제인가요?
    - ⇒ 좋다!  “진짜 삶의” 문제를 추출하는데 도움이 된다
- 왜 그게 어려웠나요?
    - ⇒ 좋다!  정확한 문제점(페인포인트)를 알 수 있고 마케팅 포인트 또한 알 수 있다.
- 그 문제를 해결하기 위해 무엇을 해보았나요?
    - ⇒ 좋다! 경쟁사와 비교우위를 알 수 있다
- 해봤는데 왜 별로였나요?
    - ⇒ 좋다! 어떤 기능을 만들어야하는지 힌트를 알 수 있다.

1-3 Empathy map

사실 내가 empathy map 을 처음에 접했을때는 별로 실용적이지 않은 쓸 데 없는 툴이라고 생각했었다. 하지만 이런 생각을 바꾸게 해준 계기가 한번 있었는데, 그것은 대학교에서 인턴하던 시절 대학교 내부에서 쓰이는 프로그램을 디자인할 때였다. 당시 IT를 잘 모르는 나이가 조금 있으신 교수분을 인터뷰하면서 요구하시는 것, 말하시는 것, 생각하시는 것이 상당히 달라서 애를 먹었었는데, 이 툴을 이용하니 인터뷰 내용을 분석하는데 상당히 유용하다는 사실을 깨달을 수 있었다.

유저가 불편하다고 하는 것, 그리고 만들어 달라고 하는 것, 그리고 진짜로 만들어지기 원하는 것은 차이가 있음으로 이를 조심히 분석하여 올바른 결론을 도출하는 것은 굉장히 중요하다. 그런면에서 empathy map은 한 사용자를 여러측면(보는것, 말하는것, 하는 것, 듣는 것, 생각하는 것)을 나누어 볼 수 있도록 도와주는 유용한 툴이다.

2. 유저의 진짜 “고민”을 알아내는 툴

2-1 Persona

페르소나(Persona)는 사용자 경험(User Experience, UX) 디자인에서 중요한 개념이다. 페르소나는 제품 또는 서비스의 대상 사용자를 대표하는 가상의 인물이다. 예를 들어, react2app을 사용하는 개발자를 김민수, 25세 개발자이면서 창업가, 대학생을 졸업하고 바로 창업을 했으며….. 이런식으로 굉장히 구체적으로 설정하는 것이다. 이렇게 구체적으로 설정된 이 인물은 실제 사용자 그룹의 특성, 필요, 목표 등을 대표하게 된다. 페르소나를 만들 때에는 유저 인터뷰, 유저 리서치를 통해 얻은 데이터를 기반으로 사용자 그룹을 대표하는 가상의 인물을 만들어내는데, 이는 디자이너나 개발자가 제품을 디자인하거나 개발할 때 사용자의 관점에서 생각할 수 있도록 도와준다. 페르소나는 사용자를 더 잘 이해하고 사용자 중심의 제품 또는 서비스를 만드는 데 도움을 준다.

페르소나는 활용하는게 중요한게 아니라 “제대로” 활용하는게 중요하다. 나느 디자이너 채용플랫폼을 운영하던 시절, 신입 디자이너의 포트폴리오를 종종 보게되는 기회가 많았는데, 유저 페르소나를 정말 형식적으로 “예쁘고 그럴듯하게”만 정의해놓은 포트폴리오가 많았다. 구체적으로 페르소나를 설정하는 것은 중요하다. 하지만 “어설프고 간략”하더라도 정말 본질적으로 이 프로덕트가 “필요한” 사람을 핀포인트 해내는 것이 페르소나를 사용하는 것의 본질이다. 이 페르소나는 우선순위를 설정하거나, 기능을 추가하거나 참고하게 되는 인물상이므로, 소설 쓰듯이 구체적으로 예쁘게 쓰는 것 보다는 “우리 프로덕트는 누가 쓸까?”, “이 사람이라면 현실에서 어떤 문제를 가지고 있을까?” 와 같이 본질적인 부분을 생각하는 것이 페르소나의 핵심이라고 할 수 있겠다.

2-2 User Story

유저 스토리(User Story)는 개발과 UX에서 사용되는 개념으로, 유저의 요구사항을 이해하고 문서화하는 방법 중 하나이다. 유저 스토리는 간단하고 구체적인 형식으로 유저가 원하는 것을 설명하며, 주로 애자일(Agile) 개발 방법론에서 사용된다.

일반적으로 유저 스토리는 다음과 같은 형식을 가지고 있다:

"As a [유저 역할], I want to [원하는 행동], so that [원하는 목적]."

여기서,

• [유저 역할]은 프로덕트를 사용하는 유저 그룹을 나타낸다.
• [원하는 행동]은 유저가 하려고 하는 작업이나 기능을 설명한다
• [원하는 목적]은 유저가 그 행동을 왜 원하는지, 어떤 가치나 이점을 기대하는지를 설명한다.

이 형식을 통해 개발팀은 사용자의 요구사항을 명확하게 이해하고, 이를 바탕으로 제품이나 서비스를 개발할 수 있다. 유저 스토리는 사용자 중심의 개발과 디자인을 촉진하며, 개발자, 디자이너, 고객 및 다른 이해관계자 간의 의사소통을 원활하게 한다.

하지만 유저 스토리가 돕는 것은 사람들의 의사 소통뿐만이 아니다. 내 경험상 유저스토리는 제품 또는 서비스를 만들 때 유저의 관점에서 생각하면서 기능들을 구체화하는데도 굉장히 큰 도움이 되었다. 사실 아이디어 단계에서는 항상 모든 기능이 계획되어 있는 경우는 흔치 않다. 그것보다는 “어? 이걸 편하게 만들 수 있겠는데?” “이러면 좋겠는데?” 이런 대략적인 아이디어만 있는 경우가 많다. 이럴 때 유저스토리를 활용해나가면서 “누구는 무엇을 하기위해서, 무엇을 하고싶다” 이런 형태로 기능들을 하나씩 정리하다보면 막연했던 아이디어가 구체화되는 데 많은 도움이 된다.

3. 유저의 “상황”을 깊이 이해하는 툴

3-1 User Journey map

이거….진짜 힘숨찐이다. 사용자 여정지도(User Journey Map)는 사용자가 제품 또는 서비스를 경험하는 과정을 시각적으로 나타낸 도구이다. 이 사용자가 제품 또는 서비스를 처음 접하는 순간부터 마지막까지의 여정을 이해하고 문제점을 파악하는 데 도움이 된다.

사용자 여정지도는 사용자가 제품 또는 서비스를 사용하는 과정을 시간순으로 나타내며, 사용자의 경험을 여러 단계로 분해하여 각 단계에서 사용자가 마주치는 감정, 행동, 요구사항 등을 기록한다. 이를 통해 유저의 관점에서 제품 또는 서비스를 분석하고, 사용자 경험을 개선할 수 있는 방안을 찾을 수 있다.

사용자 여정지도는 주로 다음과 같은 요소로 구성된다.

1. 여정 단계(Stages of Journey): 사용자 여정을 나타내는 단계로, 예를 들어 '인식', '탐색', '구매', '사용', '유지보수' 등이 있다.
2. 사용자 행동(User Actions): 사용자가 각 단계에서 취하는 행동을 설명한다.
3. 사용자 감정(User Emotions): 사용자가 각 단계에서 느끼는 감정을 표현한다.
4. 기타 요소(Additional Elements): 필요에 따라 사용자의 목표, 특이사항, 문제점 등을 추가로 기록한다.

이를 통해 제품 또는 서비스를 개발하거나 개선할 때, 사용자의 경험을 고려한 디자인 및 개발 결정을 내릴 수 있음은 물론 마케팅, UX, 개발 우선순위 정할 때도 도움이 된다.

사용자 여정지도를 실제로 작성하려면 많은 요소들이 있어 부담이 된다고 생각될 수 있다. 하지만 실전에서는 “단계”를 기록해보는 것만해도 유저를 깊게 이해하는데 많은 도움이 된다. 가령 카카오톡을 만든다고 해보자. 유저의 여정을 고려하지 않고서는 아마 “회원가입”이 첫단계라고 생각할 수도 있다. 하지만 유저 저니맵을 그려보면 회원가입 이전에도 여러 절차가 있다는 것을 깨달을 수 있다. 유저가 어디에서 어떻게 카카오톡을 알게 될 계기(인터넷 광고, 친구 소개 등)에 대해 생각해 볼 수도 있고, 그렇게 알게 된 후 해 볼 행동(네이버에 검색을 해본다, 나무위키를 찾아본다, 앱스토어에서 다운받는다 등)을 생각해 볼 수도 있다. 이처럼 “회원가입” 이 전에도 유저는 은근히 많은 행동들이 필요하며 그 행동때마다 특정 감정을 느끼게 되는데 UX를 위해서는 이 단계 또한 고려를 해서 좋은 경험을 설계할 줄 알아야한다. 그리고 그 숨은 단계들을 파악하고 경험을 설계하는데 사용자 여정지도는 많은 도움이 된다.

3-2 경쟁사 분석 competitive audits

내 생각, 내”프로덕트를 분석을 마쳤다면 그 다음은 “경쟁사”에 대해 분석을 해야한다. 경쟁사 분석은 시장과 경쟁사에 대한 데이터를 수집하여 UX 결정과 UX 전략 수립에 도움을 주는 방법 중 하나이다. 경쟁사 분석을 통해 우리는 경쟁사의 제품, 대상 고객, 가격 정책, 마케팅 전략 등을 파악하고 그들에 비해 경쟁 우위를 확보하는 디자인을 설계할 수 있다.

하지만 우리가 비지니스 리서치를 하는 것도 아니고 “남다른” 유저 경험을 설계하는데 왜 경쟁사 분석이 필요한 것일까? 그것은 바로 우리가 알아야할 것이 “우리 서비스 내에서만의 사용성” 이 아닌 “유저들의 삶 속에서의 사용성”을 디자인해야하기 때문이다. 우리가 그 어떤 좋은 아이디어를 생각했든지간에 대부분의 분야에는 그 문제 또는 비슷한 문제를 풀기 위해 노력한 경쟁자가 있기 마련이다. 그들이 문제를 기가막히게 풀어놨을 수도 있고 아예 너무 허접하게 문제를 풀었을 수도 있다 (우리는 그걸 못 풀었다고 하기로 했어요!). 이들의 서비스들은 이미 유저들의 삶 속에 포함되어있다. 사용하고 있지 않더라도 유저들이 문제를 해결하기 위해 사용할 수 있는 대안이 있다는 점이 핵심이다. 따라서 가상이 아닌 “실제” 유저들의 행동을 이해하기 위해서는 현재 대안(경쟁 서비스)이 무엇인지를 파악해놓는 것이 중요하다.

경쟁 분석은 직접적인 조사와 간접적인 조사로 나눠지는데 경쟁 분석을 위한 절차는 아래와 같다.

1. 분석 목표 설정
2. 데이터 수집
3. 강점과 약점 파악
4. 시장과 대상 고객 분석
5. 제품의 차별화 요소 결정
6. 실행 계획 수립
7. 정기적인 검토 및 업데이트

사실 이 하나하나를 모두 해야하는 것은 아니다. 그냥 일반적으로 우리가 앱이나 웹쇼핑몰을 쓸 때 “뭐가 쿠폰을 많이주더라” “뭐는 필터가 불편하더라” 처럼 “일반인”의 관점에서 보는 것도 좋다. 구체적으로 어떻게 경쟁사 분석을 하냐보다 더 중요한 것은 유저가 가진 문제를 지금 다른 사람들은 어떻게 해결을 하고 있고, 유저들이 이에 대해서 어떻게 느끼는지?를 알아내는게 핵심이고 경쟁사분석은 이를 도와준다

결론

이번 글에서는 아이디어를 바탕으로 UX를 설계할 때 사용할 수 있는 여러가지 디자인 기법에 대해서 알아봤다.

글의 서두에서 잠깐 언급했듯이 유저에게 완전히 다른경험을 제공해주는 것은 생각보다 굉장히 어려운 일이다. 왜냐하면 상상과 다르게 현실 세계에서 프로덕트를 만든다는 것은 항상 시간적인 제약, 개발적인 제약, 비용적인 제약 등 여러 제약이 뒤따르기 때문이다.(마치 “머릿속”과 “현실세계”는 런타임이 달라 아웃풋도 다르달까…?ㅎ) 그렇게 여러 제약을 뚫고 프로덕트를 만들어도 막상 결과를 보면 다른 곳과 비슷한 디자인이 되는 경우도 많고 유저들은 “A(경쟁사)와 뭐가 달라요?” 라고 묻기 십상이다.

그렇다면 이런 여러 제약 속에서 어떻게 하면 “완전히 다른” 경험을 주는 멋진 프로덕트를 만들 수 있을까?

내가 여러 시도와 경험을 통해 조금이나마 알아낸 팁은 바로 유저에게 “뼛속까지 공감”하는 것이다. 유저가 “와” 하는 프로덕트를 만들기 위해서는 유저는 어떤 삶을 살고 있는지, 유저는 어떤 문제를 가지고 있는지, 유저는 어떤 여정을 거쳐서 우리 프로덕트에 도달하게 되고 어떤 감정을 느끼는지, 지금 문제를 해결하기위해서 다른 대안들은 어떤 것들이 있는지 등등을 속속들이 파악해야 한다. 그렇게 파악한 유저들의 정보를 바탕으로 “이렇게 하면 편할까?” “저렇게 하면 편할까?” 하는 가설들을 세워 검증을 해나가면서 프로덕트를 만들어나가며 조금씩 앞으로 나가야, 그제서야 “완전히 다른” 아니면 “완전히”는 아니어도 유저가 정말 좋아하는 “멋진 프로덕트” 에 조금이나마 가까워지는 것 같다.

프로덕트 너란놈… 참 어려운 놈이구나.

끝.