디자이너 맥신, 성장일기

사용성 테스트 실행 과정 :
사용성 테스트는 총 1시간 내외로 구성하는 것이 적절

사용성 테스트 안내

• 사용성 테스트의 목적 (왜 하는  것인지), 진행 방법 (어떻게 진행될 것인지), 주의 사항에 대해 안내
• 영상/사진 촬영 동의 여부를 체크하고, 기밀 프로젝트인 경우 보안 서약서를 작성

테스크 안내

• 참가자가 수행해야 할 테스크를 알려준다.

 테스크 수행 & Think Aloud

• 참가자는 안내받은 테스크를 수행한다.
• 이 때, 진행자는 참가자에게 테스크를 수행할 때 자신의 생각과 감정을 말로 표현해줄 것을 요청한다.
  
  
  

THINK ALOUD
★★★★★
별 다섯개! 중요!

뜻 : 생각을 시끄럽게 한다.
머릿속에 떠오르는 생각이라던지 느낌이라던지, 감정, 그걸 다 말로써 표현을 하는 방법이라고 생각하면 된다.

사후 인터뷰

• 사후 인터뷰를 진행하면서 이용 만족도를 측정한다.
• 사후 인터뷰를 통해 참가자가 테스크 수행 전에 기대했던 것이 수행 후와 비교했을 때 어느 정도 차이가 있는지, 불편하게 하는 오류 요인은 무엇이 있는지 등을 파악한다.
• 사후 인터뷰는 각 테스크가 종료된 직후에 진행하는 것이 바람직하다.

마무리

• 참가자에게 테스트 종료를 알리고, 참여 보상을 증정한다.

관찰자로 참여하는 인원의 경우에도 테스트에 들어가기 전에 사용성 테스트 시나리오를 숙지하고 있는 것이 바람직하다.

Think Aloud 이해하기

테스크를 수행하면서 머릿속에서 어떤 생각이 드는 지 말로 표현하도록 하는 방법

Think Aloud를 통해 얻을 수 있는 정보 예시는 아래와 같다.

• 유저가 메뉴나 버튼, 아이콘을 클릭한 의도 (어떤 의도를 가지고 클릭했는지, 어떤 과정에 의해서 인지를 하게 되는지)
• 어떤 행동을 했을 때 기대하는 결과값
• 테스크 수행 중 유저가 겪는 어려움 (어디서 어려움을 겪었는지, 실수를 했다면 왜 했는지를 이해해 볼 수 있다.)
• 테스크 수행 중 유저가 실수를 한 이유

유저의 실제 의도와 인지 과정을 이해하고 (어떻게 하면 이걸 조금 더 잘할 수 있게 해줄지) 설계에 반영할 수 있다는 장점이 있다.

편안한 분위기에서 자연스럽게 생각을 말할 수 있는 분위기를 조성하는 것이 중요하다.

Think Aloud를 진행하는 방법에는 크게 두 가지가 있다.

1️⃣ Think Aloud
테스크 수행과 동시에 진행한다.

장점 : 정보를 찾고자 할 때 참가자의 의도를 명확히 파악할 수 있다.

단점 : 말과 행동을 동시에 하려다보니 수행 집중력이 떨어질 수 있다. 진행자가 능숙하지 않다면 실수로 참가자에게 다음 행동을 암시하는 힌트를 줄 수 있다.


2️⃣ Retrospective Think Aloud
테스크 종료 후 기억을 되살리며 진행한다.

장점 : 테스크 수행 중에는 테스크에만 집중할 수 있다.

단점 : 이전에 한 행위를 기억 못 할 수 있어요. 사소한 오류에 대해 적극적으로 표현하지 않으려는 경향이 있다.

✅ 보통은 테스크 수행과 Think Aloud를 동시에 진행하는 첫 번째 방식을 채택한다.

🚨 Think Aloud 유의사항

테스트 중에는 참가자가 말을 많이 하도록 유도해야 한다.

• 중간에 참가자가 질문을 할 때 최대한 답변을 주지 않아야 한다.
• 중간에 참가자가 실수를 한다고 해서 힌트를 주거나 고치려고 하지 말아야 한다.
• “왜 그렇게 생각하세요?”, “어떻게 해야할 것 같으세요?” 등의 열린 질문으로 참가자의 생각을 알아보는 것이 바람직하다.

 사용성 테스트의 개념

사용성 테스트(Usability Test; UT)는 프로토타입이 있다면 제품 개발 단계 중 언제든 활용할 수 있다.

• 유저가 제품이나 서비스를 실제 사용할 때 의도한 시나리오에 따라 테스크를 수행하는 지, 문제점은 없는지 관찰하기 위해 진행한다.
• 유저가 제품이나 서비스를 사용할 때 어떤 생각을 가지고 어떤 혼란을 겪는지 파악할 수 있다.
• 제품 개선 전에 진행하면 유저가 불편하게 생각하는 부분을 파악할 수 있고, 제품 개선 후에 진행하면 유저가 실제 어떻게 사용하는지를 파악할 수 있어요.

✅ 실제로 유저가 화면을 조작하는 모습을 관찰할 수 있다는 것이 최대 장점

 사용성 테스트의 중요성

사용자 테스트는 왜 해야 할까?

• 사용성 테스트를 하는 이유는 우리가 사용자가 아니기 때문. 오히려 🚨 프로젝트에 대해 너무 많이 알기 때문에 편향을 가지고 있다.
• 유저가 화면을 직접 조작하면서 마주치는 문제를 식별 가능. 이를 통해 디자인을 유저 중심적으로 개선하는 데 도움을 받을 수 있다.
• 예산이 제한적이거나 시간이 촉박한 경우에 캐주얼하게 카페에서 진행하는 사용성 테스트로도 유용한 인사이트를 얻을 수 있다.

사용성 테스트 준비

사용성 테스트를 진행하기 위해서는 진행자, 테스크, 참가자가 필요하다.

진행자 (Moderator)

• 참가자에게 사용성 테스트의 목적과 절차를 안내
• 참가자들이 편안한 분위기에서 자연스럽게 행동할 수 있는 분위기를 조성
• 참가자에게 테스크를 지시하고 테스크를 수행하는 참가자를 관찰. 동시에 참가자가 생각하고 있는 것을 말로 표현할 수 있도록 유도.

테스크 (Task)

• 참가자가 테스트 과정 중에 현실적으로 수행할 수 있는 활동으로 구성된다.
• 테스크 지시는 참가자에게 구두 또는 안내지로 전달될 수 있다.
• 참가자가 수행할 테스크를 직접 소리 내어 읽도록 안내하기도 한다. 이렇게 하면 참가자는 이해도를 높이고, 관찰자는 현재 진행 중인 테스크를 파악하는 데 도움이 된다.

참가자 (Participant)

