제품 X 저장 – 디자인 씽킹 사례 연구
게시 됨: 2022-03-11디자인씽킹이란?
아이디어가 있다고 상상해보십시오. 비즈니스 문제를 해결할 수 있는 독창적인 응용 프로그램을 생각해 냈습니다. 현재 시장에는 동일한 솔루션이 없으며 가장 유사한 솔루션은 실제로 고객이 기대하는 방식으로 작동하지 않습니다.
당신의 비전은 아직 신선하지만 마음에 떠오르는 첫 번째 근본적인 질문에 대해 생각하기 시작합니다. "그것을 완료하는 데 얼마나 걸립니까?"
그리고 우리는 예산과 시간이 무제한인 경우가 거의 없기 때문에 두 번째 질문이 빨리 옵니다. "이 일을 하는 데 비용이 얼마나 들까요?"
이 두 가지 모두 제품을 만드는 데 있어 근본적이고 중요한 질문이지만, 처음부터 정확히 잘못된 질문인 경우가 많습니다.
대신, 가장 먼저 물어봐야 할 가장 중요한 질문은 "사용자를 위해 어떤 가치를 창출할 수 있습니까?"입니다.
프로젝트의 범위, 요구 사항 및 타이밍을 더 잘 이해하기 위해 제품의 "발견 단계" 동안 도움이 되는 "디자인 사고"라는 방법론을 사용할 수 있습니다. 지금이야말로 무엇이 훌륭한 제품을 만들 것인지뿐만 아니라 그것을 어떻게 , 어떻게 만들어야 하는지 이해해야 할 때입니다. 이 창의적이고 실험적인 접근 방식은 우리가 유용할 뿐만 아니라 무엇보다도 유용한 것을 만드는 방법을 더 잘 이해하는 데 도움이 됩니다.
디자인 씽킹 프로세스는 독특하고 구체적인 결과인 지식을 생성하기 때문에 특히 유용합니다.
이 방법론은 사용 범위가 더 넓지만 이 디자인 씽킹 사례 연구의 목적을 위해 소프트웨어 제품 개발이라는 특정 분야에만 초점을 맞출 것입니다.
디자인씽킹 이론
디자인 씽킹의 실제 적용과 이를 적용한 경험을 살펴보기 전에 먼저 디자인 씽킹 프로세스에 대해 자세히 살펴보겠습니다.
디자인 씽킹은 문제 해결을 위한 솔루션 기반 접근 방식을 제공하는 방법론입니다. 인간 중심의 관점에서 사용자의 관점을 이해하는 데 중점을 둡니다. 이 방법론의 장점은 아이디어, 솔루션 또는 개선 사항이 고객에게 실제 결과를 가져올 수 있는지 신속하게 테스트할 수 있다는 것입니다. 다양한 분야(마케팅, 심리학, 디자인, 비즈니스)에서 오는 다양한 방법론, 도구 및 기술을 통합하는 디자인 씽킹의 목적은 사용자를 우리가 해결해야 하는 문제의 중심에 두는 것입니다.
방법론의 목표는 "사용자 자신을 찾아 사용자의 요구 사항을 정의"하고 이러한 요구 사항을 찾아서 실제로 유용할 수 있는 솔루션 또는 제품을 만드는 것입니다. 이 목표를 달성하기 위해 전체 개념은 6개의 디자인 사고 단계로 나뉩니다.
- 공감: 이 단계의 목표는 고객의 비즈니스에 대한 정보를 검색하고 수집하여 고객을 이해하는 것입니다. 이 단계에서 인터뷰, 포커스 그룹, 관찰 및 설문 조사와 같은 여러 도구를 사용할 수 있습니다.
- 정의: 이 단계에서는 공감 단계에서 정보를 수집하고 분류합니다. 여기에서 사용자 페르소나와 사용자 여정을 정의합니다.
- Ideate: 여기에서 팀은 위의 정보를 사용하여 솔루션을 아이디어화합니다. 어리석거나 잘못된 생각은 없습니다! 모든 것이 표현되고 문서화되어야 합니다.
- 프로토타입: 이 단계에서 실제 생활에서 아이디어를 확인할 수 있는 유형의 무언가가 생성됩니다. 이 MVP를 너무 복잡하게 만들지 말고 최대한 빨리 만드십시오.
- 테스트: 실제 사용자와 함께 실제 생활에서 아이디어를 확인합니다. 피드백을 받으세요. 개선 방법에 대해 질문하십시오.
- 구현: 수집된 모든 지식이 최종 제품으로 변환되는 단계입니다.
이 글을 읽은 후 "훌륭하지만 이것이 내 앱을 신속하게 현실화하는 데 어떻게 도움이 될까요?"라고 생각할 수 있습니다. 이를 보다 구체적으로 설명하기 위해 디자인 사고 프로세스의 이점을 얻은 제 개인적인 경험의 사례 연구를 살펴보겠습니다.
디자인 씽킹 적용 - 실제 사례 연구
소개: 프로젝트 X
얼마 전 나는 기업가, 몇 명의 관리자, 그리고 방을 맴도는 많은 아이디어와 회의에서 자신을 발견했습니다. 그들의 직접적인 경쟁자는 최근에 새로운 애플리케이션을 출시했고 긴장감이 느껴졌습니다. 이 회사는 경쟁자에게 입지를 잃지 않기 위해 시장에 새로운 제품을 출시하기를 원했습니다.
그들은 몇 가지 요구 사항, 제품이 어떻게 생겼는지, 가격이 얼마인지에 대한 막연한 아이디어가 포함된 문서를 준비했습니다.
마케팅 이사는 "우리는 다른 사람들이 해온 것을 따라야 하고 더 낮은 가격으로 따라야 합니다."라고 말했습니다. 다른 관리자는 "사용자 여정을 단순화하는 보다 유용한 시스템을 만들어야 합니다."라고 덧붙였습니다. 다른 사람은 "정보 수집 방식을 변경하고 단순화하며 프로세스를 타사와 통합해야 합니다."라고 말했습니다. "몇 달이 걸릴 것입니다."라고 기술 관리자가 고개를 저었고, 그는 이러한 모든 요청을 수백 시간의 코드로 정신적으로 번역하여 구현했습니다.
모든 프로젝트 세부 사항을 밝힐 수는 없지만 제품이 허브 통신 소프트웨어였다는 것은 밝힐 수 있습니다. 이 소프트웨어는 다양한 채널(이메일에서 SMS로, 팩스에서 VoIP로)을 관리했으며 웹 및 모바일 플랫폼용으로 제작되었습니다. 제품은 원래 몇 년 전에 만들어졌지만 사용성이 좋지 않았습니다. 출시 당시에는 경쟁업체가 사용자 경험 면에서 훨씬 앞서 있었습니다. 게다가 그들은 모바일 앱 스토어에서 입지를 굳히고 있는 우수한 모바일 앱을 가지고 있었습니다.
X사는 전통적인 프로젝트에 익숙한 전통적인 프로세스 중심의 회사였습니다. 과거에 몇 가지 Agile 프로젝트를 실행했지만 MVP를 만들고 시장에서 테스트한다는 아이디어는 낯설었습니다. 특히 그들은 미지의 것을 두려워했습니다. 새로운 MVP가 고객 사용자 기반에 바람직하지 않거나 예측할 수 없는 영향을 미치면 어떻게 됩니까? 이러한 통제력 부족은 자신감을 불러일으키지 못했습니다.
위에서 설명한 회의와 다음 회의는 실제로 달성해야 할 제품이 무엇인지에 대한 명확한 정의로 이어지지 않았습니다. 우리는 가능한 한 빨리 목표를 달성해야 한다는 것만 알고 있었습니다.
그러나 프로젝트가 진행되고 경쟁자가 눈에 띄기 시작하면서 회사의 동의가 굳어졌습니다. 대부분은 "반제품을 출시할 여력이 없다. 처음부터 제대로 작동하는 제품이 필요하다"는 아이디어에 동의했다.
처음에는 약간의 당혹감과 두려움에도 불구하고 능률적인 경량 제품을 만들어 사용자 기반에 진정한 가치를 제공하고 잠재적으로 더 많은 사용자를 유치할 수 있는 방법을 배울 수 있는 기회였습니다.
이로 인해 회사는 출시 시 필수 기능만 포함하더라도 완전한 제품을 제시간에 구축하기 위해 이전에 시도하지 않은 접근 방식을 찾게 되었습니다. 우리는 디자인 씽킹 프로세스를 사용하고 최종 사용자에게 실제로 가치를 가져다주는 것에 집중하기로 결정했고, 따라서 고객에게 필요한 것만 가져와서 경쟁에서 이겼습니다.
1단계 - 공감
공감 단계: 이 단계의 목표는 고객의 비즈니스에 대한 정보를 검색하고 수집하여 고객을 이해하는 것입니다. 이 단계에서 인터뷰, 포커스 그룹, 관찰 및 설문 조사와 같은 여러 도구를 사용할 수 있습니다.
가장 문자적인 의미에서 공감은 다른 사람의 감정을 이해하고 공유하는 능력입니다. 디자인 사고에서 공감은 "당신이 디자인하는 사람들의 문제와 현실에 대한 깊은 이해"입니다.
우리의 첫 번째 단계는 최고 급여를 받는 사람의 의견(또는 HiPPO라고도 함)이 다른 모든 사람의 의견을 지배하지 않도록 하는 것이었습니다. 따라서 관리자 및 설립자와 함께 의사 결정 프로세스에 참여할 수 있는 이해 관계자 목록을 작성했습니다.
하루 종일 회의에서 우리는 직접 연락할 수 있는 30명의 이름(직원, 기능 관리자 및 고객 간)의 첫 번째 목록을 편집한 다음 4000명의 고객(반복 고객 사용자의 약 10%)의 대상 고객도 선택했습니다. 베이스).
성별 분포, 산업 및 기타 데이터 요소의 다양성을 포함하여 목표 고객 기반을 최대한 "정규화"하려고 했습니다. 복잡성을 더하기 위해 인터뷰할 샘플의 물리적 위치는 모두 다른 도시와 일부 국가로 나누어졌습니다. 이제 인터뷰와 설문지를 수행할 연락처가 생겼습니다.
이 그룹은 스크립트로 작성된 일련의 질문과 몇 가지 기본 규칙에 따라 원격으로 인터뷰를 수행하도록 구성되었습니다.
- 인터뷰하는 동안 "5 Whys" 기법을 사용하십시오.
- 모든 행동 뒤에 숨겨진 주요 "무엇을, 어떻게, 왜"를 이해하려고 노력하십시오.
- 인터뷰 대상자가 웹캠을 사용했는지 확인하고 적어도 부분적으로 신체 언어를 포함할 수 있도록 카메라에서 충분한 거리를 유지했는지 확인합니다.
- 나중에 볼 필요가 있는 경우에 대비하여 모든 인터뷰를 녹음합니다.
우리는 사용자의 요구에 부응하는 새 버전을 신속하게 구축할 수 있도록 어떤 주요 기능을 개선하거나 제거해야 하는지 이해하려는 의도로 인터뷰 질문을 준비했습니다.
두 번째 사용자 그룹을 위해 Google 양식에 일련의 질문을 준비했습니다. 우리는 사용자가 클로즈 베타에서 사용할 수 있는 새 버전의 제품을 사용해 보라고 요구하는 질문을 포함하여 사용자와의 더 많은 상호 작용을 촉진하기 위해 공식화된 개방형 질문과 함께 객관식 질문을 선택했습니다.
전체 정보 수집 프로세스를 구성하기 위해 Skype, Zoom, Google Forms 및 모든 활동을 기록하고 상태를 추적하는 디지털 Kanban 보드를 포함하여 팀이 더 쉽게 정보를 수집할 수 있는 원격 도구를 사용했습니다.
인터뷰 대상자들이 시스템의 약점과 강점에 대해 열린 마음으로 피드백을 제공했기 때문에 인터뷰의 첫 번째 결과는 고무적이었습니다.
그러나 첫 번째 설문지 답변은 훨씬 덜 흥미로웠습니다. 보낸 300개의 이메일 중 5명만이 설문지를 완료했습니다.
이 결과에 실망한 우리는 사용자 기반을 참여시킬 새로운 방법을 시도할 준비가 되었고 한 영업 관리자가 다음과 같은 아이디어를 제안했습니다.
“나는 그들이 어떤 이메일에도 답하지 않을 것이라고 생각합니다. 그들은 우리와 상호 작용하는 데 익숙하지 않습니다. 그러나 갱신이 만료되는 모든 사람들과 소통하고 그들에게 작은 인센티브를 준다면 그들이 우리를 도와줄 것이라고 확신합니다.”
아이디어는 간단하지만 예외적이었습니다. 몇 시간 만에 새로운 사용자 목록(3800명)이 생겼고, 이 목록은 주류와 극단 사이에서 동일한 구분을 유지했습니다. 그러나 이러한 사용자는 갱신의 근접성으로 인해 시스템과 "강제로" 상호 작용해야 합니다.
이번에는 일련의 질문에 답하고, 베타에 참여하고, 그 대가로 갱신 할인을 받으라는 요청을 받았습니다. 접착은 완벽했고, 이 신모델은 처음 배송되었을 때 사용자의 70% 이상이 설문에 응답하고 완료했습니다.
몇 가지 질문을 반복하고 변경한 후, 그리고 두 번 이상 인터뷰할 의사가 있는 일부 사용자 덕분에 우리는 사용자 기반을 보다 명확하게 정의할 준비가 되었습니다.
2단계 - 정의
정의 단계: 이 단계에서는 공감 단계에서 정보를 수집하고 분류합니다. 여기에서 사용자 페르소나와 사용자 여정을 정의합니다.
정의하다의 사전적 의미 는 개념의 정체성과 본질을 결정하는 것이다 . 우리의 경우 다음을 정의하고 싶었습니다.
- 우리의 이상적인 고객
- 그들의 문제
- 그들의 문제에 대한 해결책
- 우리가 해결해야 했던 고객의 요구와 두려움
디자인 사고 방식에서 정의 단계는 관찰을 분석하고 식별한 핵심 문제로 종합하는 단계입니다.
실제 문제가 무엇인지 이해하기에 충분한 데이터베이스가 있었습니다. Empathize 단계에서 받은 피드백 외에도 X 회사 직원이 강조했지만 경영진에게 한 번도 지적한 적이 없는 점과 한 번도 고려되지 않은 강점, 약점 및 기타 문제가 포함되어 있습니다.
다음 작업은 사용자 페르소나를 만드는 것이었습니다. 이 브레인스토밍 단계에서 우리는 확장된 전체 팀을 참여시켰습니다. 브레인스토밍 단계는 화상 회의 시스템과 도구를 사용하여 페르소나와 그 생성을 실시간으로 추적하여 항상 원격으로 수행되었습니다.

