ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [제로베이스] UIUX디자인스쿨 1주차_03
    UXUI/학습일지 2023. 6. 7. 23:47

    UX이론 기초파트 Chapter 3. 모델링

    3-1 사용자 여정 지도(User Journey Map)

    • User Journey Map

    사용자가 과업을 수행하는 동안하는 행동, 느끼는 감정 그리고, 상호작용하는 접점을 시간순서로 정의한 것, 프로젝트의 성격이나 목적에 따라 자유롭게 만든다. 
     
    이를 통해 알 수 있는 것 사용동기, 시작점, 행동, 감정, 도구, 시간 
     
    장점
    - 팀원 및 이해관계자들(Stakeholders)의 공통된 이해를 돕는다.
    - 디자인 의사결정의 주요 기준이 된다.
    - 기회 요인(Opportunity)과 문제점(Problem)을 도찰할 수 있고 특히 선후 관계를 파악할 수 있다.
    - 사용자가 우리 제품을 어떻게 수용하고 있는지 쉽게 파악 할 수 있다. 
    - 타 부서와의 협업에 매우 유용한 자료가 된다. 
     
    중요성 사용자를 공감Empathy하기 위한 중요한 도구로써 깊은 공감을 통해 디자인 의사결정과정에서 보다 사용자 중심의 방향으로 나가게 해준다. 아래와 같은 실수를 막아줄 수 있다. 
    - 우리 사용자를 잘 이해하고 있다는 너무 높은 자신감
    - 나를 기준으로 우리 사용자를 해석하는 확증편향
    - 사용자 조사 결과를 객관적으로 해석하지 못함 
     
    User Journey Map 의 Basic Structure
    1. ZONE A(The Lens)
    2. ZONE B(The Experience)
    3. ZONE C(The Insights)
    >그러나 하나의 정해진 폼은 없다. 
     
    User Journey Map 만들기
    Step 1 범위 정하기
    Step 2 퍼소나 Persona 정하기 
    Step 3 기준 항목 정의 
    Step 4 프레임에 정보 채워넣기 
    Step 5 리뷰하기 
     
    예시
    Lightweight version 
    Full-covered version  

    3-2 사용자 여정 지도의 활용 

    • 사용자 여정 지도의 활용 시각적으로 우리가 유저를 어떻게 이해하고 있는지 알 수 있다. 

    > 팀원 모두가 일치된 사용자 모델을 이해
    > 문제점을 다각도로 분석하여 문제의 원인과 해결방안 모색에 도움을 줌 

     
    문제점의 구체화
    사용자 조사 결과와 여정지도를 비교하여 기존에 파악된 문제점의 상세한 원인과 그 해결방안을 모색하는 자료로 활용될 수 있다.
    > User Action과 Pain points를 파악하여 UI를 개선 
     
    물리적 시간의 표현
    사용자 여정 지도 상에서 연결되는 스텝으로 표현되어 있으나, 실제로는 각 스텝이 다른 시간을 가질 수 있다. 
    긴 스텝은 정보량이 많거나, 테스크가 많아서일 수 있으므로 개선을 위한 기회요인이 될 수 있다.
    > 테스크를 처리하다가 이탈하는 경우도 파악할 수 있다. 
     
    전략적 사고

    기존의 프로세스를 단축하거나 비즈니스적으로 효과적인 방안을 모색한다. > 서비스 진입 초반에 요구되는 많은 사용자 액션이 진입장벽으로 작용함을 발견하면, 정보의 우선순위를 기준으로 분산하여 초기 사용자의 부담을 경감시키는 방법을 선택한다. > 예시) 회원가입율이 낮은 이유가 불필요하게 많은 입력이 요구되는 것이 원인임을 파악했다면, 추가 정보는 이후 이벤트 발생 시 입력하도록 플로우 개선하여 더 많은 회원가입을 유도한다. 

     
    사용자별 특이점

    동일한 테스크에 대해 여러 맵을 겹쳐서 특정 경우에 나타나는 행태(문제)와 공통적으로 발생되는 요인을 찾는다. 이때 문제의 중요도도 함께 정이될 수 있다. >'보통의 유저는 이렇게 사용해'라는 것을 검증해볼 수 있다. 예외 케이스의 경우가 갖고 있는 포텐셜을 발견할 수 있다. 

     
    리서치 주안점 도출

    추가 리서치가 필요한 부분을 발견하고 추후 리서치 실행에 필요한 POV(Point Of View)도 함께 정의한다. > 기존 방식에 더해 추가안을 도출한다. > How Might We 과정을 통해 새로운 서비스를 고안해낼 수 있고, 이에 따른 예상 효과를 생각해볼 수 있다. 

     
    Make a consensus!
    오랜 회의 끝에 모두가 동의한 것 같은 생각도 각자의 자리로 돌아갔을 때 떠오르는 컨셉은 제각각일 수 있기 때문에 User Journey Map과 같은 시각적 자료가 매우 중요함
     
    아이디어 워크숍에서 사용
    User Journey Map을 통해 다양한 사람들이 참여하게 되는 워크숍에서 빠른 시간 내에 프로젝트의 목적과 범위를 이해시키는데 도움

     

    3-3 테스크 플로우(Task Flow)

    과업 + 흐름 = 사용자가 제품 또는 서비스를 사용하여 과업을 달성할 때까지의 일련의 과정

    출처_제로베이스 강의

    시작과 끝이 명확해야 한다. 
    하나의 테스크가 사용자 입장에서는 하나가 아닐 수 있다. 커피를 사는 행위는 하나의 테스크로 보일 수 있지만 세부적으로 나눌 수 있듯이. 시작점과 종료점을 정의해서 표시해야 한다. 
     
    User Journey Map과의 차이점
    비슷한 점 A가 B라는 목적을 이루고 싶을 때 시간 순서로 기술하는 것
    차이점 User Journey Map이 더 큰 개념이다. User Journey Map 상에서의 테스크 하나 수행을 위해서 어떤 과정을 거치는지를 풀어서 표현한 게 Task Flow
     
    Task Flow의 구조
    1. 시작 : 동기 또는 목적
    2. 사용자 행동
    3. 분기 : 의사결정
    4. 선택 가능한 옵션
    5. 종료
    + 프로젝트의 성격과 문서를 만드는 목적에 따라 가변적으로 만들 수 있다. 
    + 각 화면별로 시스템이 지원해야 하는 기능을 기술 > 개발자와 디자이너가 필요한 업무를 정한다. 
    + Frinding a follow up question > 사용자가 왜 상위 뎁스가 아닌 하위 뎁스에서 기능을 설정하는 일이 생길까에 대한 고찰을 할 수 있다. (예 : 아이콘의 의미가 사용자의 멘탈모델과 달라서 인지가 어렵나?) 
     
    즉, 테스크 플로우는 사용자가 과업을 완료하기 위한 행동의 연속을 표로 기술한 것
    > 사용자가 해야하는 과업을 정의
    퍼소나에 따라 동일한 테스크가 여러개로 정의 될 수 있음
    시나리오를 기반으로 가능한 모든 파생 루트를 표시함
    대략적인 콘텐츠/기능 설명을 포함할 수 있음(주요기능, 필수 입력 항목 등)
    UJM에서 하위 분류 된 플로우
     
     Task Flow를 정의하면 좋은점
    > 타사 UI를 분석할 때
    > UI를 가장 빨리 저렴하게 현실적으로 바라보는 방법
    > 시스템 개발 관점과 사용자 관점을 모두 포괄할 수 있다. 
    > 발생할 수 있는 문제점을 미리 발견하고 대응할 수 있다. 
    > 각 단계별로 어떤 정보/기능이 필요한지 확인할 수 있다.
    > 발생 가능한 모든 경우의 수를 확인할 수 있다. 
     
    Task Flow의 3요소
    1. Persona : 누구 중심의 테스크인가?
    2. Goal : 이 테스크의 목표는 무엇인가? 
    3. Steps : 어떤 과정을 통해 사용자는 과업을 수행하는가? 
     
    Task Fow를 그리기 위한 플로우 차트 컴포넌트
    1. 원 : Start/End
    2. 사각형 : Action
    3. 다이아몬드 : Decision
    + Pain point/Obstacle을 표시할 수 있는 컴포넌트
    + Idea/Opportunity를 표시할 수 있는 컴포넌트 
     

    3-4 테스크 플로우 만들기 

    • 테스크 플로우 준비

    1. 목적 Goal
    신규 개발을 위해
    기존 UI 분석을 위해 : 우리의 UI, 타사의 UI
    2. 시나리오 정의 Scope and Use-case : 사람마다 다른 해석의 여지와 오해를 줄이기 위함
    누가 사용하는가
    어떤 목적으로 사용하는가
    언제, 어디서, 무엇으로 사용하는가
    3. 디테일 수준 Level of Detail
    작성 목적에 따라 디테일 수준을 정한다.
    4. 작성 방법 Tool
    작성과 수정/공유가 용이한 방법을 고려
    * 처음부터 디지털화해서 작업하는 것을 추천
     
    Step 1. 테스크의 목표 정하기 : 테스크의 시작의 기준과 끝은 경우에 따라 늘 달라질 수 있기 때문에 이번 플로우에서 정의할 범위의 시작과 끝의 기준(조건)을 정한다. 
    Step 2.
    > 사용자의 모든 행동 기술하기 : 변수가 없다고 가정하고 최단시간에 과업을 끝내는 프로세스로 가정한다. 정보를 탐색하고, 버튼을 누르는 등 사업자가 과업을 완료하기 위해 하는 모든 행동을 작성한다.
    > 작성 할 '행동' 범위 : 디자인 목적에 따라 테스크 플로우에 사용자의 '행동'의 범위를 정한다.
    > 시스템 외부적으로 이루어지는 인터랙션은 경우에 따라 '필수'가 될 수도 '옵션'이 될 수도 있다. 필수와 옵션을 구분해서 표시하고, 불필요한 것들은 나중에 수정해도 된다. 
    Step 3. 분기 Decision point
    사용자의 의도 또는 시스템의 목적에 따라 테스크 플로우가 나누어지는 시점을 추가한다. 이 과정을 통해 플로우를 더욱 현실적으로 만들 수 있다. 사용자의 성향에 따라 분기에서의 선택점이 갈린다. 
    Step4. 리마커블 포인트 추가하기 
    Pain point 또는 Opportunity 좋거나/나쁜 발견점을 추가. 여러사람이 함께 보는 문서이기 때문에 각자 추가하면서 풍성해진다. 
    Step5. 확장하기 : 브랜치 플로우 정의
    필연적이 아닐지라도, 발생할 가능성이 있거나, 단순히 다양한 가능성을 검토해보기 위한 목적으로 '만약'이라는 가정하에 다양한 브랜치 플로우를 작성(일종의 아이디에이션, 생각의 확장) , 분기점에서 사용자가 선택 할 수 있는 다양한 가능성에 대해 추가해본다. 
     
    User Flow와의 차이점은? 
    유저 플로우는 테스크 플로우와 유사한 형태를 갖지만, 테스크의 시작점이 반드시 시스템이 아닐 수도 있다는 점에서 가장 차이가 크다. 가령 '쇼핑앱'에서 '신발 구입'에 대한 테스크 플로우는 애플리케이션의 랜딩페이지에서 시작하겠으나, 유저플로우의 경우 '포털서비스에서 검색하기' 또는 '인스타그램에서 태그 검색하기'등 시스템 외부가 될 수 있다.
    > 확산적사고를 위해서는 도움이 되지만, 주제를 벗어나지 않는 적절한 수준을 정하지 않으면 자료가 방대해져서 보기 어렵다. 

    3-5 스토리맵 User Story Map

    • 스토리맵이란?

    에자일 개발*방법론과 비슷하다
    *큰 덩어리를 잘게 모듈 레벨로 나눠서 개발하면 빠르게 개발할 수 있고 더 나은 퍼포먼스가 가능하다는 개념

    큰 유저의 요구사용을 작은 조각의 유저 스토리를 모음
    사용자의 작은 이야기를 바탕으로 점점 위로 올라가면서 동기를 이해하는 방식

    • 스토리맵 만들기

    Backbone만들기
    사용자에 관한 우리가 아는 모든 것(factor), 상상을 최대한 배제한다.

    경우에 따라 리서치 후에 하지만 모든 상황이 이상적으로 흘러가진 않기 때문에 사용자 조사 없이 우리가 예상하는대로 만들고 나서 검증하는 방식 그걸 바탕으로 업데이트 하는 방식이 많이 쓰인다.

    가설을 세우고 Task Flow나 User Journey Map을 만들고 컨셉 발표 후에 오히려 사람들의 호응을 얻을 수 있는 경우에 그때 가서 리서치를 하는 경우도 있다. 리서치 자료 없이 인터넷 자료로 시작할 수 있다.

    자기 생각을 검열하지 않고, 사용자를 예단하지 않는 자세 필요

    1. 이야기 만들기
    2. 관점 나누기
    나만의 해석이 깊게 개입할 수 있기 때문네 혼자 작업히기에 적절하지 않다.
    가능하면 두 명 이상이 다른 퍼소나, 다른 관점을 갖고 만들고 비교하는 것이 중요

    3. 더 풍성하게
    여러 사람이 작업하다보면 겹치는 내용이 있을 수 있고, 다른 부분들은 다시 가지치면서 여러이야기로 세분화하는 가정을 거친다

    4. 액티비티를 기준으로 그룹핑
    Activity(epic)을 정한다 > 작은 이야기들을 모아서 큰 이야기로 그룹핑하고 그 그룹에 이름을 지어준다. 상위레벨의 스텝을 볼 수 있다. 어피니티 다이어그램과 유사하다(비슷한 속성의 것들을 그룹핑하고 이름을 짓는 것)

    5. 우선순위 슬라이스
    중요도가 높은 것과 구분하여 상대적으로 낮은 것 혹은 아주 드문 이야기들은 아래에 따로 배치한다. (페이팔 이용, 이중보안인증 등)

    6. 더 자세히
    빼먹은 건 없는지 너무 큰 이야기가 하나로 묶여 있는 것은 아닌지, 겹치는 것들이 너무 분산되어 있는 건 아닌지 내용을 검증하고 보완한다.

    정리 후

    Adding User type 유저타입별로 스토리 진행 표시
    For Project management
    Backbone > 하나 하나의 기능들 혹은 이야기가 된다.

    UJM과의 차이점
    UJM은 사용자의 생각/감정/행동이 어쨌든 제품 내에 존재한다. 하지만 유저 스토리맵의 시작과 끝은 전적으로 사용자에 의해 결정된다.

    스토리의 시작점에 따라 따라오는 이야기들이 달라진다. 스토리의 종결도 정의할 수 있어야 한다.