• 참가자는 유저를 대표할 수 있어야 한다.
• 이미 출시된 제품에 대한 사용성 테스트를 진행할 때는 참가자가 해당 제품을 사용한 경험이 있거나, 유사한 경험이 있는 것이 좋다.
• 아직 출시되지 않은 제품에 대한 사용성 테스트를 진행할 때는 참가자가 유저 페르소나와 유사한 특성을 가지고 있어야 해요.
• 🚨 프로젝트 지식이 있는 내부 구성원이나 페르소나와 완전히 무관한 사람을 대상으로 테스트를 진행하면 좋은 데이터를 얻을 가능성이 낮아진다.

관찰자 (Observer)

• 사용성 테스트가 진행되는 동안 참가자의 행동과 반응을 관찰하고 기록.
• 테스트를 진행하는 방에 진행자와 함께 들어가서 기록하기도 하고, 원격으로 참가자의 화면과 참가자를 실시간으로 관찰하면서 기록하기도 한다.

사용성 테스트 공간 환경 구성

사용성 테스트를 위해 테스트가 진행되는 공간과 실시간으로 관찰할 수 있는 공간이 필요.

• 테스트 공간에서 참가자와 진행자가 테스트를 진행.
• 관찰 공간에서 관찰자들이 테스트 공간에서 일어나는 일들을 실시간으로 관찰하고 기록해요. 관찰자들은 참가자가 어떤 말을 하면서 화면을 조작하는 지 알 수 있어야 한다.
• 테스트 공간이 따로 구비되어 있는 조직의 경우 단방향 거울을 활용하기도 해요. 관찰 공간과 테스트 공간에는 단방향 거울이 있어서 관찰 공간에서는 테스트 공간을 볼 수 있지만, 테스트 공간에서는 관찰 공간을 볼 수 없다.
• 줌과 구글밋 등을 활용하여 원격에서 사용성 테스트를 진행하기도 한다. 실시간으로 참가자의 얼굴과 참가자가 조작하는 화면을 보면서 진행자가 질문을 할 수 있다.
• 별도의 관찰 공간이 없는 경우 테스트 공간에 진행자와 서기를 담당하는 관찰자 1명이 들어가기도 한다.

사용성 테스트 준비하기

사용성 테스트의 필수 인원이 정해져 있는 것은 아니지만 5명의 유저를 테스트 및 사후 인터뷰하면 85%의 사용성 문제를 발견할 수 있다.

사용성 테스트 준비 과정

사용성 테스트 준비 과정에서 파일럿 테스트를 최소 1회 시행하는 것을 추천

✅ 사용성 테스트 목적 설정 :
사용성 테스트를 통해서 확인하고 싶은 사항을 정한다.

✅ 참여자 리크루팅 & 스크리닝

• 사용성 테스트의 목적, 방식, 일정, 보상 등에 대한 정보가 포함된 내용을 작성하고 업로드하려 공지한다.
• 필요한 경우 지원자의 적합 여부를 사전 질문 등을 통해 스크리닝한다. 실제 출시가 된 서비스의 경우에는 해당 서비스를 경험이 있다던가.. 그런 식으로 스크리닝을 해볼 수 있다. 그리고 많은 사람들이 궁금해하는 부분 중 하나가 "몇 명을 하면 되나요?인데, 심층 인터뷰와 마찬가지로 5명 정도면 충분하기는 하다. 5명 테스트를 하고 사후 인터뷰를 하면 85프로 정도의 사용성 문제를 발굴할 수 있음.
  
  

✅  테스크 선정

• 실제 사용성 테스트에서 수행할 수 있는 현실적인 테스크를 선정한다. 여기에서 테스크란, 유저에게 주어지는 미션같은 것.
• 예를 들어, 커머스 서비스의 경우 아래와 같은 테스크를 선정할 수 있다.

예시 1) 이전에 구매한 상품의 리뷰를 작성해보세요.
예시 2) 장바구니에 담겨 있는 상품을 결제해보세요.

✅ 사용성 테스트 시나리오 작성

• 여러 개의 테스크들이 모여 사용성 테스트 시나리오가 구성된다.
• 사용성 테스트 시나리오에는 테스크의 수행 요청 순서, 후속 질문 리스트 등의 내용이 담긴다.
  
  
  
  

✅  파일럿 테스트 (필수 + 권장)

• 실제 테스트 환경과 동일한 환경에서 사전 테스트를 진행해보는 것을 의미한다.
• 예상치 못한 현장 변수를 미리 확인하고, 제 3자 입장에서 질문 관련 피드백을 받을 수 있다.
• 테스트 공간에서의 화면과 오디오가 관찰 공간에 실시간으로 잘 송출되는지 체크한다.
• 사용성 테스트 총 소요 시간은 적절한지 체크한다.
• 무의식적으로 전문 용어를 사용하지 않는지 피드백을 받아보도록 한다.

심층 인터뷰에서 뭔가 테크니컬하게 실시간으로 생중계가 되어야 되기도 하고, 여러가지 사전에 준비하면 좋기 때문에 해보는 것을 추천!

사용성 테스트 시나리오 예시

사용성 테스트 시나리오 : 진행자가 어떤 절차에 따라 테스트를 진행할 것인지 참조할 수 있는 가이드 문서

• 분위기를 편안하게 만들기 위해 참가자에게 아이스브레이킹 질문을 한 후 테스트를 시작하는 것을 추천.
• 테스크 수행 순서의 경우 참가자가 순서대로 진행하기 용이한 순서대로 현장 상황을 고려하여 구성하는 것을 추천.
• 참가자에게 미리 공유된 시간 내에 마무리할 수 있도록 시간을 고려하여 테스크와 질문을 구성해야 한다.

오늘 기획이론을 공부하는데 헷갈리는 부분들이 꽤 있었고, 열심히 질문하여 이해된 부분을 정리해보고자 한다. 질문하다가 인터뷰 처럼 되었는데 아주 유익한 시간이었다. 나도 진짜 제품을 내놓아 사용자한테 피드백을 받아보고 싶어 진다.

1. 성공지표와 VS 가드레일
우선 이 두 요소가 비례와 반비례 관계가 아니다, 데이터를 분석할 때 이 둘의 상관관계는 확인되어야 한다. 

2. 유저 시나리오 VS 유저 스토리 차이

답변 주신 분들 마다 개념 두 개의 명칭이 서로 엇갈리는 것 같다. 일단 개념 챙기고, 다니는 회사가 사용하는 명칭을 쓰면 될 것 같다.

📌 유저 시나리오 User Scenario #스토리텔링 #감성적 이해 #경험적인 것 

- 특정 상황보다 백그라운드, 유저의 이야기를 나열하는 식, 전반적인 이야기 (유저 스토리는 기능적인 거)

- 살인자라면, 그 준비를 하는 과정 그 씬이 될 거고, 살인현장 장면일 수 있고.. 씬 바탕, 장치도 들어가고, 장소도 들어가고, 실내야 실외야? 혼자 집에서 쓰는 앱이야? 같이 쓰는 앱이야? 커뮤니티 바탕이야? 여러 가지 기능 구체화 할 때 많이 쓴다.

