Design Thinking with SAP

나는 2일에 걸쳐서 판교 SAP AppHaus에서 Design Thinking 교육을 받았다.

SAP는 IDEO에서 태어난 디자인 씽킹을 빠르게 배워 적용시키고, 스탠포드 대학에 d.school 설립, 글로벌 교육을 진행하고 한국에도 판교에 SAP AppHaus를 두어 Design Thinking에 대해 교육 중이다.

ICE BREAKING

교육을 진행할 때 같이 교육 받는 사람들 그리고 교육을 진행하는 퍼실리테이터분들 모두 닉네임을 사용했다. 닉네임을 사용해본 건 처음이었는데 단지 그것만으로도 서로 편해지고 수평적인 느낌이 들어서 좋았다.

교육받는 인원이 30명정도 되어서 5개조로 나누어졌다. 각 조마다 교육을 도와주는 퍼실리테이터분들이 배정되어 있다.

Ground Rule을 정했다.

• 스마일
• 반말
• 폰 x
• 닉네임 안부르면 꿀밤

재밌는 규칙들이 정해졌다. 이 규칙 때문에 같은 조 사람들과 억지로라도 더 편해지고 친해졌다.

서로의 얼굴을 보고(종이는 보면안됨) 얼굴을 그려줬다. 종이를 보지 못하는 상태로 펜을 움직이며 그리기 때문에 아주 웃기는 그림들이 나왔다. 아무리 이상하게, 못 그렸어도 서로 웃기고 재밌을 뿐이다. 앞으로의 디자인 씽킹 교육에서는 어떤 이상한, 못난 아이디어를 내도 상관없다. 오히려 정제되지 않은 아이디어일수록 새롭고 재미있다.

Design Thinking 단계

1. 공감
2. 문제 정의
3. 아이디어
4. 프로토 타입
5. 테스트

디자인 씽킹을 한 문장으로 정의하자면

공감을 통해 문제를 이해하고 정의한 후 싸고 빠르게 프로토타입을 검증하는 것을 반복한다.

여기에 나오진 않지만 0단계로 현상의 발견을 두고 싶다. 우선 어떤 상황의 어떤 사람을 공감할지 정하려면 문제로 추정되는 현상을 발견해야 한다고 생각한다.

공감(Empathize)

공감은 디자인 씽킹 단계에서 가장 중요하다. 이 단계가 부족하면 자칫 고객이 원하는 제품이 아니라 우리가 원하는 제품이 탄생한다. 공감 단계를 충분히 거쳐야만 **진짜** 문제 를 찾을 수 있다.

개발자들은 공감 단계를 덜 중요시 여긴다. 기술과 해결방법, 참신한 아이디어에 초점을 맞춘다.

예를들어, 어떤 현상이 발생했을 때 그 현상에 대해서 내가 문제를 정의하고 해결 방법을 고안한 뒤, 고객에게 프로토타입을 제시한다. 심지어 프로토 타입이 아니라, mvp 혹은 완성된 제품을 제시하여 테스트 하는 경우도 존재한다.

그리고 나서 물어본다.

~~이렇게 만들(예정)었는데 쓰실 의향이 있으신가요? 예/아니오

OMG

공감을 어떻게 할 수 있을까?

• 관찰하기(Observe)
• 인터뷰하기(Interview)
• 직접 경험하기(Try and Do)

세가지 방법 모두 중요하고 해야 하지만, 가장 중요한 인터뷰하기에 초점을 맞춰보자.

인터뷰

• 열린 질문 하기
• 현상의 의미와 가치를 파악하기
• 비언어적 표현까지 기록하기

인터뷰 질문할 때 예/아니오로 대답할 수 있는 질문을 던지고 있진 않는가?
유도 질문을 하고 있진 않은가?

인터뷰어의 사견이 많이 들어간 인터뷰는 좋지 않다. 한번 질문하면 얻을 수 있는 답은 다섯번 질문해야 얻을 수도 있다. 그리고 고객의 정확한 답을 얻지 못하고, 내가 생각하고 있는 답을 얻게된다.

