퍼소나의 디테일이 중요한 이유

이 글은 제가 발제한 글에 대해서 사내메일 상으로 토론한 내용을 정리한 것입니다. 발제글에는 편의상 경어를 생략했으니 양해바랍니다 :)

발제글

퍼소나의 디테일이 중요한 이유

2010년 마이크로소프트(이하 MS)의 윈도우7 팀은 퍼소나를 포기했다고 한다. 앨런쿠퍼의 정신병원에서 뛰쳐나온 디자인(The Inmates Are Running the Asylum)책의 출간이후 2000년 초기 MS의 사무실 벽마다 퍼소나가 붙어있던 것에 비하면 상전벽해 같은 일이다.

퍼소나를 포기한 이유는 어차피 디테일하게 퍼소나를 만들어봤자 아무도 안 보기 때문이라고.
심지어 37signals 같이 퍼소나가 필요없다는 의견을 주장하는 곳도 있다. 자기들의 문제를 해결하는데 퍼소나가 왜 필요하냐는 것이다.

그러나 이런 안티퍼소나 입장을 취하는 의견이나 태도들은 사실 퍼소나를 제대로 이해하지 못하기 때문에 발생한다고 본다.
퍼소나는 커뮤니케이션 도구이기도 하지만 추론도구이기도 하며, 디자이너에게는 이 추론도구로서의 역할이 더 중요하다.

추론도구로서의 퍼소나

Cooper사의 인터랙션 디자이너인 Chris Noessel이 퍼소나가 통하는 또 다른 이유에 대해 글을 썼는데, 내 나름대로 편역 및 요약하자면 이런 내용이다.

철학자 Daniel Dennett에 따르면, 인간은 추론(reasoning)을 할 때 다음 3가지 스탠스 중 하나의 스탠스를 취한다.

1. 물질적(Physical) 스탠스 - 내가 이 모래를 불 위에 끼얹으면 어떻게 될까? 와 같이 기본적인 물질적 감각을 사용하여 일이 어떻게 일어날지에 대한 짐작
2. 디자인(Design) 스탠스 - 새의 날개는 새가 날 수 있도록 만들어진건데, 그럼 저 새가 날개를 펄럭이면 어떻게 될까? 와 같이 사물이 만들어진 용도, 기능, 디자인에 대한 이해를 바탕으로 짐작
3. 의도적(Intentional) 스탠스 - 나를 쫓고있는 저 호랑이는 내가 저 동굴 안으로 몸을 피하면 어떻게 행동할까? 와 같이 의도를 가진 생물(intentional agent)이 원하는 결과를 얻기위해 무슨 의도로, 어떻게 행동을 바꿀지에 대한 짐작

그럼 이것들 중 인터랙션 디자인에 적합한 추론방식은 무엇일까.
우선 사용자의 행동을 물질적으로 규정하는 일은 없으므로 물질적 스탠스는 맞지 않다.
다음으로, 디자인 스탠스는 바이메탈의 물질적 동작원리는 모르더라도 바이메탈이 특정 온도에서 휘는 기능(function)에 대한 이해를 바탕으로 그것을 온도계로도, 전기다리미의 부품으로도 쓸 수 있게 한다. 하지만 이렇게 기능에 따라 입맛에 맞게 바꾸는 특징은 인터랙션 디자인에서는 elastic user문제를 낳는다. ‘사용자’라는 특정 기능을 가진 존재가 이럴 땐 이렇게 행동하고 저럴 땐 저렇게 행동할 것이라고 입맛에 맞게 추론해버리기 때문이다. 이처럼 디자인 스탠스는 대부분의 사람들이 디자인을 할 때 취하는 기본적인 스탠스지만 틀린 방식이다.
따라서 인터랙션 디자인을 할 때는 End Goal - 잘 변하지 않는 사용자의 목표 - 을 이루기 위해 사용자가 어떻게 행동을 할지 그 의도를 추론하기에 적합한 의도적 스탠스를 취해야 한다.

3가지 스탠스가 철학적 관점으로도 충분히 납득가능 하지만, 실제로 Glasgow Caledonian University와 MIT의 공동연구 결과에 따르면 각 스탠스에 따라 추론을 할 때 뇌의 각기 다른 부분을 사용한다고 한다.

출처 : http://www.lrdc.pitt.edu/

당신은 디자인을할 때 어떤 스탠스를 취하고 있는가?

이 중 이슈가 되는 2가지 스탠스를 내 방식대로 설명해보면 이렇다.

• Design stance - 이성적 이해
• Intentional stance - 감성적 공감

디자인 스탠스는 추론대상의 용도, 기능, 디자인에 대한 이해를 바탕으로 그 대상을 이성적이고 논리적으로 분석하고 그에 따라 추측을 한다. 반면, 의도적 스탠스는 대상을 의도를 지닌 생물(intentional agent)로 여기고 ‘이런 의도를 가지고 있는 저 대상은 어떻게 행동할까’라는 공감에 기반한 감성적 추론을 한다.

여기서 중요한 점은 의도적 스탠스를 취하기 위해서는 추론의 대상이 의도를 지닌 생물로 여겨질 수 있도록 충분히 실제적이어야 한다는 것이다. 충분하지 못하면 감성적 공감을 할 수 없다. 예를 들어 불릿(Bullet)으로만 구성된 퍼소나는 대상을 무형의 논리적 존재로 인식하게 만들며, 심지어 ‘식스팩 조’같은 별명을 붙인 퍼소나는 대상을 실제 세상에 없는 존재로 인식하게 해, 결국 디자인 스탠스에 갖혀 추론을 하게 만든다. 따라서 이러한 함정을 피해 퍼소나가 실제 사람처럼 느껴지도록 하려면 디테일을 충분히 채워야만 한다.

