들어가며

소프트웨어에서 가장 큰 뻥은 다음 버전에서 구현하자는 것이다.

린 원칙은 3가지 방법으로 린 UX에 적용된다. 첫 번째는 UX 디자인 프로세스에서 불필요한 부분을 제거하는 것으로 엄청난 문서 작업에서 벗어나 팀의 발전적인 학습을 이끄는 디자인 제작물만을 만든다. 두 번째는 디자이너와 개발자, 제품 관리자, 품질 관리자, 마케터와 그 밖의 다른 사람들이 투명하고 조화롭게 일하는 시스템을 조성하며, 다분야 간 협업을 통해 비디자이너들을 디자인 프로세스에 참여시킨다. 마지막으로 가장 핵심일 수 있는 마음가짐의 변화는 실험에 기반을 둔 응용 모델에서 얻을 수 있다. 이 원칙은 스타 디자이너에 의지하지 않고도 최선의 해결책을 찾아낼 수 있는 것으로, 아이디어가 의도한 목표에 잘 맞는지를 신속한 실험과 측정을 통해 빠르게 도출하는 것이다.

린 UX는 디자인적 사고(Design Thinking)와 애자일 개발(Agile Development) 철학이라는 두 가지의 다른 토대로 존재한다. 디자인적 사고는 문제 해결, 긴밀한 협업을 통한 지속적인 반복 개선, 완벽함으로 가기 위한 경로 조정 방법처럼 솔루션에 초점을 두는 접근방식이다. 이를 통해 구체적인 아이디어 도출, 프로토타이핑 구현, 솔루션의 타당성을 밝히는 학습 단계를 거치며 제품의 목표를 향해 일을 진행한다. 애자일은 가치 기반의 소프트웨어 개발 방법에 초점을 맞추며, 작동하는 소프트웨어를 빠르게 고객에게 전달하고 중간중간 새로운 학습 내용을 기반으로 주기적으로 목표에 맞춰가는 것이다.

린 UX를 실행하면서 나는 '마무리가 덜 된', '준비되지 않은', '보기 흉한' 작업을 보여줄 때마다 감정을 다스려야 했다. 이런 방식으로 일하려면 고기능(high-function) 팀의 지원이 요구된다. 여러분은 어느 팀이라 해도 첫 번째 시도에서 제대로 된 것을 얻지 못하며 점진적으로 발전시키는 반복 개선을 위해 함께 일한다는 것을 알아야 한다.

이 책이 아직도 다음 버전을 기다리고 있는 UX 디자이너들의 생각을 깨웠으면 한다. 비록 내용은 기존의 프로세스를 진화시키는 데 도움이 되는 전략과 기법으로 채워져 있지만, 린 UX는 마음가짐이라는 것을 기억하길 바란다. 마음가짐이야말로 린 UX의 핵심이다.

Part 1_ 린 UX 소개 및 기본 원칙

Chapter 1_ 왜 린 UX인가?

디자이너의 포토샵 작업만큼 빠른 속도로 개발팀은 새로운 코드를 제품에 반영하고 있으며, 품질과 반응시간에 대해 예기치 않게 등장하는 고객 기대에서 경쟁우위를 선점할 수 있도록 조기 출시와 잦은 업데이트, 시장 반응 수집, 학습에 근거한 반복적인 개선과 같은 짧은 개발 주기를 도입하고 있다.

린 UX는 굉장히 상호협력적이고 다기능적이다. 왜냐하면, 제작현장과 동떨어진 특별한 작업을 더는 하지 않아도 되기 때문이다.

우리는 시장 반응을 근거로 한 객관적인 비즈니스 목표 관점으로 디자인에 대한 논의를 새롭게 조망하며 어떤 것이 효과가 있는지 측정하고, 학습하고, 조정할 수 있다.

린 UX에는 세 가지가 있다. 먼저 디자이너를 위한 프로세스 변화로 이해하는 것이 가장 쉽지만, 실은 프로세스의 변화 그 이상이다. 다음은 우리 업무를 새로운 시각으로 대하는 마음가짐이며 소프트웨어를 관리하는 방법이기도 하다.

Chapter 2_ 기본 원칙

린 UX의 세 가지 토대

디자인적 사고 (Design Thinking)

'사람들이 일상에서 무엇을 원하고 필요로 하는지, 특정 제품을 제작/포장/홍보/판매/지원하는 과정에서 사람들이 어떤 것을 좋아하고 싫어하는지 직접적인 관찰을 통해 얻어지는 혁신'이며, '기술적으로 구현할 수 있고 고객가치와 시장기회로 전환 가능한 비즈니스 전략을 사람들의 니즈와 맞추기 위해 디자이너의 감성과 방법론을 활용하는 분야'다.

애자일 개발 방법론

프로세스나 툴보다 개인과 상호작용
막연한 문서보다 작동하는 소프트웨어
계약 협상보다 고객 협업
계획을 고수하기보다 변화에 대응 - 린 UX의 가정은 첫 번째 제품 디자인은 제대로 안될 것이라는 것이다. 그러므로 최대한 신속하게 잘못된 점을 찾는 것을 목표로 한다.

린 스타트업 방법론

'제작-측정-학습'이라는 순환 피드백을 활용한다. 팀은 최소 존속 제품(MVP)을 만들고 신속하게 출시하여 될 수 있으면 빨리 학습 과정에 진입할 수 있게 한다.

린 스타트업의 철학은 '기존의 소프트웨어 개발기법보다 더 빠르게 고객 피드백을 반영하며 빠르게 프로토타이핑해서 시장 가설을 테스트하는 것'이다.

MVP가 꼭 코드로 만들어지는 것은 아니며, 최종 경험에 대한 예상일 수도 있다. MVP로부터 학습한 것을 수집하고 이를 토대로 아이디어를 발전시키는 과정이 계속 반복된다.

린 UX는 제품의 진정한 본질을 끌어내려는 기법으로 더 빠르고, 협력적이고, 다분야 융합적인 방법을 강조하며, 목표로 하는 제품의 실제 경험에 대한 상호이해 형성에 집중하는 것이다.

기본 원칙

제 1 원칙: 다분야 융합팀

소프트웨어 공학, 제품 관리, 인터랙션 디자인, 비주얼 디자인, 콘텐츠 전략, 마케팅, 품질관리(QA) 등 모두가 린 UX팀에 포함되어야 한다.

관련된 모든 업무분야로부터 아이디어에 대한 통찰력을 이끌어낸다.

제 2 원칙: 작게, 집중하도록, 같은 공간에 배치

핵심 구성원 전체가 10명 이상이 되지 않도록 팀을 작게 유지하고, 하나의 프로젝트에 집중하도록 하라.

제 3 원칙: 진전은 산출물이 아닌 성과

성과를 관리하면서(성과를 향해 점진적으로 전진하면서), 우리가 만든 기능의 효과성에 대한 통찰력을 얻게 되는데, 간혹 기능의 성과가 좋지 않을 경우, 그것을 지속해야 할지, 변화시켜야 할지, 교체해야 할지 등에 대한 객관적인 결정을 내릴 수 있다.

제 4 원칙: 문제에 집중하는 팀

단위 기능 구현이 아니라 비즈니스 문제 해결을 위해 일을 한다.

제 5 원칙: 불필요함 제거

성과에 기여하지 못하고 낭비로 간주되는 것은 무엇이든 간에 팀의 프로세스에서 제거해야 한다.

제 6 원칙: 최소 존속 크기

팀이 앞으로 나아가는 데에 필요한 디자인만 하는 것을 의미하며 검증도 구현도 안 된 디자인 아이디어로 이루어진 거창한 '기능명세'는 지양하는 것이다.

제 7 원칙: 지속적인 발견

사용자들이 우리 제품으로 무엇을 하는지, 왜 그렇게 하는지를 이해하는 것이 목표다. 사용자 조사는 정기적이고 잦은 일정으로 진행되며 팀 전체가 참여한다.

제 8 원칙: GOOB - 새로운 사용자 중심성

'사무실 밖으로 나가기(Getting Out Of the Building)'

사무실 안에서 결정되지 못할 사용자의 니즈에 대해 탁상공론을 벌이지 말라는 것으로, 그 답은 사무실 밖 시장에 있다는 의미이다.

제 9 원칙: 상호이해

무엇을, 왜 하고 있는지에 대해 팀 차원에서 공동의 이해가 쌓일수록, 일을 지속하기 위해 간접적으로 전달받는 보고서나 상세한 문서에 대한 의존도가 낮아진다.

