UX 기획 및 리서치 - 4

청산류수·2024년 7월 12일
0

내배캠 UXUI

목록 보기
81/101

UX 기획 첫 단추 : 문제 정의 및 가설 수립

문제 정의
유저 리서치를 통해서 발견한 여러 문제들중 어떤 문제를 해결 할 것인지 문제를 정의
문제의 크기를 정확한 수치로 파악해서 전달
왜 문제인지에 대한 근거 왜 발생하게 됐는지 근거 데이터 파악

문제를 풀고자 하는 목적
문제
문제를 풀었을 때의 임팩트

가설 수립
-가설 설정
특정 문제에 대해서 가정을 명확하게 정의하고 검증가능한 형태로 제시하는 단계
작은 문제부터 큰 문제까지 가설을 통해 검증할 수 있지만 한큐에 해결하는 것은 어려울 수 있다. 그래서 스텝 바이 스텝으로 쪼개서 생각해야할 수도 있다.
어떤 변경을 통해, 어떤 결과를 얻고자 하는지를 담고 있어야 한다.

-가설 검증
어떻게 검증할 것인지 검증 방법을 선정
가설을 검증할 수 있는 올바른 모니터링 자료 설정

좋은 가설의 요건
목적 지향적
특정 목표를 달성하기 위한 것
목표는 유저 경험을 개선하는 것, 유저가 가진 문제를 해결하는 것과 관련이 있어야한다.

구체성과 명확성
형용사나 추성적인 문구는 피해야한다.
구체적인 결과물을 예측할 수 있는 한 문장 단위로 작성하는 것이 좋다.

측정 가능성
검증이 가능해야하고 측정이 가능해야한다.
성공과 실패를 측정

성공 지표 - 가설을 검증할 수 있는 지표
가드레일 지표 - 조직 전체에서 중요하게 고려하는 지표, 혹은 해당 실험으로 부정적인 영향을 받을 수 있는 지표

원페이저(1 Pager) 작성
한 페이지 내에 중요한 정보가 담긴다
앞서 정의한 문제와 가설을 중점으로 실제 방향성과 목적을 한 눈에 파악할 수 있도록 정리하는 단계
다양한 이해관계자들과 논의가 시작
논의를 진행해가면서 수정, 보완
회사에서 중요하게 생각하는 가치에 따라 원페이저에 담기는 내용이나 명칭이 조금씩 다를 수 있음

UX 기획 구체화 : 유저 사용 맥락 반영

유저 시나리오 (User Scenario)
스토리텔링, 감성적 이해
서비스에 대한 유저 경험을 스토리텔링으로 통해 설명하는 방법
디자인 초기 단계에서 사용
유저 중심의 솔루션을 찾을 때 활용
페르소나를 결합하여 유저의 동기와 목표를 감성적으로 이해

유저 시나리오 구성 요소
유저 : 유저 페르소나
목표 : 무엇을 달성하려고 하나요?
동기 : 왜 달성하려고 하나요?
외부 요소 : 어떤 것에 영향을 받나요?

고객 여정 지도 (Customer Journey Map)
여정단계, 시각화
유저가 서비스를 이용하는 흐름을 토대로 시각화해서 분석하는 방법
타임라인에 따른 유저 여정을 시각적으로 표현해 특점시점에서 경험을 파악하고 개선점을 찾을 때 활용
전체 유저 경험을 시각화해서 한눈에 파악할 수 있음

Zone A : 관점
1. 유저 페르소나 : 여정을 체험하는 유저
2. 유저 시나리오 : 여정 지도가 다루는 상황 묘사, 유저의 목표와 기대치와 연결

Zone B : 경험
3. 여정 단계 : 타임라인 기반으로 분류
4. 행동 : 유저가 특정 단계에서 취하는 행동
5. 생각 : 유저의 생각, 질문, 동기, 정보에 대한 니즈
6. 감정 : 단계에 걸쳐 단일 선으로 표현

Zone C : 인사이트
7. 기회 : 유저의 경험을 어떻게 최적화할 수 있는지에 대한 인사이트
8. 담당 팀이나 부서 : 해당 인사이트를 적용해볼 수 있는 협업자 코멘트 (선택사항)

시각화하는 방법
목적 설정
어떤 유저의 여정을 시각화할 것인지 명확한 목적을 설정

유저 페르소나 정의
어떤 유저를 대상으로 할 것인지 결정해요.
유저 페르소나별로 각각의 유저 저니맵이 나올 수 있어요.
유저가 여정을 통해 이루고자 하는 목표와 가지고 있는 기대를 작성해요.

여정 단계 분류
유저가 시간의 흐름에 따라 언제 어떤 행동을 하는지 분류해요.

터치 포인트 파악
유저가 제품 또는 서비스와 상호작용 하는 지점, 즉 터치 포인트를 파악해요.
유저가 터치 포인트에서 어떤 페인 포인트를 가지고 있고, 어떤 감정을 느끼고, 어떤 생각을 하는지 작성해요.

기회 파악
유저의 타임라인별에서 문제를 파악하고, 개선점을 찾아요.

