디자이너 맥신, 성장일기

맥락을 이해하는 것이 협업의 핵심입니다

디자인과 개발의 협업에서 중요한 것은 단순히 피드백을 반영하는 것이 아니라, 그 피드백이 나오게 된 맥락을 정확히 파악하는 것이었습니다. 두 가지 경험을 통해 이를 깊이 깨닫게 되었습니다.

1️⃣ 유저 피드백을 그대로 받아들이면, 문제를 잘못 해결할 수 있습니다.

• 지도 화면에서 "장소 정보 섹션이 답답하다"는 피드백을 받았습니다.
• 처음에는 단순히 크기를 키워야 한다고 생각했지만, 피드백의 배경을 살펴보니 유저가 바텀 시트를 조절할 수 없어 답답함을 느꼈다는 점이 핵심이었습니다.
• 이에 따라 단순히 UI 크기를 조정하는 것이 아니라, 바텀 시트를 자유롭게 조절할 수 있도록 변경하여 문제를 해결했습니다.

2️⃣ 협업에서는 의견보다 맥락을 먼저 이해하는 것이 중요합니다.

• 개발자 한 분이 앱 버전 관리를 별도 섹션으로 만들어야 한다고 강하게 주장하셨습니다.
• 처음에는 일반적인 방식과 다르다고 생각했지만, 왜 그런 의견을 주셨는지 여쭈어보았습니다.
• 개발자께서는 유저가 업데이트를 확실히 인지할 수 있어야 한다는 점을 고려하신 것이었습니다.
• 이에 따라 별도 섹션을 추가하는 대신, 설정 화면의 공지사항 섹션에서 업데이트 정보를 제공하는 방식으로 해결했습니다.

💡 이후로는 피드백을 받을 때마다 ‘이것이 진짜 문제인가?’를 먼저 고민하는 습관을 갖게 되었습니다.
맥락을 이해하는 것이야말로 더 나은 UX 디자인과 원활한 협업을 위한 핵심 요소임을 배운 경험이었습니다.

휴리스틱 평가(Heuristic Evaluation) :
전문가가 인터페이스를 검토하여 사용자 인터페이스의 문제점을 발견하는 방법

• 사용성 테스트와는 달리 유저를 대상으로 하지 않고, 디자이너나 사용자 경험 전문가가 특정 휴리스틱을 기반으로 평가한다.
• 디자인 초기 단계에서 비교적 쉽고 빠르게 적용해볼 수 있다는 장점이 있다.
• 전문가 중심의 평가이기 때문에 실제 유저의 경험을 완벽하게 대변하지는 못한다는 단점이 있다.

제이콥 닐슨의 10가지 휴리스틱 평가 항목

휴리스틱 평가 중 닐슨 노먼 그룹의 제이콥 닐슨이 1994년 개정한 10가지 휴리스틱 평가(10 Usability Heuristics)가 제일 대중적으로 활용되고 있다.

✅ 시스템 상태 가시성 Visibility of System Status

유저가 현재 무엇을 하고 있는지 정확한 상태를 보여주고 있는가?
예시) 텍스트 필드의 Focused 상태

✅ 시스템과 실제 세상 매칭 Match Between System & Real World

사용되고 있는 아이콘, 문구, 메뉴명이 실제 생활에서도 사용되고 있는 것으로 제공되고 있는가?
예시) 친숙한 메타포의 아이콘과 메뉴명

✅ 유저의 선택권 및 자유도 User Control and Freedom
유저가 서비스를 자유롭게 조작할 수 있는가? 예시) 실행 취소 기능

✅ 일관성과 규정 Consistency and Standards

여러 개의 화면에서도 일관성있게 제공하고 있는가?
예시) 일관성을 유지하는 우버의 디자인 시스템

✅ 에러 방지 Error Prevention

사용하면서 실수를 최대한 하지 않도록 하고 있는가?
예시) 명확한 터치 영역

✅  기억보다는 인지 Recognition Rather Than Recall

서비스를 사용할 때 학습을 하거나 별도의 기억을 하지 않아도 직관적으로 사용할 수 있는가?
예시) 상품을 찾고 장바구니에 담는 과정