제 10 원칙: 안티 패턴 - 스타직원, 권위자, 비밀요원

린 UX는 팀 기반의 사고방식을 주창한다. 스타직원이나 권위자, 비밀요원 또는 그 밖에 고유한 기술을 보유한 엘리트 전문가는 팀의 화합을 깨뜨리고 협업을 꺼린다.

제 11 원칙: 작업물 공개

머릿속, 컴퓨터 속에 있는 여러분의 작업을 누구나 볼 수 있게 하라는 의미다. 화이트보드, 폼보드, 벽, 출력물, 포스트잇 등을 활용해서 진행 중인 작업을 팀 구성원, 동료, 고객에게 보여준다.

제 12 원칙: 분석보다 제작

잠재적인 시나리오를 분석하는 대신 뭔가를 만들어서 사무실 밖으로 들고 나가 확인하는 게 낫다.

제 13 원칙: 확장보다 학습

규모를 확대하기 전에 아이디어가 적합한지 확인하는 것은 광범위한 기능 배포에 따른 위험을 완화한다.

제 14 원칙: 실패를 용인

팀이 성공하려면 실패로부터 안전해야만 한다. 실패를 용인한다는 말은 팀이 실험에도 안전한 환경이라는 의미다. 그 철학은 기술적인 환경(아이디어를 안전한 방법으로 밀어붙일 수 있고)과 문화적인 환경(실패로 끝난 시도로 불이익을 받으면 안 된다) 모두에 적용된다.

무엇보다 실패의 원인과 결과가 투명하여 모두가 공감할 수 있어야 하고, 이를 통해 구성원과 조직 간의 신뢰가 쌓여야 발전적인 원동력이 될 수 있다.

제 15 원칙: 산출물에서 벗어나기

팀의 관심은 어떤 기능이 고객들에게 가장 큰 효과가 있는지 지속해서 학습하는 데 집중해야 하고, 팀이 직접 사용하면서 얻은 지식이 그 역할을 대신할 수 없다. 무엇보다 중요한 것은 시장 반응에 대해 측정되는 제품의 품질이다.

Part 2_ 프로세스

디자이너인 아르티는 자리로 돌아와 디자인을 다듬기 시작했고, 프론트엔드 개발자인 마크는 해당 페이지의 개발을 시작하면서 아르티의 디자인을 기다리지 않고 기본 요소를 배치하는 데 팀이 구축해 둔 라이브 스타일 가이드에 있는 기존의 컴포넌트를 사용했다. 릭은 프로젝트 위키 페이지를 열고 팀이 앱 동작에 관해 결정한 사항을 기록했는데 다음에 제품 오너와 함께 이 결정사항을 리뷰할 예정이다. 그리고 QA 테스터인 올가는 새로운 화면에 대한 테스트 시트를 만드는 작업을 시작했다.

팀은 협력적이고 반복해서 병렬로 일을 진행하며, 최소한의 산출물과 아주 적은 양의 문서를 만들어 내는 동시에 작동하는 소프트웨어와 시장의 피드백에 집중한다.

Chapter 3_ 비전 정의와 실행 계획, 성과

무엇이든 세상을 변화시키는 성과를 만들어내는 것을 목표로 한다. 그러므로 요구사항이 아니라 가정을 바탕으로 일을 시작해서 이에 따른 가설을 세우고 검증하며, 기대하는 성과가 나타나는지를 가시적으로 측정한다.

가설 기술은 프로젝트의 출발점이며 과업의 명확한 비전을 설명하는 동시에 프로젝트 팀원들과 관리자 간의 대화가 결과물(예. 싱글사인온 기능구현) 중심에서 성과(예. 신규 가입자 수 증가) 중심으로 변화하게 한다.

가정

린 UX의 첫걸음은 가정을 공식적으로 알리는 것이다.

가정 공표 활동을 거치면서 화이트보드에 모두의 아이디어를 담아내는 과정에서 팀 내의 각기 다른 의견이 드러나는 동시에 적용해볼 만한 솔루션의 윤곽이 보이기도 한다.

사전 준비 항목

제품 사용현황 분석보고서: 현재 통용되는 제품이 어떻게 활용되고 있는가?
제품 사용성 평가보고서: 고객들이 제품을 사용하면서 특정 행동을 보이는 이유가 무엇인가?
시행착오에서 얻은 정보: 이슈를 고치기 위해 어떠한 시도를 하였고 효과가 있었는가?
회사실적과의 연관성 분석: 이 문제를 어떻게 해결하는지가 회사실적에 영향을 미치는가?
경쟁자 분석: 경쟁자들은 같은 이슈를 어떻게 대처하고 있는가?

문제 기술은 팀이 해야 할 일이 무엇인지에 명확히 초점을 맞추도록 하는 동시에 모든 중요한 제약조건을 정의한다.

문제 기술은 3 가지 요소로 이루어진다.

제품/시스템의 현재 목표
사업의 이해관계자가 다루고자 하는 문제 (예. 목표를 달성하지 못한 지점이 어디인가?)
구체적인 솔루션 기술이 아닌 개선을 위한 명확한 요구사항

템플릿

[서비스명/제품명]은 [이러한 목표]를 달성하기 위해 만들어졌다. 관찰해본 바로는 이 제품/서비스가 [이러한 목표들]을 충족하지 못했고, 이것은 우리 사업이 [이러한 부작용]을 일으키고 있다. [이러한 측정할 수 있는 기준들]을 토대로 우리 고객들을 더 만족하게 하려면 어떻게 [서비스명/제품명]을 개선해야 할까?

문제 기술은 가정으로 가득 차 있다. 팀에서 할 일은 문제 기술 내용을 핵심 가정으로 해체하는 것이다.

이 활동의 목표는 팀이 그럴 법하다고 생각한 것에 대해 검토하고 기술을 모으는 것이다. 혹시라도 반발이 심한 포인트가 생겼을 때는 다른 관점으로 접근하도록 한다.

가정문서

우리 고객들은 _______하려는 니즈가 있다.
이러한 니즈는 _______으로 해결될 수 있다.
우리의 초기 고객은 _______이다(일 것이다).
고객들이 우리 서비스에서 얻어내려는 가장 큰 가치는 _______이다.
고객들은 부가적인 이득으로 _______ 또한, 얻을 수 있다.
우리는 _______를 통해 주 고객층을 확보할 수 있을 것이다.
우리는 _______으로 돈을 벌 수 있을 것이다.
시장에서 우리의 주 경쟁자는 _______이 될 것이다.
우리는 _______으로 그들을 이길 것이다.
우리의 가장 큰 제품 위험은 _______이다.
우리는 _______을 통해 이 문제를 해결할 것이다.
잘못된 걸로 판명될 경우, 우리 사업/프로젝트의 실패 원인이 될 수 있는 또 다른 가정은 _______이다.

사용자 가정

사용자는 누구인가?
그들의 일이나 삶에 있어서 우리 제품이 적합한 곳은 어디인가?
우리 제품이 풀어야 할 문제는 무엇인가?
언제 그리고 어떻게 우리 제품이 활용되는가?
어떤 기능이 중요한가?
우리 제품은 어떻게 보이고 활용되어야 하는가?

만약 초기 제품이라면 비즈니스 가정에 더 많은 시간을 투자할 것이고, 성숙한 제품을 보유하고 있다면 사용자 가정에 집중할 것이다. 이 방법은 광범위하게 영역을 잡은 다음 프로젝트의 모든 차원에서 가정을 검토해가는 것이 포인트다.

가정 항목 중 위험도가 크고 불확실할수록 검증의 우선순위도 높아진다.

가설

우리는 [이 기술이 사실이라는 것]을 믿는다.

시장에서 수집한 반응: [정성적 피드백]과/또는 [정량적 피드백]과/또는 [핵심성과지표의 변화]를 보면서 우리가 [맞았음/틀렸음]을 알게 된다.

어쩌다 보면 세워놓은 가설이 너무 커서 한 번에 테스트할 수 없을 때도 있다. 유동적인 부분이 너무 많고, 지나치게 많은 하위 가설이 포함되었을 때 그러한데, 이럴 때 가설을 보다 상세한 단위로 세분화하면 도움이 된다.

가설 세분화

타깃 고객이 정확히 누구인지
특정 기능이나 개선사항
새로운 기능을 통해 얻게 될 혜택
가설이 사실이었는지를 판단하는 내용