- 전체 플로우(전반적 서비스 흐름)를 유저테스트 할 때 유저 시나리오를 쓴다. 유저 스토리 보다 큰 범위. 

📌 유저 스토리 User Story  #개발 구현 가능 단위 #합의 도출 #걸킨 문법 #테스트 케이스

- 기능명세서와 비슷 (가장 구체적으로 - 이 화면에 어떤 기능이 들어가는데 이 기능이.. 어떤 요소가 있고.. 어떤 정보가 있는지, 명확하게 정리를.. 기능에 대한 요구사항)  

- 캐릭터를 만들기 위한 스토리가 뭐지? 이 스토리가 더 유저에 더 가깝다!(고 정함) 스토리 바탕으로 페르소나가 만들어진다. 캐릭터 성격 중심, 기능 테스트 할 때도 참여자에게 스토링 텔링을 한다.

- 여러 기능 중, 일부 기능 테스트 할 때 유저 스토리를 쓴다. (유저테스트 할 때, 유저 시나리오 보다 유저 스토리를 실무에서 더 많이 씀)

3. 여러 페르소나를 중심으로 유저저니를 만들기도 한다는데, 그럼 그다음 단계에는 어떻게 되는 건지?

- 장 보는 앱을 예를 들어보자. 사용자는 주부가 있을 거고 자취생도 있을 수 있다. 주부랑 자취생은 저니가 조금씩 다를 수 있다. 지취생은 육아하는 주부가 가는 육아용품 쪽을 가지는 않을 것이다. 마켓컬리 경우, 젊은 주부들이 많이 사용. 그들이 메인 페르소나, 그들이 많이 쓰는 섹션을 앞단에 배치한다던지. 주요 페르소나 또는 다른 페르소나들은 어떻게 이 앱에 들어갈지, 뭘 중요하게 생각해서 어디로 들어갈지를 알아야 한다. 그들의 저니에 따라서 같은 앱을 쓰더라도 하나의 서비스에도 여러 가지의 플로우가 생길 수 있다. 서로 다른 저니에서 접점지도 있을 거다. 그걸 서비스에서 어떻게 구현하는지는 다음 문제. 타깃인 코어 페르소나 를 계속 업데이트해하고 숙지하고 있어야 프로덕트의 청사진처럼 사용할 수 있다.

4. 어떻게 페르소나를 업데이트하는지?

1st 파티 도메인 - 모니터링 가능, 가입회원 데이터로, 쌓이기 전에는 마켓 조사 통해서 페르소나를 만들기는 한다.

5. 시장조사 하고 유저 조사하고 분석해서 제품을 만들어 시장에 내놓아도 맞지 않는 경우가 많다던데?

틀린 것도 정답이다. 가설이 맞지 않으면 다시 애자일 하게 빨리 변화하는 시장에 맞춰 개선하고 다시 내놓는 일을 반복한다. 어쨌든 마켓은 예측불가다. 알아볼 수 있는 방법은 내 새끼를 시장에 내놓는 것 밖에 없다. 그리고 자리 잡을 수 있도록 현실감각을 키워주는 것이다.

6. 프로덕트 디자인 실력 향상의 가장 빠른 길은 시장에 내놓은 프로덕트 사용자들한테 두들겨 맞는 것이라는 말이 떠오른다. 

진짜 맞는 말이다. 사용자는 냉정하다. 거기다 익명이니까. 내주머니에서 돈이 나간다 생각하면 100원 쓰는 것에도 내가 왕인 것처럼 행동한다. 보통 주니어 때는 사용자와 맞닥뜨리는 일이 별로 없다. 나 같은 경우는 시장이랑 전면대결을 3-4년 차 때부터 했다. 하도 단련되어서 이제는 '이것밖에 안 하나? 좀 더 세게 나와도 될 것 같은데?'라는 여유도 생겼다. (쓴배님..멋져요...😍)

목차
01. UX 기획 첫 단추 : 문제 정의 및 가설 수립
02. UX 기획 구체화 : 유저 사용 맥락 반영
03. UX 기획 구체화 : 논리적인 흐름 설계
04. UX 기획 문서화 : 화면 설계서 및 QA 문서

협업을 위한 문서화 작업

1️⃣ 화면 설계서
2️⃣ QA

1. 화면 설계서

프로젝트의 복잡도가 높고, 이해관계자가 많을 경우 원활한 히스토리 파악 및 유지 보수를 위해 화면 설계서를 작성하기도 한다. 와이어프레임과 기능 상세 정의를 합친 문서로, 화면에 존재하는 각 요소를 분리하여 설명한다.

보통 좌측에는 와이어 프레임을 두고 우측에는 기능 상세 정의를 같이 두어서 설명을 붙여놓는다. 화면에  존재하게 되는 각 요소들에 대해서 넘버링을 하고 각 요소에 대한 설명들을 아래 이미지 우측 처럼 작성을 하게 된다. 

변경된 내용은 작성일과 함께 (날짜가 언제고, 버전이 얼마다) 기록하여 버전을 관리한다.

변경 이력 같은 경우에 마이너한 변경이면, 이 화면에서 아주 약간 변경되었다면 이력은 해당 페이지에서 업데이트가 되었다 라는 것을 표시해주고, 언제 변경이 되었다, 이런 정보까지 함께 수록을 하는 편이다.

• 회사나 프로젝트의 성격에 따라 화면 설계서를 작성하는 경우도 있고, 아닌 경우도 있다.
• 회사에 따라 화면 설계서를 작성하는 직군이 다르기도 하다. 예를 들어, 사업기획부에서 작성하기도 하고, PO/PM이 작성하기도 하고, UX/UI 디자이너가 작성하기도 한다.

2) QA 문서

QA(Quality Assuarance)는 기능 배포 전에 기능을 테스트하는 과정으로, 크게 테크니컬 QA (의도한 대로 기능이 동작하는지, 테스트 케이스를 작성하고 요구사항을 충족하는지에 초점)와 디자인 QA으로 나뉜다.

• 제품팀에서 오너십을 가지고 테크니컬 QA와 디자인 QA를 수행해요. 이 때, 보통 작업자가 직접 QA를 진행한다.
• 별도의 QA 팀이 있는 경우, 협업을 통해 예상치 못했던 버그나 사이드 이펙트를 발견하여 보완하기도 한다.
  
  
  
• 테크니컬 QA는 의도대로 기능이 잘 동작하는지에 초점을 맞춰서 이루어진다.
  보통 테스트 케이스를 작성하고, 요구 사항을 충족하는지 확인한다.
  
  📌 테스트 케이스 문서 작성 TIP :
  특정 조건 하에서 테스트 가능해야하므로 어떤 조건에서 테스트 하는지 상세하게 명시한다.
  
  