✅ 유연성과 효율성 Flexibility and Efficiency of Use

서비스 대상 모두가 사용할 수 있게 제공되고 있는가?
예시 ) 스포티파이의 이퀄라이저 개인화 및 자동차 모드

✅  심미적이고 미니멀한 디자인 Aesthetic and Minimalist Design

최소한의 디자인을 통해 심미성을 잘 느낄 수 있게 제공되고 있는가?
예시 ) 최소한의 디자인 요소로 정보를 제공하는 에어비앤비 숙소 리스트 화면

✅ 유저가 에러를 전달할 때 상황, 이유, 해결책을 말하기 Help Users Recognize, Diagnose, and Recover from Errors

에러가 발생했을 때, 유저가 잘 인지하고 스스로 해결할 수 있게 도와주고 있는가?
예시 ) 회원가입 시 비밀번호 설정 가이드 문구

✅ 문제 해결과 문서화 Help and Documentation

유저에게 충분한 도움말을 제공하고 있는가?
예시 ) 고객센터의 FAQ

1) 사용성 테스트 결과 정리하기

✅ 문제점 도출 → 원인 도출 → 개선 방향 도출을 통해 결과를 정리한다.

결과를 정리할 때는 "문제는 그래서 어떤 것이고 그 원인이 무엇인데 개선을 어떻게 하면 좋을 것 같아." 이런 식으로 정리를 하면 된다. 문제점을 도출할 때는 진행자와 관찰자들이 남긴 기록들을 종합해서 문제점을 파악할 수 있다. 그 내용은 참가자가 어떤 생각을 했고, 어떤 행동을 했다. 이걸 종합해보면 자연스럽게 문제점이 파악될 수 있다. 

• 문제점 도출
  • 참가자의 생각과 행동에 대한 기록을 종합하여 문제점을 파악한다.
  • 진행자와 관찰자의 기록을 종합하여 문제점을 파악한다.
• 원인 도출
  • 유저가 예상하는 경험과 실제 경험이 어떻게 달랐는지 확인한다.
  • 유저가 이해하고 기대하는 내용과 실제가 어떻게 달랐는지 확인한다.
• 개선 방향 도출
  • 테스크별로 개선이 필요한 부분을 리스트업한다.
  • 정보 구조 관점에서 개선이 필요한 부분을 리스트업한다. (구조적으로 개선이 필요할 때는 해당 페이지만 개선해서 끝나는 문제가 아닐 수도 있어서 전반적인 개선이 필요하다.. 그런 부분이 있다면 리스트업을 해 두면 된다.)
    
    
    

2) 우선순위 논의 TIP

✅ 사용성 테스트에서 유저의 이용 만족도와 행동 데이터를 수집하여 우선순위 논의 시 의사 결정 근거로 활용하기도 한다.

★ 테스크 수행 후 참가자의 이용 만족도를 측정.
전체 테스크 중 이용 만족도가 높은 경우와 낮은 경우를 파악할 수 있다.

적용 예시 ) 
테스크 수행의 난이도는 어땠나요? 그리고 그 이유를 알려주세요.
(진짜 설문에서 테스크라는 단어는 참여자 입장에서 좀 애매할 수 있다. 조금 풀어서 작성하자.)
① 매우 쉬웠다 ② 쉬웠다 ③ 보통이다 ④ 어려웠다 ⑤ 매우 어려웠다

★ 참가자의 테스크 성공/실패 여부를 측정.
특정 테스크가 유독 실패 비율이 높다면 이용에 (크리티컬한) 불편함이 있다고 볼 수 있다.

적용 예시 ) 
참가자가 테스크를 수행하는 과정을 진행자 혹은 관찰자가 관찰하면서 테스크 성공/실패 여부에 따라 점수를 부여한다.
점수 산정 기준은 성공(S), 부분 성공(P1, P2), 실패(F)로 정의할 수 있다.

P = PASS, F = FAIL

★ 참가자가 테스크를 쉽게 달성할 수 있었는지를 측정.
이 때 참가자의 이동 동선을 살펴보면 어떤 장애 요인이 있었는지 원인을 파악할 수 있다.