각 페르소나에 대해 우리는 그들의 전기, 기술에 대한 접근 방식, 소셜 미디어 사용, 선호하는 브랜드, 요구 사항 및 아이디어를 식별하고 고객 여정이 어땠을지 추측했습니다.
그 후, 우리는 공통 클라이언트 사용자 페르소나를 선택했고 인터뷰와 설문조사에서 나온 데이터 세트를 완성했습니다. 이것은 우리의 손을 더럽힐 적절한 시간이었습니다.
정의 단계에서 우리는 "우리는 매출을 10% 증가시킬 제품이 필요합니다"와 같은 문제에 대한 일반적인 정의를 "35세에서 45세 사이의 남성과 성인 여성"과 같은 보다 구체적인 솔루션으로 변환하려고 했습니다. 사무실에서 일하는 사람들은 보낸 사람이 실제로 그들이 말하는 사람인지 확인하기 위해 법적 효력이 있는 통신문을 받아야 합니다.”
프로젝트 프로세스의 이 시점에서 우리는 사용자에 대한 브레인스토밍 세션을 완료하고 솔루션을 가정했으며 가능한 모든 혁신에 열린 마음을 유지했습니다. "유일한 어리석은 생각은 결코 표현되지 않은 생각입니다."는 진언이었습니다.
우리의 주체가 누구인지를 염두에 두고 짧은 시간 안에 사용자에게 유용한 것이 무엇인지, 고객 여정에서 해결해야 하는 요구 사항과 우려 사항이 무엇인지 명확하게 파악했습니다.
그런 다음 사용자의 프로세스를 범주화하고 테마에 매핑할 수 있는 "사용자 스토리 맵"을 구축하는 데 참여했습니다. 각 페르소나에 대해 여정 동안 완료해야 한다고 가정하는 일련의 활동, 이야기 및 작업을 정의했습니다. 그렇게 함으로써 우리의 아이디어를 신속하게 테스트하고 핵심 요구 사항을 충족하는지 이해할 수 있었습니다. 그렇게 한다면 경쟁업체가 날로 더 성공을 거두고 있기 때문에 다른 누구보다 빠르게 시장에 출시할 수 있었습니다.
3단계 - 이상화
아이디어 구상 단계: 여기에서 팀은 위의 정보를 사용하여 솔루션을 아이디어화합니다. 어리석거나 잘못된 생각은 없습니다! 모든 것이 표현되고 문서화되어야 합니다.
정의에서 한 단계 더 나아가서 핵심은 추상적인 정의가 아니라 실제 개념과 솔루션을 형성하는 아이디어 단계입니다.
디자인 씽킹 용어로, 관념화는 "스케치, 프로토타이핑, 브레인스토밍, 브레인라이팅, 최악의 아이디어 및 기타 다양한 관념화 기술과 같은 세션을 통해 아이디어와 솔루션을 생성하는 프로세스"입니다.
우리 팀은 완전히 원격이었기 때문에 재료를 생산하고 검토할 때 린 방식으로 작업을 진행하기로 결정했습니다. 예를 들어, 디자이너와 팀의 다른 구성원은 가능한 한 빨리 종이에 그림을 그리는 것으로 시작하여 그룹에서 사진을 공유하는 것이 가장 좋은 해결책이라는 데 동의했습니다. 그래야만 Balsamiq 또는 Axure에서 가장 흥미로운 디자인을 생산할 수 있습니다.
생성된 각 스케치에 대해 사용자로부터 정보를 수집하고 일련의 솔루션을 정의한 다음 해당 사용자에게 돌아와서(가능한 한 자주) 프로세스와 결과를 테스트했습니다.
4단계 - 프로토타입
프로토타이핑 단계: _ 이 단계에서 실제 생활에서 아이디어를 검증할 수 있는 유형의 무언가가 생성됩니다. 이 MVP를 너무 복잡하게 만들지 말고 최대한 빨리 만드십시오. _
프로토타입 단계에서 마침내 우리의 정의와 아이디어가 실현될 시간이었습니다. 프로토타입은 제안된 제품의 첫 번째 원본 모델이며 이것이 바로 우리가 구축하기 시작한 것입니다. 디자인 사고 기준에 따르면 프로토타입 단계는 실제 제품의 저렴하고 축소된 버전을 만들어 이전 단계의 솔루션을 조사하는 단계입니다.
여정을 시작한 지 거의 10일 만에 우리는 결정적인 순간에 이르렀습니다. 바로 개발자 팀과의 회의에서 우리의 가정과 추정을 확인할 기회가 있었습니다. 개발자 팀과의 협의 및 정의 세션 후, 우리는 이야기를 평가했고 개발 작업의 주요 노력은 백엔드 시스템의 개발과 현재 제자리에 있는 레거시 시스템과의 인터페이스에 있을 것이라는 점을 이해했습니다. 이와 함께 프론트엔드 시스템을 만드는 것이 훨씬 더 짧은 시간이 될 것이라는 것도 깨달았습니다. 따라서 우리는 시간을 절약하기 위해 시스템에 이미 존재하는 구성 요소를 사용하여 프런트 엔드 프로토타입을 만들기로 결정했습니다.
프로토타입의 첫 번째 버전을 준비하는 데 3일이라는 시간 제한이 있었습니다. 이 프로토타입은 최대한 제품을 반영하고 필요한 기능을 유지해야 했습니다.
3일 후 프로토타입의 첫 번째 버전이 준비되었습니다. 우리가 만들고자 했던 소프트웨어의 동작을 반영하는 "가짜" 데이터가 있었습니다. 일부 액세서리 요소가 누락되었지만 해당 상태의 소프트웨어는 계획된 전체 콘텐츠의 상당한 비율을 시각적으로 나타냅니다.
2주의 작업 끝에 실제 사용자와 함께 테스트할 수 있는 소프트웨어가 생겼습니다. 우리는 사용자 경험 모니터링 소프트웨어를 사용하여 프로토타입을 탐색하는 동안 히트 맵과 사용자 주의를 분석했습니다.
5단계 - 테스트
테스트 단계 - 실제 사용자와 함께 실제 생활에서 아이디어를 확인합니다. 피드백을 받으세요. 개선 방법에 대해 질문하십시오.
정의, 아이디어 및 프로토타입 단계를 거친 후 마침내 우리 제품이 실제 생활에서 실제로 작동하는지 확인할 차례였습니다. 디자인 사고 방식에서 테스트는 프로토타입 단계에서 생성된 최상의 솔루션을 사용하여 완전한 제품을 시험해 보는 것을 의미합니다.
우리의 경우 테스트 단계가 끝날 때만 발생한 것이 아니라 가능할 때마다 피드백과 반복의 지속적인 루프였습니다. 각 단계가 완료될 때마다 사용자 또는 고객으로부터 피드백을 받고 다음 단계로 넘어갈 수 있도록 설득했습니다.
프로토타입이 완성되면 최대한 많은 청중을 대상으로 테스트하고 고객의 요구를 얼마나 효과적으로 충족하는지, 고객의 인식을 이해하고, 목표를 달성했는지 이해해야 합니다.
테스트 단계에는 특히 사용자가 새 워크플로를 보고 작업을 수행할 수 있는 연습 프로토타입과 팀에서 사용자를 직접 관찰하면서 응답을 추적하는 몇 가지 세션이 포함되었습니다. 플랫폼의 특정 기능에 대한 전환율을 수집하기 위해 간단한 설문지를 사용했으며, 사용자는 1-10의 프로세스 점수를 매기도록 요청받았습니다.
테스트 단계는 나중에 전체 팀과 심지어 초기 세션 동안 시스템 구현에 대한 피드백을 제공하는 데 기꺼이 동의한 조직 외부의 일부 개인(고객 및 사용자)까지 확장되었습니다.
이 테스트의 결과는 고무적이었습니다. X사의 이해관계자들은 목업을 볼 수 있을 뿐만 아니라 처음으로 제품을 체험해보고 만질 수 있었습니다. 확장된 팀은 2주 이내에 가정을 테스트 및 검증하고 시간이 지남에 따라 수정할 수 있는 기회를 가졌습니다.
이제 최종 테스트가 기다리고 있었습니다. 사용자에게 테스트를 공개하고 다음에 일어날 일을 이해하는 것이었습니다.
6단계 - 구현
구현 단계: 수집된 모든 지식이 최종 제품으로 변환되는 단계입니다.
우리는 데이터, 아이디어, 페르소나 및 첫 번째 유형의 프로토타입을 가지고 있었습니다. 소매를 걷어붙이고 개발을 시작할 때였습니다. 새 시스템을 구현하는 데 한 달 반이 걸렸습니다.
짧은 시간에 MVP를 구현하기 위해 다음과 같은 규칙을 정의했습니다.
- 우리는 새로운 기능을 추가하지 않고 우리가 정의한 것만 구축할 것입니다.
- 우리는 주요 비즈니스 목표에 계속 집중할 것입니다.
- 팀 내에서 애자일 방법론을 사용하여 워크로드를 관리합니다.
프로젝트를 제시간에 완료하기 위해 발견 단계의 초기 단계부터 프로젝트에 참여하지 않은 몇 명의 새로운 팀원을 영입했습니다.
프론트엔드 개발자, 백엔드 개발자, 디자이너를 추가했습니다. 팀의 새로운 구성원은 원격으로 작업했고 프로젝트 기간 동안 모든 구성원을 같은 방에 모을 수 없었기 때문에 의사 소통을 유지하기 위한 올바른 도구가 있는지 확인했습니다.
작업을 관리하기 위해 배치된 프로세스는 애자일 프로세스였습니다. 우리는 남은 시간을 여러 개의 짧은 스프린트로 나누었습니다. 매일 원격 회의를 하고 낮에는 Slack을 통해 업데이트하여 아이디어를 교환하고 서로 문제를 해결하도록 도왔습니다.
전체 문서가 어딘가에 저장되어 있지는 않았지만 정신적으로 우리 모두는 팀 간에 포괄적인 작업 세트, 공통된 비전 및 목표를 가지고 있었습니다. 우리 모두는 사용자 페르소나를 자신의 필요와 문제가 있는 실제 사용자로 인식하기 시작했습니다. 우리 팀이 정렬된 비전을 갖기 시작하자 우리는 프로젝트를 제시간에 완료하기 위해 무엇을 해야 하고 언제 완료해야 하는지 정의하는 단계로 넘어갔습니다.
활동은 페르소나의 원래 증거와 제품에 제공하려는 흐름을 유지하기 위해 User Story Map에 요약되어 있습니다.
사용자 스토리 맵은 활동 식별, 활동 완료에 필요한 단계 식별, 각각과 관련된 스토리/작업 목록의 세 가지 명확한 단계를 통해 생성되었습니다. 어떤 구성 요소가 제품을 구성하는지 지시하는 우선 순위(반드시, 해야 함, 할 수 있음)에 따라 스토리를 분류했습니다.
팀이 공유한 명확한 비전과 위 경영진의 직접적인 지시 없이 팀이 궤도를 유지할 수 있도록 하는 방법 덕분에 팀은 구현 초기부터 빠른 속도로 진행할 수 있었습니다. 프로젝트에 참여하는 모든 사람들은 디자인 씽킹 단계에서 다음과 같은 질문을 염두에 두고 있었습니다.
- 플랫폼 내부의 각 사용자는 어떤 작업을 수행해야 하며 무엇을 달성하려고 했습니까?
- 이러한 사용자가 최종 목표에 도달하기 위해 취해야 하는 단계는 무엇입니까?
- 이전에 어떤 고통을 겪었으며 어떻게 피해야 합니까?
이를 통해 우리 팀은 자체적인 미세 결정을 내리고 최종 목표를 향해 제품을 조정할 수 있었습니다.
우리는 각 스프린트가 끝날 때 진행 중인 작업에 대한 두 가지 검토를 수행하고 제품이 최종적으로 생산에 들어가기 전에 경로가 끝날 때 한 번의 최종 릴리스 검토를 했습니다. 마지막 스프린트를 사용하여 제품을 실행하고 출시하는 데 필요한 인프라를 준비했습니다.
마지막으로 기존 제품을 사용하던 사용자를 다시 초대하여 새 버전을 사용해 보도록 했습니다. 우리 제품은 만들기에 대한 아이디어가 표현된 회의 후 2개월 후에 생산에 출시되었습니다. 제품이 작동하고 사용자가 사용하기 시작했으며 점진적으로 이전 도구 대신 이 도구에 더 많은 새 사용자를 보냈습니다. A/B 테스팅은 그들이 신제품을 선호한다는 것을 보여주었고, 그 프로젝트는 회사에서 대성공으로 받아들였습니다.
더 중요한 것은 디자인 씽킹 방법론이 마침내 받아들여졌다는 것입니다. 우리는 이것이 훌륭하고 오래 지속되는 영향을 미치고 미래에 더 나은 제품을 만들 수 있다고 믿습니다.
결론
이 사례 연구를 통해 제한된 시간과 예산으로 실제 문제에 디자인 씽킹 방법론을 적용하는 방법을 보여주었습니다.
보다 전통적인 접근 방식을 사용하고 순차적인 단계로 제품을 생산하는 대신 6가지 디자인 사고 단계를 반복하기로 결정했습니다. 공감. 정의하다. 아이디어. 원기. 테스트. 구현하다. 이것이 우리의 만트라가 되었고 매우 좋은 반응을 얻은 제품을 생산할 수 있게 되었습니다.
디자인 씽킹을 사용하면 시간을 절약할 수 있고 결과적으로 프로젝트 비용을 절약할 수 있습니다. 우리는 수백만 가지의 다양한 기능에 대해 작업한 것이 아니라 팀의 모든 사람에게 명확한 작업을 통해 잘 생각한 소수의 기능만 작업했습니다. 무엇보다 사용자가 필요로 하는 제품과 가치를 전달할 수 있었습니다.
디자인 씽킹 프로세스를 사용하면 다음과 같은 다양한 영역에서 도움이 됩니다.
- 프로젝트 관리 관점에서 프로젝트 범위를 명확하게 정의하고 범위 이동을 방지할 수 있었습니다.
- 비즈니스 관점에서 비즈니스에 진정한 가치를 제공하는 기능을 선택할 수 있었습니다.
- 개발 관점에서 볼 때 빌드를 시작하기 전에 빌드해야 하는 명확한 목표를 보는 데 도움이 되었습니다.
- 팀 관점에서는 모든 팀 구성원이 참여하여 프로세스의 모든 부분에서 효과적으로 협력하고 의견을 들을 수 있었습니다.
우리가 디자인 씽킹 프로세스를 시작했을 때 클라이언트는 회의적인 반응을 보였습니다. 그러나 완료하고 고객으로부터 피드백을 받았을 때 우리가 제시한 단계가 매우 어렵거나 그렇지 않으면 불가능합니다. 이것은 고객이 높이 평가했으며 앞으로의 도전 과제에 대한 내부 주력 프로젝트가 되었습니다.