감성적인 측면은 정량적 측정이 어려우므로 성공측정의 기준에 정성적 반응을 포함하는 것은 매우 중요하다. 사람들이 디자인으로 인해 즐거워하는가? 우리 제품을 친구들에게 추천하고 있는가? 트위터에 언급하는가? 성공측정을 위한 매트릭스를 정의할 때 잊지 말자. 숫자가 전부는 아니다.

현 상태를 나타내는 측정값(매트릭스)은 아이디어의 성공 여부를 결정하는 기준점이 되므로 팀이 목표를 확실히 알 수 있도록 미리 파악해놓을 필요가 있다.

가설을 기술하는 것은 제작하려는 결과물과 서비스를 이용할 퍼소나 정의, 상황에 적합할 것으로 믿는 기능을 블록 쌓기처럼 하나로 조합하는 것이다.

성과

가입자 증가나 이용률 증대처럼 달성하고 싶은 두어 가지의 상위레벨의 성과가 있을 것이다. 이러한 상위레벨의 성과를 작은 단위로 세분화하는 방법을 생각해보자. 사용을 늘리는 행동에는 어떤 것이 있나? 더 많은 방문객이 오는 것? 이메일 마케팅에서의 더 많은 클릭율? 쇼핑카트에 담기는 상품 수의 증가? 큰 성과를 낼 것이라 예상되는 개별 성과목록을 만들 때 팀 브레인스토밍이 도움이 되기도 하며, 이 리스트는 하나로 합쳐지게 된다.

퍼소나

가정에서 시작한 다음 그 가정을 입증하는 사용자 조사를 하는 것이다. 이렇게 하면 몇 달에 걸친 필드 인터뷰 대신 단 몇 시간 만에 프로토 퍼소나를 만들 수 있다. 프로토 퍼소나는 누가 왜 우리 제품을 사용하는지 또는 할지에 대해 우리가 할 수 있는 최선의 추정이다. 팀 구성원 모두의 가정을 끄집어내기 위해 팀 전체가 함께 참여하며 쓱쓱 퍼소나를 그려본다. 그런 다음 계속되는 조사를 통해서 최초의 예측이 얼마나 정확했는지 빠르게 알아내고 더불어 타깃 사용자(퍼소나)를 조정할 수도 있으며, 우리가 한 디자인 역시 조정될 수 있다.

퍼소나 구성 요소

간단한 퍼소나 스케치와 이름, 역할을 넣은 영역
기본적인 인구통계학적 정보 영역이며 구체적인 행동유형을 예측할 수 있는 정보
현재 제품이나 상황에 대한 사용자의 니즈와 불만
니즈에 대한 잠재적인 솔루션을 적고, 이 정보는 기능이나 문제를 해결할 아이디어를 도출하는데 활용될 것

나이나 성별 등 인구 통계적 접근보다는 니즈나 활동으로 퍼소나를 구별하는 것이 좋다.

기능

누군가가 낸 기능 아이디어 하나로 디자인 프로세스가 시작되는 경우가 매우 빈번하고, 그 기능이 타당한지 밝히기 위해 결국 다시 일을 되돌리는 상황이 될 수 있으므로 유의해야 한다.

하위 가설 조합

가설을 쓸 때는 어떤 퍼소나(들)가 우리가 제안하는 솔루션에 적합한지 검토한다. 한 번에 한 명 이상의 퍼소나에 해당하는 해결책이 나타나는 것은 흔히 있는 일이고, 하나의 기능이 한 개 이상의 성과를 이끌어내는 가설 또한 일반적이다. 각 기술내용이 단 하나의 성과에만 적용되기 원하는 경우 가설을 두 부분으로 나누도록 한다.

중요한 것은 아이디어가 충분히 구체화되어 있어야 아이디어의 타당성을 확인할 수 있는 테스트 설계가 가능하다.

가설 목록

우리는: [기능을 제작]
을(를) 위해서: [퍼소나]
달성하려고 한다: [성과]

Chapter 4_ 협업기반 디자인

협업기반의 공동 디자인이 전체 팀의 디자인 IQ를 증가시킨다. 공동 디자인은 팀의 모든 구성원이 자신의 아이디어를 표현하도록 하고 디자이너들이 사용자 경험을 다듬어내면서 팀원들의 아이디어를 참조하여 한층 더 폭넓은 시야로 아이디어를 표현할 수 있도록 한다.

린 UX는 팀 구성원들 간의 기본 커뮤니케이션으로 대화를 권장한다. 그런 면에서 "프로세스나 툴보다 개인과의 상호작용"을 권장하는 애자일 선언과 부합한다.

협업기반 디자인 역시 UX 디자이너가 이끄는 활동이며 이를 위해 미팅을 소집하는 것 뿐만 아니라 미팅을 퍼실리테이팅하는 것까지도 UX 디자이너의 역할이다. 때로는 화이트보드를 활용한 개발자와의 1:1 세션이 될 수 있고, 또 어떤 경우는 팀 전체와 함께하는 디자인 스튜디오 활동이 될 수도 있는데 이 활동의 핵심은 바로 다양한 소속의 팀 구성원과 협업하는 것이다.

공동 디자인 세션의 결과물은 대부분 완성도가 낮은 로우파이 스케치와 와이어프레임으로 구성되며, 이 정도의 완성도가 실무에서 유연성을 유지하는 데 중요한 역할을 한다.

협업기반 디자인 실무

대시보드의 모든 콘텐츠와 기능을 어떻게 배치할지에 대한 내 아이디어를 화이트보드에 스케치했다. 내 스케치에 대해 설명하고는 꼭 개발자에게 화이트보드 마커를 넘겼다. 몇 번 왔다갔다하면서 결국 하나의 레이아웃과 인터랙션 구조로 의견을 모았고 그 스케치 결과는 사용하기 편리할 뿐 아니라 우리에게 주어진 2주의 스프린트 기간에 구현 가능한 목표이기도 했다.

디자인 스튜디오

디자인 스튜디오는 5~8명 정도로 운영하는 게 적당하다.

1단계. 문제정의와 제약사항 (15~45분 소요)

해결해야 할 문제와 공표했던 가정, 도출한 가설, 현실적인 제약을 인지하고 있는지를 확인한다.

2단계. 개인별 아이디어 제안 (10분 소요)

시트지의 박스마다 각자 구체적인 페인 포인트와 문제를 기술할 퍼소나의 이름을 적도록 한다.
6칸의 백지 시트를 (또는 때에 따라 이름이 붙여진) 앞에 두고, 모든 사람에게 5분 동안 각 퍼소나와 페인 포인트를 위한 솔루션을 6개 칸마다 완성도가 낮아도(low-fidelity) 상관없으니 스케치하게 한다. 단, 반드시 글이 아니라 시각적으로 표현(UI 스케치, 워크플로우, 다이어그램 등)해야만 한다.

3단계. 프레젠테이션과 비평 (1인당 3분 소요)

각 참여자가 3분 동안 자신의 스케치를 들고 발표한다.

발표자는 누구(퍼소나)를 대상으로 한 문제를 해결했는지 어떤 것이 페인 포인트로 알려졌는지(가설)를 구체적으로 밝히고 나서 스케치를 설명한다.

비평은 발표자의 의도를 분명히 하는 데 초점을 두어야 한다. "이 기능이 어떻게 퍼소나의 특정 문제를 나타내는 건가요?"와 같은 질문은 도움이 되겠지만, "난 저 아이디어 별로예요."라는 피드백은 발전할 가치도 없을뿐더러 발표자가 아이디어를 보완하는 데에도 도움이 되지 않는다. 반드시 모든 참여자가 발표하고 비평받도록 한다.

4단계. 반복적인 수정과 정교화 (5~10분 소요)

비평과 피드백을 더해서 아이디어를 하나로 줄인 다음 정교화해서 A3 한 장에 담아낸다. 여기서 목표는 가장 가치 있는 아이디어를 선택하는 것이고 아이디어를 더 발전시키는 것이다. 시간이 되면, 참여자 모두 발표와 비평 과정을 한 번 더 거치도록 한다.

5단계. 팀 아이디어 도출 (45분 소요)

팀 차원의 아이디어를 하나로 모아야 한다. 이 단계에서 팀은 가장 큰 성공의 기회라 여겨지는 아이디어로 의견을 수렴할 수 있도록 노력한다.

팀은 전지 사이즈의 큰 이젤 패드나 화이트보드를 사용해서 선정된 아이디어의 구성요소(컴포넌트)와 워크플로우를 스케치한다. 이 단계에서 합의에 도달하기까지 많은 타협과 논쟁이 거듭될 것이다. 팀은 이 과정에서 우선순위를 부여해야 하고 기능을 축소해야 할 것이다. 좋은 아이디어가 버려지지 않도록 팀의 아이디어를 모아두는 '임시공간'을 만들면 좋다. 임시공간을 활용하면 아이디어를 제외하는 일도 한결 수월하다.