• 테스트 화면, 조건, 테스트 케이스, 기대하는 결과, 테스트 환경, 테스트 결과(PASS/FAIL) 등이 포함될 수 있어요.
• 뎁스가 많은 화면일 경우 **대분류/중분류**로 구분하여 화면을 그룹화하기도 해요.

🚨주의 : 특정 조건 하에서 작동하는지 살펴보는 것이기 때문에 어떤 조건에서 테스트하는지 굉장히 자세하게 명시되어야 한다.

🙋‍♀️ 누가 QA를 진행할까?
보통 제품팀에서 직접 작업한 사람이 오너쉽을 가지고 1차 QA진행. 조직에 따라서 별도의 QA팀이 있는 경우도 있다. 이 경우에는 협업을 통해서 함께 예상하지 못했던 버그라던지, 사이드 이펙트를 좀 더 발견할 수 있는 포인트가 있다.

☘️ 디자인 QA 문서 작성 TIP

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

1️⃣ QA 문서에서 개발 반영 여부와 최종 확인 여부를 구분해서 최종적으로 이슈가 해결되었는지 명확하게 추적하는 것을 추천
(개발 반영 여부와 최종 확인 여부가 다를 수 있기 때문. 개발자는 열심히 개발을 반영했다고 하지만 막상 확인해보면 생각보다 의도한 것과 또 다르게 구현이 되어 있는 경우도 심심치 않게 있다.)

디자인 QA 이슈 리스트에는 우선순위, OS, 발생 화면, 이슈 내용, 개발 반영 여부 및 최종 확인 여부, 리뷰어 등의 정보가 포함된다.

우선순위(HIGH, MEDIUM,LOW)

HIGH - 이거 해결하지 않으면 유저의 경험에 심각한 문제가 된다.
MEDIUM - 고치면 좋다. 바로 고쳐지지 않을 거라면 언제까지 반영할 수 있을지 논의는 해야 한다.
LOW - 굉장히 급박한 일정일 경우에는 스킵하고 넘어갈 수 있는 정도.

2️⃣ AS-IS와 TO-BE를 명확하게 설명한다.

개발자한테 "이렇게 구현을 했는데 의도한 것은 이런 거다." 하고 두 개를 비교해서 보여주는 것이 중요하다.

예) 문구가 '지금 시작하기'로 되어 있는데 의도한 디자인에서는 '0원으로 시작하기'를 의도한 거에요. 라고 AS-IS, TO-BE를 같이 보여주는 것이 중요

만약 굉장히 마이너한 곳에서 디테일하게 어긋나다 하면 그 화면에다 빨간색 표시를 해서 전달하기도 한다.

목차
01. UX 기획 첫 단추 : 문제 정의 및 가설 수립
02. UX 기획 구체화 : 유저 사용 맥락 반영
03. UX 기획 구체화 : 논리적인 흐름 설계
04. UX 기획 문서화 : 화면 설계서 및 QA 문서

논리적인 흐름을 설계할 수 있는 방법론

1️⃣ 유저플로우 #화면 간의 이동
2️⃣ 와이어 프레임 #Lo-fi #아이디에이션
3️⃣ 정보 구조도 #그룹핑 #라벨링

정해진 순서는 없다. 유저 플로우와 와이어 프레임은 디자이너 개개인마다 선호도가 있어서 유저 플로우를 먼저 작업하는 것을 선호하는 디자이너도 있고 와이어 프레임을 먼저 작업하는 것을 선호하는 디자이너도 있다.

플로우를 먼저 설계한 다음에 화면에 뭐가 들어갈 건지 고민하는 디자이너가 있고, 화면에 뭐가 들어갈 건지 생각해 본 다음에 플로우를 구성하는 것을 선호하는 디자이너도 있다.

1) 유저 플로우 (User Flow)

유저가 제품이나 서비스를 이용하는 과정을 유저의 행동 및 화면 간의 이동에 초점을 맞추어 시각화하는 단계.

• 유저가 최종 목표에 도달하기 위해 서비스 내에서 어떤 경로로 이동하며, 어떤 행동을 하는지 구체화하는 도구로 활용할 수 있다.
  
  
• ‘해피 패스’에 매몰되지 않고 다양한 경로를 고려해볼 수 있다는 장점이 있다.
  
  해피 패스(Happy Path)
  유저가 제품이나 서비스에서 원하는 목적지까지 아무런 문제를 겪지 않고 도달했을 때의 경로
  
  
• 유저 플로우와 와이어프레임은 상호보완적인 도구로 활용할 수 있으며, 작업에 정해진 순서가 있는 것은 아니다.
  
  
• 유저 플로우 구성 요소

✅ 원형 : 시작/끝 프로세스의 시작이나 끝

✅  사각형 : 동작/프로세스 유저의 입력이나 액션

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

✅  화살표 : 플로우의 방향 한 상태나 단계에서 다음 상태나 단계로의 흐름을 표현

☘️ 유저 플로우 예시
유저가 로그인 시도 시 소셜 로그인 및 이메일 로그인을 했을 때 경험할 수 있는 플로우를 도식화한 예시

TIP)
화면, 유저 액션, 시스템 액션, 모달의 경우 색상으로 구분하여 이해를 높일 수 있다.

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

유저가 상품을 탐색하고 결제하기까지의 플로우를 도식화한 예시

2) 와이어프레임 (Wireframe)

화면의 레이아웃과 플로우를 단순한 선과 도형으로 설계하는 과정.

• 로우 피델리티(Lo-fi)로 작업되어 작업자들이 부담 없이 아이디어에 자유롭게 참여하고 의사결정에 기여할 수 있도록 도와주는 도구로 활용할 수 있음.
• 그래픽 요소 및 기술적인 세부사항을 배제하고 신속하게 결과물을 생성하여 작업자 간 커뮤니케이션을 위한 초기 비주얼을 제공할 수 있다는 장점이 있다. (화면 그릴 때, 그래픽 요소나 기술적으로 구현이 구현이 가능할지 혹은 디자인시스템에 맞는 건지 등 생각보다 고려할 것이 많은데, 이런 걸 다 빼고 신속하게 결과물을 생성할 수 있다.)
• 변경되는 요구 사항에 대응하여 빠르게 구조를 검토하고 수정하기가 용이하다.
• 논의의 초점을 (그래픽적으로 이게 유려한가 혹은 기술적으로 구현이 가능한가를 배제하고) 레이아웃과 플로우에 집중되도록 최소한의 색과 디자인을 사용하여 작업한다.
• 와이어프레임에 화면 이동에 대한 정보를 추가했을 때는 ‘와이어 플로우(Wire Flow)’라고 부르기도 한다.

☘️ 와이어프레임 예시

와이어프레임은 종이에 손으로 그리는 타입부터, 디자인 툴에 작업하는 타입까지 다양한 피델리티로 작업할 수 있다.

• 신속하게 제작하고 손쉽게 수정할 수 있다.
• 회의 중 간단한 종이나 보드에 함께 스케치하면서 아이디어를 즉각적으로 공유하고 토론하기 용이하다.
• 손으로 그리는 과정 중에 아이디어를 발산하기 용이하다.

