린과 애자일 그리고 진화하는 사용자 경험
린UX
이제 Lean UX, Agile이라는 말은 더 이상 낯설게 들리지만은 않는다.
많은 스타트업, 심지어 대형 서비스 업체에 이르기까지 린앤 애자일UX 방법을 적용하여 서비스를 만들고 있다. 린UX의 개념의 시초, 이런 린UX열풍을 불러 일으킨 근본격인 책을 소개하며 두루뭉술하게 퍼져있는 린UX의 개념을 견고하게 하고자 한다.
Part1. 린 UX 소개 및 기본원칙
Chapter 1. 린 UX의 세 가지 토대
린UX는 다음과 같은 개념을 기본으로 하고있다.
1. 디자인적 사고
사람들이 일상에서 무엇을 원하고 필요로 하는지, 특정 제품을 제작/포장/홍보/판매/지원하는 과정에서 사람들이 어떤 것을 좋아하고 싫어하는지 직접적인 관찰을 통해 얻어지는 혁신. 기술적으로 구현할 수 있고 고객가치와 시장기회로 전환 가능한 비즈니스 전략을 사람들의 니즈와 맞추기 위해 디자이너의 감성과 방법론을 활용하는 분야.
2. 애자일 개발 방법론
애자일 개발의 4가지 핵심원칙
- 프로세스나 툴보다 개인과 상호작용 - 팀과 아이디어를 계속 자유롭게 주고받아야 함
- 막연한 문서보다 작동하는 소프트웨어 - 동작하는 소프트웨어를 빨리 제작함으로써 시장에 적합산 솔루션인지 성공할만한지 평가할 수 있음
- 계약 협상보다 고객 협업 - 고객이나 팀 동료 전체가 의사결정에 참여, 문제와 솔루션에 대한 상호이해
- 계획을 고수하기보다 변화에 대응 - 제품 디자인은 제대로 안될것이라는 것 가정
3. 린스타트업 방법론
프로젝트의 위험을 최소화하고 팀이 빨리 만들고 배우기 위해 제작-측정-학습이라는 순환 피드백 활용
Chapter 2. 린UX의 기본원칙
린UX는 다음과 같은 사항을 기본 원칙으로 삼는다
제1원칙: 다분화 융합팀
제품을 만드는 데 참여하는 다양한 업무분야로 이루어진 팀. 다양한 업무문야 간의 높은 수준의 협업을 요구한다.
제2원칙: 작게, 집중하도록, 같은 공간에 배치
핵심 구성원 전체가 10명 이상이 되지 않도록 팀을 작게 유지하고, 하나의 프로젝트에 집중하도록 해야한다.
제3원칙: 진전은 산출물이 아닌 성과
기능이나 서비스는 산출물이고, 우리가 진정 달성해야 하는 비즈니스 목표는 성과다. 린UX는 명확한 비즈니스 성과의 관점에서 그 진전 여부를 측정한다.
제4원칙: 문제에 집중하는 팀
문제에 집중하는 팀은 단위 기능 구현이 아니라 비즈니스 문제 해결을 위해 일을 한다. 이것은 성과에 집중한다는 것의 연장선에 있다.
제5원칙: 불필요함 제거
궁극적인 목표 달성을 이끌어내지 못하는 것은 무엇이든 제거하는 것이다. 팀의 리소스는 언제나 제한적이다.
제6원칙: 최소 존속 크기
작은 작업 크기로 일하는 것. 적은 재고, 높은 품질. 검증도 구현도 안 된 디자인 아이디어로 이루어진 거창한 ‘기능명세'는 지양.
제7원칙: 지속적인 발견
제품 프로세스 내내 고객과 교감하는 진행 프로세스. 사용자 조사는 정기적이고 잦은 일정으로 진행되며 팀 전체가 참여한다.
제8원칙: GOOB: 새로운 사용자 중심성
getting out of the building. 사무실 안에서 결정되지 못할 싸용자의 니즈에 대해 탁상공론을 벌이지 말라는 것으로 그 답은 사무실 밖 시장에 있다.
제9원칙: 상호이해
무엇을, 왜 하고 있는지에 대해 팀 차원에서 공동의 이해가 있을수록 보고서나 상세 문서에 대한 의존도가 떨어진다.
제10원칙: 안티패턴: 스타적원, 권위자, 비밀요원
고유한 기술을 보유한 주목받고싶어 하는 엘리트 전문가는 팀의 화합을 깨트리고 협업을 꺼린다.
제11원칙: 작업물 공개
머릿속, 컴퓨터 속에 있는 작업을 누구나 볼 수 있게 해야한다.
제12원칙: 분석보다 제작
회의실에서 아이디어의 장단점을 논쟁하느라 반나절을 보내는 것보다 첫 버전을 만드는게 더 가치있음.
제13원칙: 확장보다 학습
아이디어가 적합한지 학습에 먼저 집중하고 그다음으로 규모에 집중.
제14원칙: 실패를 용인
팀이 실험에도 안전한 환경을 조성. 실패를 용인하면 실험문화가 싹트고 실험은 창의성을 키운다. 최고의 작품은 다작을 한 그룹에서 나온다.
제15원칙: 산출물에서 벗어나기
무엇을 만들고 있는가에서 어떤 성과를 이루어낼 것인가로 논의의 중심이 바뀌어야 한다.
Part2. 린UX의 프로세스
Chapter 3. 비전 정의와 실행 계획, 성과
린UX는 무엇이든 세상을 변화시키는 성과를 만들어내는 것을 목표로 한다. 그러므로 요구사항이 아니라 가정을 바탕으로 일을 시작해서 이에따른 가설을 세우고 검증하며, 기대하는 성과가 나타나는지를 가시적으로 측정한다. 린UX의 프로세스에서는 다음과 같은 항목들을 알아야 한다.
1. 가정: 실제로 일어날 것이라 믿는 대전제
2. 가설: 제품이나 이용과정의 특정 부분에 대한 가정을 실험에 맞게 작은 단위로 기술한 것.
3. 성과: 시장에서 나타나는 가설에 대한 타당성 여부를 입증하는 시그널. 대개 정량적 수치지만 정성적으로도 나타남.
4. 퍼소나: 문제 해결의 대상이 되는 사용자 모델
5. 기능: 원하는 결과물을 도출해내기 위한 제품의 변경 또는 개선
1. 가정
가정을 공표하는 것이 린UX 프로세스의 첫 단계다.
사전준비 항목:
제품 사용현황 분석 보고서: 현재 통용되는 제품이 어떻게 활용되고 있는가?
제품 사용성 평가보고서: 고객들이 제품을 사용하면서 특정 행동을 보이는 이유는 무엇인가?
시행착오에서 얻은 정보: 이슈를 고치기 위해 어떠한 시도를 하였고 효과가 있었는가?
회사실적과의 연관성 분석: 이 문제를 어떻게 해결하는지가 회사 실적에 영향을 미치는가?
경쟁사분석: 경쟁자들은 같은 이슈를 어떻게 대처하고 있는가?
문제기술
문제기술은 세가지 요소로 이루어진다.
제품/시스템의 현재 목표
사업의 이해관계자가 다루고자하는 문제(목표를 달성하지 못한지점이 어디인가?)
구체적인 솔루션기술이 아닌 개선을 위한 명확한 요구사항
문제 기술 템플릿
[서비스명]은 [어떤목표]을 달성하기 위해 만들어졌다. 관찰해본 바로는 이 제품/서비스가 [어떤목표]을 충족하지 못했고, 이것은 우리 사업에 [어떤 부작용]을 일으키고있다 [어떤 측정할 수 있는 기준들]을 토대로 우리 고객들을 더 만족하게 하려면 어떻게 [서비스명]을 개선해야 할까?
문제 기술은 가정으로 가득 차 있다. 팀에서 할 일은 문제 기술 내용을 핵심 가정으로 해체하는 것이다.
가정문서
우리 고객들은 —하려는 니즈가 있다.
이런 니즈는 —으로 해결될 수 있다.
우리의 초기 고객은 —이다(일 것이다)
고객들이 우리 서비스에서 얻어내려는 가장 큰 가치는 —이다.
고객들은 부가적인 이득으로 —또한, 얻을 수 있다.
우리는 —를 통해 주 고객층을 확보할 수 있을 것이다.
우리는 —으로 돈을 벌 수 있을 것이다.
시장에서 우리의 주 경쟁자는 —이 될 것이다.
우리는 —으로 그들을 이길 것이다.
우리의 가장 큰 제품 위험은 —이다.
우리는 —을 통해 이 문제를 해결할 것이다.
잘못된 걸로 판명될 경우, 우리의 사업/프로젝트의 실패 원인이 될 수 있는 또다른 가정은 —이다.
사용자가정
사용자는 누구인가?
그들의 일이나 삶에 있어서 우리 제품이 적합한 곳은 어디인가?
우리 제품이 풀어야 할 문제는 무엇인가?
언제 그리고 어떻게 우리 제품이 활용되는가?
어떤 기능이 중요한가?
우리 제품은 어떻게 보이고 활용되어야 하는가?
가정에 대한 우선순위 정하기
모든 가정을 다 테스트할 수는 없다. 정리된 가정 목록에서 가장 위험도가 높은 항목부터 착수하려면 어떤 항목이 위험도가 높은지를 파악해야 한다. 가정 항목 중 위험도가 크고 불확실할수록 검증의 우선순위도 높아진다.
2. 가설
우선순위가 정해진 가정 목록이 정리되었으면 가설 기술을 작성할 수 있다.
가설기술 포멧
우리는 [이 기술이 사실이라는 것]을 믿는다.
시장에서 수집한 반응: [정성적 피드백] 또는 [정량적 피드백] 또는 [핵심성과지표의 변화]를 보면서 우리가 [맞았음/틀렸음]을 알게 된다.
가설이 너무 커서 한번에 테스트할 수 없을 때도 있다. 유동적인 부분이 너무 많고, 지나치게 하위가설이 포함되었을 때 그러하다. 이럴 때 가설을 더 세분화 하는게 도움된다.
우리는
[이러한 사람들/퍼소나]을 위해
[이것을 실행/이 기능을 구현/이 경험을 창조]하는 것으로
[이런 성과]를 달성할 수 있다고 믿는다.
[시장반응, 정량적 수치 또는 정성적 통찰]을 확인해봤을 때
사실 여부를 알 수 있다.
이때 가설 증명에서 숫자가 전부는 아니다.
3. 성과
가입자 증가나 이용률 증대처럼 달성하고 싶은 두어가지의 상위 레벨의 성과가 있을 것이다. 이러한 성과를 작은 단위로 세분화 하는 것을 생각해보자. (이메일 마케팅에서의 더 많은 클릭률, 쇼핑카트에 담기는 상품 수의 증가 등)
4. 퍼소나
퍼소나는 변경할 수 없는 것이 아니다. 퍼소나 제작 방법은 가정에서 시작한 다음 그 가정을 입증하는 사용자 조사를 하는 것이다.
퍼소나 양식
스케치와 이름
행태적 인구통계학 정보
페인포인트와 니즈
잠재적 솔루션
5. 기능
원하는 성과를 달성하는 데에 활용할 수 있는 기능, 제품, 서비스에 대해 생각
하위가설 조합
결과적으로 위 5가지 항목을 알면
가설목록 작성할 수 있다
가설 목록은 이러한 형태를 띈다:
우리는 [기능을 제작]
을(를)위해서 [퍼소나]
달성하려고 한다 [성과]
Chapter 4. 린UX의 협업 기반 디자인
디자인의 방향에 대해 합의를 이루는 가장 효과적인 방법은 처음부터 끝까지 협업하는 것이다.
대화를 많이 해야 한다. 공동 디자인 세션에서 팀은 함께 스케치하고 결과물을 비평하고 궁극적으로 팀이 성공과 가장 가깝다고 느끼는 솔루션으로 의견을 모은다. 결과물은 대부분 완성도가 낮은 오루파이 스키체와 와이어프레임으로 구성된다. 예상한대로 동작하지 않으면 빠르게 방향 전환이 가능하다.
디자인 스튜디오 진행 프로세스
1단계. 문제 정의와 제약
2단계. 개인별 아이디어 제안
3단계. 프리젠테이션과 비평
4단계. 피드백을 반영하여 반복적인 수정과 정교화
5단계. 팀 아이디어 도출
스타일가이드
요소의 형태 요소벌 최소/최대크기, 가로/세로 제한, 요소에 필요한 모든 스타일에 대한 상세한 설명을 포함
화면 배치 화면 특정 영역에 지속해서 위치해야하거나, 디자인 패턴에서 벗어날만한 모든 예외적 요소에 대해 명확하게 설명
사용시점 언제 라디오3 버튼보다 드롭다운 메뉴를 사용하는지 UI 요소 선택을 결정짓는 요인이 무엇인지 팀 모두가 반드시 알 수 있게 해야한다.
성공적인 스타일가이드는 ‘접근하기 쉬워’야하고, ‘지속해서 개선되는(라이브 문서)’여야하고, ‘실행가능(코드뿐만아니라 그래픽과 와이어프레임 모음)까지도 활용 가능해야 한다.
Chapter 5. MVP와 실험
MVP는 2가지 쓰임새로 사용된다.
팀이 무언가 먼저 배우기 위해서, 시장에 제공할만한 가치가 아니라 시장이 무엇을 윈하는지 이해하려고
가능한 빨리 시장에 가치를 전달하기 위해
가장 먼저 할 일은 무엇을 학습할것인지 정하는 것이다.
아래의 질문을 생각하면 유용하다.
내가 만드는 솔루션에 대한 니즈가 있는가?
내가 제공하는 솔루션과 기능에 가치가 있는가?
나의 솔루션은 사용하기 편한가?
1은 사용자조사로 답을 얻을 수 있고, 2,3은 MVP를 이용하면 된다.
MVP는 가능한 작아야하고 학습에 초점이 맞춰져야한다.
MVP를 프로토타이핑 해 보아라. 제품의 모든 경험을 다 프로토타이핑 할 필요는 없다. 오히려 우리 고객과 비즈니스에서 가장 중요한 부분만 만들어 보라. 만들어진 프로토타이핑 MVP를 많이 노출할수록 타당성있는 통찰력도 더 증가한다.
MVP를 제작하기 위해서 굳이 프로토타이핑이 필요한건 아니다.
내가 학습하고자 하는 것은 무엇인가?
가설을 검증하기 위해 시장으로부터 필요한 주요한 신호는 무엇인가?
주요한 신호를 나타내는데 활용되는 지표를 테스트할 수 있는 또 다른 신호가 있는가?
이러한 정보를 수집하는 가장 빠른 방법은 무엇인가?
→ 이것들을 생각해 봤을 때 프로토타이핑이 필요하지 않고 이메일, 구글애드, 랜딩페이지, 검색로그, 퍼널분석, A/B테스트 등등으로 해결을 할 수도 있다.
Chapter 6. 조사와 피드백
린 UX에서는 지속적이고 협력적인 조사를 실행한다.
팀이 함께 실제 현장에 나가서 협업 기반의 발견을 해야 한다.
팀이 함께 질문, 가정, 가설과 MVP를 리뷰하라. 무엇을 학습해야 하는지 팀이 결정하라.
팀이 함께 우리의 학습 목표를 다루기 위해서 누구를 대상으로 조사할지 결정하라.
대화를 이끌가는데 활용할 인터뷰 가이드를 작성하라
팀 인원을 인터뷰할 짝으로 나누어라. 각 짝은 다양한 역할과 업무배경이 섞이도록 한다.
MVP 버전을 모든 짝에게 나눠준다
각 인터뷰 팀을 고객/사용자와 만나도록 내보낸다
한 명이 인터뷰를 하고 나머지 한 명은 기록을 담당한다.
질문으로 시작해서, 대화하고 관찰한다.
MVP는 세션 후반에 시연하고 고객이 사용해볼 수 있도록 한다.
고객피드백을 잘 기록한다
인터뷰 진행자가 마무리 했을 때, 역할을 바꿔 기록자에게 후속 질문할 기회를 준다.
인터뷰 마지막에 유용한 피드백을 줄 적합한 사람을 소개해줄 수 있는지 물어본다.
팀원들이 다시 모였을 때, 각 그룹은 기록한 내용을 읽어주고, 패턴으로 나타난 것을 검토한다. 이 과정에서 몇가지 가정이 증명되고 또 다른 몇가지는 틀린 것으로 판명난다.
린 UX에서 중요한 최선의 방법은 일정 리듬이 생기게끔 정기적인 고객 참여를 게획하는 것이다. (매주, 목요일 3명의 사용자)
“모든 것을 테스트하라"
규칙적인 리듬을 유지하는 사용자 테스트를 운영하기 위해 모든것을 테스트하자는 방침을 도입해야 한다. 팀 전체가 테스트 일자를 데드라인으로 삼고 무리하지 않도록 한다.
(스케치, 정적인 와이어프레임, 하이파이 비주얼 목업, 조작가능한 목업, 코드프로토타입 등)
고객지원 담당자와의 협업
고객지원 담당자는 우리가 전체 프로젝트 과정에서 만나는 것 보다 더 많은 고객과 일상적으로 이야기한다. 그들의 지식을 활용하자
고객지원 담당자를 만나 우리가 담당하고 있는 제품 영역에 대해 고객에게 어떤 이야기를 들었는지 물어본다.
이번 달에 고객들의 좋아하는 것은 무엇인지? 싫어하는 것은 무엇인지? 고객 트렌드를 이해하기 위해 정기적인 월간 미팅을 연다.
고객지원 담당자의 지식을 활용하여 우리팀에서 담당하고 있는 도전 과제를 어떻게 해결할지에 대해 배워본다. 디자인세션과 디자인리뷰에 포함하는 것도 방법
가설을 그들의 전화 스크립트에 포함시키는 것은 아이디어를 테스트하는 가장 저렴한 방법 중 하나다. 고객이 고려 중인 아이디어와 관련 있는 불만을 문의해 왔을 때 이를 해결하는 방법으로 아이디어를 제안해본다.
Part3. 적용하기
용어정리
스크럼: 애바일 방법론은 일정하게 정해진 주기, 구체적인 팀 구성, 높은 팀 권한을 장려한다. 스크럼은 애자일에서 가장 인기 있는 방법론이다.
유저스토리: 사용자에게 이점이 있는 것을 표현한 최소한의 단위로 일반적인 유저스토리는 다음과 같은 문법을 활용하여 작성한다. [사용자 유형]으로써 [어떤 혜택이 발생하기]때문에 나는 [어떤 일을 하고]싶다.
백로그: 유저스토리에 우선순위를 부여한 목록으로 백로그는 애자일에서 가장 강력한 프로젝트 관리 툴이다. 백로그를 현실적으로 정리하는 것으로 매일의 업무량과 계속해서 수집되는 정보 사이에서 어디에 힘을 쏟아야 할지 조정한다. 팀이 애자일한 상태를 유지하는 방법이다.
스프린트: 하나의 주기. 각 스프린트의 목적은 작동하는 소프트웨어를 만들어내는 것이다. 대부분의 스크럼 팀이 2주 주기로 스프린트를 운영한다.
스탠드업: 매일하는 짧은 팀 미팅, 모든 구성원들이 그날의 과제를 이야기하고 무엇을 하고 뭇슨 일이 일어날지를 공개적으로 밝힌다.
회고: 각 스프린트의 마지막에 일어나는 미팅, 무엇이 미흡했고, 팀이 다음 스프린트에서 어떻게 그 프로세스를 개선하고자 하는 것.
이터레이션 계획 미팅: 매 스프린트가 시작할 때 하는 미팅. 다음 번 스프린트를 계획한다.
http://www.yes24.com/Product/Goods/11043345