스타일 가이드

스타일 가이드는 인터랙션, 비주얼, 사용자 인터페이스와 시스템에 반복되는 요소와 같이 광범위한 패턴 라이브러리를 체계화한 것이다. 흔히 패턴 라이브러리라고도 하는 스타일 가이드는 모든 제품마다 고객과 접촉하는 요소의 살아있는 조합으로 픽셀로 된 것이면 모두 스타일 가이드에 들어가게 된다. 헤더, 푸터, 그리드, 폼, 레이블, 버튼의 로직과 제품의 사용자 경험에 들어가는 나머지 모든 것이 다 스타일 가이드에 포함된다.

스타일 가이드는 워크플로우 구현을 위해 조합하고 조정될 수 있는 인증된 인터페이스 요소를 바로 쓸 수 있는 저장소를 제공하며, 폼 형식의 레이블 배치와 같은 필수 요소에 대한 논쟁이나 '긍정적인' 액션버튼을 좌/우에 둘 지와 같은 끝나지 않을 논쟁을 최소화한다.

검토 과정도 매끄러워지는데 특히 글로벌 내비게이션 처리 같은 반복적으로 사용하는 요소는 따로 논쟁할 필요가 없으므로 핵심제품의 도전적인 시도에 초점을 맞추고 제안된 솔루션을 더욱 다양한 시각으로 바라볼 수 있다.

일괄처리 방식

일괄처리 방식은 현시점에서 제한된 시간(1~2주, 때론 몇 개월)을 들여 제품의 모든 UI 요소를 스타일 가이드 문서로 만드는 것이다.

점진적 방식

점진적 방식은 새로 생성되거나 변경사항이 있을 때마다 요소를 추가하는 것이다.

런칭하고 유지보수하면서 살아 움직이는 프로세스로 스타일 가이드를 생각해야지 정적인 상태로 만들어놓는 것은 바람직하지 않다. 최신 정보로 사용하기 쉬워야 팀에서도 실제 스타일 가이드를 활용한다.

픽셀로 작업된다면 스타일 가이드에 포함된다. 모든 인터랙션 디자인 요소를 정의하고 가이드에 포함해야 하고, 스타일 가이드의 베이스라인으로 기존 제품에서 잘 돌아가는 디자인 패턴을 활용한다. 폼필드, 레이블, 드롭다운 메뉴, 라디오버튼 배치와 행태, Ajax와 jQuery 이벤트와 버튼 역시 스타일 가이드에 모두 포함된다.

요소 정의를 위한 3가지 데이터

요소의 형태
화면 배치
사용 시점

다음으로는 모든 비주얼 디자인 요소가 포함되고, 제품의 공통색상 팔레트로 시작한다. 각 기본색상을 hex 값과 보색, 몇 가지 보조색과 함께 활용 가능하다는 것을 표시한다. 버튼처럼 상태에 따라 다른 색상을 가지는 특정 요소의 경우, 이런 정보를 포함시켰는지 확인한다. 또 포함해야 할 다른 요소는 로고, 헤더, 푸터, 그리드 시스템과 타이포 정보(어떤 폰트가 어디에 쓰이는지, 폰트 크기와 두께)다. 인터랙션 디자인 요소 중 동일한 속성을 가진 것은 무엇이고 언제, 어디에 쓰는지도 포함되어야 한다.

마지막으로 카피라이트 스타일도 기술하였는지 확인한다. 브랜드가 가진 어조와 피해야 하는 단어, 문법적 표현, 용납되거나 용납되지 않는 비속어, 버튼명(OK/예/실행 등)과 그 밖의 내비게이션명(이전/다음, 더보기/간략보기 등)도 점검한다.

성공적인 스타일 가이드의 특성

접근하기 쉬운
지속해서 개선되는
실행 가능한

개인적으로 위키 활용을 추천하는데, 그 이유는 다음과 같다.

위키는 개발자들에게 친숙한 공간이다.
위키는 변경 이력을 기록해둔다.
위키는 누가 무엇을 수정하고 의견을 달았는지 저장한다.

새로운 요소가 스타일 가이드에 추가될 때마다 팀에서 필요한 포맷이 무엇이든 간에 내려받아서 활용할 수 있게 만들어야 하고, 코드뿐만 아니라 그래픽과 와이어프레임 모음까지도 활용 가능한지 확인해야 한다.

스타일 가이드 제작

목차: 인터랙션 디자인, 비주얼 디자인, 카피라이팅, 브랜드 가이드라인, 접근성과 그 밖에 사업적으로 이해할 수 있는 상위 레벨 섹션으로 분리한다.
내용: 일괄처리 방식 vs. 점진적인 방식

스타일 가이드는 오로지 디자이너와 관계된 정보만을 담는 것이 아니며, 내부에서 사용하는 짧은 코드도 포함되어야 한다.

라이브 스타일 가이드는 기본적으로 제품의 일부분으로 제작팀만 볼 수 있고, 사이트에 사용되는 모든 스타일과 위젯을 '각각 하나씩' 페이지로 생성하여 보여주며, 자동화된 유지보수에 가깝다는 장점이 있다.

웹 사이트에서 HTML과 CSS 구조를 변경하면, 변경된 내용이 스타일 가이드 페이지에 나타난다.

Chapter 5_ MVP와 실험

MVP의 포커스

어떤 경우에는 팀이 무언가 먼저 배우기 위해 MVP를 만드는데, 이때 시장에 제공할 가치가 아니라 시장이 무엇을 원하는지를 이해하려는 것이다. 또 다른 경우는 가능한 빨리 시장에 가치를 전달하기 위해 제품의 소규모 버전이나 기능을 제작하는 것으로 MVP를 알맞게 디자인하고 배포한다면 1차적으로 초점을 맞춘 내용은 아닐지라도 MVP로부터 학습이 가능할 것이다.

아이디어를 테스트한 MVP는 자사의 웹사이트 회원가입 양식이었다. 회원가입 단계에서 뉴스레터를 알리고 고객들의 이메일 주소를 물어보았다. 이 접근은 아직 고객에게 어떠한 가치도 전달하지는 않았다. 그 대신, 팀이 이 일을 계속 추진하는 게 옳은지 결정하기 위한 충분한 학습기회를 확보하는데 초점을 두었다.

이 사례에서 해당 팀은 실제 뉴스레터를 디자인하거나 제작하는 데 어떠한 노력도 들이지 않았다. 오히려 뉴스레터 제작은 '진행하자/말자'를 결정할 충분한 데이터를 수집한 다음 고려할 사항이었다. 팀이 충분한 데이터를 모으고 난 후, 고객들이 뉴스레터를 원한다는 데이터가 수집되면, 팀은 다음으로 MVP로 옮겨가고, 가치와 학습을 제공하는 MVP를 시도해보는 것이다.

MVP 만들기

MVP 계획의 3가지 기본 질문

내가 만드는 솔루션에 대한 니즈가 있는가?
내가 제공하는 솔루션과 기능에 가치가 있는가?
나의 솔루션은 사용하기 편한가?

학습 극대화를 위한 가이드

명확하고 간결하게 — 아이디어에서 핵심이 되는 가치제안을 정제하는 데 시간을 들여라.
우선순위는 가차 없이
언제나 애자일하게 - 빠르게 정보가 유입될 것이므로 중간 수준의 완성도를 넘지 않도록 하라.
행동 측정 — MVP를 제작하는 것은 사람들이 무슨 말을 하는지가 아니라 실제로 어떻게 행동하는지를 관찰하고 측정하기 위함이다.
실행문구 활용 — '회원가입' 또는 '구매하기'와 같은 실행문구는 사용자들에게 특정한 액션을 요구하는 확실한 표현이다. 서비스 사용을 위한 동의, 서비스 가입 등의 옵션제공은 사용자가 관심이 있는지 알 수 있는 훌륭한 방법이다.

고객에게 가치를 제공하기 위한 가이드

실용적이게 — 통합은 실제 사용 시나리오를 만들 수 있는 정도여야 한다.
기존 분석과 통합하여 — MVP의 성과 측정은 기존 제품의 워크플로우 안에 속해 있는 상황에서 이루어져야 한다.
나머지 애플리케이션과 일관성 있게 — 바이어스 발생을 최소화하기 위해, MVP는 현재 스타일 가이드나 브랜드에 맞게 디자인한다.