• 손으로 그린 와이어프레임보다 비교적 정확하고 일관된 와이어프레임을 만들 수 있다.
• 디자인 툴로 작업한 경우 링크를 공유하여 피드백을 받기 용이하다.
• 물리적으로 같은 공간에 있지 않더라도 실시간으로 함께 작업하는 것이 가능하다.

3) 정보 구조도 (Information Architecture)

제품이나 서비스를 구성하는 요소들의 구조를 도식화하는 것으로, 유저가 길을 잃지 않고 원하는 정보를 쉽게 찾고 작업을 완료할 수 있도록 돕는 과정

• 유저가 자신의 현재 위치와 다음 장소로 가기 위해 무엇을 해야할 지 인지할 수 있도록 설계할 때 활용
• 정보 구조가 효과적으로 설계될 경우 유저의 접근성이 향상되지만, 부적절하게 설계될 경우 유저의 이탈과 오류를 발생시킬 수 있다.
• 상위와 하위 개념을 효과적으로 그룹핑하고 올바른 라벨링을 하는 것이 중요하다.
  
  
• 정보 구조도의 기반이 되는 구성 요소

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

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

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

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

☘️ 정보 구조도 예시

정보 구조도는 비슷비슷하게 보이지만, 반드시 지켜야 하는 형태가 있지 않다.
때문에 프로젝트 성격과 상황에 따라 맞춰서 적용하는 것을 추천한다.

✅ Organization 예시 :
화해 쇼핑 이벤트 페이지 내 콘텐츠들이 어떻게 그룹화되어 있는지 도식화한 예시

✅ Labeling 예시 :
화해 쇼핑의 카테고리 구조를 도식화한 예시

✅ Navigation 예시 :
화해의 바텀 내비게이션 구조를 도식화한 예시

✅ Searching 예시 :
화해 쇼핑의 검색 기능을 도식화한 예시

목차
01. UX 기획 첫 단추 : 문제 정의 및 가설 수립
02. UX 기획 구체화 : 유저 사용 맥락 반영
03. UX 기획 구체화 : 논리적인 흐름 설계
04. UX 기획 문서화 : 화면 설계서 및 QA 문서

유저 사용 맥락을 반영할 수 있는 방법론

1️⃣ 유저 시나리오 User Scenario
2️⃣ 고객 여정 지도 Customer Journey Map
3️⃣ 유저 스토리 User Story

1) 유저 시나리오 (User Scenario)

제품 또는 서비스에 대한 유저 경험을 스토리텔링으로 기술하는 방법

• 디자인 초기 단계에서 유저에 대한 공감을 바탕으로 유저 중심의 솔루션을 찾을 때 활용한다.
• 유저 페르소나와 결합하여 작성하면 유저의 동기와 목표를 감성적으로 이해하는 데 도움이 된다.

유저 시나리오의 구성 요소

✅ 유저 : 유저 페르소나
✅ 목표 : 무엇을 달성하려고 하는지?
✅ 동기 : 왜 달성하려고 하는지?
✅외부 요소 : 어떤 것에 영향을 받는지? ex) 사용 상황, 사용 시간 등

☘️ 유저 시나리오 예시

버티컬 커머스 서비스를 사용하는 유저의 시나리오

• 버티컬 커머스 : 특정 카테고리를 중점적으로 다루는 온라인 쇼핑 전문몰. 예를 들어, 무신사는 패션 전문 버티컬 커머스다.

유저 : 홈트를 즐기고 건강에 관심 있는 30대 직장인 여성 클레어

목표 : 건강과 관련된 제품을 효율적으로 온라인으로 구매하고, 홈트 공간을 더욱 효과적으로 꾸미기

동기 : 품질높은 건강 제품과 홈트를 위한 트렌디하고 기능적인 아이템을 갖고 싶다.

외부 요소 : 평소 때는 구매를 하지 않지만, 오늘 블랙프라이데이 할인 쿠폰을 받았다. 눈독 들이고 있던 요가블럭이 마침 78% 할인된 가격에 판매되고 있어서 얼른 쿠폰까지 적용하여 저렴하게 구매한다.

2) 고객 여정 지도 (Customer Journey Map)

제품 또는 서비스를 유저가 이용하는 흐름을 시각화하여 분석하는 방법.

• 타임라인에 따른 유저의 여정을 시각적으로 표현하여 특정 시점에서의 경험을 파악하고 개선점을 찾을 때 활용.
• 전체 유저 경험을 한눈에 파악할 수 있다.
• 고객 여정 지도의 구성 요소

Zone A : 관점

1. 유저 페르소나 : 여정을 체험하는 유저
예시- 야근을 자주하는 20대 회사원 유진

2. 유저 시나리오 : 여정 지도가 다루는 상황 묘사, 유저의 목표와 기대치와 연결
예시 - 카카오T로 택시를 호출하여 편리하게 집에 돌아가고 싶어요. 얼른 빨리 집에 돌아가서 쉬고 싶은 마음 뿐이에요. 그런데 시간대가 밤이라서 편리한 호출과 안전한 운행을 기대하고 있어요.

Zone B : 경험

3. 여정 단계 : 타임라인 기반으로 분류
예시 - 호출 및 대기 단계, 픽업 단계, 이동 단계, 도착 및 결제 단계

4. 행동 : 유저가 특정 단계에서 취하는 행동
예시 - 호출 시 앱을 열어 목적지를 입력하고 택시를 호출해요. 이동 중 휴대폰이나 업무에 전념하거나 휴식을 취해요. 결제 시 앱을 통해 간편하게 결제를 진행하고 리뷰를 남겨요.

5. 생각 : 유저의 생각, 질문, 동기, 정보에 대한 니즈
예시 - 호출 시 택시가 빨리왔으면 좋겠다고 생각해요. 이동 중 길이 많이 안 막히길 바라면서 끝내지 못한 업무를 계속 생각해요. 결제 시 등록된 카드에 잔액이 남아있는지 잠시 생각해요.

6. 감정 : 단계에 걸쳐 단일 선으로 표현
예시 - 호출 시 근거리라 배차 거부를 하는 몇몇 택시 때문에 조급해져요. 이동 중에 괜히 길을 빙 둘러가지 않을까 불안해요. 결제 시 할증으로 비싼 택시비 때문에 잠시 당황해요.

Zone C : 인사이트

 7. 기회 : 유저의 경험을 어떻게 최적화할 수 있는지에 대한 인사이트
예시 - 할증에 대한 투명성과 다양한 결제 옵션을 제공하면 유진이 더 편리한 결제 경험을 할 수 있을 거예요. 근거리 배차 거부를 최소화한다면 야근하는 유진이 퇴근하기 더 편리할 거예요.

