DAY 02 | 디자인 스프린트 Day 1 — 팀 빌딩과 문제 정의
오늘부터 본격적인 디자인 스프린트가 시작됐다.
이번 프로젝트는 단순히 서비스를 기획하는 것이 아니라, 5일이라는 짧은 기간 안에 문제를 정의하고 해결책을 설계한 뒤 프로토타입까지 제작해 사용자 검증을 진행하는 방식으로 진행된다.
오늘은 팀을 구성하고 프로젝트 주제를 선정한 뒤, 해결해야 할 문제를 구체적으로 정의하는 시간을 가졌다.
오늘 배운 내용
1. 디자인 스프린트란?
디자인 스프린트는 구글벤처스(GV)에서 만든 문제 해결 방법론으로, 짧은 시간 안에 아이디어를 검증하기 위한 프로세스다.
기존 서비스 개발은 기획부터 개발, 출시까지 오랜 시간이 걸리기 때문에 잘못된 방향으로 진행되더라도 뒤늦게 문제를 발견하는 경우가 많다.
디자인 스프린트는 이러한 시행착오를 줄이기 위해 문제 정의부터 프로토타입 테스트까지를 5일 안에 빠르게 진행한다.
수업에서는 디자인 스프린트가 해결하려는 대표적인 문제도 함께 소개됐다.
- 무엇을 해결해야 하는지 명확하지 않은 상태에서 프로젝트가 시작되는 경우
- 기획자, 디자이너, 개발자가 서로 다른 목표를 바라보는 경우
- 프로젝트 범위가 계속 변경되면서 핵심 목표가 흐려지는 경우
- 충분한 사용자 검증 없이 내부 의견만으로 의사결정하는 경우
결국 디자인 스프린트는 빠르게 만들기 위한 방법론이 아니라, 올바른 문제를 빠르게 검증하기 위한 방법론이라는 점을 이해할 수 있었다.
2. 디자인 스프린트를 통해 배우는 것
이번 과정에서는 단순히 결과물을 만드는 것보다 문제를 정의하고 검증하는 과정을 더 중요하게 다루고 있었다.
특히 다음 다섯 가지 역량을 중심으로 프로젝트가 진행된다.
- 문제 해결의 본질(WHY) 정의
- 협업과 커뮤니케이션
- 애자일(Agile) 방식의 프로젝트 진행
- 데이터 기반 의사결정
- 프로젝트 결과물 도출 및 검증
기능을 많이 만드는 것보다, 해결하려는 문제가 정말 존재하는지 확인하는 과정이 핵심이라는 점이 인상적이었다.
팀 프로젝트
팀 구성
이번 프로젝트는 총 5명으로 구성되었다.
- 선아님
- 연수님
- 형준님
- 재현님
- 나
주제 선정 — 쿠팡 가품 문제
팀 주제는 내가 제안한 아이디어가 선정됐다. (야호)
예전에 쿠팡에서 화장품을 구매했다가 가품으로 의심되는 제품을 받은 경험이 있었고, 관련 사례를 찾아보니 비슷한 피해가 꾸준히 발생하고 있다는 점에서 문제를 구체화할 수 있었다.
| 항목 | 내용 |
|---|---|
| 기업 | 쿠팡 |
| 서비스 | 상품 상세 페이지 및 구매 경험 |
| 문제 | 구매 전에 판매자의 신뢰도를 판단하기 어려움 |
리서치를 진행하면서 쿠팡의 ‘아이템 위너’ 구조에서는 동일 상품의 리뷰가 판매자와 관계없이 합산되어 표시된다는 점을 확인했다.
이 때문에 새로운 판매자가 기존 상품 정보를 그대로 활용해 가격만 낮춰 판매하더라도, 소비자는 현재 판매자의 신뢰도를 확인하기 어렵다.
결국 상품에 대한 리뷰는 많지만 현재 구매하려는 판매자가 믿을 만한 판매자인지는 판단하기 어렵다는 것이 핵심 문제라고 정의했다.
문제 해결 방향
우리 팀은 구매 결정 시점에서 판매자의 신뢰도를 직관적으로 확인할 수 있는 UX를 제안하기로 했다.
아이디어는 다음과 같다.
- 판매자별 리뷰 필터 제공
- 현재 구매 가능한 판매자의 리뷰를 기본으로 노출
- 판매자 유형, 입점 기간, 가품 신고 이력을 기반으로 신뢰 배지 제공
서비스의 핵심 정보는 유지하면서도, 사용자가 구매 전에 판매자를 판단할 수 있도록 돕는 방향으로 문제를 해결하고자 했다.
HMW(How Might We)
문제를 정의한 뒤에는 HMW를 활용해 해결 방향을 구체화했다.
팀에서 도출한 질문은 다음과 같다.
- 어떻게 하면 소비자가 가품 의심 상품을 쉽게 신고하고 결과를 확인할 수 있을까?
- 어떻게 셀러 정보를 더 투명하게 제공할 수 있을까?
- 어떻게 수많은 리뷰 속에서 가품 관련 후기만 빠르게 확인할 수 있을까?
- 어떻게 사용자들의 신고와 피드백을 다른 구매자에게 효과적으로 전달할 수 있을까?
장기 목표는 사용자가 별도의 검증 과정 없이도 안심하고 구매할 수 있는 플랫폼을 만드는 것이다.
느낀 점
오늘 가장 크게 느낀 점은 문제 정의는 거창한 아이디어보다 실제 경험에서 시작될 때 더 설득력이 있다는 것이었다.
내가 직접 겪었던 불편함을 바탕으로 문제를 제안했고, 팀원들도 공감하면서 자연스럽게 프로젝트 주제로 이어질 수 있었다.
또한 개발을 할 때는 해결 방법부터 고민하는 경우가 많았는데, 디자인 스프린트에서는 해결책보다 먼저 “정말 해결해야 하는 문제인가?”를 반복해서 검증하는 과정이 인상적이었다.
앞으로 남은 스프린트에서도 기능을 추가하는 것보다 사용자의 문제를 얼마나 정확하게 정의하고 검증하는지가 더 중요하다는 점을 계속 의식하면서 프로젝트를 진행해보고 싶다.
취업 부트캠프 청년취업사관학교 새싹 aipm dx교육 ai교육 실무프로젝트 실무경험 취업포트폴리오 포트폴리오 전z전능 코멘토 모비니티