MVP는 학습을 위한 도구라는 것을 기억하자. 계속적인 반복 개선을 거칠 것이고, 수정해갈 것이다. 어쩌면 온전히 버리는 것에 능숙해질 수도 있다.

한 가지 반드시 새겨둘 것이 있는데, 대부분 MVP에 코드가 하나도 포함되지 않을 수 있다. 대신, 스케치, 프로토타이핑, 카피라이팅과 비주얼 디자인과 같은 UX 디자이너들이 사용하던 다양한 기존 도구를 활용할 수 있다.

프로토타입은 경험을 추정하는 것으로 제품이나 서비스에서 궁금한 부분을 어떻게 사용하는지 재연해볼 수 있다. 클릭(태핑)이 가능해야 하지만 동시에 프로토타입 제작에는 가능한 최소의 노력을 들이는 것이 여러분의 목표가 되기 때문에 프로토타이핑 툴 선택도 중요하다.

프로토타이핑의 특성에 따른 툴 선택

누가 사용할 것인지
무엇을 학습할 것인지
얼마 만에 제작해야 할 것인지

로우파이 프로토타입: 페이퍼

종이를 뒤집는 방법으로 다른 상태를 보였다가 숨겨지게 하거나 움직이는 이미지 슬라이드쇼용 '윈도우'를 제작해서 제품이 어떻게 작동하는지를 이해하도록 할 수 있다.

페이퍼 프로토타이핑은 화면을 직접 조작할 수 있는 터치 인터페이스에 특히 유용하다.

로우파이 프로토타입: 조작 가능한 와이어프레임

사용자에게 테스트하고 팀원들은 마우스나 키보드 등의 입력기기로 프로토타입을 조작한다. 클릭, 탭, 또는 제스처 등 제품의 인터랙션에 대한 보다 나은 통합과 피드백을 제공한다.

조작 가능한 와이어프레임 제작 툴

발사믹 — 저렴한 와이어프레임 제작용 툴로 '스케치' 형태의 결과물을 제공
옴니그라플 (맥 전용) — 드로잉 이미지를 사용할 수 있기 때문에 보기 좋은 결과물로 만들 수 있는데 옴니그라플의 핵심은 화면의 구성이지 워크플로우나 인터랙션을 시뮬레이션 하는 것은 아니다.
마이크로소프트 파워포인트 — 파워포인트는 어느 정도의 인터랙션을 흉내낼 수 있다는 면에서 쓸만하다. 파워포인트에서는 와이어프레임을 그리기 위한 드로잉 전용 툴을 사용하고 링크를 걸 수 있고, 목업, 와이어프레임, 또는 다른 툴에서 제작한 스크린샷 이미지를 불러올 수 있다.
플루이드 디자이너/팝 프로토타입 온 페이퍼 — 모바일 프로토타이핑 툴로써 프로토타입을 신속하게 제작할 수 있도록 하고 스마트폰에서도 돌아간다. 이미지나 스케치 사진을 불러들이고 핫스팟을 사용해서 금방 링크를 걸 수 있다.

미드 앤 하이파이 프로토타입

인터랙션과 비주얼, 어떤 경우에는 콘텐츠 디자인까지 최종 제품 경험과 흡사한 프로토타입으로 이를 활용해서 시연과 디자인 테스트를 하게 된다.

제작비용도 크기 때문에 툴의 활용도가 상당히 감소하고 있다.

비주얼 디자인과 브랜드 요소까지 테스트가 가능하다.

미드 앤 하이파이 프로토타입 제작용 툴

애쥬어 RP — 스크린과 폼, 실행되는 워크플로우를 사용해서 실제 웹 페이지를 제작할 수 있다. 애쥬어 목업은 모든 브라우저에서 돌아가고 웹페이지 시뮬레이션을 실제처럼 훌륭히 수행한다.
어도비 파이어웍스 — 어도비 일러스트레이터와 포토샵의 특장점을 합치려 시도했고, 가상의 인터랙션을 적용할 수 있어 시각적 완성도가 중요한 작업에 강력한 툴이다.

코드 프로토타입

코드 프로토타입은 가장 높은 완성도의 모의 경험을 제공한다. 사실상, 이 유형의 프로토타입은 구현 범위에 따른 제약이 없는 한 사람들은 최종 제품과 구별할 수 없어야 한다.

수동 코딩 프로토타입은 최종 제품처럼 보이고 그렇게 동작하지만 실시간 데이터 입력과 처리 혹은 그 결과를 고려하지는 않으며 단지 시뮬레이션일 뿐이다. 라이브 데이터 프로토타입은 실시간 데이터와 사용자의 입력값을 처리한다. 그렇기 때문에 실제 고객들에게 빈번히 배포되고 프로토타입 사용량에서 분석적인 통찰을 얻을 수 있으며 이는 수동 코딩 프로토타입에서는 할 수 없는 일이다.

프로토타입에 무엇을 넣어야 하는가?

MVP의 가장 기본이 되는 워크플로우에 집중하는 것은 팀에게는 일시적으로 터널비전을 갖게 한다. 이는 경험의 구체적인 부분과 그 타당성 및 효율성을 평가하는데 집중하게 하는 긍정적인 방법이다.

팀의 데모 데이에 프로토타입을 가져가 프로젝트의 진행상황을 보여주도록 한다. MVP를 많이 노출할수록 타당성 있는 통찰력도 더 증가한다. 다음에는, 현재 고객과 잠재 고객에게 프로토타입을 보여주고, 두루두루 조작하게 한 다음 사용 경험에 대한 피드백을 수집하도록 한다.

어떤 때는 제품과 연관된 것을 테스트하는 대신 제품을 시뮬레이션하지 않는 MVP를 만드는 것이 좋을 수 있다. 예를 들어, 여러분의 팀이 새로운 기능이나 제품의 가치를 결정하려고 할 때, 우리가 제대로 된 길을 가고 있는지는 프로토타입 없는 MVP로 파악하는 경우도 빈번히 있다.

프로토타입이 없는 MVP를 만들 때 염두할 사항

내가 학습하려는 것은 무엇인가?
가설을 검증하기 위해 시장으로부터 필요한 주요한 신호는 무엇인가?
주요한 신호를 나타내는 데 활용되는 지표를 테스트할 수 있는 또 다른 신호가 있는가?
이러한 정보를 수집하는 가장 빠른 방법은 무엇인가?

프로토타입이 없는 MVP의 유형

이메일

고객에 대한 학습을 위해서라면 이메일은 매우 강력한 툴이다. 메일을 열어본 비율, 클릭율, 수신자들의 태스크 완료비율 등 아이디어가 가치가 있는지에 대한 모든 통찰을 제공한다.

구글 애드워즈

사람들이 무엇을 검색하는지를 모니터링하면서, 어떤 표현이 우리 고객과 교감하는 요소인지에 대한 피드백을 수집할 수 있다.

랜딩페이지

랜딩페이지는 온라인의 서부영화 스튜디오와 같다. 우리 서비스의 얼굴이고, 매우 구체적이고 명확한 실행 기능으로 이루어져 있으며, 회원가입, 즉시 구매, 또는 친구에게 공유하기 등 랜딩 페이지에서 테스트를 완수하려는 모든 사용자의 반응을 제품 아이디어에 대한 검증으로 간주한다.

연결 안 된 버튼

인터페이스에 새로운 기능을 홍보하는 버튼을 추가함으로써 기능을 테스트할 수 있다. 버튼은 오로지 클릭수를 측정하기 위함이며 그 이상의 의미는 없다. 각각의 클릭은 그 기능에 대한 고객의 바람을 나타낸다.

하이브리드와 창의성

백엔드를 구축하는 대신, 셔릴은 서비스에 가입 고객에게 고유한 이메일 주소를 부여했다. 고객들의 모든 쿠폰 이메일이 부여받은 이메일 주소로 갈 것이라고 알려주었고, 그 이면에서는 셔릴이 모든 쿠폰을 수작업으로 데이터베이스에 넣고 있었다.

결국 가장 중요한 것은 이것이 린 UX적 접근방식의 핵심이라는 것이다. 필요한 것만 디자인하라. 빨리 내보내라. 고객과의 충분한 접점을 만들어 의미 있는 피드백을 빨리 얻도록 하라.

Chapter 6_ 조사와 피드백

지속적이고 협력적인 조사

첫 번째, 린 UX 조사는 지속하는 것으로 조사 활동을 매 스프린트마다 포함시킨다.

두 번째, 린 UX 조사는 협력적이다. 팀의 학습을 위해서 전문적인 조사기관에 의지하는 대신 조사 활동과 책임을 전체 팀원들에게 분배한다.