페르소나

• 특정 인물을 상상하여 어떤 사람이 어떤 상황에서 겪는 문제인지 명확히 한다.
• 페르소나는 인터뷰 질문을 만드는데 도움이 된다
• 페르소나는 공감의 대상이며 공감을 하기 위한 관점이다
• 내가 누구의 시선에서 문제를 바라볼지 결정하는 기준이다
• 누구를 위한 솔루션인지 집중하도록 만들어준다

문제 정의(Define)

문제 정의는 철저히 공감하기(인터뷰)에서 나온 내용을 바탕으로 정해진다. 내가 획기적인 생각을 할 필요가 없다. 그냥 있는 그대로 고객이 말한 PainPoint와 Insight를 정리, 정의하면 된다.

분류하기

• 비슷한 문제들 끼리 분류하기
• 복잡한 문제를 구조화 하기
• 반복되는 문제를 찾아내기

연결하기

• 파악한 문제를 공유하기
• 파생/연결되는 문제 확인하기
• 사용자 중심으로 문제를 매핑하기

하나의 문제에 집중하기

POV(Point of View)나 HMW(How might We) 문장들은 공감하기 단계에서 나온 Pain Point 와 Insight 로 만든다.

POV(Point of View)

customer 은 what 불편하다. 왜냐하면 why 때문이다.

EX ) 퍼플(customer)은 자주쓰는 중요한 물건이 가방에 고정되지 않고, 자주 사용하지 않는 물건의 위치를 까먹어서 잘 찾지 못하는 것(what)이 불편하다. 왜냐하면 물건이 쉽게 굴러다니고 작은 물건은 안보이기(why) 때문이다.

HMW(How might We)

어떻게하면 우리가 customer 를 위해 ~ 할 수 있을까?

EX ) 어떻게 하면 물건을 많이 들고다니는 개발자 퍼플 님을 위해 물건들을 편리하게 관리할 수 있는 가방을 만들 수 있을까?

아이디어(Ideate)

💡 질보단 양, 어떤 것을 선택할지는 나중에 투표로 정하면 된다.

아이디어를 내는 단계에서는 각자 생각나는 아이디어들을 포스트잇에 적어 모은다.

• 모든 아이디어를 적거나 말한다(비난하지 않기)
• 자유롭게 토론하기

충분히 나왔으면 아이디어를 분류한다.

아이디어를 분류한 뒤, 팀원들과 동시에 투표를 진행한다. 동시에 하는 이유는 다른 사람의 의견이 내 의견에 영향을 미칠 수 있기 때문이다. 우리는 스티커를 통해 마음에 드는 아이디어에 투표했다. 각자 총 6개의 스티커를 3개, 2개, 1개 마음에 드는 순으로 투표하였다.

아이디어를 분출할 때는 모든 아이디어를 말하지만, 선택할 때는

• 기술적으로 구현 가능한지
• 현실적 가격인지
• 사람들이 원하는지

를 고려해서 투표해야 한다.

프로토 타입(Prototype)

평소에 나는 프로토타입을 MVP(Minimum Viable Product)와 거의 동일하게 생각했었다. MVP라 생각했으니 당연히 ‘동작’해야한다고 생각했고 핵심 기능만 있는 가벼운 제품을 상상했다. 하지만 프로토타입은 아이디어를 전달하기만하면 되는 훨~~씬 가벼운 시제품이다.

Prototype은 싸고, 빠르게

테스트(Test)

제작한 프로토타입을 실제 고객혹은 실제 고객과 유사한 사람들에게 직접 테스트하고 피드백 받는다. 좋안던점, 바라는점을 피드백 받는다(I LIKE, I WISH).

🌝 이 단계에서 실제 고객의 반응에 따라 다시 ‘공감하기’단계로 돌아가야 할 수도 있다. 아니면 다른 현상을 찾아야 할지도..?