그럼 디테일을 충분히 채우는 방법은 무엇인가? 바로 내러티브(Narrative)이다. 좋은 스토리텔링은 퍼소나에 새 생명을 불어넣어 살아숨쉬는 실제 사람처럼 느껴지도록 만들어준다. 이해를 돕기위해 다음 2가지 버전의 퍼소나 예시를 보자. 첫 번째는 불릿(Bullet)으로만 구성된 퍼소나이고 두 번째는 내러티브(Narrative)가 가미된 퍼소나이다. 어떤 버전에서 해당 퍼소나가 충분히 실제적인 사람으로 느껴지는지 그리고 감정적으로 공감이 가는지 스스로 생각해보기 바란다.

*아래의 퍼소나 예시는 <인간중심UX 디자인> 11장에 나온 퍼소나 예시를 조금씩 고친 것임을 밝힌다.

에밀리 모티머 (불릿버전)
- 34세
- 그래픽 디자이너
- 캘리포니아 거주
- 이전 자동차: 혼다 시빅 하이브리드 모델
- 컴퓨터: Mac
- 웹사이트 영향: 아마존
- 쇼핑 이유: 현재 소유 중인 차의 할부기간이 끝나서

현재 소유중인 자동차: 2010 미니쿠퍼
- 좋은 점: 좋은 연비, 트렁크 공간, 좁은 데에서도 주차하기 쉬움
- 함께 고려했던 차종: 포드 포커스, 폭스바겐 비틀
- 비용 지불기간: 2년
- 언제부터 보아왔는지: 영화에서 보고 나서 부터
…(중략)…

목적
- 자동차를 원하는 이유가 분명해야 한다.
- 바로 차를 받고 싶다.
- 차를 구입하는 과정 자체를 즐길 수 있어야 한다.
- 구입 후에도 지속적인 서포팅을 받고 싶다.

에밀리 모티머 (내러티브 버전)
34살의 에밀리 모티머는 2주 안에 새 차를 구매하려고 한다. 2010년 첫 번째 차(혼다 시빅 하이브리드 모델)의 비용을 다 갚은지 얼마되지 않아, 영화 <이탈리안 잡>을 VOD로 보고 나서 미니쿠퍼의 활력넘치는 디자인의 매력에 빠져버렸다. 한 주가 지나고 캘리포니아를 차를 타고 돌아다니면서 에밀리는 자신이 길에서 만난 모든 미니 들을 동경하고 있음을 깨달았다.
에밀리는 배너광고 작업을 한 뒤 점심시간을 이용해, 평소 읽던 메트로폴리스 잡지대신 미니쿠퍼 웹 사이트를 확인하기로 마음먹었다. 미니쿠퍼 사이트의 분위기는 그녀가 계속 사이트를 탐색하게끔 부추겼다. 구매를 위한 조사를 한다기 보다는 마치 놀러다니는 듯한 느낌이었다. 에밀리는 마음이 끌리는 모델을 구입하는 것이 합리적 구매가 될 수 있는 이유들을 찾기 시작했다. 그 모델은 충분히 작아서 도시 주차가 쉬웠고, 트렁크가 넓어서 여러 쇼핑백들을 넣기에도 충분했고, 좋은 연비를 가지고 있어서 하이브리드를 구매하지 않는 것에 대해 가책을 느끼지 않아도 되었다.
…(중략)…
구입 몇 달 후, 에밀리는 언제 자동차 정비를 해야할지 의문이 들었다. 그래서 미니쿠퍼 제조사 사이트의 오너(Owner) 섹션에 로그인했지만 매우 실망했다. 차에대한 모든 정보를 입력했음에도 어떤 서비스가 제공되는지 언제 정비를 해야할지 아무런 정보를 제공하지 않았기 때문이다. 그 후 그 사이트에 다시 접속하지 않았다.
미니쿠퍼가 좋기는 하지만 비용도 지불이 다되었고, 에밀리의 관심은 다시 다른데로 쏠리고 있다.

에밀리의 목적
- 자동차를 원하는 이유가 분명해야 한다. 그녀의 선택이 해당 모델의 스타일이나 감성적인 매력에 끌렸기 때문이더라도 에밀리는 스스로 합리적인 사람이라고 느끼고 싶다. 
- 바로 차를 받고 싶다. 그녀는 새 차를 구매할 준비가 되면 바로 행동을 취하고 싶어한다.
- 차를 구입하는 과정 자체를 즐길 수 있어야 한다. 자동차 쇼핑은 재밌어야 한다. 일이 아니다. 새로운 자동차는 그녀에게 특별한 선물이다.
- 구입 후에도 지속적인 서포팅을 받고 싶다. 오너(Owner)에 대한 미미한 지원은 제품의 이미지와 경험을 떨어뜨린다.

실제로 에밀리 모티머를 위한 웹사이트를 디자인한다고 가정해보자. 다양한 솔루션을 발상하는 것도, 여러 솔루션 중 선택을 하는 것도 모두 에밀리 모티머는 이렇게 행동할/판단할/생각할/좋아할 거야 라는 추론에 근거하여 결정해야 한다. 그렇다면 어떤 버전의 퍼소나가 이러한 추론과정에 적합하겠는가? 

