User Scenario부터 User Flow까지

안녕하세요. 그린입니다🍏

이번 포스팅에서는 기술 학습이 아닌 조금 다른 부분에서 개념 정리를 해볼까해요🙌

바로 User Scenario부터 User Flow까지 초기 앱 설계 및 기획에 있어 필요한 과정들을 정리해보려해요ㅎㅎ

 

개발자여도 유저 입장에서 바라보는것과 의견을 낼 수 있는것은 정말 중요하다고 생각합니다.

이에 어떤 흐름으로 유저 입장에서 생각해볼 수 있으며 어떤 단계에서 유저에 필요한 사항들을 정리할 수 있는가에 대해 총 6가지로 구분 할  수 있습니다.

 

그 여섯가지 이제부터 하나씩 개념 정리해보시죠🕺🏻

 

User Scenario

• 목적
  • 서비스의 특성을 이해하기 위함
  • 해당 서비스에서 기대할 점
  • 해당 서비스를 어떻게 사용할 것인지에 대해
  • 유저의 Motivation, Needs, Barriers를 이해할 수 있음
    
    
• 포함해야할 형식 및 내용
  • Who: 페르소나의 디테일
  • What: 유저가 달성하고자 하는 목표
  • When: 유저가 언제 서비스를 이용할지
  • Where: 유저가 어디서 서비스를 이용할지
  • Why: 유저가 왜 이 서비스를 이용할지
    
    
• 예시

• 유의 사항
  • 개발/기획/디자인과 같이 기술적 배경이 없는 사람도 쉽게 이해할 수 있을 정도로 평이한 문장으로 작성해야함
    
    

즉 유저 시나리오는 서비스 컨셉을 구상할 때 필요한 과정입니다.

 

Use Case

• 정의
  • 유스케이스는 시나리오의 집합으로 일차 액터는 목표를 가진다.
    시스템은 일차 액터가 목표를 달성하도록 도와야한다.
    어떤 시나리오는 목표 달성을 보여주고, 또 어떤 시나리오는 목표를 달성하지 못하고 끝난다.
    각 시나리오는 행동과 상호작용이 어떻게 전개되는지를 보여주는 일련의 단계를 포함한다.
    유스케이스는 모든 시나리오를 함께 모아서 목표가 달성되거나 실패하는 모든 경우를 보여준다.
    
    
• 내용
  • 일차 액터
  • 범위
    
    
• 수준
  • 1) 요약 수준 목표
  • 2) 사용자 목표
  • 3) 하위기능 수준 목표 가운데 하나
    
    
• 선조건
  • 유스케이스가 시작되기 전에 시스템이 True라고 보증할 무언가를 선언
    예시) 사용자는 이미 로그인 하였으며 인증을 받음
    
    
• 최소 보증
  • 일차 액터가 목표 달성에 실패했을 때를 대비해 시스템이 이해 관계자와 맺는 최소한의 약속
    예시) 시스템은 작업이 진행된 곳까지 로그를 남겼다.
    
    
• 성공 보증
  • 유스케이스가 성공적으로 종료한 뒤 이해 관계자의 어떤 이해 관계가 충족되었는지 서술
    예시) 시스템은 고객의 주문 처리를 시작하고 지불 정보를 받으며 주문 요청도 기록
    
    
• 트리거
  • 유스케이스를 시작하도록 하는 사건
    예시) 고객이 카드를 삽입한다.
    
    
• 주요 성공 시나리오
  • 트리거부터 완료까지 일차 액터가 목표를 달성하고 모든 이해 관계자가 만족하게 되는 과정을 일련의 행동 단계로 서술한다.
    어떤 단계든 다음 내용을 서술한다.
  • 두 액터 간의 상호작용
    예시) 고객이 주소를 입력
  • 이해 관계자의 이해 관계를 보호하기 위한 검증 단계 
    예시) 시스템이 비밀번호를 검증
  • 이해 관계자의 이해 관계를 충족시키기 위한 내부 변경
    예시) 시스템이 잔고에서 일정액을 차감
    
    
• 확장
  • 주요 성공 시나리오가 아닌 다른 성공 시나리오와 모든 실패 시나리오
    
    
• 예시

• 유의 사항
  • 유스케이스는 그 자체로 요구사항이지만 요구사항의 전부는 아니다.
    
    

즉, 유스 케이스는 상대적으로 복잡한 서비스를 설계 시, 사용자 요구샇아과 시스템 요규사항을 빠짐 없이 파악하고 구현하기 위해 작성

 

Usage Narrative

• 활용
  • 유스케이스를 작성하기 전 또는 읽기 전 사용할 시스템을 마음에 그려보기 위한 준비운동으로 작성
  • 사용자, 요구사항 작성자 등이 시스템의 범위를 파악하고 시스템의 비전을 공유하기 위해 작성할 수 있음
    
    
• 정의
  • 유스케이스가 실제 동작하는 즉, 액터가 시스템을 사용하는 상황의 예시
  • Usage Narrative는 요구사항이 아니고 요구사항을 더 자세히 혹은 일반적으로 설명하기 위한 준비작업
    
    
• 예시
  • 출근길에 두 딸을 어린이집에 데려다 주려던 메리는 현금인출기(ATM)가 있는 곳으로 차를 몰고 가서, 카드판독기에 카드를 대고 비밀번호를 누른 뒤, ‘빠른 현금’ 메뉴를 선택하고 35달러를 입력한다. 현금인출기는 35달러가 차감된 계좌의 잔고를 보여주는 영수증과 함께 20달러짜리 1장과 5달러짜리 3장을 내어준다. ‘빠른 현금’ 거래 후 현금인출기 화면이 안내화면으로 재설정되므로, 메리는 차를 몰고 나가면서 다음 운전자가 그녀의 계좌에 접속할까봐 걱정하지 않아도 된다. 메리가 ‘빠른 현금’ 서비스를 선호하는 이유는, 서비스를 지연시키는 많은 질문을 피할 수 있기 때문이다. 그녀가 특별히 이 현금인출기로 온 까닭은, 이 기계가 어린이 집에 지불해야 할 5달러짜리 지폐를 발행할 뿐만 아니라 차에서 내리지 않고 이용할 수 있기 때문이다.
    출처 -> (<Writing Effectve Use Cases>, p.24)
    
    