8. 담당 팀이나 부서 : 해당 인사이트를 적용해볼 수 있는 협업자 코멘트
예시 - 결제 팀에서 요금 구조를 전달하는 방식과 결제 옵션 다양화를 고려할 수 있어요. 운영 및 품질 담당 팀에서 근거리 운행 거절에 대한 패널티 시스템을 고려할 수 있어요.

3) 유저 스토리 (User Story)

특정 기능을 실제 개발 구현 가능한 작은 단위로 기술하는 방법

• 주로 애자일(Agile) 방법론에서 사용. 특히 엔지니어가 개발 작업 시 기능을 이해하고 구현하는 데 유용하게 활용.
• 문서에서 일일이 모든 내용을 정의하기에는 한계가 있기 때문에 유저 스토리를 통해 구현할 사항에 대한 구성원 간 합의를 도출.
• ✅ 실무에서는 협업 시 유저 시나리오, 유저 저니맵보다 빈번하게 활용.

유저 스토리의 구성요소 :

★ As a {user} : 유저
★ I want {goal} : 유저가 원하는 기능 또는 행동
★ So that {benefit} : 이를 통해 유저가 얻을 수 있는 이득

☘️ 유저 스토리 예시 

커머스 서비스에서의 유저 스토리

★ As a - 로그인한 유저
★ I want - 장바구니에 상품을 추가
★ So that  - 나중에 담긴 상품들을 확인하고 구매하기 위해서

★ As a - 로그인한 유저
★ I want - 네이버페이와 카카오페이를 통한 간편 결제
★ So that  - 편의성을 누리고 포인트 혜택을 받기 위해서

(심화)
걸킨 문법을 활용하여 테스트 케이스에 활용하기 좋은 구조로 유저 스토리를 구체화할 수 있다.

걸킨 문법 활용하여 유저 스토리 구체화하기

• 걸킨 문법(Gherkin Syntax)은 유저의 행동에 중점을 맞추어 개발하는 행동 주도 개발(Behavior-Driven Development) 환경에서 널리 활용되는 특수한 문법.
• As a, I want, So that만으로는 기능 구현 여부를 명확히 판단하기 어려워서 테스트 케이스를 구체적으로 정의하기 위한 용도로 활용하기도 한다.
• 걸킨 문법을 활용한 유저 스토리 구체화 요소
  ★ Given (주어진 상황) - 유저에게 주어진 상황
  ★ When (조건 및 행동) - 유저의 특정 액션 또는 이벤트
  ★Then (결과) - 특정 결과나 상태

☘️ 걸킨 문법을 활용한 유저 스토리 예시

• 유저의 추가 액션이 있을 경우 **And**와 **Or**을 활용하여 표현할 수 있다.
• 한 유저 스토리에 대한 구현에 대한 기준은 여러 개가 될 수 있다.
  ex) 간편 결제 기능의 경우 결제 실패 케이스 등에 대한 내용도 포함될 수 있다.

목차
01. UX 기획 첫 단추 : 문제 정의 및 가설 수립
02. UX 기획 구체화 : 유저 사용 맥락 반영
03. UX 기획 구체화 : 논리적인 흐름 설계
(기획의 구체화의 두 가지 관점 : 1. 유저 사용 맥락을 반영 2. 논리적인 흐름을  설계)
04. UX 기획 문서화 : 화면 설계서 및 QA 문서
(여러사람들과 커뮤니케이션을 위해 문서화해야 될 필요성이 생긴다.)

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

문제를 정의하고 가설을 수립하는 방법 : 유저 리서치를 통해 도출한 제품의 현재 문제점을 특정하는 단계

PO랑 PM이 문제 정의하고 가설 수립할 수 있다. 하지만 포괄적인 관점에서 문제정의를 하기 때문에 한계점이 있을 수도 있다. 기술적 차원에서 비즈니스 차원에서 해결할 수 있는 부분이 있을 것이고, 디자인 관점에서 해결할 수 있는 방법, 아주 넓은 관점에서 문제를 정의하고, 가설을 수립하게 된다. 그렇기 때문에 오히려 디자인 관점에서 문제를 정의하고 가설을 수립하는 걸 디자이너가 훨씬 잘할수 있는 부분도 있다.

예를 들어, PO or PM은 "기술적으로 지금 추천 로직을 조금 더 개선해서 유저들이 더 질 좋은 추천을 받을 수 있게 하는 게 중요하지 않을까?"라던지 "영상 스트리밍 속도가 느리면, 기술적으로 개선을 해서 사용자 경험을 개선할 수 있지 않을까?"등 이런 쪽에 조금 더 포커스를 맞출 수도 있다.

그런데 디자이너의 강점은 뭐다? 유저의 입장에서 조금 더 고려해서 디자인 쪽으로 풀 수 있는 그런 고민들을 더 할 수 있다! 그렇기 때문에 거꾸로 디자이너들이 "이렇게 했으면 좋겠어요.", "이렇게 하면 유저 경험이 나아질 수 있지 않을까요?"라고 역으로 제안할 수 있다. 그리고 기업에서도 적극적으로 의견을 어필하는 디자이너를 선호한다. PM, PO들이 기술적인 문제라던지 비지니스 차원에서의 문제, 이런 것들을 풀다 보면 이외로 디자인 관점에서 문제를 많이 풀지 않는 경우도 있다. 그러면 막상 분기가 지나고, 1년이 지났을  포트폴리오에 남는 게 없다. 그렇기 때문에 유저한테 좋은 것 + 나의 포트폴리오에도 좋고, 회사에도 좋은 교집합을 잘 찾아서 아이디어를 제시하는 것은 굉장히 중요하다.

기획의 첫 단계이다 보니 시작을 어떻게 하냐에 따라서 기획을 구체화 하는 데 있어 많은 영향을 미치게 된다.

 1) 문제 정의 : 유저 리서치를 통해 도출한 제품의 현재 문제점을 특정하는 단계

• 해결해야 할 문제가 무엇인지를 정의
• 문제의 크기를 정량화된 수치로 파악
• 왜 문제로 정의했는지 충분한 근거 확보
• 문제 발생 원인에 대한 근거 데이터를 파악 (근거 데이터를 챙겨 커뮤니케이션)
  
  

☘️ 문제 정의 예시 : 회원가입 화면에서의 문제 정의 과정

문제 :
유저의 40%가 회원가입을 완료하지 않고 중도에 이탈하는 문제

문제로 정의한 이유 :
이 때, 유저 경험 관점과 비즈니스 관점을 함께 생각해보는 것을 추천

유저 경험 관점
회원가입은 제품의 초기 진입점 중 하나로, 유저가 제품을 처음 경험하는 단계. 여기에서 유저가 얼마나 수월하게 진입하느냐가 전반적인 유저 경험에 큰 영향을 미칠 수 있기 때문에 이 부분에서의 개선이 필요.

비즈니스 관점
많은 유저가 회원가입 중 이탈한다면, 효과적인 유저 획득이 어려워져서 잠재적인 유저 손실로 이어질 수 있다.

근거 데이터 :
유저 행동 데이터, 인터뷰 등을 통해 문제 발생 원인에 대한 힌트를 찾을 수 있다.

