[UX/UI 스터디] 더블 다이아몬드 (디자인씽킹을 지탱하는 다이어그램)

이미지 출처 - Fluxspace

Discover - Empathy Building
문제를 풀 때 고객 중심으로 푼다.

이 단계에서 Assumption 가정 하기가 쉽다. 이 단계에서 Diverge라고 하는 이유는, 모든 것을 버리고, 내려놓고, 고객 데이터와 리서치에 흡수되어 고객의 진짜 문제를 찾아내자는 의미에서..

리서치 방법 : 상황에 따라, 어떤 솔루션을 찾느냐에 따라서 적합한 방법이 다름.
Quantitative vs Qualitative 양적 질적

• Ethnographic Study - 조사하는 사람이 유저의 환경에 들어가서 유저가 어떻게 행동하고, 우리의 제품을 이용하는지 직관하는 것. (Bias 되지 않고, Assume가정이 아닌 고객의 말에 의존할 필요도 없고, 제품을 실제로 이용하는 것을 보기 때문에 Discovery에 유용 & 많은 디자이너와 리서쳐들이 선호) 하지만 질적 리서치다 보니, 데이터적으로 봤을 때 많이 할 수 없음. (참여자 모집하는 등) 시간도 많이 들어서 (투자 많이해야함) 많아봐야 서너명의 유저들과 진행함. 회사입장에서도 제품을 빨리 출시해야하는 입장이니 오랜시간 여유있게 조사할 수 없음.
• 유저 인터뷰 User interview - 말 그대로 인터뷰, 제품을 쓰면서 느낀점들을 물어보면 자연스럽게 불편한 점들을 알아냄. (노골적으로 물어보기 보다는 Task based로 ‘이런 거는 어떻게 이용하나요?’ 이런식으로 질문하면서 조금씩 파고들어가는 방식으로. 
• Diary studies - Ethnographic study와 비슷, 일기장을 적어달라고 하는 것. 단점으로 시간이 많이 걸림.
• Focus Groups - 회사에서는 시간에 많이 쫒기다 보니 많아봐야 인터뷰를 7명 함. 그래서 한 세션에 한 명이 아닌 여러명에게 토론주제를 가지고 와서 대화나눠 보게 함. 주로 아이디에이션(새로운 생각)을 하려고 하거나 제품을 쓰면서 문제가 있을 때 서로 공감을 할 수 있는 환경을 만들어줌. 단점으로, 세션 당 말이 많다. Attention을 받는 유저들이 꼭 한 두명 있음. 그 사람들의 의견이 크게 반영되는 경우가 많기 때문에 진짜 동의하지 않는 상황에서도 이 사람들의 의견에 따라가는 경우가 많다. Discovery Phase에는 좋은데, 그 이후에는 쓰면 좀..별로..
• Surveys -  기본적인 데이터를 모으기 좋다. A/B테스트도 하고..
• Card Sorting -  기본적인 제품의 구성 A피쳐 B피쳐를 다 카드로 적은 다음에 사람들에게 ‘여러분의 생각대로 그룹핑 해주세요’라고 주문하여 멘탈모델. 도출 그들의 Mental Organisation을 통해 카드가 어떻게 정리되었냐에 따라서.. 이 방법은 양적 질적 리서치 모두 가능. 이걸 온라인으로 돌릴 수 있다. 실제로 7-8명에게 organising 해달라고 할 수도 있고, 유용함.

서베이와 카드소팅은 디스커버리 단계에서만 쓰지는 않음.
Quantitive research, 데이터를 많이 가지고 와서 분석하고 싶을 때 좋은 방법.

---

Define - Problem Definition

전 단계에서 모은 데이터로 <실제로,정확하게> 문제점이 무엇인지

Clearly defining the problem space by synthesising research findings, identifying user pain points, and framing the design challenge in a way that inspires creativity and innovation.

취합한 수많은 데이터에서 하나로 추려낸다는 의미에서 ‘Converge’ phase.

분석단계 : 다양하게 어떻게 분석을 할 지

Methodologies

• Affinity Mapping - 포스트잇으로 비슷한 데이터나 Finding을 테마별로 인사이트별로 그룹핑 > 그룹핑 한 것들 중 하이레벨 테마로 또 다시 그룹핑 (예 : 유저1이 유저인터뷰에서는 이렇게 얘기했고, 포커스그룹에서도 비슷한 것 두 가지가 나옴. 그럼 그 두 가지를 묶어서 테마를 정해준다. 그래서 유저는 이런 문제가 있다라고 정의함.) 하이레벨 테마에서도 서로 겹치는 테마가 있을 것임. 계속해서 하이레벨로 그룹핑. 어피니티 맵핑으로
• Personas -  데이터 기반 Assumption하여 실제로 존재하는 사람은 아니지만, 우리가 생각할 때 이런 고객이 우리의 제품을 쓰고 있고, 이런 문제를 가지고 있다는 거를 보여주는 페르소나. 디자이너들이나 혹은 스테이크 홀더들 피엠, 엔지니어 등에게 공감을 형성할 수 있게 해줌.
• User Journey Map -  유저가 프로덕트를 이용하는 과정을 보여주는 지도
• Design Principles Establishment - 리서치로 찾은 유저데이터로 Key customer problem을 정의. 엔지니어나 피엠들이 어떤 제품에 이런 아이디어가 있다. 혹은 (엔지니어들이 만들기 복잡하니) 이런 제품의 기능을 간소화 해달라고 하면 .. 많이 데이터들을 모아보면 패턴이 보이잖아요? 유저는 ~할 때 ~하다 등등.. 그거를 글로 적어서 규칙으로 만들어 놓으면 좋다. 나중에 implement phase에서 피엠이나 엔지니어가 ‘우리는 이 Feature를 없애야해 왜냐하면 데드라인이 얼마 안남았어’ 할 때 데이터에 기반한 principle을 제시하며 ‘유저가 이렇기 때문에 이 기능은 필요하다’고 대응할 수 있다.
• Problem Statements - Come up with “How might we” statements to → Stake holder들이 문제점을 파악하고, 집중할 수 있게 해줌.

---

Design - Ideation

Define단계에서 가져온 포인트들을 가지고, 디자인 시작 + 아이디에이션, 문제해결 과정, 창의적인 아이디어를 낼 수 있음.

Methodologies (정해진 것은 없음)

1. Brainstorming and Ideation - Engage in brainstorming sessions to generate a multitude of ideas and concepts. 

a. Mind Mapping
b. Competitive Analysis
c. Storyboarding

1. Wireframe/Lo-Fidelity Design - Create a skeletal outline or blueprint of the idea. It focuses on structure, layout, and functionality rather than visual design details.
2. Speed Dating - rapid-fire brainstorming or idea generation session where participants rotate between different groups or stations to share and gather ideas quickly.
   
   

---

Deliver - Test & Repeat

 딜리버 하고 사용하는 유저들 리서치. (리서치로 시작해서 리서치로 끝나는 다이아몬드)

• Prototyping - 디자이너 뿐만아니라 회사, 엔지니어들 모두 선호한다. 이유는 제작비용이 싸고 빠르다. 프로토타입 만들어 유저테스트 (사람들이 실제로 프로덕트를 사용한 것과 같기 때문에 유저빌리티 테스트하기 좋음) > 피드백 받고 디자인 보완 강화 > 다시 테스트 > 디자인 업그레이드 > 엔지니어에게 디자인을 건네기 전에 PRODUCTION READY DESIGN이 됨.
• User Testing - Ensure that the product meets user expectations and performs as intended. Test the product with real users in real-world scenarios to identify and remaining usability issues or areas for improvement.
• Card Sorting - Great methodology to assess user mental model for information hierarchy and architecture.
• Refinement and Prioritisation - Refine and prioritise the proposed solutions. This involves evaluating the feasibility, viability, and desirability of each concept. → 프로덕트 매니저랑 엔지니어 팀, 디자이너과 합쳐지는 상황. 디자인 리서치를 통해서 다양한 Features set을 만들어야 할 때, 주어진 타임라인 안에서 만들 수 있는 제품이 뭘까? 하고, Refinement and Prioritisation 미팅을 많이 함. 디자이너 입장에서 유저를 대변하여 ‘유저가 blahblah 이기 때문에 이 Feature는 꼭 론칭 되어야 한다’등의 의견을 피력할 수 있다. 프로덕트 디자이너는 타임라인에 맞게 주어진 시간 안에 제품을 론칭할 수 있고, 한 번에 다 런칭하지 않아도 되니 어떤 Feature set은 런칭 후에 제작할 수 있다. 등의 결정을 할 수 있다. 엔지니어는 스콥을 어떻게 잡고 어떻게 현실적으로 만들 수 있는지 고민하고, 아 Feature는 없어야 될 거 같다. 너무 크다 혹은 작다. 등의 의견을 냄. 여기서 바로 Converge가 됨. (여기서 무엇이 진짜 Deliver 되는지가 결정된다.)