위의 예에서 알 수 있듯이, 불릿으로 된 퍼소나는 이성적이고 논리적인 이해를 하는 디자인 스탠스로 추론을 하게 하며 디테일을 갖춘 퍼소나는 감성적 공감을 통해 퍼소나의 머리 속을 들여다보고 의도적 스탠스로 추론을 할 수 있도록 돕는다. 퍼소나의 디테일이 중요한 이유가 바로 여기에 있다.


디테일은 잘못이 없다

앞서 MS에서 퍼소나의 디테일을 포기한 것에 대해 해당 아티클에서는 ‘Abby가 Soccer mom이라는 사실은 윈도우 비스타의 검색기능을 만드는데 아무런 쓸모가 없다’라고 얘기한다. 이건 디테일의 문제를 논하기 전에 자신들이 퍼소나를 제대로 만들고 있는지 부터 되돌아 봐야할 문제다.

퍼소나의 디테일이 중요하다는 것은 해당 프로젝트 도메인과 관련이 없는 픽션을 마구잡이로 넣어도 좋다는 얘기가 아니다. 퍼소나가 해당 도메인에서 과업을 수행하는데 행동에 영향을 미치는 것들을 다분히 의도적으로 내러티브를 살려서 넣어야 하는 것이다. Soccer mom이라는 디테일은 자녀와 자신의 일정을 함께 관리해주는 일정관리 어플과 같은 도메인에서나 의미가 있을 것이다. 그런 디테일을 아무렇게나 채워넣는다고 알아서 의도적 스탠스로 추론이 될 것이라고 생각했다면 그렇게 퍼소나를 만든 디자이너가 정말 우스운 풋내기였다라고 할 수 밖에 없다. (아마 개발자들이 퍼소나의 디테일을 무시하게 된 것도 이런 쓸모없는 디테일들 때문일지도 모르겠다.)

그리고 37signals가 퍼소나를 쓰지 않아도 잘나가는 이유는 간단하다. 자기 자신이 퍼소나이기 때문이다. 솔루션을 발상할 때는 자신을 되돌아 보면된다. 자기 자신은 실제 사람이기 때문에 의도적 스탠스를 취해서 추론을 한다. 너무나 당연한 이치이다. 그런데도 해당 아티클에서는 Persona don’t vs People do라는 도발적인 비교를 하고 있는데 이 또한 퍼소나에 대한 몰지각에서 오는 반응이 아닐까.

퍼소나의 디테일은 퍼소나를 제대로 사용할 줄 아는 자에게만 의미를 부여한다. 당신은 어떤 사람인가?

jun.ee

제 개인 블로그에 생각을 정리해본 글인데, 다른 분들의 의견을 듣고 싶어서 공유합니다.

비판, 지적 모두 환영합니다. 무엇보다 어떻게 생각하시는지 그게 젤 궁금하네요.

Aiden Park
퍼소나의 디테일이 중요하다는 점에는 원론적으로 동의하고요.

다만, jun.ee님의 글을 보면 퍼소나를 불릿 버젼 vs. 내러티브 버젼으로 구분하고 상대적으로 내러티브 버젼이 디테일을 가지고 있기 때문에 추론 도구로써 적합하다는 글의 흐름인데, 이 부분에 있어서는 디테일을 어떻게 채우고 표현하느냐, 퍼소나를 어떤 목적으로 활용할 것이냐에 따라 여러가지 접근이 가능하다고 봐요.

실제로 프로젝트에서 퍼소나를 사용하다 보면, 개인적으론 내러티브 형태의 퍼소나를 잘 사용하지 않습니다. 왜냐하면 클라이언트가 보기에 핵심 포인트가 잘 보이지 않기 때문이죠.

그렇다고 내러티브 없이 만들지는 않습니다. 단지 내러티브를 부각하여 강조하지 않을 뿐이죠. 때론 내러티브를 강조하는 프로젝트도 있고요.

그때그때 상황에 맞게, 퍼소나의 목적에 따라 정보를 시각적으로 표현하기도 하고 비교할 수 있는 표를 만들기도 하고 시나리오를 만들기도 합니다.

이렇게 한다고 해서 이 퍼소나가 내러티브가 없다고 생각되지는 않습니다.

그리고 퍼소나 활용 측면에서 보아도, 퍼소나의 디테일은 여러가지 관점에서 접근할 수 있습니다.

새로운 기능에 대한 가치판단 관점이냐, 타겟을 명확하게 하는 타겟 비교와 분리의 관점이냐, 프리젠테이션의 관점이냐 등등에 따라 퍼소나의 디테일은 다양할 수 있고, 여러 데이터와 컨텍스트로 채워질 수 있죠. 표현방식도 달라질 수 있고요.

추가로 전성진님이 예전에 HCI학회에서 발표하신 '퍼소나 활용하기' 를 참고하시면 좋을것 같습니다.

다시 퍼소나의 근본으로 올라가보면, 결국 디테일의 시작은 C.C(Critical Characteristics)라고 생각해요.

C.C를 제대로 뽑을 수 있다면, 그 각각의 C.C에 많은 디테일이 담겨 있죠. (C.C 구성에 대한 것은 또 다른 주제이니 여기선 논외로 하고요.)

결국 잘못되거나 부족한 C.C를 뽑아서, 스테레오 타입의 퍼소나를 만들게 되고, 억지로거나 뻔한 디테일을 채우다 보니 퍼소나에 공감을 하지 못하고 퍼소나가 필요없다는 식의 이야기가 나오는 것이라고 생각하고요.

Lean UX에서의 프로토퍼소나 역시, 수행하는 사람이 얼마나 숙련되게 C.C를 빠른 시간에 도출할 수 있냐가 매우 중요하다고 봅니다.