적용 예시 ) 

과제별 평균 소요 시간

• 소요 시간 측정 시 테스크 간에는 목표하는 바가 다르기 때문에 상호 비교하지 않아요.
• Think Aloud를 진행하거나 사후 인터뷰를 진행한 시간은 제외하고 측정해요.

페이지 이동 횟수

• 페이지 수 측정 공식 = 예상 경로 페이지 수 / 이동한 전체 페이지 수
• 예상 경로 페이지보다 더 많은 페이지를 이동하거나 페이지를 여러 번 방문했다면 장애 요인을 확인해봐야 해요. 

클릭 및 커서 횟수

• 메뉴명이 명확하지 않으면 사용자가 클릭 후 되돌아가거나 커서를 대었다가 클릭하지 않는 행위를 반복할 수 있어요.
• 참가자가 원하는 메뉴를 찾기 어려웠다는 의미로, 메뉴 개선을 고려할 수 있어요. 

이동 동선

• 참가자가 클릭하여 이동한 경로, 즉 화면을 의미해요.
• 참가자 대부분이 주로 이용하는 이동 동선을 분석하여 주요 장애 요인을 한 눈에 파악할 수 있어요.
• 개별 참가자가 예상 동선에서 벗어난 경우에는 그 원인이 무엇이고, 어떻게 대처하는 지 살펴볼 수 있어요. 

사용성 테스트 결과 공유 TIP
팀에 공유 시 사용성 테스트 결과를 문서로만 공유하는 것보다
실제 참가자 영상을 함께 공유하는 것이 더 효과적이다.

사용성 테스트 실행 과정 :
사용성 테스트는 총 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년 차 때부터 했다. 하도 단련되어서 이제는 '이것밖에 안 하나? 좀 더 세게 나와도 될 것 같은데?'라는 여유도 생겼다. (쓴배님..멋져요...😍)

1) 유저 페르소나 이해하기

살아있는 인물로 묘사하기 때문에 유저를 집중해서 분석할 수 있고, 현실적이고 와닿는 내용들로 팀원들과 공감대를 형성할 수 있다.

• 유저 페르소나란, 특정 유저 타입을 대표하는 가상의 인물을 뜻함.
• 유저 페르소나를 작성하는 특정 단계는 정해져 있지 않으며, 작성한 후에도 내용은 시간이 지남에 따라 변할 수 있다.

허울 뿐인 유저 페르소나가 되어버리는 것을 경계해야 한다.

• 실제 사람으로 느껴지도록 묘사해야 한다.
• 대부분의 유저를 대표할 수 있어야 한다.
• 여러 유저 페르소나가 있다면 각각이 명확하게 구분되어야 한다.
• 의사결정에 영향을 줄 수 있는 인사이트가 있어야 한다.

2) 유저 페르소나 작성하기

대표적인 유저 페르소나 구성 요소로는 이름, 주요 인적 사항, 니즈, 페인 포인트, 기술 친숙도, 관심있는 브랜드 등이 있다.

꼭 모든 요소를 담을 필요는 없다.
어떻게 하면 팀원들과 쉽게 커뮤니케이션할 수 있을지 고려하여 정하면 된다.

2) 유저 페르소나 예시

홈트레이닝 서비스를 사용하는 30대 여성을 기준으로 유저 페르소나

✅ 주요 인적사항과 라이프 스타일 :
4세 딸을 육아하는 30대 워킹맘으로, 평소 주 2회 필라테스 수업을 들으며 집에서 홈트를 해요.

✅ 니즈 :
운동 초보자로서 난이도를 알맞게 조절하여 짬짬이 운동을 하고, 운동을 통해 성취감을 느끼고 싶어한다.

✅ 페인 포인트 :
바쁜 육아와 업무로 항상 시간이 부족하다. 고난이도 운동이나 복잡한 운동 동작을 소화하기엔 부담스럽다.

유저 페르소나의 가장 중요한 목적은
팀원들과 공감대를 형성하고 문제의식을 공유하는 것임을 잊으면 안된다.

---

페르소나 만드는 이유가 유저 공감을 위한 것으로만 알고 있었다면 이 마지막 문구가 이해가 잘 안될 수도 있다.

