디자이너 샤론, 성장일기

요즘 한창 일본어 공부 중이다.
JLPT 시험을 보게 되어 단어를 외우려고 다운로드한 앱.
회독 JLPT

앱을 사용할 때마다
이렇게 팝업 문구가 뜨는데
유저를 동기부여 하는 여러 문장들이 돌아가며 나온다.

오케이.
여기까지 좋다.
하지만 유저인 내 마음을 불쾌하게 하는 문구가 있다.

바로 이것.
이 문구만 아니었으면 벌써 리뷰를 남기고도 남았을 듯.

왜 사용하는 모든 유저를 잠재적 적으로 돌리는
유엑스 라이팅을 선택했을까.

볼 때마다 인상 찡그려진다.

가끔 UX/UI 디자이너 공고를 보면 원하는 포트폴리오 구성을 알려주는 곳들도 있다. 오늘은 유난히 세세하게 알려주는 곳을 발견해서 챗지피티에게 어떻게 준비해야 하는지 답변을 받고 따로 정리한다.
 

1. 포트폴리오 분석 및 업데이트

• 요구 사항 확인: 요청된 4개 이상의 복잡한 웹 애플리케이션 사례(SaaS, CRM, ERP, 대시보드 등)를 명확히 이해하고, 자신의 프로젝트 중 해당하는 사례를 식별하세요.
• 프로젝트 정리:
  • 프로젝트 이름과 목적
  • 사용자 문제와 요구 사항
  • 디자인 프로세스(리서치, 와이어프레임, 프로토타이핑, 피드백)
  • 결과물(화면 디자인, 사용자 피드백, 성공 지표)
• 비주얼 중심 구성: 텍스트보다 화면 설계, 대시보드, 인터페이스 구성 등을 이미지와 함께 시각적으로 정리하세요.
• NDA가 있는 경우: NDA로 인해 공유할 수 없는 작업이라면, 작업 프로세스와 유사한 허용 가능한 데이터를 사용하여 비슷한 프로젝트를 재구성할 수 있습니다. 이를 미리 정리하여 인터뷰에서 설명할 준비를 하세요.

2. 시각적 품질 개선

• 통일성 유지: 동일한 스타일과 레이아웃으로 포트폴리오를 구성해 일관성을 유지하세요.
• 강력한 비주얼: 대시보드, 그래프, 데이터 시각화 등 주요 화면을 돋보이게 보여주세요.
• 툴 활용: Figma, Adobe XD, Sketch 등을 사용하여 깔끔하게 정리된 스크린샷과 모형을 만들어 제공하세요.

3. 프로젝트 설명 준비

• 주요 성과 강조:
  • 복잡한 구조를 어떻게 단순화했는지.
  • 사용자 경험(UX)을 어떻게 개선했는지.
  • 비즈니스 문제를 해결한 디자인 사례.
• 숫자와 데이터: 클릭율 향상, 사용자 유지율 증가, 작업 시간 단축 등의 데이터로 성과를 입증하세요.

4. NDA 프로젝트 공유 방법

• 인터뷰 중 시연 준비: NDA가 있는 경우 인터뷰에서만 공유 가능한 프로젝트를 시연하기 위해 준비하세요.
  • 화면을 설명할 수 있는 간결한 스크립트를 만들어 두세요.
• 모의 인터뷰: 친구나 동료와 함께 인터뷰 시나리오를 연습하며 설명을 매끄럽게 연습하세요.

5. 추가 자료 준비

• 웹 애플리케이션 관련 사례 부족 시:
  • 가상 프로젝트를 준비하세요. 예를 들어, 대시보드 디자인 리디자인 프로젝트를 생성해 실제 프로젝트처럼 포트폴리오에 추가하세요.
  • 이전 작업과 유사한 SaaS, CRM, ERP 등을 빠르게 이해하고 응용한 프로젝트를 준비하세요.
• 지원 회사와 관련된 산업 분석: 회사가 SaaS나 CRM에 어떻게 기여하는지 이해하고 관련 포트폴리오에 연결하세요.

6. 전달 방식

• 온라인 포트폴리오: Behance, Dribbble, 개인 웹사이트 등에서 한눈에 볼 수 있도록 포트폴리오를 업로드하세요.
• PDF 버전: 필요시 이메일로 쉽게 전달할 수 있도록 PDF 포트폴리오도 준비하세요.

예상 질문 대비:

1. 이 디자인에서 가장 어려운 점은 무엇이었나요?
2. 사용자의 피드백을 반영한 사례는 무엇인가요?
3. 복잡한 데이터 시각화를 간단히 만든 경험이 있나요?

용어 정리 & 포트폴리오 준비 방법

1. SaaS (Software as a Service)

• 뜻: 클라우드 기반 소프트웨어를 인터넷을 통해 제공하는 서비스.
• 예: Google Workspace(Gmail, Docs), Slack, Dropbox.
• 특징:
  • 설치가 필요 없고, 인터넷 브라우저에서 실행.
  • 사용자는 구독 형태로 서비스 비용을 지불.
  • 종종 복잡한 인터페이스(여러 사용자 유형과 데이터를 처리).