mango01

저도 앞의 의견에 동의합니다.
불릿이냐 내러티브냐.

만들어진 퍼소나를 어떻게 전달하냐에 대한 이야기 인것 같습니다.

물론 이런 부분도 의미는 있겠지만, 중요한 것은 얼마나 핵심을 짚은 퍼소나를 만들었는가.

즉, C.C를 제대로 뽑았고 모델링 했냐가 관건이라고 생각합니다.

명확히 핵심을 짚었다면, 제 경험상 단 한 두단어로도(퍼소나 이름만으로도) 관련자들의 공감을 불러일으킵니다.

긴 설명은 필요 없겠지요.

이 재용

퍼소나는 불릿보다 더 강력할 것이다. (이 때 불릿은, 불릿형 퍼소나가 아니라, 불릿형 기능 요구 사항)는 연구가 있었습니다.

만약 ‘공감’이 중요한 부분이라면, 디자이너는 사용자 요구사항(불릿)만 보고 디자인 했을 때, 공감을 덜 할 것이고, 잘 만들어진 퍼소나를 보면 공감을 잘 할 것이다. 따라서 잘 만들어진 퍼소나를 보고 디자인했을 때 더 좋은 결과가 나올 것이다.

연구 결과는? 안타깝게도 상황에 따라 다르더라… 연구 결과 자체를 100% 믿을 순 없지만, 하여간 이러한 추리를 해 보는 건 의미있다고 봅니다. 제가 만약 학자(교수)였다면 그런 연구를 많이 해 보고 싶었어요.

 

http://www.slideshare.net/arangyi/persona-3323174

여기 38페이지 보시면 나옵니다.

jun.ee

논문을 읽어봤는데, 솔직히 실험설계가 형편없는 수준 같습니다.

우선, User Requirement와 Persona를 직접비교를 하는 것은 말이 안된다고 봅니다.

알고 계시다시피, 목적지향 디자인의 프로세스는

퍼소나 도출 -> 솔루션 발상 -> 컨텍스트 시나리오 도출 -> 시나리오 기반 요구사항 도출 -> 프레임워크 디자인

과 같은 순서로 진행됩니다.

따라서 요구사항은 퍼소나를 기반으로 나오는 결과물이지, 퍼소나와 그대로 비교할 동등관계가 아닙니다.

또한 요구사항이 (제대로만) 주어져 있으면 당연히 요구사항 그대로 디자인하면 되지만, 퍼소나만 가지고 디자인하려면 발상단계를 추가로 거쳐야하니 직접비교를 하는 건 말이 안된다고 봅니다.

만일 실험의 퍼소나는 요구사항을 내러티브 형태로 삽입했기 때문에 비교할 수 있다고 한다면, 그건 퍼소나가 이미 아니므로 틀린 실험설계라고 답할 수 있겠네요. 퍼소나는 요구사항을 풀어서 설명하는게 아니라, 리서치를 통해 발견된 행동패턴을 묶어서 유형화 한 것 이니까요.

그리고 저수준 공감 퍼소나의 예시를 보니 더 실험이 엉망처럼 보이는데요.

하이브리드 자동차 구매자를 타겟으로 하는 서비스에서, 저수준 공감 퍼소나를 만들기 위해 디스크립션을 일부러 '싫어하는 동료들이 최근에 도요타 하이브리드를 구매했기 때문에 프랭크(주인공)는 하이브리드 기술에 대해 편향된 시각을 가지고 있다' 라고 만들었다라는 부분에서 실험의 신뢰도가 팍팍 떨어지네요.

마지막으로, 실험이 Memory vs Empathy가 포커스가 되어서 참가자들에게 요구사항과 퍼소나를 1~3분만 보여줬다는 것도 현실과는 너무 동떨어진 것 같고요.

제가 실험설계를 한다면, 불릿형 퍼소나 vs 내러티브형 퍼소나 각각을 가지고 솔루션 발상을 하게 하되 fMRI를 이용해서 두뇌의 어느 쪽을 사용하는지를 측정할 것 같습니다.

제 발제글의 링크 중에 디자인 스탠스와 의도적 스탠스는 각기 다른 두뇌 영역이 활성화 된다고 나오는데, 실제로 내러티브형 퍼소나로 추론을 할 때 의도적 스탠스를 취하는지 확인해보고 싶어서요.

근데 아마 실제로도 그럴 것 같습니다. 이건 그냥 제 추측이고, 사실 이 부분에 대한 의견이 궁금했던 것이었어요.

無異

퍼소나의 서술적인 디테일이 있으면 도움이 되긴하겠지만

그게 없이 특징들만 블릿으로 잡았다고 해서 감성적인 공감을 못한다(매우 어렵다)는 주장은 동감하기 어렵습니다.

저는 퍼소나를 사용하면 퍼소나라는 가상의 인물 하나를 위해 디자인 한다고 생각하지 않거든요.

퍼소나를 통해서 대상을 포커싱하기는 하는데, 그때 만들어내고 이름 붙인 가상의 인물 한명이 아니라 사용자조사를 하면서 만났던 실제 사람들, 뽑아낸 특징과 유사한 패턴의 내가 살면서 경험했던 주변 사람들, 영화나 드라마 등에서 보았던 주인공들의 보다 풍부한 내러티브에서 생각을 하게 됩니다. 

특징으로 만들어진 추상화된 모델과 그 모델을 만들기 위해서 차용한 많은 사람들의 구체적이고 실제적인 모습들 간을 계속 왔다갔다 하면서 생각을 해요.