협업기반의 발견은 문자 그대로나 비유적으로나 팀 전체가 밖으로 나가 직접 고객을 만나고 학습하는 조사적 접근이다. 이는 팀 구성원 모두가 가설이 어떻게 테스트되는지 알 수 있는 기회가 되며, 가장 중요한 것은 팀이 활용할 수 있는 고객에 대한 통찰력이 팀원 수만큼 늘어난다는 것이다.

질문을 설계할 때 순차적으로 좁혀가는 방법을 고려한다. 처음에는 고객이 우리의 타깃 집단이 맞는지 확인해야 하고, 해당 고객군에서 발생하는 문제에 대한 가설을 확정한다. 마지막으로 프로토타입이나 목업이 있으면 우리가 보여주는 솔루션 안에서 고객 의견이 제한되지 않도록 인터뷰 막바지에 보여준다.

린 UX에서 중요한 최선의 방법은 일정한 리듬이 생기게끔 정기적인 고객참여를 계획하는 것이다. 정해신 시기마다 고객과의 정기적 인터뷰는 가설 생성, 실험 디자인과 사용자 피드백 간 소요시간을 최소화하여 가설을 빨리 검증할 수 있도록 한다.

고객 피드백 주기가 2~3일을 넘지 않는다는 것을 아는 것은 팀에 강력한 영향을 미친다. 의사 결정에 대한 부담을 덜어주고 시장에서 의미 있는 데이터를 수집하기까지 2~3일 이상 걸리지 않는다는 것을 알기 때문이다.

지속적인 랩 테스트: 매주 목요일, 3명의 사용자

나는 고객이 매주 정해진 시기에 사무실로 방문해 조사에 참가하도록 했다. 이것을 '3-12-1'이라 칭했는데, 3명의 사용자, 12시부터, 일주일에 한 번이라는 원칙에서 비롯된 것이다.

월요일: 참가자 모집과 계획 — 참가자 모집은 꽤 시간이 드는 일이므로 외부업체 활용도 고려할 만하다.
화요일: 테스트 제품 다듬기
수요일: 테스트 제품 마무리, 스크립트 작성과 참가자 모집 확정
목요일: 테스트 — 고객 한 명당 1시간을 넘지 않도록 하고, 팀원 모두가 관찰 기록을 한다. 팀원들은 다른 장소에서 관찰 준비를 하고, 마지막 참가자 조사가 끝나면 바로 전체 팀원이 모여 수집한 아이템을 함께 검토한다.
금요일: 계획수립

한 가지 전문적인 툴을 추천하자면, Morae, Silverback이나 GoToMeeting과 같은 데스크톱 레코딩과 브로드캐스팅 소프트웨어 등이 있다.

브로드캐스팅 소프트웨어는 테스트 세션을 팀원들과 의사결정자에게 공유할 수 있는 핵심 요소로, 이를 통해 고객에 대한 이해를 조직 깊이 전파할 수 있기 때문에 협업에 큰 도움이 된다.

리쿠르터에게 지금되는 비용은 통상 참가자당 10~20만 원 가량 소요된다.

사례 연구: Meetup의 매주 목요일 3명의 사용자

모바일 사용량이 증가하면서, Meetup은 좋은 모바일 테스트 장비를 기다리며 모바일 플랫폼에 대한 테스트를 미루는 대신 3만 원 정도의 비용으로 자신들만의 장비를 직접 만들었다.

팀이 모두 모였을 때, 모두에게 각자 자신들이 발견한 결과를 읽도록 한다. 이를 수행하는 효율적인 방법은 사람들이 노트한 내용을 소리 내어 말하고 인덱스 카드나 포스트잇에 작성한 다음 주제별로 분류하는 것이다.

학습이 극대화되고 있는지 확인하는 방법

패턴 찾기
예외 모아두기
다른 소스로 확인하기

대규모의 연구를 진행하는 대신, 매주 적은 수의 사용자를 대상으로 하고, 그러다 보니 어떤 질문은 몇 주 동안 계속 되기도 하고, 또 어떤 결과는 시간이 지나면서 흥미로운 패턴으로 밝혀지기도 한다.

테스트 날 무엇이 준비되었던 간에 사용자와 함께 테스트한다는 방침은 팀 전체가 테스트 일자를 데드라인으로 삼고 무리하지 않도록 하며, 모든 디자인과 개발 단계에 대한 통찰력을 얻을 수 있는 주간 테스트 세션이라는 장점을 발견하게 될 것이다. 하지만 각 유형별 테스트 대상마다 도출할 피드백 형태에 대한 적절한 기대치는 설정해두어야 한다.

스케치

스케치에 대한 피드백을 받는 것은 콘셉트의 가치를 검증하는데 도움이 된다.

정적인 와이어프레임

와이어프레임을 테스트 참가자에게 보여주면 정보구조와 사용자 경험을 담은 화면 레이아웃에 대한 평가를 받을 수 있고 용어, 내비게이션, 정보설계에 대한 피드백까지도 얻을 수 있다.

하이파이 비주얼 목업(조작 불가능)

테스트 참가자들은 형태와 배경의 연관성, 요소의 분류와 명백한 실행 액션뿐 아니라 브랜딩, 아름다움과 시각적인 구조에 대해서까지도 응답할 수 있을 것이다. 테스트 참가자들은 또 컬러가 효과적으로 선택되었는지에 대해서도 의견을 줄 것이다.

고객들이 각 클릭의 결과에 대해 어떻게 생각하는지를 묻고, 무엇을 기대하고 있는지에 대해 확인해야 한다. 그리고 응답한 반응이 우리가 계획한 경험과정에 반하는 것인지 검증하도록 한다.

목업(조작 가능)

사용자들은 조작을 통해 실제와 같은 결과를 볼 수 있지만, 인터랙션에 따라 데이터가 연동되는 것을 평가할 수 있는 것은 아니다.

코드 프로토타입

제품의 디자인과 사용행태, 워크플로우를 그대로 제작한 것으로 이에 대한 피드백은 실제와 다름없고, 사용자 경험에 바로 적용할 수도 있다.

지속적인 모니터링 기법과 협업기반의 발견

고객 지원

고객 트렌드를 이해하기 위해 정기적인 월간 미팅을 연다.
설을 고객 지원팀의 전화 스크립트에 포함시키는 것은 아이디어를 테스트하는 가장 저렴한 방법 중 하나다. 고객이 고려 중인 아이디어와 관련 있는 불만을 문의해 왔을 때 이를 해결하는 방법으로 아이디어를 제안해보는 것이다.

매월 고객 지원 부서는 우리에게 10가지 고객 불만을 알려주고 우리는 이 정보에 모두의 노력을 집중한 다음 우리가 적용한 업무의 효율성을 측정하고자 했다. 만약 페인 포인트 중 한 가지를 해결하려고 시도했다면 월간 미팅의 대화에서 우리의 노력이 결실이 있었는지에 명백히 결과를 알 수 있었다. 우리가 해결하려 한 이슈가 TOP 10 목록에 여전히 남아있다면 우리가 적용한 솔루션이 적절하지 않았다는 것을 의미하였다.

현장 피드백 설문

사이트의 특정 세션으로부터 얼마나 많은 인바운드 메일을 받고 있는지 세어보기
온라인 토론에 참여하고 우리의 가설을 몇 가지 제안하기
참가자 구인이 어려우면 커뮤니티 사이트에 요청하기

검색 패턴은 사용자가 무엇을 찾고 무엇을 찾지 못하는지를 나타낸다. 약간의 변형을 통한 반복적인 쿼리는 특정 정보를 찾으면서 겪은 어려움을 나타낸다.

사이트 이용로그와 분석 패키지(특히, 퍼널 분석)는 고객들이 사이트를 어떻게 사용하는지 보여준다.

A/B 테스트는 원래 마케터가 만든 조사기법으로 두 개 혹은 그 이상의 상대적으로 유사한 콘셉트 중 어느 것이 더 효과적으로 목표한 바를 달성하는지 측정하는 것이다.

여기서 주의해야 할 것은 각 안마다 적용하는 변화의 폭이 아주 작고 구체적이어야 한다. 그래야 행동 유발 요인을 직접 확인할 수 있다. 너무 많은 것에 변화를 주면, 행동변화를 일으킨 원인이 되는 직접적인 가설이 무엇인지 파악할 수 없다.

Part 3_ 적용하기

Chapter 7_ 애자일과 린 UX의 통합

몇 가지 정의