유저 스토리 (User Story)
개발 구현 가능 단위, 합의 도출, 걸킨 문법, 테스트 케이스
특정 기능을 실제 개발 구현 가능한 작은 단위로 기술하는 방법
주로 에자일방법론에서 사용됨
엔지니어들이 개발 작업 시 기능을 이해하고 구현하는 데 유용하게 활용

유저 스토리의 구성요소
As a {user} : 유저

I want {goal} : 유저가 원하는 기능 또는 행동

So that {benefit} : 이를 통해 유저가 얻을 수 있는 이득

걸킨 문법
유저의 행동에 중점에 맞춰서 개발하는 BDD라고 해서 행동 주도 개발 환경에서 널리 활용하는 특수한 문법
테스트 케이스를 구체적으로 정의하기 위한 용도로 활용

걸킨 문법을 활용한 유저 스토리 구체화 요소
Given {주어진 상황} : 유저에게 주어진 상황

When {조건 및 행동} : 유저의 특정 액션 또는 이벤트

Then {결과} : 특정 결과나 상태

UX 기획 구체화 : 논리적인 흐름 설계

유저 플로우 (User Flow)
화면간의 이동
유저의 행동이나 화면간의 이동에 초점을 맞춰 시각화 하는 단계
다양한 경우의 수를 고려해볼 수 있다.
해피 패스(유저가 제품이나 서비스에서 원하는 목적지까지 아무런 문제를 겪지 않고 도달했을 때의 경로)에 매몰되지 않고 다양한 경로를 고려해볼 수 있음

원형 : 시작/끝
프로세스의 시작이나 끝을 표현하기 위해 사용해요.

사각형 : 동작/프로세스
유저의 입력이나 액션을 표현하기 위해 사용해요.

마름모 : 조건
특정한 조건이나 결정 지점을 표현하기 위해 사용하며,
여기서 유저의 행동이나 시스템의 상태에 따라 플로우가 여러 가지로 나뉠 수 있어요.

화살표 : 플로우의 방향
한 상태나 단계에서 다음 상태나 단계로의 흐름을 표현하기 위해 사용해요.

  • 화면 : 유저와 시스템의 상호작용이 발생하는 공간
  • 유저 액션 : 유저가 화면에서 수행하는 행동 또는 입력
  • 시스템 액션 : 유저의 행동에 의한 응답으로 시스템이 수행하는 동작
  • 모달 : 특정 상황이나 유저의 행동에 대한 부가 정보나 선택지 제공

와이어프레임 (Wireframe)
로우 피델리티, 아이데이션
작업자들이 부담 없이 아이디어에 자유롭게 참여가능
신속하게 결과물 생성해서 작업자 간 커뮤니케이션
변경되는 요구사항에 빠르게 검토하고 수정하기 용이
최소한만 사용하여 레이아웃과 플로우에 집중

정보 구조도 (Information Architecture)
그룹핑, 라벨링
유저가 제품 내에서 길을 잃지 않고 원하는 정보가 있으면 쉽게 찾고 하려던 거를 빠르게 완료할 수 있도록 돕는 과정
서비스를 구성하는 여러가지 요소들의 구조를 도식화 하는 것을 의미
정보 구조가 효과적으로 설계될 경우 유저의 접근성이 향상되지만, 부적절하게 설계될 경우 유저의 이탈과 오류를 발생
상위와 하위 개념을 효과적으로 그룹핑하고 올바른 라벨링을 하는 것이 중요

정보 구조도의 기반이 되는 구성 요소
Organization : 조직 및 구성 시스템
정보를 체계적으로 정리하고 구성하기
웹사이트의 메뉴 계층 구조, 콘텐츠 그룹화, 상위 및 하위 카테고리화

Labeling : 라벨링 시스템
정보를 명확하고 이해하기 쉽게 표현하기
메뉴 항목의 명칭, 버튼 레이블, 카테고리명

Navigation : 내비게이션 시스템
유저가 정보를 찾고 이동함
웹사이트의 메뉴 바, 내비게이션 바

Searching : 검색 시스템
유저가 원하는 정보를 검색하여 찾기
웹사이트의 검색 기능, 검색 결과 페이지, 필터 및 정렬 옵션

UX 기획 문서화 : 화면 설계서 및 QA 문서

화면 설계서
포르젝트의 복잡도가 높거나 이해관게자가 많을 경우 사용
원활한 히스토리 파악 및 유지 보수를 위해 작성하기도 함
와이어프레임과 기능 상세 정의를 합친 문서
면에 존재하는 각 요소를 분리하여 설명
변경된 내용은 작성일과 함께 기록하여 버전을 관리

QA 문서
QA(Quality Assuarance)는 기능 배포 전에 기능을 테스트하는 과정
테크니컬 QA - 의도한대로 기능이 잘 동작하는지 초점을 맞춤, 테스트 케이스를 작성하고, 요구 사항을 충족하는지 확인

디자인 QA - 의도대로 디자인이 잘 구현되었는지에 초점을 맞춤, AS-IS(구현된 화면)와 TO-BE(의도한 화면)를 명확하게 전달하는 것이 중요

profile
smooth talker -> sumith talker

0개의 댓글