다양한 실제의 인물에서 내러티브에서 얻어내는 것 보다 하나의 가상 인물을 토대로 만든 소설에서 얻는게 더 의미가 있다고 하긴 어렵지 않을까요?

또 원문에서는 뭔가 두리뭉실하게 쓴 것 같고, jun.ee님은 이러한 태도(intentional stance)로 솔루션을 생각해야 한다고 쓰셨는데요.

다양한 솔루션을 발상하는 것도, 여러 솔루션 중 선택을 하는 것도 모두 에밀리 모티머는 이렇게 행동할/판단할/생각할/좋아할 거야 라는 추론에 근거하여 결정해야 한다. - jun.ee

전 솔루션을 생각할때는 뭔가 사용자의 입장에서(walking in my shoes) 해답을 찾지 않는 것 같아요.

사용자 입장에서 공감을 통해서 문제를 찾으면 가급적 더 한번 추상화해서 근본적인 문제를 찾고 그 문제를 순수하게 분리해 내어 다양한 도메인에서 답을 찾으려고 하는 것 같아요. 이때는 오히려 그런 구체적인 맥락이 방해가 될 수 있는 것 같거든요.

구체화와 추상화 단계를 반복해야 더 좋은 문제해결을 할 수 있고요.

검증을 할때도 역시나 가상의 인물 한명이 아니라 더 많은 사람들의 진짜 맥락을 적용해서 검증하려고 합니다.

jun.ee

불릿으로 잡는 것이 감성적 공감을 하기 어렵다는 데에 동의를 못하시는 이유가 무엇인지요?

그 뒤에 쓰신 내용은 또 다른 내용이라, 왜 그렇게 생각하시는지에 대한 설명이 없어서 궁금합니다.

제가 생각하는 퍼소나는 단순히 '가상의 인물 하나'가 아닙니다.

퍼소나는 리서치를 통해 발견한 다수의 잠재적/실제적 사용자들의 행동패턴들 중 유사한 것들을 모아서 유형화 시킨 것이니까 허구적으로 만들어낸 한 명의 인물이라고 볼 수 없다고 생각합니다.

또, 리서치와 인터뷰에서 나온 Raw 데이터들을 그대로 다 가지고 가기엔 기억하기도 어렵고 정제도 되지 않았기 때문에 모델링을 하는 것인데요.

특징으로 만들어진 추상화된 모델과 그 모델을 만들기 위해서 차용한 많은 사람들의 구체적이고 실제적인 모습들 간을 계속 왔다갔다 하면서 생각을 해요. - 無異

라는 건 모델링을 해놓고 다시 또 Raw데이터들을 상기시켜서 솔루션 발상을 한다는 얘기로 보여서 이상하게 들립니다.

구체적이고 실제적인 모습이라고 말씀하셨지만 사실 그 단계 쯤에서 머리 속에 남는 것은 디자이너 개인 취향에 맞는 흥미로운 몇 가지 사실 정도이고, 심지어 왜곡되고 단편적으로 남은 기억일 가능성도 있고요.

사용자조사를 하면서 만났던 실제 사람들, 뽑아낸 특징과 유사한 패턴의 내가 살면서 경험했던 주변 사람들, 영화나 드라마 등에서 보았던 주인공들의 보다 풍부한 내러티브에서 생각을 하게 됩니다. - 無異

그리고 퍼소나는 실제 개개인의 독특한 취향들을 중성화시키고 일반화시킨 것인데 위와 같이 개별적인 내러티브들로 생각을 다시 하신다면 퍼소나를 만드는 의미가 없어지는 것 같습니다. 무엇보다도 주변사람과 영화 드라마에서 뽑은 내러티브는 다분히 디자이너의 기호에 따라 매우크게 달라질 것 같아서 위험한 방식같아 보이고요. 

정확한 퍼소나는 데이터에 기반해야 하는 것 아닐까요.

뭔가, 無異님이 퍼소나를 가상인물의 소설이라고 표현하신 부분에서 왠지 퍼소나를 모델링의 결과가 아니라 디자이너가 맘대로 정한 타겟유저라고 보고계시는 게 아닐까라고 생각이 듭니다. 

그래서 정확하게 퍼소나를 만들었다면 가상의 인물 한 명에 대한 소설이 아니라, 리서치 데이터를 기반으로 여러 사람의 행동패턴을 잘 유형화한 일반화된 사용자의 서술이라고 보는게 맞는 것 같아요.

그리고 답변 뒷 부분에서 '사용자 입장에서 해답을 찾지 않는다. 구체적인 맥락이 방해가 되므로 추상화해서 근본 문제를 찾는다' 라고 하신 부분은 제가 잘 이해를 못했어요.

혹시 무슨 말씀인지 예를 들어주실 수 있을까요?

無異

제가 받아들이는 퍼소나는 대상 사용자를 제한 한다는 컨셉까지 입니다. 

제가 퍼소나를 위해서 디자인한다고 하면  가상의 인물이 아니라 그런 특징을 공유하는 진짜 사람들의 문제를 해결해 주는 것으로 생각하거든요.

그런 모델 유형에 해당하는 진짜 사람들에 공감하려고 하지 만들어진 퍼소나에 몰입하고 공감해서 디자인 하지 않는 것 같아요.

퍼소나가 모델링의 결과면 공통되는 c.c.를 빼고는 people의 일반적인 특징을 가져왔다고 하겠지만 결국 임의로 선택한거잖아요.

 c.c.와는 상관없지만 우선 남자인지 여자인지 선택 하잖아요.