✅ 회원가입을 위해 한 번에 입력해야 하는 정보가 많아서 유저가 부담감을 느끼고 있다.
(힌트 : 이탈하는 유저 중 65%가 정보를 모두 입력하기 전에 이탈하고 있다.)

✅ 약관 동의가 왜 필요한지에 대한 명확한 안내가 없어서 유저가 프라이버시 침해에 대한 불안감을 느끼고 있다.
(힌트 : 1. 이탈하는 유저 중 20%가 정보 입력 후 약관 동의 전에 이탈하고 있다. 2. 인터뷰에 따르면 유저들은 약관 동의 시 개인정보가 수집되는데 그에 대한 설명이 불충분하다고 느꼈다.)

✅ 회원 가입을 위한 정보 입력과 약관 동의가 동시에 이루어져서 유저가 복잡하다고 느끼고 있다.
(힌트 : 인터뷰에 따르면 유저들은 첫 눈에 보기에 해야하는 게 많아보여서 귀찮다고 느꼈다.)

문제 정의, 어떻게 시작할지 막막할 때,
아래 세 가지를 연결지어 생각해보는 연습을 하면 도움이 된다!

1️⃣ 문제를 풀고자 하는 목적
문제를 통해 무엇을 이루고자 하나요?

2️⃣ 문제
목적을 이루기 위해 문제가 되는 것은 무엇인가요?

3️⃣ 문제를 풀었을 때의 임팩트
문제를 해결하면 목적이 얼마나 달성되나요?

추가학습자료 (문제 정의와 문제 해결에 힌트를 얻을 수 있는 예시 자료)

2) 가설 수립 : 특정 문제에 대한 가정을 명확하게 정의하고 검증 가능한 형태로 제시하는 단계

• 가설 설정
  • 작은 문제부터 큰 문제까지 모두 가설을 통해 검증할 수 있어요. 다만, 문제를 하나의 아이디어로 한 번에 해결하는 것은 어려운 일이다. 그렇기 때문에 스텝 바이 스텝으로 가설을 쪼개서 설정하는 것도 필요할 수 있다.
  • 가설은 개선을 시도하고자 하는 부분에 초점을 맞추어 1) 어떤 변경을 통해 2) 어떤 결과를 얻고자 하는지 담고 있어야 한다.
• 가설 검증
  • 가설을 어떻게 검증할 것인지 검증 방법을 선정한다.
  • 가설을 검증할 수 있는 올바른 모니터링 지표를 설정한다.

좋은 가설의 요건

• 목표 지향
  • 가설은 특정 목표를 달성하기 위한 것으로.
  • 여기서 목표는 유저 경험 개선이나 유저가 가진 문제 해결과 관련 있어야 한다.
    예) Data Driven UX 트렌드에서 배웠던 지표 예시들 - 페이지 뷰 수, 전환율 이런 걸 개선하기 위한 것이다 라는 목표
• 구체성과 명확성
  • 불확실한 용어나 추상적인 문구는 피하기. (형용사라던지 이게 무슨 뜻인지 모르는 문구는 NO)
  • 구체적인 결과물을 예측할 수 있도록 하기. (가설 문장만 봤는데도 구체적으로 어떤 결과가 나오겠구나 라고 모두가 예측가능하게)
• 측정 가능성
  • 가설은 검증 가능하고 측정 가능해야 한다.
  • 지표를 통해 성공과 실패를 측정할 수 있어야 한다.

☘️ 가설 수립 예시 : 회원가입 화면에서의 문제를 바탕으로 가설을 수립하는 과정

가설 : 회원 가입을 시도하는 유저가 한 번에 한 정보만 입력할 수 있도록 하면, 더 많은 유저가 회원 가입을 완료할 것이다.

검증방법 : A/B Test

A안 기존 안 노출

B안 : 한 번에 한 정보만 입력할 수 있도록 하는 새로운 안 노출

모니터링 지표  :

알아야 하는 용어
🔮 성공지표 : 가설을 검증할 수 있는 지표
🔮 가드레일 지표 : 조직 전체에서 중요하게 고려하는 지표, 혹은 해당 실험으로 (의도와 상관없이) 부정적인 영향을 받을 수 있는 지표 (가드레일 지표는 +alpha로 설정하면 좋다.)

성공 지표와 가드레일 지표를 설정

*성공 지표 (Success Metric) : 이탈율 (이탈율이 B군에서 30% 이내일 경우 성공한 것으로 보기로 약속할 수 있음)

*가드레일 지표 (Guardrail Metric) : 구매 전환율, 소요 시간, 단계 완료율 (아무래도 한 페이지에 있던 가입정보 기입란들이 여러 단계로 나누어 졌기 때문에 작성 소요 시간이 오히려 늘어날 수 있는 것이 우려되는 부분이라 가드레일 지표로!)

* 가드레일 지표 활용 방법

• B군에서 구매 전환율이 5% 이상 낮을 경우 성공 지표를 달성하더라도 전면 적용은 고민해봐야 한다.
• B군에서 소요 시간이 5% 이상 길 경우 성공 지표를 달성하더라도 전면 적용은 고민해봐야 한다.
• B군에서 단계 완료율이 10% 이상 낮을 경우 성공 지표를 달성하더라도 전면 적용은 고민해봐야 한다.

Q. 성공 지표는 얼마나 높으면 성공적이고, 가드레일 지표는 얼마나 낮을 때 부정적일까?

• 어떤 기준으로 성공과 실패를 정의하느냐에 따라 천차만별이 될 수 있다.
• 테스트 결과에 따른 액션을 고려할 때 토론이 이어지는 경우가 많아요.
• 산업 표준 자료, 유사 프로젝트의 결과 비교, 프로젝트의 성격, 비즈니스 목표, 이해 관계자의 기대치 등을 종합적으로 고려하게 돼요.
• 예를 들어, 비즈니스 목표로 매출 추세 유지가 중요한 회사의 경우 성공 지표인 리텐션이 5% 오르더라도, 가드레일 지표인 매출이 0.1% 하락한다면 전면 적용을 결정하지 않을 수도 있다. (고작 0.1프로라고 생각할 수 있지만 커머스 회사에서 매출 0.1%로면 몇 억이 왔다 갔다 하기도 한다. 그렇기 때문에 신중하게 결정하게 되는 경향이 있을 수도 있다.)
  

📌 성공지표와 가드레일을 헷갈려하는 주니어들이 많다. 우선 이 두 요소가 비례, 반비례 관계가 아니라는 것을 염두해두면 좋고, 데이터를 분석할 때 이 둘의 상관관계는 확인해야 한다. 


방향이 잘못 될 수 있기 때문에 지표는 보통 여러개로 설정된다.

예시) 서비스의 해지 방어 하기 위해서 해지 버튼 누를 때 팝업창을 만들기

*성공지표 : 해지 방어

*가드레일 지표 : 구매전환율, CS증가