2. CRM (Customer Relationship Management)

• 뜻: 고객 관계 관리 소프트웨어.
• 예: Salesforce, HubSpot CRM, Zoho CRM.
• 목적:
  • 고객 데이터 관리(연락처, 구매 기록).
  • 고객과의 커뮤니케이션 개선.
  • 영업, 마케팅, 고객 지원 프로세스를 통합.
• 디자인 측면: 복잡한 대시보드, 데이터 입력/조회 화면, 워크플로 관리.

3. ERP (Enterprise Resource Planning)

• 뜻: 기업 자원 관리 소프트웨어.
• 예: SAP, Oracle ERP, Microsoft Dynamics.
• 목적:
  • 기업 내부의 다양한 부서(재무, 인사, 제조, 공급망 등)를 통합 관리.
  • 운영 효율성과 데이터 가시성 향상.
• 디자인 측면: 대규모 데이터 시각화, 여러 부서를 위한 사용자 정의 가능 화면.

4. 대시보드 (Dashboard)

• 뜻: 주요 데이터와 정보를 한 화면에서 시각적으로 보여주는 인터페이스.
• 예: Google Analytics 대시보드, 프로젝트 관리 도구(Jira, Trello).
• 목적:
  • 데이터를 분석하고 의사결정을 지원.
  • 사용자에게 실시간 정보 제공(예: 매출, 사용자 활동, 프로젝트 상태).
• 디자인 측면: 그래프, 차트, 테이블, 필터 기능 포함.

어떻게 준비할 것인가?

이 용어들은 복잡한 비즈니스 소프트웨어의 종류 또는 핵심 구성 요소를 나타내고 있다. 각각의 소프트웨어는 다양한 사용자 유형, 복잡한 데이터 처리, 그리고 효율적이고 직관적인 UX/UI 디자인을 요구한다. 포트폴리오를 준비할 때 이러한 소프트웨어 유형에 맞춘 사례를 포함하면 효과적으로 어필할 수 있을 것이다.

말이라는 것이 참 중요한 것 같다.
지난 한 해 동안 내 가능성에 부정적인 대표에게 가스라이팅을 제대로 당했다. 주변에서 디자인 너무 못한다고 나를 자르라고 난리날 정도면 나는 진짜 형편없는 디자이너인건가. 디자인을 그만둬야 하나 싶었다. 그런데 퇴사 후 이 부트캠프에 참여하면서 바닥까지 내려갔던 자존감이 올라갔다. 오래된 경력의 디자이너 분들이 상주튜터로 계시는데 내 작업물을 보시고는 원래 디자인을 한 것을 눈치채시는 분도 계시고, 과제 피드백에 카카오 페이와 네이버 프로덕트 디자이너셨던 튜터님이 칭찬을 해주셔서 완전 힐링되었다.

이번 주는 UX 기획 리서치 수업과 관련하여 스파르타 부트캠프 랜딩페이지의 개선을 위한 과제를 했다. 덕분에 사용성 테스트를 처음으로 해봤다. 어떻게 진행할 지 계획하고, 튜터님께 조언을 얻은 뒤, 바로 과제를 받은 당일에 동네에 있는 대학생 참여자들에게 시나리오를 설명하고 테스크를 전달했다. 참여자들 마다 랜딩페이지와 인터렉션하는 모습들 다 제각각이라 그 부분이 흥미로웠다. 그러면서도 해당 페이지를 볼 때 중요하게 생각하는 부분이 어느 정도 비슷한 점도 신기했다. 이 과제를 통해서 알게 된 (UX 디자이너로서의) 장점은 추진력이 있고, 처음 보는 사람도 마치 원래 알고 있었던 사람 마냥 친근하게 잘 다가가는 성격이라는 점이었다. 각설하고, 테스트에서 바로 인사이트가 나왔고 그동안 배운 디자인 이론을 바탕으로 근거 있는 디자인 솔루션을 도출해낼 수 있었다. 무언가 드라마틱한 변화는 아니었음에도 TO BE 디자인을 스크롤 할 때 확실한 변화와 개선을 느낄 수 있었다. 내 생각과 짐작이 아닌 참여자들을 테스트 하여 나온 결과물이라 아주 만족스러웠다. 물론 튜터님께 어떤 피드백을 받게될지는 모르겠지만... 씨익...

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자 입장에서 질문 관련 피드백을 받을 수 있다.
• 테스트 공간에서의 화면과 오디오가 관찰 공간에 실시간으로 잘 송출되는지 체크한다.
• 사용성 테스트 총 소요 시간은 적절한지 체크한다.
• 무의식적으로 전문 용어를 사용하지 않는지 피드백을 받아보도록 한다.

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

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

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

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

목차
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 예시 :
화해 쇼핑의 검색 기능을 도식화한 예시