[독후감] 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 Series의 Running Lean에 이은 두 번째 책은 Lean UX이다. 저자인 Jeff Gothelf는 lean design studio인 Proof를 창업했는데, 이후 Neo Innovation Lab에 합병되었다. Josh Seiden은 Cooper와 LUXr를 거쳐 현재 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##]