이미 ‘디자인 씽킹’에 관한 책이 대 여섯 권 있던 터였다. 사실 이 책은 지난해 10월에 진행 중이던 도서를 팀 역할별로 재분배하면서 기획이 완료된 채로 내게 배정되었다. 일반적으로 기획과 원고 완성을 한 편집자가 하게 되니 이례적인 상황은 아니었다. 무슨 책인지도 자세히 파악하지 못했으므로 아래와 같은 의문이 드는 건 어쩌면 당연한 일일 거다. “어떻게 시중에 출간된 책과 차별화된 유익함을 독자에게 줄 수 있을까?“ 기획서를 읽어보고 입고된 원고를 읽고 나서 저자와 미팅을 했다. ‘디자인 씽킹’의 ‘디’도 모르므로 터문의 없는 나의 의문들을 미팅 내내 저자에게 쏟아부었다. 그 끝에서 다음과 같은 사실을 알게 되었다. 원체 디자인 씽킹이라는 것이 측정 불가능하다는 것 기존 책들은 이론에 그쳐 현업에 적용하기가 어렵다는 점 그러한 현업의 어려움을 돕고자 이 책은 1부에서 전반적인 이론을, 2부에서는 측정 가능한 How To를 담는다는 점. 그리고 이 책 전반에서 <놀 프로젝트>, <캣치캣츠 프로젝트>, <소규모 요양원 경쟁력 강화 프로젝트>라는 저자의 고민이 담긴 3주체 3색 실전 예제를 비중 있게 다루는 점. 미팅 끝에 원고를 살펴볼 기준을 세울 수 있었다. 요리를 좋아하는 자신의 할머니에게 요리의 즐거움을 다시 찾아주고자 26세 나이에 3년간 80세 노인으로 살아보기로 한 패트리샤 무어에 대해 짧은 이야기가 새삼 떠오른다. 사실 그녀의 실천은 ‘고객 신발로 걷기’라는 마케팅에서 아주 중요한 기법을 실천한 모범사례다(이 글을 읽는 여러분이 프로그래머라면 ‘개밥 먹기’라는 말이 더 익숙할 것이다). 기법의 이름이 무엇이든 그녀에게 직접 물어보지는 않았지만, 그녀는 그때 즈음 아마 다음과 같은 자문을 했을 것 같다. “어떻게 나는 할머니가 요리의 즐거움을 되찾게 할 수 있을까?” 사실 위 문장은 ‘우리가 어떻게 ~해볼까? How Might We?’라는 HMW 기법의 응용이다. 서비스 디자인 씽킹의 6단계 중 첫 번째 단계인 ‘이해하기’의 중요 기법인 HMW는 그야말로 모든 문제 해결의 시발점이다. 디자인 씽킹이 당면한 과제를 해결하여 혁신적인 서비스로 고객의 마음과 지갑을 여는 방법을 고안하는 것이든, 혹은 그렇지 않든… HMW에서 시작하지 않으면 한 발도 더 나아갈 수 없을 것이다. 『처음부터 다시 배우는 서비스 디자인 씽킹』은 2017년 6월 세상의 빛을 보았다. 2016년 10월로 다시 돌아가 이 책의 미래를 다시 그려본다. “어떻게 시중에 출간된 책과 차별화된 유익함을 독자에게 줄 수 있을까?“ 이 책에 그러한 고민의 흔적이 충분히 반영되었다. 그러하므로 나쁘지 않은 출발점이었던 걸로 기억하기로 했다. Point of View(POV)는 Design Tinking 프로세스에서 해결해야 할 Challenge를 정의한다. 훌륭한 POV는 사용자, 그들의 니즈, 인사이트에 촛점을 맞춘 목표 지향적 방식으로 Design Challenge를 생각하고 문제를 해결하게 할 것이다. 당신은 좁게 포커스된 문제 진술 또는 POV를 구성해야 한다. 왜냐하면, 이것은 나중에 Brainstorm, Brainwriting, SCAMPER와 다른 아이디어 세션 동안에, 당신과 팀이 아이디어를 생성하기 시작할때 더 많은 양과 고품질 솔루션을 만들 수 있기 때문이다. 아이디어 프로세스에서, POV는 특정 사용자의 니즈와 인사이트 또는 복합 성격에 촛점을 맞춘 진술을 가이드할 것이다. 이전 작업에서 얻은 리서치의 핵심 본질의 촛점 유지를 돕는 의미있고 실행 가능한 문제 진술이 없다면, 아이디어 세션에서 길을 잃기 쉽다. 훌륭한 POV는 당신이 궤도를 유지하도록 해준다. 이것은 사용자와 그들의 니즈에 맞게 디자인하도록 돕는다. 만약 당신이 POV를 정의하는 것을 게을리 한다면, 당신은 아이디어 세션과 프로토타입 과정에서 길을 잃을 수 있다. 이제는 POV를 정의하는 방법을 알아야 할 시간이다. Point Of View(POV)를 어떻게 정의하는가? Step 2 : 도시에 살고 있는 성인 : 한주에 1~4번 10~60분 차동차를 사용하기 원한다 : 사용자는 자신의 차를 원하지 않는다. 왜냐하면 그의 니즈에 비해 너무 비싸기 때문이다. 그는 비슷한 니즈를 가진 사람들과 자동차를 공유하고 싶어한다. 하지만 그에게 맞는 쉽고 저렴한 솔루션이 없다. 친환경을 생각하며 살아가고 실제 필요한것 이상으로 소유하지 않는 사용자에게 중요하다. Step 3
: POV Madlib 당신은 다음 문장에서 사용자, 니즈와 인사이트의 정보를 넣음으로써 POV를 표현할 수 있다. POV Madlib를 활용해서 Point Of View를
압축하라 Step
4 : Point Of View가 하나인지 확인하라 이제 POV를 만들 준비가 되었고 공감모드에서의 모든 작업을 구체화하는 POV 활용을 어떻게 시작하는지를 이해할 시간이다. "How Might We" 질문들로 구성하고
디자인 목표를 제공하라 POV에서 Design Challeng를 정의했을때, 당신은 Design Challenge를 해결할 아이디어를 내놓기 시작할 수 있다. 당신은 "어떻게 하면 우리가" 또는 "우리가 어떤 방법으로"로 시작되는 특정 질문을 하면서 POV 활용을 시작한다. HMW 질문은 브레인스토밍과 다른 아이디어 세션을 하는 최고의 방법이다. HMW는 Design Challenge 해결에 도움되는 아이디어들을 탐구하는 아이디어 세션을 시작한다. HMW 처럼 Design Challenge를 구성함으로써, 아이디어 단계에서의 혁신적인 솔루션을 위해 준비할 수 있다. HMW 방법론은 새로운 아이디어를 위한 장을 여는 방식으로 구성되고 우리가 현재 정답을 알지 못한다는 것을 인정하고, 그것을 해결하기 위해 협력적인 접근방법을 권유한다. 예를 들면, POV가 다음과 같다면... HMW질문은 다음과 같이 전개할 수 있다 : 이것들은 아이디어 단계에서 약간 다른 접근방식의 영향을 줄 수 있는 미묘한 늬앙스를 가진 질문들이다. HMW 질문은 앞으로의 창의적 아이디어 및 디자인 활동들이 당신이 발견하지 못한 사용자 니즈와 핵심 인사이트에 잘 부합되고 상상력을 불어넣는 여러개의 HMW 질문 중 하나를 권고 받을 것이 확실할 것이다. "어떻게 하면 멀리 떨어진 마을에 사는 부모들이 죽어가는 신생아에게 생존 기회 제공에 도움이 되는 아기 난방장치를 만들 수 있을까? 이 HWM 질문은 시골 마을의 조산아에게 따뜻함을 제공하고 전통적 병원 인큐베이터의 일부 비용으로 접근할 수 있는 Embrace Warmer 침낭 장치 디자인에 영감을 줬다. 전통적인 접근방식은 인큐베이터 비용을 줄이기 위해 기술적 시도를 하는 동안, 공감 리서치는 핵심문제의 하나로 마을을 떠나 오랫동안 병원에 아기를 맡기는 것을 꺼리는 것으로 드러났다. 이것은 인큐베이터를 보온 장치로 재구성했다. 거기서부터 당신은 다음과 같은 후속 질문을 할 수 있다. 2. 더 작게 실행 가능하고 의미있는 질문들로 더 많은 POV Challenge로 시작하라. POV 하나당 5~10개 HMW질문은 좋은 출발점이다. 3. 솔루션 브레인스토밍 전, HMW질문에 대한 브레인스토밍을 하는것이 도움된다. 4. HMW 질문을 살펴보고 다양한 솔루션으로 이어질지 질문하라. 만약 그렇지 않다면 그들을 확장하라. HMW질문은 가능한 많은 답변을 만들고 브레인스토밍과 같은 아이디어 세션을 하는 동안, 발판이 될 것이다. 5. 만약 HMW질문이 너무 광범위하다면, 그들을 좁혀라. 브레인스토밍을 어디에서 시작할지 알 수 있도록 충분히 좁은 프레임을 목표로 해야한다. 하지만 동시에 거친 아이디어를 탐색할 수 있을 만큼 충분히 넓어야 한다. 훌륭한 POV는 인간 중심 문제 진술을 만들 것이다 POV를 만드는 것은 인간 중심 방식에서 문제 진술서처럼 문제를 정의하는데 도움된다. 인간 중심 문제 진술은 Design Thinking 프로젝트에서 중요하다. 왜냐하면, 당신과 당신의 팀을 안내하고 잠재적 특정 니즈에 촛점을 맞추기 때문이다. Design Thinking 과정의 아이디에이션 단계에서 아이디어를 만들 수 있게 가능성과 낙관적인 면을 만들어 준다. 좋은 문제 진술은 다음과 같은 특징이 있어야 한다. + 인간 중심. 이는 공감 단계 동안에 팀이 얻은 특정 사용자, 니즈, 인사이트로 문제 진술을 구성한다는 의미이다. 문제 진술은 기술적, 금전적 이익 또는 제품 사양에 촛점을 두기보다 팀이 돕고 싶은 사람들에 관한 것이어야 한다. + 창작의 자유를 위해 충분히 넓여야 한다. 이는 솔루션 구현에 관련 특정 방법론에서 너무 좁게 촛점을 맞추지 않아야 한다. 문제 진술은 기술적 요구 사항이 나열되어 있어야 한다. 왜냐하면, 이러한 것들은 팀을 불필요하게 제한하고 예기치 못한 가치와 통찰력을 가져올 수 있는 영역 탐색을 방해할지 모른다. + 관리할 수 있게 충분히 좁혀라. 다른 면에서, "인간 건강상태를 개선하라"와 같은 문제 진술은 너무 범위가 넓고 팀원이 쉽게 기분상하게 할 것 같다. 문제 진술은 그들을 쉽게 관리할 수 있을 만큼 충분한 제약요소를 가져야 한다. [출처 : https://www.interaction-design.org/literature/article/define-and-frame-your-design-challenge-by-creating-your-point-of-view-and-ask-how-might-we?utm_source=facebook&utm_medium=sm&utm_content=unpackinh_design_thinking_how_to_define_your_point_of_view_and_frame_your_design_challenge&utm_campaign=post] HMW 예시 우리가 어떻게 하면 가난한 농부들이 간단하고도 비용이 저렴한 장비와 서비스를 통해 경작지의 생산성을 끌어 올릴 수 있도록 지원할 수 있을까? |
How Might We 기법 - How Might We gibeob
관련 게시물
저작권 © 2024 nguoilontuoi Inc.
