태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.


'agile persona'에 해당되는 글 2건

  1. 2013.08.20 [독후감] Lean UX (1) by 이 재용
  2. 2011.04.22 Agile과 UCD (User Centered Design) (2) by 이 재용
2013.08.20 00:10

[독후감] Lean UX

Lean UX
Applying Lean Principles to Improve User Experience
by Jeff Gothelf with Josh Seiden

Lean Startup의 저자 Eric Ries가 Series Editor를 맡은 The Lean SeriesRunning Lean에 이은 두 번째 책은 Lean UX이다. 저자인 Jeff Gothelf는 lean design studio인 Proof를 창업했는데, 이후 Neo Innovation Lab에 합병되었다. Josh SeidenCooperLUXr를 거쳐 현재 Neo에 근무하고 있다.
(참고: 한국어 번역자 김수영씨와의 대담 보기


Lean UX란 무엇인가?
많은 분들이 궁금하게 생각할 것 같은데, 이 책의 정의는 꽤 단순하다.
The junction of Lean Startup and User Experience-based (UX) design -- and their symbiotically coexistence -- is Lean UX. p XIII
흠 그렇지. 당연히 Lean UX는 린스타트업과 UX의 결합이겠지. 그럼 대체 뭐가 이전이랑 달라지나? 
린 UX를 하게 되면, 이전의 UX 디자인 프로세스에서 어쩔 수 없이 생겼던 낭비적인 요소, 즉 다음 단계의 작업을 위해 멋진 문서를 만들던 일이 줄어든다. 그리고, 디자이너들이 홀로 떨어져 완벽한 문서를 만들어 개발자들에게 넘기는 방식이 아니기 때문에, 모든 팀이 진정으로 협업을 하게 된다. 하지만 앞의 두 원칙보다 더 중요한 포인트는, 바로 관점의 변화(mindset shift)를 얻게 된다는 것이다.

UI와 UX의 차이점에 대해 수많은 사람들이 업무의 범위나 적용 대상의 차이에 주목할 때, 필자는 인간을 대하는 사고 방식의 차이가 가장 핵심적인 차이라고 주장한 바 있다.
UI-UX의 차이는, 인간을 바라보는 사고 방식의 차이이다. 질적 사고, 공감 도구, 전략적 타당성이 중요하다. 흔히 사람들은 UI와 UX의 차이에서 I와 X의 차이만 생각하지만 더 중요한 것은 U와 U의 차이다. 사용자를 바라보는 사고 방식의 차이가 UX를 만들었다.UI에서 U가 보편적 인간을 모델로 한 분석 대상이었다면, UX에서 U는 주관적 인간을 모델로 한 공감 대상이기 때문이다.
from (쉽게 쓴) UX란? 그리고 UI와 UX의 차이
역사적인 관점에서 보면 너무나도 그 차이가 극명하게 보인다. 왜 반드시, 필연적으로 UX라는 개념이 나타날 수 밖에 없었는지, 그리고 왜 동시에, 수많은 사람들이, 그런 개념이 필요하다고 생각하게 되었는지. 시대가 변했기 때문에 UX가 나타난 것이지, 사람들이 UX라는 걸 발명한 것이 아니다.


왜 Lean UX인가?
린 UX도 마찬가지다. 이 책에서는 적어도 그렇게 주장한다.
제품과 인쇄 디자인에서, 소프트웨어 디자인으로 바뀌면서 바뀐 것 만큼이나, 소프트웨어 산업이 최근 변화하고 있다. 인터넷의 발전과 더불어, 더 이상 패키지로 공급되지 않는 소프트웨어의 발전은 Agile을 무기로 한 회사들이 경쟁력을 갖추도록 하고 있다. 따라서,
It's time for a change. Lean UX is the evolution of product design. It takes the best parts of the designer's tool kit and recombines them in a way that makes them relevant to this new reality. p 4
기존의 waterfall 프로젝트 방식이 가졌던 디자이너의 고립, 성공을 확인하기 전에 과도하게 투입되는 자원 등의 문제를 극복하고, 우리가 디자인에 대해 생각하는 사고 방식을 바꿀 것이라는 것이 필자의 주장이다. 이렇게 현실이 바뀌면서 바뀐 현실에 근거한 패러다임들은 몇 가지 공통점이 있다. 즉 비슷한 생각을 여러 사람들이 서로 다른 이름으로 동시에 제시하다가, 어느 순간 한 용어로 통일된다는 점이다.


원칙들
Lean UX는 크게 세 가지 미리 존재하던 광범위한 현상에 기초하고 있다. 바로 IDEO의 디자인 사고(Design Thinking), 애자일 개발(Agile software development), 그리고 마지막으로 린 스타트업(Lean Startup method)이 그것이다.

디자인 사고(Design Thinking)에 대해서는 피엑스디 블로그에서 많이 다룬 바 있다. 디자인 사고란,
디자인 사고란, 인간을 관찰하고 공감하여 소비자를 이해한 뒤, 다양한 대안을 찾는 확산적 사고와, 주어진 상황에 최선의 방법을 찾는 수렴적 사고의 반복을 통하여 혁신적 결과를 내는 창의적 문제 해결 방법이다.
- 디자인 사고(Design Thinking)란?
이렇게 디자인 사고란 만들어 보고, 고치고, 또 고치는, 디자이너의 일반적인 작업을 일반화한 사고 방식이다.
- 디자인 사고(Design Thinking) 스터디 가이드
- 디자인 사고(Design Thinking) 읽을거리
- [독후감] 디자인에 집중하라 Change by Design
- [독후감] 디자인 씽킹 The Design of Business

애자일 개발 방법론은 여기서 간단히 다루기엔 너무 광범위하니까, 이 책에서 소개한 네 가지 원칙만 간단히 적고 넘어가려고 한다. 좀 더 자세한 내용은 피엑스디에서 애자일에 맞추어 진행한 경험을 공유한 아래 글을 참고하기 바란다.
- Agile과 UCD (User Centered Design)

1. Individuals and interactions over processes and tools.
절차나 도구보다는 각 개인들이 자유롭게 생각을 교환하고 활발히 소통하는 것이 더 중요하다
2. Working software over comprehensive documentation
다음 단계 사람들이나 최종 결과물을 위해 문서를 이해하기 쉽게 만드는 시간을 줄이고, 실제 소프트웨어을 잘 만드는데 시간을 사용
3. Customer collaboration over contract negotiation.
고객과의 협업에 집중함을 통해 더욱 성공적인 소프트웨어를 만들 수 있음
4. Responding to change over following a plan
초반 설계가 잘못되었을 가능성이 높다는 걸 인정하고 끊임없이 수정하여 목표를 찾아가는 것

마지막으로 린스타트업 방법론은 현재 이 시리즈에서 열심히 설명하고 있는 바다.
- 린스타트업과 Lean UX 
- Running Lean (린 스타트업) 
- 린 스타트업 용어 정리
- 왜 LeanUX인가? 


방법(Process)
책의 중반 이후는 이제 Lean UX를 진행하는 자세한 방법에 대하여 소개하고 있다. 방법 전체를 이 글에서 소개할 순 없고, 흥미로운 점들만 지적하면,

우선 가정(Assumptions), 가설(Hypotheses), 결과(Outcomes), 퍼소나(Personas), 기능(Features)에 대해 설명한다. 이 때 가정과 가설을 검증하는 방법에 있어서, lean UX에서 말하는 measure는 반드시 수치화된 것만은 아니어야 한다고 주장한다. 그럴 것 같기도 하다. 하지만 그렇게 해 버리고 나면, 왠지 lean이 아닌 것 같이 보여버린다. 즉 측정의 요소를 Measure:market feedback, quantitative measure, or qualitative insight라고 말하면서,
It's not all numbers! It's worth noting that there's been a lot of backlash in the design world against measurement-driven design. The argument is that by reducing every design decision to factors that can be measured, we take the delight and soul out of our products. I actually agree with this perspective, which is why I think it's so important to include qualitative feedback in your success criteria. Are people delighted by a design? Do they recommend your product to their friends? Do they tweet about it? When you look for success metrics, remember that it's not all numbers. From Lean UX p.24
얼마나 많은 사람들이 이 글에 동의할지 잘 모르겠다. 동의해도 좀 이상한 것 같고, 아닌 것도 좀 이상한 것 같다. Lean을 공부하는 디자이너들은 '그럼 그렇지'라며 동의하고, 경영이나 공학쪽의 사람들은 '뭐야, 핵심을 놓쳤잖아!'라고 말할 것 같기도 하다.

Proto-Personas
보통 퍼소나는 탄탄한 현장 연구 끝에 만들어내지만, lean UX 프로세스에서는 그렇게 만들어 낼 수 없다(당연히!). 이 때 사용하는 방법이 프로토타입 같은 퍼소나, 즉 프로토-퍼소나이며, 프로젝트에 참가하는 팀원들의 가정(Assumption)에 의해 만드는 퍼소나이다. 일단 이렇게 간략하게 만든 다음에 향후 리서치를 통해 계속해서 발전시켜나가는 방식이다. 이 프로토-퍼소나에는 크게 네 가지 요소가 들어간다. 1. Sketch and name 2. Behavioral demographic information 3. Pain points and needs 4. Potential Solutions (p29)


 이는 기존의 여러 회사/연구자가 제시했던 rapid persona, assumption persona (Ad-hoc persona)와 크게 다르지 않다. 피엑스디에서도 이러한 방식을 제시한 바 있다. 피엑스디에서는 이를 Agile Persona라고 불렀다. (초기 연구자들은 필드 리서치에 기반하지 않은 퍼소나는 퍼소나가 아니라고 부정하는 경향이 컸지만, 최근에는 모두 받아들이는 추세다) 다만 차이점이 있다면, 문제와 해결을 철저히 분리하는 전통적인 방식과는 달리 Potential Solution이 있다는 점이다. 
- Agile과 UCD (User Centered Design)

피엑스디의 Agile Persona 생성 방식과 이 책에서의 Proto-persona 생성 방식을 비교해 보는 것도 재미있을 것이다.

디자인 협업
이 장에서는 확산적 사고와 수렴적 사고를 반복하는 디자인 사고(Design Thinking)를 적용하여, 디자이너가 퍼실리테이터가 되고, 모든 팀(개발,기획,마케팅 등)이 함께 모여 디자인 스튜디오를 운영하는 방법과 지속적 배포를 위하여 스타일 가이드를 운영하는 방법, 그리고 원격지에 떨어진 사람들끼리 디자인 스튜디오를 운영하는 방법을 설명한다.


MVP
MVP는 Minimum Viable Product의 약자이다. MVP는 가능하면 증명되지 않거나 집중할 필요가 없는 부분을 제외하고 최소한의 기능만으로 실제 사용자가 제품을 사용하게 함으로서, 우리가 생각한 가설을 검증하고, 이를 통해 학습을 하기위한 도구이다.
먼저 MVP의 초점(the focus of MVP)이 중요한데, 여기에는 크게 두 가지 다른 방향이 있다.
Sometimes teams create an MVP primarily to learn something. They're not concerned with delivering value to the market; they're just trying to figure out what the market wants. In other cases, teams create a small version of a product or a feature because they want to start delivering value to the market as quickly as possible. In this second case, if you design and deploy the MVP correctly, you should also be able to learn from it, even if that's not the primary focus. from p 56
즉 학습을 우선시 하여 가치를 제공하는 측면을 무시할 것인가(학습의 극대화), 아니면 가치를 제공하는 것을 우선시할 것인가(물론 이 경우에도 학습은 이루어진다)의 문제이다.

이 챕터 전반에서는 학습 우선시와 가치 전달 우선시를 동시에 이루려는 것이 일반적이나 둘 사이에 무엇에 더 중점을 두어야 하는지에 대해서는 설명이 없다. 다소 암묵적으로는 '학습'에 좀 더 중점을 둔 듯이 느껴지기도 한다.

그러나 UX를 해 온 입장에서 이 부분에 대해서는 강한 반감을 가질 수 밖에 없다. 

만약 학습을 중심에 둔 것이라면 그것은 MVP가 아니라 프로토타입이어야 한다. 많은 사람들이 이렇게 MVP를 Minimum Testable Product 정도로 생각하는 것 같다. 그렇다면 정말 프로토타입과 다를 것이 없다. 하지만, 절대 프로토타입을, 혹은 Minimum Testable Product를, 혹은 학습을 우선시한 그 무언가를 시장에 내 놓으면 안된다고 생각한다. 그것은 사용자를 상대로 실험하는 것이고, 비윤리적인 행위이다. 

학습이 우선이라면, 혹은 테스트를 위한 것이라면 프로토타입을 만들어서, 가상의 소비자에게 보여주는 것이 옳다. 그러나 MVP의 강력한 부분은 실제 소비자들이 판단한다는 점이고, 그렇다면 MVP는 절대 minimum testable이 아닌, minimum "Viable" 즉 시장에서 살아남을 수 있는 독자적인 가치를 제공해야 한다고 생각한다.

이 대목에서, 역시 '정성적인 측정'과 비슷한 느낌이 든다. 배움을 위해 프로토타입을 MVP에 포함시킨다면... 뭔가 달라진 것이 없는 예전 방법론 그대로이다. 무릎을 쳤던 것은 Viable 즉 시장의 real user feedback이라는 점이었는데, 도로 프로토타입이라... 되돌아간 느낌이다. 그런데 프로토타입을 배제시킨다면 좀더 차별화된 Lean용 MVP라 선명하긴 한데, 초기 단계가 힘들어질 것 같다. 어떻게 처음에 배우지? 넓히면 예전 그대로이고, 좁히면 답답해지는 그런 느낌이다. (하여간 그래서 필자는 '학습'을 중심으로 한 MVP는 없어야 한다고 생각한다. 위 주장은 이제 막 LeanUX를 배우기 시작한 초보 학습자의 혼란으로 이해해 주시길...)

어쨌든 이 책에서는, 시장에서의 가치를 가진 형태를 MVP, 그리고 그것을 테스트해보기 위해 만드는 프로토타입. 이렇게 구분한다. 따라서 prototype MVP 라고 부르는 형태가 가능하다.

학습 중심, 테스트 중심의 MVP는 이상하다. 학습이나 테스트를 원하면 prototype MVP를 만들어라. (프로토타입이 아닌) MVP는 언제나 소비자에 진짜 가치를 전달해야하고, 시장에서 살아 남을 수 있어야 하고, 결과적으로 학습할 수 있게 한다. 

프로토타입이 아니면서 MVP라고 주장하는 방법들
놀랍게도 이 책에서는 다양한 Non-prototype MVP를 제시하는데, 사실 이런 방법들은 철저히 학습을 위하여 소비자를 우롱하는 방법들인데, 버젓이 책에 적어 놓고 있다는 것이 놀랍다. 이 저자들이 정말 UX를 하는 사람들이란 말인가?

-뉴스레터를 실험해 보기 위해, '뉴스레터' 신청하기 버튼을 만들어 본다. (반응 안 좋으면 뉴스레터 안 만든다)
-사람들의 반응을 살펴보기 위해 구글에 가짜 광고를 실어본다.
-공갈 버튼 : 사람들이 얼마나 관심있는지를 학습하기 위해, 실제 눌러도 아무 기능도 하지 않지만, 누른 회수를 측정하는 버튼을 만들어 본다. p69

미친 것 아닌가?  

린 UX가 대세가 된 세상에 당신이 소비자라고 생각해 보자. 당신이 멋진 기능이라고 생각해서 누른 버튼들이 모두 자기들 학습을 위한 공갈 버튼들이라고 상상해 봐라. 상상만해도 짜증이 확 나는구만.


Feedback
대개의 린스타트업 방법의 경우 '측정'에 의해 이루어지지만, Lean UX에서는 User Research가 피드백을 얻는 방법일 수 있다. 
책에서 Lean UX의 리서치는 1. 기존 리서치와 달리 지속적으로 이루어진다는 점 2. 다른 분야의 사람들과 협동적으로 이루어진다는 점 등을 기존 UX 리서치와 차이점으로 둘 수 있다고 설명한다. p 74 자연스럽게도, 대개 이러한 방법의 리서치들은 사전에 이루어지지 않고 사후에, 즉 3. 무언가를 만들기 위해 리서치 하는 것이 아니라, 만든 것을 측정하기 위해 리서치 한다는 점도 (책에는 없지만) 포함시켜야 한다고 생각한다.

특히 지속적인 사용자 피드백 연구를 위하여 저자는 3-12-1 시스템을 제시하는데, 매주 목요일 12시 전에 3명의 사용자를 인터뷰한다는 뜻이다. (p77)




결론:Lean UX의 도입
간단하게 말해서 Lean UX는 '어 우리도 도입해 볼까?'하고 간단히 도입할 수 있는 방법론이 아니다. 한마디로 말해,

조직 전체가 바뀌어야 한다!

우선 산출물(output)이 아니라 매출, 혹은 회원수등의 실질적인 결과물(outcome)을 중시하도록 문화나 계약이 바뀌어야 하고, 기존 인원들의 역할이나 스킬도 달라져 진정한 Cross-functional 팀이 '작은' 규모로, '하나의' 장소에 모여 일해야한다. 

특히 에이전시든 인하우스든 BDUF (Big Design Up Front, p114)라 불리는 일이 없어질 것이며, 특히 에이전시에게는 큰 도전이 될 것이다.

필요한 변화들 가운데, '아름다움보다 스피드가 더 중요하다(p116)' 등의 원칙은 왠지 마음에 들지 않는다. 어쨌든 이 책은 여러 가지 설득되지 않는 부분도 많고, 미흡해 보이는 부분도 많다. 하지만 이 분야에 가장 먼저 깃발을 꽂은 책인 만큼, 충분히 일독의 의미가 있다고 볼 수 있다.

jun.ee 댓글(2013.09.02)
LeanUX 방법론의 핵심은 프로세스나 도구의 이용방법 보다도, Shared Understanding(p10) 이라고 봅니다. 예를 들면 Lean UX 방법론의 가장 큰 기둥 2개는 Collaborative Design(p33-35)과 Collaborative Discovery(p74-76)인데, 이 둘 모두 Shared Understanding 하나를 잘 이루기 위해서 존재하는 것이니까요. 심지어 저자가 아예 Lean UX의 통화(Currency)는 Shared Understanding이라고 했으니(p34) 말 다했죠. ㅎㅎ

그래서 Lean UX 방법론을 그대로 따르지 않더라도, '우리 조직(Cross functional team, p7)에서 어떻게 하면 최소비용/최고속도/최대효율로 Shared Understanding을 생성, 유지, 발전시킬 수 있을까'를 진지하게 고민하다 보면 어느새 Lean UX를 실천하고 있는 자신들을 발견할 수 있지 않을까 생각해봅니다.

암튼, 이 부분에 대한 언급이 없어서 아쉬운 마음에 댓글 남깁니다.



참고:
책 홈페이지 http://www.leanuxbook.com/
User Interface Engineering(UIE) Articles Why Lean UX? by Jeff Gothelf
Cooper Journal Lean UX: An Interview with Jeff Gothelf and Josh Seiden
[참고##Lean UX##]



팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 2 Comment 1
Ad Test...
2011.04.22 22:10

Agile과 UCD (User Centered Design)

일반적으로 사용자 중심 디자인(UCD, User Centered Design)은 개발에 들어가기 전, 사용자 연구 등을 통해 필요한 사항(Requirement)과 전략을 명확히 하면 할 수록, 개발 비용도 줄고 과업의 성공 확률도 높다고 주장하고 있다. 이에 따르면 하나의 단계가 끝나고 또 다른 단계를 진행하는 전통적인 폭포수 진행법(Waterfall Process)이 적합해 보인다.
그런데 개발에 있어서 폭포수 진행법이 공격을 받으면서, 빠르게 개발하는 다양한 방법(Agile Process)이 개발자들에게 인기를 점차 얻게 됨에 따라 사용자 중심 디자인에 익숙해져 있던 전통적인 UI 디자이너들도 이에 대응할 필요가 생기게 되었다.
과연 1주에서 2주 내에 빠르게 제품을 만들어 (어떤 부분이든 돌아가게) 빌드하고, 릴리스하면서 제품의 문제점을 빠르게 보완해 가는 반면 전통적인 요구사항(Requirement)이란 실패의 지름길이라고 여기는 이 애자일(Agile) 방법론에서 UI 디자이너들은 어떤 태도를 취해야 할까? 우리 나라에도 제법 사례가 있을텐데 구글신께서 알려주질 않으니 알 도리가 없고, 해외 사례들을 가지고 찾아보았다.


우선, Agile 용어가 낯선 분들 위해 간략하게 무엇인지 알아보면,
http://j.mp/gSrMYc (위키피디아)
http://xper.org/wiki/xp/AgileMethodology

그런데 왜 이것이 UCD와 문제가 되는가?에 대해 기초적인 포스팅은,
http://www.boxesandarrows.com/view/bringing-user인데,
대체로 이 포스팅에서 Agile 환경에서 문제점을 지적하길, 1. 디자인의 역할이 불명확하거나 아예 없다. 2. 요구사항 단계도 없고, 자유로운 컨셉 탐색 단계도 없다. 3. 미완성에서 안정화보단 기능추가 욕구가 더 생긴다.4. 결과적으로 품질 문제가 생긴다. 그래서 개선에는 도움이 되지만 맨 처음 만들 때는 도움이 안된다(Agile is good for refining, not defining.)고 말한다. 따라서 Agile 하게 진행하고 싶으면, 프로젝트 초반에 '컨셉' 혹은 '전략' 잡는 단계를 두고, 그 뒤에 Agile하게 진행하는 것이 좋다는 결론이다.

또 다른 글에서도 역시 비슷한 지적을 하고 있다.
http://www.agileproductdesign.com/blog/emerging_best_agile_ux_practice.html
Agile 에서 성공하려면, 프로젝트 초반에 '최소한의' 사용자 조사와 모델링을 하라는 것이다.(Research, model, and design up front - but only just enough) 이 글에서는 이를 포함하여 총 12가지의 Agile 환경에서 성공하기 위한 방법을 설명하는데, 예를 들면 디자이너들이 개발팀의 일부가 되어야 한다, 계속 사용자 테스트를 하기 위한 사용자 풀이 있어야 한다, 개발과 병행하여 사용자 연구를 계속해야 한다, 프로토타입(low fi)을 계속 만들고 이를 요구사항으로 여겨야 한다는 등의 조언을 하고 있다.

대부분의 사람들처럼 갑자기 들이닥친 Agile 환경에 대응하여 실패에서 성공으로 이끈 사례를 발표한 슬라이드
http://www.slideshare.net/jgothelf/beyond-staggered-sprints-integrating-user-experience-and-agile
에서는 첫번째 단계에서 실패하고 두 번째, 세 번째, 네 번째 점점 더 나아져 결국 성공하게 되었는데, 우선 쉽게 가져다가 쓸 수 있는 풍부한 라이브러리(스타일 가이드, 혹은 패턴 라이브러리)가 갖추어지고, 프로토타입을 계속 만들어가면서 개발팀 전체가 같이 디자인하는 식으로 일하면서 계속 User Test를 해 나가면 성공할 수 있다는 것이다.

프로젝트가 시작되면, 일주일 혹은 이주일 단위로 테스트하고 수정해야하는데,
http://agile2010.agilealliance.org/files/agile_2010_Cindy_McCracken.pdf
에서 보는 것처럼 기존의 긴 기간 하던 몇 가지 방법들을, 기간이 짧아지고 계속 반복해야하는 만큼 수정해야할 필요가 있다. 예를 들면 테스트 리포트 같은 경우에도 과정을 하나씩 나열하고 결론을 쓰는 것이 아니라, 신문 기사처럼 가장 중요한 것을 두괄식으로 쓰는 것이다.

자, 이제 요약하면,
1. 디자인팀이 전체 개발팀과 완전히 한 팀이 되어야 한다.
2. 프로젝트 초반에 최소한의 사용자 조사와 모델링을 한다.
3. 부지런히 베껴서 빨리 프로토타입을 만들고 반복하여 테스트한다.

정도로 요약해 볼 수 있다. 자! 이제 우리도 시작해보자.

1. Agile Persona
시간이 없다는 개발팀을 설득하고 설득하여 약 3주간의 리드 타임을 확보하였다.
이를 위하여 pxd에서는 여러 차례 적용하였던 빠른 user research 기법을 사용하였는데, 이 기법의 핵심은 모든 것을 거꾸로 하는 것이다. 즉 전통적으로 user interview ->modeling(critical characteristics)->persona->strategy 순서로 진행했다면, 이번에는

1. peer interview (2~4) -> 2. persona assumption -> 3. questionnaire(critical characteristics) -> 4. user interview

즉 아주 짧은 peer interview를 한다. peer interview란 프로젝트를 함께 진행하는 구성원들간에 '너는 어때?'하고 물어보는 것이다. 물론 정말 시간이 없으면 1번도 하지 않겠지만, 그럴만큼 급한 경우는 없다. 1-2시간에 끝나기 때문이다.

그리고 그것을 통해 대략 퍼소나에 대한 감을 잡은 후,퍼소나를 구분할 수 있는 설문지를 만든다. 이것도 1-2시간안에 끝난다. 설문지는 key critical characteristics를 구별할 수 있는 4-7개의 문항으로 2-3분 내에 끝나게 만든다. 전통적인 설문지가 상호 배타적인 보기(라디오)로 이루어져 있어서 무엇과 무엇 중에 선택을 해야한다면, pxd에서 사용하는 설문지는 모든 문항이 체크로 이루어져 있어 응답자들이 머리를 텅 비우고 답할 수 있게 만들어져 있다. 또한 이 설문지의 모든 보기는 critical char.의 구성 요소가 되도록 만들어져 있기 때문에, 응답자의 대답을 보는 즉시 퍼소나 패턴을 판별할 수 있도록 되어 있다.

이렇게 설문지를 계속 돌리면서 궁금한 패턴이 나타나는 사람들을 불러서 질문한다. 이 작업은 주어진 시간이 될 때까지 한다. 그렇게 하기 위해선 아는 사람들에게 설문지를 돌리고, 궁금한 사람들을 즉시 부르거나 전화로 물어볼 수 있어야 한다. 당연히 필요하면 설문지도 계속 수정한다. 필요하면 persona assumption도 바꾼다. Agile하게! 대략 하루-이틀 정도 걸린다.

첫 번째 주- 일주일만에 user research와 persona & strategy building을 마치고

2. Framework Sketch Workshop
5명의 프로젝트 외부 구성원을 초청하여 1시간동안 프로젝트 개요를 설명한 뒤, 본 프로젝트팀원 포함하여 8명이 각자 프레임웍 두 개씩 그려오기를 두 시간 동안 진행한 뒤, 각자 발표 시간을 가졌다. 거기서 가장 뚜렷한 방향을 가진 프레임웍 3개를 골라서

-퍼소나의 잡을 가장 잘 해결한 프레임웍
-안정적이고 익숙한 구조를 가진 프레임웍
-서비스의 고유한 컨셉을 가장 잘 시각적으로 보여주는 프레임웍

본 프로젝트 구성원 3명이 각각 발전시키기로 하고, 하루동안 작업한 후, 이를 다시 두 개로 통합하여 정리하고, 고객에게 제시하기 위한 준비를 마쳤다.

두 번째 주-일주일만에 프레임웍 15개 그려보고, 3개 골라 발전시키고, 결국 2개로 통합하여 정리

3. Rapid Design Styling
GUI 팀은 프레임웍 워크샵에서부터 참여하기 시작한 사람과 주 중반에 프레임웍이 3개 혹은 2개로 골라지는 시점에 참여하는 사람 등을 포함하여 초기부터 스타일링 작업을 시작하고 2주차 후반에 시안 작업을 시작하였다.

세 번째 주-고객과 최종 프레임웍 결정하고 디자인 시안 완성하여 3주 마지막에 디자인 결정하는 것이 목표 (진행중)

---------

이렇게 만들어진 최소한의 사용자 조사, 모델링, 전략을 가지고 개발에 들어가며, 개발이 Agile 하게 진행되는 경우 2주에 한 번씩 프로토타입을 만들고 테스트할 계획이다. (이렇게 준비했는데 개발이 agile하게 안 할 가능성 발생 ㅠㅠ)

여전히 Agile 프로세스에 앞서 약간의 waterfall을 하는 것이라 완전한 agile 주장자들에겐 변칙으로 보일 가능성도 있고, 또 매우 성급한 결론을 역으로 적용시키는 방식이라 전통적인 UCD 지지자들에게는 날림으로 보일 가능성이 있다. 그러나 Agile 개발 환경이 점점 더 필요하고 늘어나는 것이 대세가 된다면, 분노하고 거부하는 것만이 답은 아니라고 많은 사람들이 문헌에서 밝히고 있다.

그런데 이러한 방법을 진행하기 위하여 매우 중요한 부분이 하나 있다. 이렇게 진행하려면 프로젝트를 진행하는 사람이 매우 경험이 많아야 오류나 우왕좌왕을 피할 수 있다는 것이다. 사용자 조사 경험이나 사용자 인터페이스 설계 경험도 풍부해야겠지만, 도메인 지식도 풍부해야한다. 이 부분이 많은 문헌에서 간과하고 있지만, 필자가 생각하기에 가장 중요한 부분이다.

--------
참고 문헌 포인트로 Keywon Chung & Amy Chung 두 분이 도와 주셨다.
http://ux.stackexchange.com/questions/1919/resources-for-building-a-ui-ux-team-and-process/1940#1940

[참고##Lean UX##]

팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 2
Ad Test...