사용자 입장에서 해결을 찾지 않는다는 건 문제정의와 해결을 분리하겠다는거에요.

문제를 잘 해결할 수 있는 건 도메인의 전문가지 사용자가 아니거든요.

사용자는 자기의 문제를 찾는 것 까지는 할 수 있겠지만(잘 못하지만) 문제 해결의 전문가는 아니거든요.

좋은 집(UI)를 설계할 수 있는건 건축가지 그 집에 살 사람은 아닙니다.

문제 해결을 전문가에게 맡기려면 문제를 추상화해서 구체적 맥락과 분리해 내는게 더 좋습니다.

내 말은 빨리 달리지 못해. 발이 휘었어. 발굽이 두꺼워. 뭐 그런 사용자의 구체적 맥락 안에서 해결을 생각할게 아니라 빨리 이동하지 못한다고 문제를 추상화해서 분리해내야 자동차를 발명하기 쉽다는 거지요.

전성진

제가 항상 하는 말이지만, 주장하는 바를 선명히 하기 위해 주변을 까대면 역풍을 맞습니다. 선명히 하려면 필요한 일이긴 하지만 괜한 소모성 논쟁을 불러일으키기도 하죠. jun.ee님의 예시에서 주장하고자 하는 바는 '디테일이 중요하다'는 것이지 '불릿형 기술'이 나쁘다는 아닐겁니다.

쿠퍼의 크리스 노이셀(Chris Noessel)이 강조하는 내러티브는 디자인과정에서의 '발상'도구로서의 퍼소나를 말하는 것 같습니다. 사용자의 니즈나 불편사항을 잘 캐치하고 목표를 설정하고 핵심문제를 해결해주는 과정은 대체로 논리적 추론의 과정입니다. 하지만 훌륭한 솔루션을 만들기 위해서는 여기에서 '점프'가 필요하죠. 창의적 발상 말입니다. 이를 위한 다양한 툴들과 프로세스가 있는데 쿠퍼의 퍼소나를 이용한 디자인프로세스는 퍼소나에 전적으로 의존하는 것 같아요. 창의적 발상을 하려니 사고의 블랙박스가 필요하고, 인격체로서의 퍼소나에게로 공감을 하여 '퍼소나가 어떻게 행동할까....?'라고 창의적 발상을 하는 것이죠. 창의적 발상 프로세스가 나름 잘 갖추어진 디자인 조직은 퍼소나에 크게 의존하지 않고 나름의 브레인스토밍과 코웍샵을 통하여 이걸 해결하는 것 같아요. 여하간...쿠퍼에서 퍼소나를 창의적 발상툴로 생각보다 크게 비중을 두는구나라고 다시금 깨닫게 됐네요.

저도 초기 퍼소나에서는 교과서대로(?) 내러티브를 서술했었는데 몇번 해보다가 불릿으로 정리하게 되더군요. 하지만 jun.ee님이 예시로 들은 그런 감정없는 불릿이 아니라 의도와 목표가 드러나도록 행동패턴을 일목요연하게 정리하는 것이죠. 내러티브로 서술해놓으니 고객이 잘 안읽더라구요. 또 퍼소나를 발표하고 전달하는 과정에서도 갈 길 먼데 구구절절 퍼소나의 인생에 몰입하게 하려니 어렵고요. 또 핵심이 잘 안드러나고 문장 속에 섞여 있으니 갈 길 바쁜 사람에게는 답답해 보이는 것이죠. 하지만 발상의 단계에 있는 디자이너에게는 필요한 것 같아요. 가장 공감을 잘 해야하는사람들이고 이들을 위해서는 잘 정리된 이야기 하나는 필요하죠. 고객에게는 이 이야기를 틈나는대로 구전해주고요. 이참에 생각을 다시해보니 불릿 이전에 내러티브 방식의 잘 정리된 스토리를 꼭 쓰는게 좋겠다는 생각이 들었습니다.

이 외에도 퍼소나를 '이름'으로 불러줄거냐, '별명'으로 불러줄거냐의 이슈도 있어요. '이름'으로 불러주고 이것이 익숙해지면 공감에는 분명 더 도움이 됩니다. 하지만 '내러티브 방식'이 스토리에 몰입하게 되기까지의 어려움이 있는 것과 마찬가지의 문제가 발생하더군요. 이게 잘 안되면 퍼소나가 '남의 자식' 같이 되어 몰입/공감에 더 방해가 되기도 합니다. 그래서 다소 객관적인 행동패턴을 설명하는 '별명'을 붙여주는데 이렇게 하면 단시간에 능률을 올릴 수 있거든요. 커뮤니케션도 쉽고. 하지만...저는 '이름'을 불러주는 것이 초반에 힘들어도 더 맞다고 생각해요. 이를 위해서는 프로젝트 과정에서 클라이언트가 훨씬 더 깊이 관여를 해야만 합니다. 사용자조사도 같이하고 인사이트도 함께 발견하고, 퍼소나도 함께 만들어야 하는 것이죠. 그리고 이렇게 하는 것이 결과도 더 좋고요.

이상 제 견해를 정리하면....

- 내러티브가 확실히 공감이 잘 된다.

- 내러티브 방식은 디자인 과정에서의 '창의적 점핑'에 도움이 된다.

- 하지만 클라이언트와의 커뮤니케이션 과정에서의 몰입과 전달이 어렵다. 이를 극복하려면 클라이언트를 프로젝트 과정에 깊이 관여시켜야 한다. 성공하면 결과는 더 좋다.

