UX 이야기

본 글을 시작하기에 앞서 이 글은 2007년에 발간된 HCI Vistats의 Article을 번역한 글임을 알려 드립니다. 원 제목은 "Ten steps to Personas"이고, Lene Nielsen박사에 의해 쓰여졌습니다.

10 Steps to Personas

Persona를 하기에 앞서서 우리가 중요하게 봐야할 세가지 영역은 다음과 같다. 데이터 매터리얼, 퍼소나를 기술하는데 얼마나 결부되어 있는지, 그리고 디자인을 다시 하거나 처음부터 시작하는 디자인 프로세스에서 퍼소나에 대한 신뢰가 형성이 되어 있는지. 이 퍼소나의 10 단계의 개발에 대한 근거는 있으며, 초기 데이터 수집에서부터 현재 진행중인 개발까지 다룰 수 있도록 시도하였다.

다음에서 10가지 단계를 기술하도록 하겠다. 퍼소나를 사용하는 모든 프로젝트가 이 10단계를 따라야 하는 것은 아니다. 결과가 이미 예상되는 프로세스는 어느정도 생략 혹은 간소화도 괜찮다.

첫번째 단계는 사용자에 대한 지식을 가능한 많이 쌓는 것이다. 데이터는 많은 방법으로 수집될 수 있다. 인터뷰, 관찰 기법, 질문지 작성, 보고서, 문화적 조사 등이 예가 될 수 있다. 개인적인 경험으로 큰 회사들은 종종 마케팅 리포트, 콜센터 등으로부터 사용자에 대한 데이터들을 많이 가지고 있다. 이런것들은 사용자들을 실제로 만나는것을 대신할 수 있다. 그러나 프로젝트의 주제에서 초점을 벗어나게 할 수도 있다는 문제는 안고 있다. 이런것들은 다음 스텝에서 점점 가시화 되게 된다. 

퍼소나를 적용 한다는 것은 프로젝트에서 다루게 될 특정한 컨텍스트에 처한 사용자에게 집중 하겠다는 것이다. 많은 회사에서 종종 자신들의 사용자들을 지칭하는 방법들이 있지만 웹사이트를 사용한다거나, 시스템을 사용하는 등의 다양한 컨텍스트들이 존재한다는것은 고려 대상이 되지 않는다. 덴마크 정부의 각각의 다른 조직을 위해 비즈니스 포탈을 재디자인하는 최근의 프로젝트에서 국가 정부 당국은 조직 규모와 사업 분야에 따라 덴마크에서 진행중인 비즈니스를 분류하는 관행이 있었다. 직원들을 인터뷰 하고, 콜센터 등을 통해서 가설은 정립되었다.

과거 정부 조직은 이 프로젝트에 대해서 동감하지 못하였다. 그리고 정부에서 보고를 받을때, 어떤 사업 분야인지는 중요하지 않고, 얼마나 큰 회사이냐만이 주요 고려 대상이였다. 그리고 회사나 컨설턴트 등 정부에 보고하러 오는 사람은 퍼소나로 삼아야 할지 가설을 정립하고 있었다. 수 많은 설문조사가 진행되었고, 이 부서를 생각하고 있었던 응답은 없었으며, 새로운 관점에서 재해석 되어야 했다.

내 경험에 의하면 퍼소나 프로젝트에서 가장 어려운 태스크는 '어떻게 케잌을 자를 것인가?' 하는 문제이다. 데이터에서 의사결정까지 어디까지의 서술들을 인정하고 포함 시켜야 하는지를 말한다. 이 문제는 퍼소나 10개 스텝 중에서 몇개의 스텝을 파지하고, 데이터와 사용자의 서술을 분석하고 분류할 많은 인력이 필요하다.

'입증' 단계에서 집중해야 할 부분은 데이터를 찾는 것이다. 이 데이터들은 사용자들의 초기의 특정한 패턴과 서술(description)과 시나리오를 작성할 퍼소나를 뒷받침 해줄 수 있어야 한다. 이곳에서 찾아낸 정보들은 시나리오 작성과 서술(description)과 충분히 결부되어 있어야 한다. 예를 들어, 사용자는 무엇을 좋아하고 싫어하는가, 그들이 추구하는 가치는 무엇인가, 사용자가 시스템이나 사이트는 어떤 자세로 대하고 있는가, 어떠한 상황(condition)에서 사이트나 시스템을 이용하는가, 이 데이터들이 수집 되었을때 향후 이 데이터를 뒷받침 하는 사용 행태를 보일 것인가? 혹은 반대인가?