스크럼 — 일정하게 정해진 주기, 주체적인 팀 구성, 높은 팀 권한을 장려, 애자일에서 가장 인기 있는 방법론이다.
유저스토리 — [사용자 유형]으로써 [어떤 혜택이 발생하기] 때문에 나는 [어떤 일을 하고] 싶다.
백로그 — 유저스토리에 우선순위를 부여한 목록으로 백로그는 애자일에서 가장 강력한 프로젝트 관리 툴이다.
스프린트 — 각 스프린트의 목적은 작동하는 소프트웨어를 만들어내는 것이다. 대부분의 스크럼 팀이 2주 주기로 스프린트를 운영한다.
스탠드업 — 각 구성원들은 팀 동료 모두에게 매일 그들이 무엇을 하고 무슨 일이 일어날지를 공개적으로 밝힌다.
회고 — 무엇이 미흡했고, 팀이 다음 스프린트에서 어떻게 그 프로세스를 개선하고자 하는 것이다. 프로세스는 제품으로써 반복 수정된다.
이터레이션 계획 미팅 — 가끔은 스토리 수집과 추정을 포함하기도 하며, 백로그의 우선순위를 정한다.

시차 스프린트(Staggered Sprints)의 극복

지와 밀러는 개발 스프린트보다 한 스프린트 앞서 디자인 작업을 진행하는 프로세스를 설명한다. 디자인 작업은 '디자인 스프린트' 동안에 디자인되고 검증된 후 개발 단계로 넘겨지고 개발 스프린트 동안 구현 작업이 이루어진다.

많은 팀이 이 모델을 잘못 해석하는데 사실 지와 밀러는 디자인과 개발 스프린트에서 디자이너와 개발자 간의 강력한 협업을 언제나 주장했다.

이 모델은 중간 과정으로써 잘 작동한다 할 수 있지만 팀이 최종적으로 추구하는 모습은 될 수 없다. 왜냐하면 대체로 각자 작업을 해서 팀 전체가 동시에 같은 작업을 하기 힘들기 때문이다. 사람들이 각자 다른 작업에 집중하고 있기 때문에 다분야 간 협업의 장점을 절대 알 수 없다. 협업 없이는 상호이해를 만들 수 없고 문서와 의사소통을 위한 산출물에 크게 의존할 수밖에 없다.

디자인 스프린트 동안에 작업한 내용을 문서로 만드는데 시간을 허비해야 한다. 만약 개발자들이 디자인 스프린트에 참여하지 못했다면 개발자들은 작업물의 구현 가능성 혹은 범위에 대해 검증 시간을 가질 수 없고, 산출물을 넘겨주기 전까지 그런 이야기를 해볼 수도 없다.

스크럼 리듬에 린 UX 적용하기

주제

스프린트를 하나의 시리즈로 묶을 수 있다고 가정하고 이것을 주제라고 부를 것이다.

스케치와 아이데이션을 위한 킥오프 세션

각각의 주제는 브레인스토밍과 검증 활동 시리즈로 시작되어야 한다. 이러한 활동은 오후시간 정도로 짧게 진행되거나 길어봤자 일주일 정도면 된다.

킥오프의 초점은 전체 팀의 스케치와 아이디어를 모으고, 테스트하고 학습할 아이디어에 대한 백로그를 작성하는 것이다.

다음 스프린트를 위한 백로그 작성을 위해 가장 최근의 통찰력을 활용하도록 한다.

이터레이션 계획 미팅

킥오프 세션의 결과물을 한 데 모으기 때문에 스토리를 추출할 때 필요한 상호이해 형성이 용이하다.

사용자 검증 계획

아이디어 세션에서 만든 결과물을 사용자 테스트를 위한 기본 자료로 활용한다. 아이디어가 초기 단계일 때는 가치에 대해서 테스트한다는 것을 기억하라(예를 들면, 사람들이 우리 제품을 사용하고 싶어하는가?). 일단 우리 제품에서 매력요인을 만들기 시작하고 나면, 보다 높은 완성도의 작업물을 가지고 이어서 테스트한다. 이것이 우리의 솔루션이 사용할 만한 것인지를 밝혀줄 것이다.

참여하기

애자일 프로세스에서 린 UX가 작동하려면 팀 전체가 모든 활동에 참여해야 한다. 스탠드업 미팅, 회고, IPM, 브레인스토밍 등의 활동 모두 전원 참여가 있을 때 성공적일 수 있다.

팀은 미팅을 통해 의사결정을 하며, 결정은 토의를 기반으로 이루어진다. 회의 내용의 90%가 당장 본인이 하는 작업과 관련이 없다고 해도, 10%의 관련 내용이 회의에서 무슨 일이 있었고 왜 그런 결정이 도출되었는지에 대해 나중에 설명을 들어야 하는 시간을 아껴줄 것이다.

팀 스포츠로써의 디자인: Knowsy 사례 연구

새 제품이 구현될 때까지, 사람들이 같은 제품 비전 안에서 일한다는 것은 어려운 일이다. 팀에서 어떤 기능이 중요한지 혹은 어떤 걸 먼저 해야 할지에 대해 논쟁이 있다면 비전 공유가 부족하다는 증거다. 팀이 '아주 빠른 움직임'을 보이지 않는 느낌이 들 때도 그럴 수 있고 혹은 동일한 이슈를 계속해서 반복하며 되돌릴 때도 역시 그렇다.

스케치하면서 나는 "이럴 때 무엇을 해야 할까?"와 같은 질문으로 일관성 없는 부분을 짚고 넘어갈 수 있었다. 이러한 접근은 "내가 맞고 당신은 틀렸어"라는 방식이 아니라 "우리가 어떻게 이 문제를 해결할까?"로 대화의 관점을 바꾸는 이점이 있었다.

스크럼팀을 넘어

성과 중심적인 팀의 도전과제는 프로젝트 일정이 학습으로부터 영향을 받는다는 것이다. 그들은 반응적이기 때문에 전형적인 계획은 한번에 작은 규모의 배치 작업 정도로 계획했다. 기껏해야 반복 개선이나 두 단계 앞의 계획 정도만 세울 수 있다. 이것은 '근시안적인' 것으로 대부분의 상위 관리자들을 만족시킬 수 없는 계획이다. 그렇다면 린 UX와 스크럼 프로세스를 지속하는 어려운 상황에서 어떻게 상위 관리자들을 안심시킬 것인가?

주도적인 커뮤니케이션, 이 두 단어로 요약할 수 있다.

대화는 기능 구현이 아니라 결과물에 초점을 맞추도록 하라(어떻게 여러분이 목표를 향해 나아가고 있는지).

지원부서(고객 지원, 마케팅, 재무 등)의 업무에 영향을 미칠 수 있는 변화는 그들이 미리 알고 있는지 확인하라.

Chapter 8_ 조직 변화 만들기

변화 1: 성과물

성과를 결정하는 것은 리더십 활동인데, 많은 조직들이 잘하지 못하고 있거나 전혀 못하는 부분이다. 오히려 흔히 볼 수 있는 리더십은 제품개발팀이 제작해야 하는 결과물이나 기능으로 정리된 프로젝트 로드맵을 보면서 제품개발팀을 이끄는 것이다.

제품 관리자와 프로덕트 오너는 어떤 비즈니스 지표에 가장 중점을 두어야 할지를 결정해야 하고, 결과적으로는 성과물을 가지고 상위 관리자들과 대화해야 하며, 이러한 변화는 필연적으로 조직의 최상위 단계까지 이르게 될 것이다.

관리자들은 팀이 자유롭게 실험할 수 있는 환경을 유지해주어야 한다.

변화 2: 역할

조직 간 사일로는 협업하는 팀에게 무덤이라 하겠다.

린 UX가 성공하기 위해서, 조직은 '역할보다 역량'이라는 기준을 입버릇처럼 적용해야 한다.

변화 3: UX 디자이너의 새로운 스킬

팀에서 여전히 핵심적인 UX 스킬이 필요로 하더라도, UX 디자이너들은 자신들의 핵심역량 중 하나로 퍼실리테이터 역할을 추가할 필요가 있다.

디자이너는 반드시 디자인 진행과정을 공개해야 한다.

팀원들의 의견을 구하고, 거기서 얻은 통찰을 디자인에 다시 적용하여 다듬어간다.

디자이너는 자신이 속한 팀에서 리더십을 지녀야 한다.

동료들이 여러분의 디자인 작업을 비평하는데 익숙하다는 것은 그들이 여러분과 함께 디자인하는 것에 익숙하지 않다는 것을 의미한다.