- 프로젝트 상황에 따라 불릿방식의 보완된 형태가 능률적일 수 있다. 현실적으로는 이 방식이 더 유용하기도 하다.

- 앞으로는 내러티브와 불릿을 다 사용하는 것이 좋겠다.

- 비슷한 이슈가 퍼소나의 '이름'과 '별명'에도 존재한다. 

덕분에 저도 생각을 정리했네요. ^^

mango01

제 생각을 조금 덧대어 봅니다.

정확한 퍼소나는 데이터에 기반해야 하는 것 아닐까요.

그리고 제가 생각하는 퍼소나는 단순히 '가상의 인물 하나'가 아닙니다.

이전 쓰레드에도 쓴 내용이지만, 퍼소나는 리서치를 통해 발견한 다수의 잠재적/실제적 사용자들의 행동패턴들 중 유사한 것들을 모아서 유형화 시킨 것이니까 허구적으로 만들어낸 한 명의 인물이라고 볼 수 없다고 생각합니다.

뭔가, 無異님이 퍼소나를 가상인물의 소설이라고 표현하신 부분에서 왠지 퍼소나를 모델링의 결과가 아니라 디자이너가 맘대로 정한 타겟유저라고 보고계시는 게 아닐까라고 생각이 듭니다 - jun.ee

퍼소나는 정확한 데이터에 기반해야 합니다.

또한 사용자들의 행동패턴들 중 유사한 것을 모아서 유형화 시킨 것도 맞습니다.

그러나 실제로 퍼소나를 자주 만들다보면, 많이 보이는 패턴 중에 중요도에 따라 발췌해야 하고, '이 것이 패턴이다' 라고 명명하는 사람 자체가 디자이너이다 보니, 디자이너의 관점. 시야. 배경지식. 숙련도를 무시할 수 없습니다.

즉, 일전에도 한번 이야기 했듯이 누가 만들었냐(디자이너가 누구냐)에 따라 상당히 퍼소나가 달라집니다. 같은 데이터라도 객관적 정답이 없다는 이야기입니다. 단지, 모든 이해관계자가 동감하고 사용자마저 동의할 만한, 중요한 C.C들이 충분히 부각되었냐의 점검이 가능하겠지요.

또, 리서치와 인터뷰에서 나온 Raw 데이터들을 그대로 다 가지고 가기엔 기억하기도 어렵고 정제도 되지 않았기 때문에 모델링을 하는 것인데요.

특징으로 만들어진 추상화된 모델과 그 모델을 만들기 위해서 차용한 많은 사람들의 구체적이고 실제적인 모습들 간을 계속 왔다갔다 하면서 생각을 해요. - 無異

라는 건 모델링을 해놓고 다시 또 Raw데이터들을 상기시켜서 솔루션 발상을 한다는 얘기로 보여서 이상하게 들립니다.

구체적이고 실제적인 모습이라고 말씀하셨지만 사실 그 단계 쯤에서 머리 속에 남는 것은 디자이너 개인 취향에 맞는 흥미로운 몇 가지 사실 정도이고, 심지어 왜곡되고 단편적으로 남은 기억일 가능성도 있고요. - jun.ee

그래서 無異님 이야기는 다 적절합니다. 

추상화된 모델과 실제적 모습을 왔다갔다하면서 솔루션을 냅니다. 

모델링의 목적은 '단순하고 쓰기쉽게 무엇이 중요한지' <핵심>을 파악하기 위해서지, Raw데이터 자체를 쓰지말도록 하는데 있지 않습니다. 도리어 <핵심>을 파악하고 나면, 원래 알고 있던 Raw데이터가 다르게 보입니다. 그래서 프로젝트 막판까지 사용자 조사 내용을 리마인드해가며 솔루션을 내기도 합니다.

사용자조사를 하면서 만났던 실제 사람들, 뽑아낸 특징과 유사한 패턴의 내가 살면서 경험했던 주변 사람들, 영화나 드라마 등에서 보았던 주인공들의 보다 풍부한 내러티브에서 생각을 하게 됩니다. - 無異

그리고 퍼소나는 실제 개개인의 독특한 취향들을 중성화시키고 일반화시킨 것인데 위와 같이 개별적인 내러티브들로 생각을 다시 하신다면 퍼소나를 만드는 의미가 없어지는 것 같습니다. 무엇보다도 주변사람과 영화 드라마에서 뽑은 내러티브는 다분히 디자이너의 기호에 따라 매우크게 달라질 것 같아서 위험한 방식같아 보이고요. 

정확한 퍼소나는 데이터에 기반해야 하는 것 아닐까요. - jun.ee

디자이너가 2~3달 조사 했다고 해서, 그 분야에 대해 충분한 리서치를 했다고 할 수 없습니다. 즉, 자기 개인적 경험을 배제한 체 2~3달 조사한 데이터만 활용하겠다는 생각은 위험해 보입니다. 
구체적 자기 경험들, 주변 사람들과의 관계, 사건들을 활용해 최소 30년의 내공을 넣어서 사람을 이해하고 솔루션을 만들어야 합니다.

<모델링>은 핵심을 파악하기 위한 도구이자, 기준이 되어 줍니다.

<모델링> 아이디어를 내는데 영감이 되어주고 분별력과 힘을 실어주지, 혁신적 아이디어 자체를 내는데 필요충분 조건은 아닙니다. 

혁신적 아이디어는 디자이너의 경험에서 나오는 경우가 많습니다.