기존에 우리가 쓰는 '카카오톡' 등의 슈퍼앱들은 이것 저것 하는 것이 많고 페르소나로 딱 특정지을 수 없는 평이하고 다양한 유저들이 있다. 그래서 슈퍼앱은 페르소나 보다는 기존 사용자 데이터 분석을 한다. 물론 새로운 기능을 만들게 되면 슈퍼앱도 페르소나 만드겠지만 사용자 데이터 분석에 더 비중을 둘 수 있다.

페르소나를 만드는 경우

페르소나를 만드는 경우는 보통 데이터가 없는 새 제품을 만들고, 새로운 기능을 만들 때다. 사용자 데이터가 없는 상태에서는 페르소나가 중요한 데이터가 된다. 만약 메디컬 의사들만 또는 마라토너들만 쓰는 제품을 만들게 되었다고 해보자. 그렇다면 그들의 특수성을 알아야 하고, 사용할 이 유저들이 어떤 사람인지에 대한 이해도가 제품을 만드는 사람들끼리 함께 얼라인 되어야 한다.

페르소나의 쓰임새

팀회의 때 의견이 다를 때가 많다. 사용자입장에서 생각한다고 하지만 결국 주관적인 생각일 수 있기 때문. 근데 여기서 페르소나를 정의하게 되면 팀원이 모두 페르소나의 입장에서 얘기하고 유대감 공감대가 생긴다.

페르소나가 여럿일 수 있다. 사용자가 하나의 스타일은 아닐테니 2,3명은 될 수 있음. 하지만 회의할 때 1명의 페르소나 기준으로 얘기하자. 2번째면 2번째 기준으로 얘기하고, 그 다음 페르소나 기준으로 도 얘기하고 이런식으로.

제품팀 : 제품을 만들기 위해 각자 다른 전문적인 능력을 갖춘 사람들이 모인 팀

• 제품팀을 구성하는 데에는 다양한 방법이 있다.
• 제품팀을 구성하는 최소 조건 : 보통 1명의 제품관리자 (PO나 PM), 1명의 디자이너, 2명의 엔지니어
• 그 외, 회사에 따라 제품팀에 데이터 애널리스트, 마케터, BO(Business Operator) 등이 포함될 수 있어요.

스타트업에서는 목적조직과 기능조직이 교차하는 매트릭스 조직으로 팀을 구성.

👉 목적조직 : 특정한 목적을 달성하기 위해 여러 직무의 사람들이 모인 팀

예를 들어, 핀테크 회사라면 도메인별로 대출팀, 카드팀, 예/적금팀으로 나뉠 수 있음

• 일반적으로 제품팀이라고 하면 이 목적조직을 의미.
• 목적조직은 주로 스쿼드나 사일로라고 불림.
• 목적조직은 제품의 목표를 달성하기 위해 다양한 직무의 사람이 모여있는 팀이기 때문에 속도가 빠르고 효율적.

 👉 기능조직 : 유사한 직무끼리 구성된 팀 (예  - 기획팀, 디자인팀, 개발팀 등)

• 기능조직은 주로 챕터라고 불림.
• 기능조직은 비슷한 일을 하는 사람들끼리 모여있기 때문에 전문 분야에 대해 깊게 논의하고 서로의 발전을 도울 수 있음.

👉 매트릭스 조직 : 기능조직과 목적조직이 교차된 형태로 소속된 구성
예를 들어, 프로덕트 디자이너는 기능조직인 디자인팀에 속하면서 동시에 목적조직인 스쿼드에 속할 수 있음.

• 일반적으로 많은 스타트업이 이 방식으로 일함.
• 팀의 규모는 회사마다 다를 수 있지만 아마존의 창업자 제프 베조스는 최대 16명을 넘지 않는 것을 추천.

💡 피자 두 판의 법칙
신속하고 효율적으로 운용할 수 있도록 팀원을 피자 두 판으로 식사를 해결할 수 있는 수 이내로 유지하라는 원칙

→ 나 처럼 식성좋은 사람들을 고려해서 이름을 세 판의 법칙으로 바꾸었음 좋겠다.