변화 4: 다분야 융합팀

개별 업무를 다른 사람에게 지시하는 것이 아니라 모두가 공동의 목표를 향해 나아가는 것이다. 디자이너들을 '개발자 미팅'에 참여하도록 하고 개발자 역시 디자인 미팅에 참여한다.

변화 5: 작은 팀

제프 베이조스의 유명한 얘기처럼 '피자 두 판' 팀(5~7명이 한 팀)으로 나누도록 하라. 피자 두 판보다 더 많은 양이 필요한 팀이라면 그 팀은 규모가 너무 큰 것이다.

변화 6: 업무환경

팀을 같은 공간에 배치하여 모두가 가시거리 안에 있고 접근이 쉬운 작업환경을 만들도록 하라. 팀이 작업한 결과물이나 다른 작업물을 붙일 수 있는 벽면이 있는 공간이 필요하다. 동료들과 함께 돌아보고, 작업물을 보면서 의견을 나누고, 스케치하고, 아이디어를 주고받고, 표정과 몸짓을 파악해가면서 고민스러운 주제에 대한 해결책에 도달하는 것보다 더 효과적인 것은 없다.

변화 7: 더는 스타는 없다

린 UX는 글자 그대로 스타를 기다리고 있을 시간이 없다. 모든 디자인 콘셉트가 가설이라는 것이 스타주의의 권위를 바로 날려버리는데, 디자이너로서 우리 모두는 자신이 제안한 많은 아이디어가 테스트 과정에서 실패할 수 있다는 것을 받아들여야 한다. 스타들은 실패를 인정하지 않는다. 반면, 린 UX 디자이너들은 실패를 프로세스의 한 부분으로 포용한다.

변화 8: 속도 우선, 심미성은 그다음

'속도 우선, 아름다움은 그다음'이라는 이야기는 37시그널스 CEO 제이슨 프라이드가 트위터에 남긴 말이다. 품질을 타협하자는 얘기는 아니었고, 아이디어를 다듬어가는 프로세스의 근본을 얘기한 것이었다. 린 UX에서 빨리 일하는 것의 의미는 많은 작업물을 내놓는 것이다.

비주얼 디자인의 정교화 단계에서 보이는 부분에 집착에 가까운 공을 들이는 것은 많은 의미가 있지만, 와이어프레임, 사이트맵, 워크플로우 다이어그램과 같은 초반 작업물을 완벽하게 다듬으며 심혈을 기울이는 것은 시간 낭비일 뿐이다.

변화 9: 가치중심의 문제 해결

디자이너들은 아이디어에서 유효한 학습까지 경험에 이르는 경로를 설명함으로써 자신들의 문제 해결 능력을 발휘할 수 있고, 이를 통해 디자이너로서의 깊은 가치를 인정받게 될 것이다. 문제 해결가를 발굴하고 보상하고자 하는 조직은 이러한 디자이너들을 선호하며 디자이너들 또한 그러하다.

변화 10: 불완전한 UX

팀은 지속적인 개선을 약속할 필요가 있으며, 이것은 단순히 코드를 리팩토링하고 기술적인 불완전성을 표명하는 것뿐만 아니라 사용자 인터페이스를 재제작하고 개선하는 것까지도 의미한다. 팀은 불완전한 UX라는 콘셉트를 받아들이고 사용자 경험에 대한 지속적인 개선을 약속해야 한다.

변화 11: 산출물 중심의 에이전시

에이전시에서 린 UX 업무를 실행하기 위해, 업무에 투입된 모든 사람은 두 가지 사항을 극대화하는 데에 집중할 필요가 있다. 하나는 클라이언트와 에이전시 간의 협업을 확대하는 것이고, 나머지는 산출물에서 성과물로 초점을 바꿔 업무를 수행하는 것이다.

협업을 확대하기 위해 에이전시들은 클라이언트와 자신들을 분리시키는 벽을 깨뜨리려는 시도를 할 수 있다. 클라이언트들은 프로세스의 초기부터 더 자주 참여할 수 있고, 다소 비공식적인 단계에서 자연스러운 참여가 일어나게 된다. 또한, 에이전시와 클라이언트가 함께하면서 추가적인 통찰력째과 피드백, 다른 사람들과의 협업에 따른 효용성이 있을 때에 협업 세션이 마련될 수 있다.

개발 파트너들은 프로젝트의 전반에 걸쳐 참여해야 하며 수동적인 관찰자가 되기보다 가능한 일찍부터 소프트웨어 개발에 착수할 방법을 찾아야 한다.

변화 12: 서드파티 업체와 일하기

서드파티 업체들과 일할 때면 정해진 일정과 자료를 근거로 프로젝트를 만들어야 한다. 그렇게 해야 개발 파트너와 유연한 관계를 형성할 수 있고, 린 UX 프로세스의 일부인 변화에 대응도 할 수 있다.

변화 13: 표준 문서화

린 UX에 요구하는 사내 표준 문서 제작은 가설이 입증되고 디자인 방향이 정해졌을 때이다. 의사 결정 히스토리를 수집하고 제품에 대한 향후 팀의 업무를 알려주는 것과 같은 정확한 이유가 있는 문서를 활용하라. 이러한 문서들이 올바른 제품을 위한 의사 결정을 방해하지 않도록 하라.

변화 14: 현실적으로 조직을 바라보기

허용보다는 관용을 구해보도록 하라. 몇 가지 아이디어를 시도해보고 수치로 측정할 수 있는 성공으로 가치를 증명해보이자. 프로젝트에서 시간과 비용을 절약하는 것 혹은 지금까지의 작업 중 가장 성공적인 업데이트를 이끌어 내는 것과 같은 성과는 자신만의 사례를 만드는 데 도움이 될 수 있다.

변화 15: 전방위적인 관리

여러분의 업무에 영향을 받는 부서는 언제나 존재한다. 위험 요소가 되지 않도록 미리 확인하라.

예정된 제품의 중요한 변화 중 어떤 것이든 고객들이 알 수 있도록 하고 사용하지 않을 수 있는 선택권을 제공하라(최소한 일시적이라도).

서평

'린(LEAN)한 방식'으로 통용되는 스타트업계에서 선풍적인 인기를 끌었고, 여전히 중요한 개념을 디자인에 적용하는 방식에 관한 책입니다. 출간된 시기는 오래 되었지만, 여전히 읽어볼 만한 책이라고 생각합니다.

창업을 꿈꾸는 사람이라면, 어떠한 형태로든 제품 또는 서비스를 제작하게 됩니다.

그리고 제작 과정에서 절대로 빠지지 않는 과정이 UX/UI 디자인 과정입니다.

여기서 UX는 User Experience, 즉 사용자 경험을 의미하며 이는 제품 또는 서비스와 사용자가 상호작용하는 방식에 대한 포괄적인 표현이라는 생각이 듭니다.

사실 디자인 관련 학부를 막 졸업한 학생이라면, 학부 과제를 진행하면서 해왔던 대로 전체 UX를 통합적으로 '한번에' 설계하려는 노력을 합니다. 그리고 제품/서비스에서 일관적인 사용자 경험을 제공한다는 것은 매우 바람직한 일입니다.

그런데 문제는, '기껏 고민 끝에 설계한 UX/UI가, 사용자에게 제대로 전달되지 않는 경우가 허다하다'는 것입니다.

그만큼 사용자의 행동 패턴을 직접 경험하지 않고서는 그들의 행동을 예측한다는 것 자체가 어려운 일이라는 겁니다.

이에 대한 해결책을 린 UX가 전달합니다. '빠른 실행과 피드백을 통해 수정/개선이 이루어지는 순환 구조'

이번에 린 UX를 읽고 보니, 디자이너와 함께 약 2년 정도 일을 하면서 '내 동료가 이런 생각을 가지고 있었구나' 하고 생각하게 됩니다.

디자인 관련 전공을 가지고 있고, 자신이 UX 디자인으로 꿈을 키우고 있다면 꼭 읽어야 할 책입니다.

물론 제품 또는 서비스 프로젝트 매니저(PM)에게도 정말 좋은 책입니다.

저작자표시 비영리 동일조건

'독서 > IT·모바일' 카테고리의 다른 글

MS 본사 데이터 과학자가 알려주는 헬로 데이터 과학 - 김진영 (0)	2020.05.09
구글 애널리틱스 실전 활용법 -김동우 (4)	2019.08.22

UX 디자인이 궁금하다면 명심해야 할 디자인 프로세스, 린 UX - 제프 고델프, 조시 세이던