프로젝트를 시작함에 앞서서 '어떤 사람들이 내 서비스의 사용자들일까?' 하는 생각을 하게 마련이다.
서비스나 제품을 사용할 만한 사용자, 즉 타겟으로 삼을만한 사용자들이 누구인지 정의를 하게 되는데 이 그룹은 정말 생각하기 나름인 그룹이 되어버리는 경우가 많다.
그야말로 기획자들이 생각하는 사용자는 Cooper가 이야기 하듯, 쭉-쭉 늘어나는 'Elastic User'가 되기 쉽상이다.
more..
'Elastic User'가 아닌 자신이 원하는, 혹은 회사가 원하는 사용자들을 알 수 있는 방법은 여러가지가 있겠지만 그 중 가장 효율적이라고 생각되는 방법론은 'Persona'가 아닐까 생각한다.
하지만 Persona를 만들어내는 과정은 실무에서 언제나 일정문제에 걸리기 마련이다.
'서비스 오픈일정이 O월 O일 까지니까 O월 O일 까지는 기획서를 주셔야 합니다.'
서비스를 기획할 때 항상 듣는 이야기이다.
이때 기획에서 사용할 수 있는 시간은 (프로젝트의 크기마다 다르겠지만) 1달~3달 남짓 주어진다고 생각된다.
이 기간은 대체로 순수 시나리오를 만드는데 걸리는 시간이므로 User Research를 해서 사용자들의 니즈를 파악하여 사용자 모델링을 하고, 이를 통해 시나리오에 적용할 사용자 요구사항을 정의하는데 걸리는 시간은 별도인 경우가 대부분이다.
여기서 만약 내가 '사용자들의 진정한 요구사항을 우선 알아야 진정한 사용자 중심 디자인을 할 수 있지 않겠습니까!, 라고 이야길 한다면,
'아직도 Academic하게 접근을 하는데 익숙하군요, 실무는 그렇지 않아요-!' 라는 핀잔을 듣기가 쉽지 않을까 싶다. (물론 회사의 분위기, PM의 성향에 따라 많이 다르긴 하다.)
즉, Persona를 만들어내기 위해서는 직접 대상이 될만한 사람들을 모집하여 Ethnographic Interview를 하여 분석하는 과정이 필요한데, 이 프로세스를 명확히 지킨다면 더 바랄 것이 없겠지만 현실적으로는 힘든 것이 사실이라 생각한다.
다시 이야기하면 Persona의 최대 맹점은 많은 리소스(일정,인력 등)의 투입이다!
그렇다면 빠른 시간안에 Persona를 만들어낼 수 있는 방법은 없을까?
맞는 지는 모르겠지만, 최소 시간으로 최대의 효과를 낼 수 있는 방법도 있을 것이란 생각을 하였다.
주어진 시간은 하루, 그리고 가상의 인물을 만들어내야 한다.
그냥 무시하고 지나치는 것이 나을까?
절대 그렇지 않다고 생각한다.
이 프로세스에서 만들어낸 가상의 인물(persona)은 실제 사용자들의 인터뷰를 토대로 만들어낸 가상의 인물이 아니므로 맹신하기엔 무리가 있을 수 있다.
하지만 서비스의 목표로 하는 사용자 모델 없이 서비스를 만들어나가는 것 보다는 더 나을 수 밖에 없다라는 것은 명백한 사실이다.
따라서 하루 중 반나절 정도만 이용해서 Persona를 만드는 방법에 관해 고민해 보았다.
단기 Persona를 위한 순서는 다음과 같다.
1. 가상 사용자 모집
: 프로젝트에 대하여 최대한 잘 알고 있는 사람들을 모은다.
2. 퍼소나 작업에 대한 간단한 소개
: 퍼소나에 대하여 알고 있는 사람들일지라도 지금 진행하는 작업에 대한 목적이나 진행방법에 대하여 간단히 설명을 한다.
3. 브레인 스토밍 진행
: 참가한 사람들은 최대한 '이런 사람들이 사용할 것이다' 라는 상상하에 다양한 생각들을 도출하여 포스트 잇에 적어넣는다. 이때 보다 효율적인 진행을 위해 포스트 잇 상단에는 '나이', '직업', '성별'을 적어 넣도록 한다.
4. 어피니티 벽(Affinity wall)에 포스트잇 붙이기
: '이제 사람들이 만들어낸 여러 포스트잇을 붙여넣도록 한다. 되도록 적어놓은 내용은 붙이면서 함께 간단한 설명을 하도록 하는 것이 좋다. 적혀있는 내용만으로는 그 사람의 의도를 잘못 파악할 수도 있기 때문이다.
5. 어피니티 다이어그램(Affinity Diagram) 만들기
: 사람들이 설명과 함께 모든 포스트 잇을 붙여 넣으면 그 내용들을 분류하여 그룹핑하는 작업을 한다.
이때 많은 사람들이 함께 모여있을 필요는 없다. 2명 정도가 pair로 작업하는 것이 보다 효울적이다.
6. 상위 노트 구성하기
어느정도 만들어진 그룹들에 대한 상위 노트를 만들어 붙인다.
이때 상위 노트는 그룹들의 내용들을 포괄할 수 있는 내용으로 붙이며 다른 컬러의 포스트 잇으로 붙인다.
7. 각 그룹을 한번 더 살피고(Affjinity walk) 전체적인 구조를 재정리한다.
: 어피니티 다이어그램을 구성하는 과정은 bottom-up과정이다. 따라서 작은 것에 몰입되어 큰 구조를 잃어버리는 경우가 많다. 어피니티 벽에서 뒤로 떨어져 전체적인 구조를 살펴보도록 한다.
8. 정리된 그룹을 통해 Persona를 도출한다.
: Primary Persona와 Secondary Persona를 도출한 후 참가했던 사람들에게 다시한번 피드백을 받도록 한다.
만일 critical하게 잘못된 그룹이 있다면 재조정하도록 한다.
지금 보니 내 글씨 정말 악필이군하..
이후 과정은 기존 퍼소나를 만드는 과정과 동일하다.
(만들어진 persona를 통해 시나리오를 작성하고, Data object와 attribute를 설정하여 필요한 상세 시나리오를 다시 작성한 후, 필요 기능스펙을 뽑아 framework design을 함)
서비스의 성공요인이 사용자들의 요구성만으로 이루어지지는 않지만,
내 서비스의 사용자들 알고 그 사용자들만을 위한 서비스를 만든다고 하면 해당 서비스의 성공 확률은 훨씬더 높아질 것이라고 생각한다.
일정 때문에 언제나 Persona라는 강력한 커뮤니케이션 툴이자 디자인 툴을 사용할 수 없었던 실무자들에게는 조금이나마 도움이 될 수 있지 않을까 하는 생각으로 오늘의 포스팅은 마치고자 한다.
* 마지막으로 오해가 없었으면 하는 부분에 대하여 밝히고자 한다.
: 현 포스팅에서 밝히는 간단한 persona만들기는 일정 상, UX 프로세스에 대한 개념이 아직 서투른 사람들과 프로젝트를 시작하게 되는 기타 등등의 어쩔 수 없는 경우에만 활용할 수 있는 방법이라고 생각되어진다. 최소한 3~4일이라는 시간만 주어진다고 하더라도 직접 사용자들을 만나서 사용자 모델링을 할 수 있는 충분한 시간이 될것이라고 생각하며, 그것이 User Modeling을 함에 있어 휠씬 Risk를 줄일 수 있는 방법이라는 것에는 분명히 이견이 없다.
: 현 포스팅에서 밝히는 간단한 persona만들기는 일정 상, UX 프로세스에 대한 개념이 아직 서투른 사람들과 프로젝트를 시작하게 되는 기타 등등의 어쩔 수 없는 경우에만 활용할 수 있는 방법이라고 생각되어진다. 최소한 3~4일이라는 시간만 주어진다고 하더라도 직접 사용자들을 만나서 사용자 모델링을 할 수 있는 충분한 시간이 될것이라고 생각하며, 그것이 User Modeling을 함에 있어 휠씬 Risk를 줄일 수 있는 방법이라는 것에는 분명히 이견이 없다.
댓글을 달아 주세요
잘 봤습니다. 기획의 입장에서는 프로파일이건 퍼소나건 기획서의 타켓정의형태이건 간에 아는 만큼의 고객에 대해서라도 구체화하는 것은 좋은 것 같습니다. 그러나 만드는 사람들이 생각하는 고객을 제품 개발에서 사용할 고객의 원형으로 삼는 것은 고객과 개발자의 차이라는 근본적인 문제가 있으므로 이 일에 고객연구자는 관여해서는 안될 것 같네요.
안녕하세요, dobiho 님-!
이렇게 온라인에서 만나뵈니 또 기분이 새롭네요 ^-^
좋은 말씀감사합니다. ^^
실제 사용자들을 인터뷰함으로써 사용자들의 요구사항들을 뽑아내는 것이 맞겠으나, 그렇게 진행할 시간이 없을 경우의 방법론에 대해 고민을 하다보니 최대한 현실적인 방안을 찾으려고 고민해보았다고 생각해주시면 좋을 것 같습니다.
말씀하신 것 처럼 고객연구자가 참여하는 것이 맞는지에 대해서는 저도 고민을 많이 해보았습니다. 어떻게 하면 가장 빠르게 Persona를 만들 수 있을지에 초첨을 맞추다 보니 이에 대한 언급이 부족했던 것 같습니다.
고객연구자는 최대한 진행과 해석세션에만 참여를 하는 것이 좋고 진행 시 참여자는 해당 서비스에 대한 지식을 어느정도 가지고 있는 사람(제가 고민하는 경우는 피험자를 섭외할 시간도 없을 때이므로 실무자가 될 수도 있을 것 같습니다.)이 되는 것이 가장 현실적인 모델이 될 수 있지 않을까요? ^^
실무를 진행하면서 너무 이용자들에 대한 정의없이 아이데이션을 하고 시나리오를 그리는 경우를 많이 보았고 그 이유 중 하나가 '일정상'이라는 문제 때문이었습니다.
그래서인지 지난번 HCI 학회에서 야후 코리아의 노광진님이 세션에서 언급하셨던 '사용자에 대해서 모르면 의견일 뿐' 이라고 언급하신 부분 또한 인상깊게 남네요.. ^^
제한된 상황에서도 열심히 하시는데 얘기하기가 좀 어렵지만 그냥 얘기 꺼리로만 애기 해보면, 퍼소나를 제품개발의 전과정에서 사용할 도구라는 측면과 고객에 대한 정보를 담는 형식의 측면에서 볼 수 있는 것 같습니다. 형식과 이용이라는 측면에서 퍼소나는 고객연구자이건 제품기획자이건 아무나 해도 상관없을 것 같습니다. 다만 퍼소나가 제품기획과정에서 사용될 고객연구에 대한 다른 형태의 산출물이라는 내용적인 관점에서 본다면 고객연구자의 산출물로볼 수 있을 것 같습니다. 퍼소나는 누구의 산출물인가? 에 대한 얘기도 되는것 같습니다.
네, dobiho님이 우려하시는 부분이 어떤 부분인지는 알것 같습니다. 저도 퍼소나는 실제 피험자들의 Contextual Data안에서 도출되어야 한다고 생각합니다.
퍼소나는 '실제 사용자의 산출물'이 되어야 하는 것이 맞다고 생각하구요.
그럼에도 불구하고 '간단한 퍼소나 만들기'를 시도해본 가장 큰 이유는 아무런 타겟 사용자, 심지어는 타겟 마켓조차 없이 만들어 지는 서비스들을 종종 봐왔기 때문입니다.
즉, 가상의 퍼소나가 될 지언정 '없는 것 보단 낫다!'라는 생각이 출발점이었다고 생각해주시면 감사하겠습니다. ^^
* Dobiho님 말씀을 들어보니 이렇게 만들어진 가상인물을 일반적으로 UX 분야에서 이야기하는'퍼소나'라고 부르는 것 자체가 오해의 소지가 있을 수 있다는 생각도 드네요. 차라리 '가상 서비스 이용자 상상해보기'라는 제목이 더 나을런지요? ^^
기성님 여기서 만나는군요.. 이런 내용들 바쁘신 중에 언제 다 정리하셨데여? ㅋ 좀 짱인듯.ㅋ
자주 참조하겠습니다. 짧은 기간이었지만 UT랩 있었을 때 정말 많이 배웠어여. 늘 감사하고 있습니다.^^
재환님-
오랜만~ dudmi라는 아이디가 익숙하네 ^-^
아직 홍대에 있는건가? 온라인이던 오프라인이던 종종 연락합시다~
+ 실용적일지도 모르지만 .. 위험할지도 모른다는 걱정도 함께 됩니다.
+ 하지만 .. 무엇이든 .. 없는것 보다는 있는게 좋다는 생각입니다. ^^
+ 좋은 글 감사합니다.
안녕하세요, tennygood님-
에 대한 실험적인 방법이었으며, 실무에서 사용해본 결과-
음..역시나 우려하던 부분에 대한 의견들을 주시는 군요. ^^
우선 tennygood님의 의견대로 위험할 수도 있다는데 동의합니다.
음..최소 3일정도의 시간만 주어진다고 하더라도 직접 사용자들을 접해보는 것이 신뢰도가 높을 것으로 판단됩니다. (1일-피험자 섭외 및 인터뷰 설계, 2일-참여자 인터뷰, 3일-사용자 모델링)
하지만, 이러한 시간조차 없는 경우엔 어떻게 할까?
(아시다시피 실무 일정이란..--
개발자, 디자이너, 다른 이해당사자들과 커뮤니케이션 할 수 있는 커뮤니케이션의 도구로써의 활용가치로도 그 역할은 충분하지 않았을까 하는 생각이 듭니다. ^^
다음 UXT랩에서, 정말 재밌게 일하시는 것 같아요.
위에서 말씀해주신 의견들도 동의하는 한편 이렇게나마 현업에서 실무자들이 활용할 수 있는 가이드가 있다라는 건 정말 의미있는 일이라고 생각해요. 나중에 한번 만나서 기대한 만큼 효과는 얻었는지 한계점은 무엇인지 등등 얘기 들어보고 싶어요.
리건님, 안녕하세요- ^-^
요새 일에 너무 치이다 보니 답글이 너무 늦었네요.
말씀대로 랩에서는 재미있게 일하고 있습니다.
저도 리건님의 다양한 경험과 고민들에 대해서 실제 뵙고 이야기 나누었으면 좋겠네요.
* 항상 좋은 글 잘 읽고 있습니다. ^-^
일만 하고 사시는 건 아닌지
옆모습이 예전만 못해보여...
Karl 박사님-
이렇게 온라인에서도 뵙게 되는군요 ^-^
제가 알려드린 URL로 타고 들어오신거죠?
음..
그리고 제 옆모습은 카메라 각도 문제라고 해두죠.
조만간 만나뵙고 옆모습 보여드리겠습니다. (__)