여기까지의 스텝은 정성적인 질문들로부터 유추된 데이터들을 정리하는 작업들이였다. 모든 팀원들이 이제까지 잘 따라오고 있는지는 토론이 일어났을때 잘 따라오는지, 모든 사람들이 같은 질문에 같은 대답을 하는지로부터 알 수 있다. 그러므로 다른 팀 멤버나 프로젝트 파트너에게 분류된 데이터를 보여주는 것은 중요하다.

중요한 스텝 중의 하나로, 퍼소나를 서술하는 문장들을 만들때와 전형적인 퍼소나 설립을 피하는 방법에 무엇들이 포함되어 있는지를 알아봐야 한다. 이제까지 퍼소나를 진행해 오면서 퍼소나 서술 문장들이 디자인과 결부되기 힘든 슈퍼맨이나 전형적인 사람을 만들어 내는것을 보아 왔다. 이번 단계를 진행하면서 퍼소나는 사용자를 기술하는것이 목적이 아니라, 솔루션을 만들어내는 출발점으로써 퍼소나가 필요하다는 점을 기억해야 한다.

가상적으로 구성한 인물에 대해서 지식들을 다음 5가지 캐릭터에 대해서 잘 서술되도록 나타나야 한다. 말할것도 없이 가능한한 구체적으로 기술해야 한다.

• Body - 사진이나 어떻게 생겼는지에 대한 기술이 필요하다. 이는 실존하는 사람이라는 느낌을 주며, 취하고 있는 자세, 입은 옷까지도 그 사람에 대해서 많은것을 말해준다.
• Psyche (마음, 정신) - 각자는 삶에 대한 전반적인 가치관을 가지고 있다. 이는 기술을 대하는 방법에 영향을 미친다. (예. 내성적, 외향적)
• Background - 사회적 배경, 교육, 가정교육 등은 사람의 전반적 능력, 삶의 자세, 세상을 이해하는데 영향을 미친다.
• Emotions and attitudes - 기술이나 디자인의 중심을 향한 감정이나 자세를 말한다.
• Personal traits(성격상의 특성) - 이 항목은 약간 혼란스러울 수 있다. 가상으로 서술하는데에는 평평한 성격과 둥글둥글한 성격을 구분이 필요하기 때문이다. 평평한 성격을 가진 경우에는 전형적으로 모든 일들에 대해서 한가지 반응만을 나타낼 가능성이 높다. 그 말은 평평한 성격의 캐릭터는 디자인과 결부되기 어려울수도 있다. 그러나 둥글둥글한 성격을 가진 캐릭터는 하나 이상의 특성을 지닌다. 이 경우 예상이 쉽지않고, 디자인과 쉽게 결부된다. 퍼소나를 작성할때 전형적인 캐릭터를 만드는것을 반드시 피해야 한다. 그리고 프로젝트 멤버들이 결부될 수 있는 서술을 작성해야 한다. 그러므로 같은 특성들이 반복되는 정보들을 찾는것이 바람직하다.

개인적인 경험으로 팀 구성원들이 직접 퍼소나 서술을 하게끔 하는 조직은 잘 없었다. 그 대신에 외주 업테를 사용하거나 사용성을 담당하는 부서에 퍼소나 서술을 맡기곤 하였다. 그러나 이 퍼소나 방법론은 프로세스 중 하나라고 느끼기 보다는, 이 퍼소나 서술은 어떻게 나왔으며, 어떻게 사용될 수 있는지 의견 일치를 하고 이해하고 있어야 한다. 퍼소나를 작성하는데 다른 부서 사람이 작성할 수 밖에 없다고 한다면 퍼소나 작성의 일부분에 가담하여 퍼소나가 자신의 것이라고 느껴야 한다. 서술하고 프레젠테이션 에서 동질성을 가진 한 사람의 퍼소나를 만들기 위해서 재작성 될수도 있다. 그러나 향후 퍼소나 서술을 작성하는 프로세스에서 좀더 많은 정보를 첨가함으로써 성과를 올릴 수 있다.