• 유의 사항
  • 읽는이가 한눈에 내용을 파악할 수 있도록 간결하게 작성
  • 서술된 액터의 동기 혹은 감성적인 내용도 중요
    
    

즉 Usage Narrative는 사용자가 서비스를 구체적으로 어떻게 사용할지를 이야기 형식으로 서술함으로 서비스가 어떤 요건을 갖춰야 할지 대략적으로 파악할 때 필요

 

User Story

• 활용
  • Agile Framework에서 User Story < Epic < Initiative의 포함 구조
  • 백로그를 User Story 형태로 작성
  • 1개의 User Story = 1개의 Sprint
  • 각 Sprint마다 각 User Story를 실제 소프트웨어 기능으로 어떻게 구현할지 고민해야 한다.
    즉, 한 문장으로 정리된 User Story가 개발 요구사항 혹은 스펙 단위가 된다.
    
    
• 정의
  • end-user 관점에서 작성한 소프트웨어 기능에 대한 비공식적인 설명
  • 사용자가 서비스에서 목적을 달성하기 위해 해야하는 액션을 한 문장으로 정리
    
    
• 목적
  • 소프트웨어가 고객에게 어떤 방식으로 가치를 제공하는지를 명확하게 설명하기 위해 작성
    
    
• 유의 사항
  • User Story는 모든 직군의 팀원이 이해할 수 있는 평이한 언어로 작성
  • User Story를 통해 어떤것을 또 왜 만드는지 이해할 수 있어야 한다.
    
    
• 작성 형식
  • 1) As a ... (user, 페르소나, who)
  • 2) I want ... (action, 필요, what) -> 기능 및 UI가 아니라 사용자가 정말 원하는것을 기술
  • 3) So that ... (purpose, 목적, why)
    
    
• 예시
  • 마케팅 매니저로서, 나는 우리 제품의 최고의 커뮤니케이션 채널이 무엇인지 알 수 있도록, 우리 웹사이트에서 사용자 구매까지 이르게 하는 트래픽 매체와 출처를 알고 싶습니다.
    
    
• 유의 사항
  • 규모가 큰 서비스 개발에는 부적합할 수 있음
  • User Story는 정확한 스펙을 작성하는 것이 아니기에 기획자와 개발자가 협의할 사항이 많음
    
    

즉, User Story는 Agile 방식으로 소프트웨어 프로덕트 개발을 반복할 때 시스템 요구사항을 작성하는 방식으로 서비스의 상세 기능을 본격적으로 구현하려고 할때 필요

 

Wireframe

• 목적
  • 세부 디자인 전 디자인 전략을 수립하고 검토하기 위해 작성
    
    
• 구성 요소
  • 화면 구조
  • 콘텐츠
  • 기능 (인터페이스 작동 방식)
    
    
• 특징
  • Wireframe으로 알 수 있는 시각적 특징은 제한적
  • 화면 간 이동이 아닌 개별 화면의 구조 및 동작을 나타냄
  • 선, block, 음영 등으로 정보 아키텍처, 콘텐츠 및 레이아웃 등 고려사항을 표현
    
    
• 예시

 

User Flow

• 정의
  • 사용자가 목표를 달성하기 위해서 취하는 일련의 행동들을 사용자가 처하는 실제 맥락에서 보여주는 도표
  • 상세 화면 이미지 없이 도형만으로 사용자 행동의 흐름을 보여주는 도표는 편의상 다이어그램 또는 플로우차트로 부름
    
    
• 작성 프로세스
  • 1) User Goal: 사용자의 목표를 한 문장으로 정리
  • 2) Task Flow: User Goal에 이르기까지의 단계 작성 (Case 분기 없이 선형으로 진행)
  • 3) Wireflow: Wireframe에 화살표로 주요 화면 간 Flow 표현
  • 4) Userflow: 실제 화면 이미지에 여러 분기 Case까지 포함해 Flow 표현
    
    
• 예시

 

마무리

프로덕트 기획부터 개발까지 이뤄지기에 수 많은 작업 중 가장 선행되는 작업으로 우리가 지금 어떤 프로덕트를 왜 개발해야하는지를 넘어 정말 유저의 입장을 충분히 고려해보면서 더 나은 사용성의 프로덕트 개발을 지향할 수 있는 기반 지식이 될 수 있다고 생각합니다.

 

[참고 자료]

https://product.kyobobook.co.kr/detail/S000001469859

WRITING EFFECTIVE USE CASES(앨리스터 코오번의 유스케이스) | 앨리스터 코오번 - 교보문고

https://brunch.co.kr/@b30afb04c9f54dc/20

유저 시나리오와 유저 스토리

https://www.atlassian.com/ko/agile/project-management/user-stories

사용자 스토리 | 예제 및 템플릿 | Atlassian

https://yozm.wishket.com/magazine/detail/754/

유저 스토리는 무엇인가? | 요즘IT

https://uxdesign.cc/when-to-use-user-flows-guide-8b26ca9aa36a

User flow is the new wireframe

https://brunch.co.kr/@b30afb04c9f54dc/25

유저플로우(User Flow) 그리는 방법