드라마에서 뽑은 내러티브가 위험하다고 하셨는데, 저 역시 병원관련 프로젝트를 할때, 병동별 특성 차이에 대한 이해와 솔루션에서 '하얀거탑'의 도움을 많이 받았습니다.

우리는 사회과학자가 아닙니다. 데이터만으로 그림을 그릴 수 없습니다.

데이터의 <재해석> 과정의 주체가 디자이너인 이상, 혁신적 솔루션을 내는 주체가 디자이너인 이상, 디자이너의 기호, 경험, 취향 모두 엄청 중요합니다. 그것을 배제하고 데이터만 가지고 정답을 찾으려는 태도가 더 위험합니다.

(물론 jun.ee님이 지적한대로, 데이터를 무시하고 자기 경험만 중시하는 태도도 엄청 위험하지요^^)

리서치로 현실을 잘 파악한 만큼, 디자이너인 자신의 능력과 한계를 잘 알고 솔루션을 내는게 좋다고 생각합니다.

<모델링>은 그 중간 도구 중 꽤 중요한 하나일 뿐입니다. 

이게 옳다는 말은 아니고, 그저 개인적인 생각입니다. 

퍼소나의 디테일이 주요한 역할을 한다는 점에서는 대체적으로 동의하지만 그 중요도와 활용방법에 대해서는 토론에 참여하시는 분들마다 약간씩 다른 모습을 보여주셨습니다.

여러분은 어떻게 생각하시나요? :)

그럼 퍼소나를 창시한 앨런쿠퍼가 그 당시 어떻게 퍼소나를 만들게 되었는지에 대한 글의 발췌문으로 포스팅을 마무리 하겠습니다.

I was writing a critical-path project management program that I called “Plan*It.” Early in the project, I interviewed about seven or eight colleagues and acquaintances who were likely candidates to use a project management program. In particular, I spoke at length with a woman named Kathy who worked at Carlick Advertising. Kathy’s job was called “traffic,” and it was her responsibility to assure that projects were staffed and staffers fully utilized. It seemed a classic project management task. Kathy was the basis for my first, primitive, persona.
나는 Plan*It 이라는 크리티컬 패스 프로젝트 관리 프로그램을 작성하고 있었다. 그리고 프로젝트 초기 단계에서 해당 프로그램의 사용자라고 볼 수 있을 만한 7~8명의 동료들과 지인들을 인터뷰했다. 나는 그 중 Kathy라는 Carlick Advertising에서 근무하는 여성과 많은 얘기를 나눴는데, Kathy의 직업은 교통정리자(traffic)라고 불렸다. 그녀의 임무가 프로젝트들에 제대로 인력이 충원되고 모든 인력이 제대로 활용되도록 하는 것이었기 때문이다. 그건 전통적인 프로젝트 관리 업무였고, Kathy는 나의 최초의 원시 퍼소나가 되는 기반이 되었다.

In 1983, compared to what we use today, computers were very small, slow, and weak. It was normal for a large program the size of Plan*It to take an hour or more just to compile in its entirety. I usually performed a full compilation at least once a day around lunchtime. At the time I lived in Monterey California, near the classically beautiful Old Del Monte golf course. After eating, while my computer chugged away compiling the source code, I would walk the golf course.  During those walks I designed my program.

1983년에는 오늘날과 비교해서, 컴퓨터가 매우 느렸기 때문에 Plan*It과 같은 대형 프로그램은 컴파일(역주: 소스코드를 실제 프로그램으로 만들어내는 과정)하는데 에만 1시간 이상이 걸렸다. 나는 보통 점심시간에 프로그램 전체의 컴파일을 걸어놓았다. 그 당시 나는 Monterey California에 살았는데 근처에 아름다운 Old Del Monte 골프 코스가 있어서 컴퓨터가 컴파일을 하는 동안 나는 점심을 먹고 골프코스를 따라 산책을 했다. 그렇게 걸으면서 내 프로그램에 대한 디자인을 했다.

As I walked, I would engage myself in a dialogue, play-acting a project manager, loosely based on Kathy, requesting functions and behavior from my program. I often found myself deep in those dialogues, speaking aloud, and gesturing with my arms. Some of the golfers were taken aback by my unexpected presence and unusual behavior, but that didn’t bother me because I found that this play-acting technique was remarkably effective for cutting through complex design questions of functionality and interaction, allowing me to clearly see what was necessary and unnecessary and, more importantly, to differentiate between what was used frequently and what was needed only infrequently. 
나는 그 길을 따라 산책하면서, Kathy를 떠올리며 내 자신을 그 프로젝트 매니저라고 생각하며 일종의 연극을 하며 가상의 대화를 나눴다. '이러한 기능이 있어야하고, 이러한 인터랙션(행동)들이 프로그램에 있어야 합니다' 라는 식의 대화말이다. 나는 종종 그 대화 속에 깊이 빠져서 큰 소리로 얘기를 하고, 팔을 사용해 제스쳐를 취하고 있는 내 자신을 발견하고는 했다. 몇몇 골퍼들은 내가 그러고 있어서 깜짝 놀라기는 했지만 나는 크게 개의치 않았다. 왜냐하면 그렇게 연극을 하며 대화를 나누는 그 기법이 기능과 인터랙션에 대한 복잡한 디자인적 의문을 한방에 해결하는데(cutting through) 너무나도 효과적이었기 때문이다. 그 기법은 나에게 무엇이 필요하고 불필요한지, 무엇이 더욱 중요한지, 무엇이 자주 사용되고 덜 사용될 것인지에 대한 것을 명확히 알게 해주었다.

[참고##퍼소나##]
[참고##사내 토론##]