앞에서 언급했듯이, 퍼소나의 진짜 목적은 퍼소나 서술(description) 으로부터 시나리오를 도출해 내는 것이다. 이 스텝은 시나리오를 작성하는 준비 단계로써, 퍼소나에서 기술된 사용자가 사용될 시스템이나 사이트가 어떤 상황에서 필요할지 정의한다. 이는 퍼소나에서 기술된 사용자가 해당 제품을 사용하는 상황을 연출하게 될 것이다. 이런 각각의 필요나 상황은 시나리오의 시작이 된다.

모든 참가자가 퍼소나 기술(description)과 상황에 동의하게 하기 위해서 두가지 전략이 필요하다. 모든 사람들의 의견을 물어보고 프로세스 안에 참여하게 한다. 종종 퍼소나 방법론은 사용자와 개발자와 다른 사람들 사이의 커뮤니케이션으로 알고 있으나, 이는 사용자 중심(User-centered)의 개발을 좀더 완고하게 해주는 프로세스이기도 한다. 프로세스의 시각에서 바라보는 것은 모든 이해관계자(디자이너, 사용자, 개발자 등등)를 소집하고 퍼소나를 발전시키면서 디자인에 사용될 수 있도록 하는 회의를 주관하게 한다.

나는 모든 사람이 프로세스에 참여할 수 있다는 것을 충분히 알고 있다. 신입사원이나, 회사의 실무급 인원도 참여할 수 있다. 그러나 퍼소나가 참여 인원들에게 퍼뜨려 지지 않는다면 그 인원은 아무 가치도 없다. 퍼소나의 결과가 제대로 전파되어야 할 뿐만 아니라 그 뒤에 있는 데이터들도 같이 전파 되어야 하며, 이 퍼소나들을 어떻게 사용될 수 있는지도 전파 되어야 한다. 많은 프로젝트들이 개발자와 디자이너들에게 퍼소나를 어떻게 사용하고, 시나리오에 어떻게 녹이고, 유즈 케이스를 작성하는게 어떻게 사용하는지를 전달하고 학습시키는 것은 잊어버리곤 한다. 

앞에서 언급한것처럼 퍼소나 그 자체로는 아무 쓸모도 없다. 퍼소나가 시나리오에 녹여졌을때 그 가치를 증명할 수 있다. 시나리오는 한 이야기에 가깝다. 특징(퍼소나)가 있고, 연출(액션이 일어날 장소)이 있고, 목적(퍼소나가 이루고자 하는것), 목적이 이루기 까지의 행동(시스템/사이트/디바이스와의 인터랙션)이 있다. 그리고, 목적을 달성하는데 방해 요인들이 존재한다. 나는 허무맹랑한 시나리오 몇가지들을 봤었는데, 이런 시나리오에는 디바이스가 모든 문제들을 해결해 버린다. Mrs. Tahira Khan이라는 퍼소나를 설정한 프로젝트를 진행한 적이 있는데 그녀가 당뇨병을 어떻게 극복하는지 보면 내가 무엇을 이야기 하는지 알 수 있다. 현실적이지도 설득적이지도 않은 65세의 퍼소나를 설정하였으며, 당뇨병은 발견되지 않은 상태로 영국에 여행을 갔고, 영어는 잘 하지 못하지만, 어떤 디바이스 하나로 당뇨병을 극복해버린다. 

마지막으로 퍼소나의 정보들을 지속적으로 업데이트 할것을 권장한다. 만약 사용자의 테스트 결과나 퍼소나 환경에 변화가 있다면 업데이트가 이루어 져야 한다. 정보는 누구나 업데이트 할 수 있는게 아니라, 업데이트 하려면 누구에게 연락을 해야 하는지 알고 있어야 한다. 퍼소나 설계 프로젝트에 참여 인원이여서 퍼소나 서술에 이상한점을 발견하면 누구에게 연락을 해야 하는지 알고 있고, 퍼소나 서술의 히스토리를 알고 있는 퍼소나 대사(personas ambassador)를 둘 것을 권장한다. 그리고 Adllin과 Pruitt는 "퍼소나 라이프 사이클"을 두고 퍼소나의 원래 목적보다 더 오래 살고 있을때 퍼소나를 없애는것도 필요하다고 한다.