스터디

Design Research Process 02

JiHae 2022. 5. 24. 15:41

내가 읽은 글 : https://brunch.co.kr/@rladudrl305/19

 

 

# 서비스 콘셉트

 

문제의 정의, 리서치 (시장조사, 유저조사, 서베이, 경쟁사 분석, 사용자 인터뷰 등), 이를 위해 사용한 방법론(페르소나, 사용자 여정 지도. 브레인 스토밍 등)을 통해 나온 결과에 의미를 부여하는 것

 

언제 / 누가 / 무엇을 / 어떻게 라는 질문을 통해 콘셉트 구조를 이해해야 함

- When / Where : 이런 상황에서 (context )

- Who : @@을 대상으로

- How : ##을 할 수 있는

- What : App / Websiste

 

 

# HOW MIGHT WE (HWM)

 

여러 디자인 방법론에서 응용됨

MAP 단계에서도 사용됨 / 구글 스프린트에서도 사용

일반적으로 내놓았던 추상적인 문장으로 나열된 해결방안들은 실천하기 쉬운 작은 계획으로 바꾸는 방법

AS IS - TO BE를 활용한 HWE 방법론

 

HMW에서는 AS-IS 와 TO-BE가 중요

- 앞에서 현재 상태의 문제점을 발견한 뒤, 개선된 가치를 제공, 사용자들에게 더 나은 경험을 제공해주는 것이 중요

- 사용자가 직면하는 문제점에서 해결책을 끌어내는데 도움이 됨

- 문제점은 사용자의 맥락과 상황 등 많은 것들과 깊은 연관이 있음

- 콘텍스트와 페인 포인트를 합한 것이 HMW

 

 

우선순위를 정하는 방식은 운영의 방식과 목적에 따라 다양하게 사용

자주 사용하는 것은 포지셔닝 맵

포지셔닝 맵

포지셔닝 맵

- X축과 Y축 기준을 두고 우선순위 아이데이션을 정리하는 것

- 특성에 따라 여러 기준을 설정할 수 있음

- 진행하면서 서비스 전체의 방향성이 정해질 수 있음

- 시작점에서부터 개선 결과까지의 연결고리가 논리적이어야 함 > 상대방 설득과 스스로 납들을 위해

 

 

 

# 유저 스토리 (User Story)

 

디자인과 개발을 하게 될 메인 Feature과 Task를 설명

 

같은 유저에 관한 스토리라고 하더라도 직군마다 같은 기능을 표현하는 방식, 그리고 생각하는 기능이 다르게 표현될 수 있기 때문에 이를 사용함

 

Feature

- 사용하는 주체, 기능, 목적을 정의

- 프로젝트에 연관된 실무자들을 위한 커뮤니케이션 도구 역할

- 애자일 방법론에서 많이 사용 /. 스크럼을 실행하는 조직에서 사용

- 유저들의 니즈를 짧게 묘사하는 방법 중 하나로 스크럼을 실행하는 조직에서도 사용

 

*스프린트

: 작업량 작고, 개발기간도 짧으며, 반복적인 개발 주기를 의미하며, 지속적으로 할 수 있는 개발단위 (평균 2주)

 

3가지 기준으로 설정할 수 있는 유저 스토리

 

 

# 유저 시나리오 (User Scenario)

 

"사용자가 이렇게 행동을 한다면 어떨까?"와 같은 질문을 끊임없이 던지면서 진행

 

특징

- 서비스나 제품이 제공할 새로운 사용자 경험을 이야기 형태로 기술하는 것

- 유저 스토리보다 더 넓은 범위의 사용자 목표들을 다룸

- 가능한 디자인 대안을 구체적으로 설명하는데 효과적

- 서비스나 제품이 사용자들과 어떻게 커뮤니케이션을 하는가에 효과적으로 사용

 

구성요소

- 사용자 : 정의한 페르소나

- 목표 : 무엇을 성취하려고 하는가?

- 동기 : 왜 그것을 달성하려고 하는가?

- 외부적 요소 External Factors

 : 사용자는 어디에 있는가? 감정상태는? 어떤 상황에 처해있는가?

 : 모바일 기기를 사용하는가? 데스크탑을 사용하는가?

 

장점

- 주체가 우리가 정한 페르소나일 경우 시나리오의 힘이 제대로 발생

- 사용자의 행동 패턴과 동기를 이해하고 들어가기 때문 (= 목표 / 동기)

- 테스크의 중요도와 순서, 페르소나의 목표에 초점을 맞추어 사용자에게 어떤 기능과 가치를 제공해야 하는지 생각

   > 그것에 맞춰 디자인의 방향을 설정할 수 있음

- 구성요소의 경우 사용자가 목표를 이루기 위해 필요한 리서치 내용을 바탕으로 테스크와 맥락을 이해할 수 있음

 

내비게이션(정보의 접근 방법), 콘텐츠와 정보적인 관점에서 접근의 방법을 고려할 수 있음

 

주의할 점

- 디자이너의 추측과 아이디어를 기반으로 작성되기 떄문에 사용자 리서치와 데이터 모델링 단계에서 수집되고 충분하게 분석된 자료들을 근거로 만들어져야 함

- 시나리오상 테스크들이 사용자의 목표를 중심으로 선택되었는가를 반복적으로 확인할 필요가 있음

 

 

 

# 유저 플로우 (User Flow)

 

유저가 서비스 또는 제품을 이용하면서 수행하는 구체적인 Task들의 Path를 나타냄

구체적인 화면, 기능, 인터렉션 등을 정의

* 개발할 수 있는 단계의 로직을 구성하는 경우 기획자는 매우 세밀하고 완벽하게 플로우를 그려야 함

 

페르소나에 따라 플로우가 달라지는 경우가 있어 각각의 페르소나에 맞는 플로우를 그릴 수 있어야 함

상황과 기능, 종류에 따라 다양하게 그려질 수 있음

 

 

 

# 정보구조 (Information Architecture)

 

정보구조 IA

- 제품 또는 서비스를 구성하는 정보, 요소들의 우선순위와 내비게이션, 구조 등을 도식화한 것

- 정보구조가 잘 설계되어 있어야 정보에 대한 직관적인 접근이 가능 > 사용자가 정보를 빠르고 쉽게 발견 > 목표 달성

- 서비스의 각 기능이 어떻게 묶여 있는지, 안의 콘텐츠는 무엇이 있는지 한눈에 확인

  > 서비스 또는 제품의 전체적인 그림 및 구조를 파악하고 확인할 수 있음

- 화면 또는 기능의 흐름에서 상하 관계를 고려하는 것이 가장 간단하게 정리하는 방식

 

Hierarchical Navigation

- 한 화면에서 시작해 한 뎁스씩 아래로 내려가는 방식

- stetting이나 mail앱에서 흔히 발견되는 내비게이션 형태

- 다른 Path로 가기 위해서는 처음 시작한 화면으로 되돌아와야 함

 

Flat Navigation

- 여러 카테고리의 콘텐츠 간 이동이 가능한 형태

- Music, App store 등 하단 탭이 있는 모바일 앱에서 보이는 구조

 

Content-Driven Navigation

- 콘텐츠 간 이동이 매우 자유로운 구조

- 콘텐츠 자체가 내비게이션을 결정

- 모바일 게임, 전자책 서비스에서 많이 보이는 형태

 

 

항상 IA는 명확하고 직관적인 Path를 제공하는 것이 중요

 

사용자가 정보와 콘텐츠에 접근하기 쉽도록 구조화하는 것에 집중하는 대신, 사용자의 탭, 스와이프, 화면 간의 이동은 최소화하는 것이 좋음