의도한 대로 해지율 방어에 성공했지만 CS에 문의해서 해지하고 싶다고 하는 사용자가 증가. 결국, 해지방어성공했지만 CS증가로 리소스가 더 늘어났다면 이거는 옳은 개선이라고 판단하기 어려움.

+ 공급자 입장에서는 매출이 일어나야하는데 구매전활율이 높아져야 매출이 증가한다. 기존 사용자가 해지했다면 나중에 구매할 확률이 높아진다. (해지한 고객도 잠재적 구매 사용자로 볼 수 있다. 나중에 다시 와서 구매할 확률이 높아짐)

사용자 공급자 입장을 다 생각해서 개선방안을 봐야함..  테스트 지표도… 다양한 변수 요소 고려해야하기 때문에 모든 유관 부서가 대응해야 안전적인 검증을 할 수 있다.

추가 학습 자료 (실무에서는 어떻게 가설을 설정하여 디자인 솔루션을 도출하는 지 예시)

3) 원페이저(1 Pager) 작성 : 정의한 문제와 가설을 중점으로 실험의 방향성과 목적을 한 눈에 파악할 수 있도록 정리하는 단계 (한 페이지 내에 주요한 정보들이 담긴다)

• 이 단계에서부터 다양한 이해관계자들과의 논의가 시작된다.
• 논의를 진행해나가면서 원페이저는 계속 수정/보완되고, 더 다양한 정보들을 담게 된다.
• 회사에서 중요하게 생각하는 가치에 따라 원페이저에 담기는 내용이나 명칭은 조금씩 다를 수 있다.

☘️ 원페이저 초안 예시 :
해결해야 할 문제의 성격에 따라 포함되는 내용은 더 많아질 수 있으며,
논의 과정에서 디자인 솔루션, 실험 기간, 예상 일정 등에 대한 내용이 구체화

크게 세 파트로
1️⃣ 문제 정의      2️⃣ 가설 및 검증 방법      3️⃣ 모니터링 지표

1️⃣ 문제정의
문제가 어떤 것이고, 이게 왜 문제라고 생각하는지, 그 근거가 무엇인지 데이터 기반으로 설명한다.

2️⃣ 가설 및 검증 방법 
그래서 가설은 어떤 것으로 생각을 했고 어떻게 검증을 할 것인지 이 설계를 러프하게라도 하게 되고,

모니터링 지표, 성공 지표는 어떤 걸로 보고 싶고, 가드레일 지표는 어떤 것으로 보고 싶다.

처음에는 이렇게 간단한 문서로 시작을 했다가 논의과정에서 디자인 솔루션을 어떻게 가져갈 건지 실험 기간을 어떻게 가져갈 건지, 예상 일정을 어떻게 생각하는지 등의 다양한 정보들이 담길 수 있다.

본격적으로 그동안 구매했던 UX/UI 관련 책들을 읽으며
스터디 하고자 캠프에서 나눠준 아티클/ 책 스터디 하는 법을 다시 들여다 본다.

---

📖 매일 찾아보는 정보에서 얻은 인사이트를 단순히 흘려보내기 보단 스터디를 통해 나의 자산으로 만들어 봅시다. 하루 1~2개의 아티클 또는 책을 읽고 그 내용을 정리합니다.

[UXUI 아티클/책 스터디 진행 방식]

• 매일 팀원들과 함께 마이크와 화면을 켜고 스터디를 진행 (언제할지 팀원과 상의해서 결정)
• 팀원 전원이 함께 스터디할 아티클 / 책 중 하나를 택하여 분석을 진행
• 30분 분석 및 리서치 + 10분 내용 정리 및 공유
• 공유는 텍스트가 아닌 반드시 마이크와 카메라를 키고 구두로 진행해주세요.

분석 및 리서치 방법

1. 분석하고자 하는 아티클/책 을 선정한다.
2. 아티클/책 을 분석하여 30분동안 글을 작성한다.
   • 아티클
     1. 링크 또는 출처를 작성한다.
     2. 핵심 내용을 요약한다.
        1. 가독성과 짜임새를 고려하여 작성해봅시다. 이 과정에서 아티클에 대한 이해도가 높아집니다.
     3. 해당 아티클을 읽고 얻은 인사이트, 알게 된 개념을 작성한다.
        1. 인사이트 : 좋았던 점 / 아쉬웠던 점으로 나눠 작성해봅시다.
        2. 알게 된 개념은 제목과 간단한 설명으로 작성합니다.
        3. 우리가 웹에서 만나는 아티클(브런치, 블로그, 웹페이지…)은 각자의 관점으로 작성되어 있으므로 정답도, 오답도 있을 수 있고 때로는 나와 시각이 다를 수 있습니다. 이 정보를 그대로 흡수하는 것이 아니라, 중립적으로 바라보고 받아들이는 연습을 해봅시다.
   • 책
     1. 책 이름을 작성한다.
     2. 내가 읽은 부분의 내용을 요약한다.
     3. 코멘트를 작성한다.
        1. 좋았던 점
        2. 아쉬웠던 점
        3. 알게 된 개념

참고할만한 책

• [책] 사용자를 생각하게 하지 마! (예스24)
  • 부제: 웹과 모바일 사용성 원칙으로 디자인하는 UX
  • ‘웹과 모바일 사용성 원칙’ 바이블. 사용자를 고민에 빠뜨리지 마라! 이 책에서 저자인 스티브 크룩이 가장 강조하는 첫 번째 사용성 원칙이다. 사용자가 자신이 보고 있는 것이 무엇인지, 그리고 사용법은 어떻게 되는지를 과한 수고를 들이지 않고도 자명하게 이해하게 하는 방법 등 웹 사이트를 명료하게 만드는 사용성 원칙들을 유쾌하게 풀어낸다.
• [책] 사용자를 사로잡는 UX/UI 실전 가이드 (예스24)
  • 이 책은 이제 막 디자인 너머 사용자를 고민하기 시작한 주니어부터 PM으로 활발히 활동 중인 시니어까지 사용자를 사로잡을 디자인을 꿈꾸는 모든 이를 위한 책이다. 주니어는 UX/UI의 이해부터 나무가 아닌 숲을 보는 방법과 기초 소양을, 시니어는 급변하는 트렌드의 소용돌이에서 건져낸 인사이트를 얻을 것이다.
• [책] 오늘도 개발자가 안된다고 말했다 (예스24)
  • “개발하기 싫어서 안 된다고 말하는 게 아니다”
  • 많은 IT 종사자들이 안 된다고 말하는 개발자로 인해 협업에 어려움을 겪는다. 우리는 IT 비전공자로서 소통을 잘하기 위해 개발자의 입장에서 많이 생각하게 됐고, 이 과정을 통해 개발자의 안 된다는 말에 담겨 있는 여러 가지 의미를 깨달았다. 이 책에는 우리의 성장 과정에서 발견한 협업 노하우들을 담아냈다.