[기초/이론] 디자인 평가 및 테스트

이 글은 제로베이스 UIUX 강의를 참고하여 정리한 글입니다. 오타나, 잘못된 내용이 있으면 언제든지 알려주세요! 감사합니다.😊

 

프로토타입 Prototype

Prototype: 미리 만들어 보는 것

말은 지나가고 망각하기 쉽기 때문에 시각적인 자료로 만들어서 더욱 효율적인 소통을 할 수 있다.

 

프로토타입은 왜 필요할까

Test early, Test often!!

→ 가능한 빨리 검증해서 빨리 문제점을 도출해서 개선을 한다.

 

Lo-fi prototype

No time + Early stage = Concept evaluation

• 시간이 없거나 돈이 없다면 기본적인 틀만 만든다.
• 상상을 현실로
• 저렴한 제작비용
• 손 쉬운 수정

 

Hi-fi prototype

Time + (Almost) Final stage = Realistic usability

• 실제로 사용자가 보는 것처럼 진짜처럼 만든다.
• 현실적인 디자인 검증
• 인터랙션 개발 리뷰
• 시나리오 검증

 

프로토타입의 제작과 활용

1. 제작 목적 정하기
2. 제작 범위 정하기 - 제작 범위는 시나리오를 바탕으로
3. 제작 Tool 정하기
4. 프로토타입 만들기
5. 프로토타입 공유하기
6. 피드백 수집

 

프로토타입을 통해

• 사용자 테스트
• 다양한 피드백 수집
• 개선사항 도출

 

MVP (Minimum Viable Product)

 

MVP(Minimum Viable Product) = 최소 기능의 제품

MVP는 최소한의 노력을 최대한의 유의미한 사용자 피드백을 얻기 위한 최소한의 제품.

최소한 사용자에게 무슨 의미를 전달하고 싶은지 보여줘야한다.

 

MVP의 개념

 

MVP Process

MVP 디자인 프로세스를 사용한다면 초반에 빠르게 개선할 사항을 찾을 수 있다.

 

MVP Step 1. 핵심 기능 정의

MVP Step 2. 제품 개발

• 또는 데모 비디오나 컨셉 시나리오 만으로도 가능함.

MVP Step 3. 검증, 인사이트 도출

• In-depth interview
• FGI
• Concept studies
• Desirability studies

 

사용성 평가

사용성 평가란 사용자가 제품을 제작 의도에 알맞게 불편함 없이 사용할 수 있는지 확인하는 것. 말 그대로 실제 사용자가 사용하는 것을 평가하는 것이다.

• 내부 사용자 테스트 및 UI 분석
• 사용자 조사 및 경쟁사 비교분석
• Feature coverage: 사용자가 원하는 기능이 들어가 있는가?
• UI comparison: 어떤 UI가 사용자 입장에서 좋을까?

사용성 평가는 언제? (from Product Life Cycle)

모든 때에 가능하다.

• 새로운 VOC가 유입되었을 때, 업데이트 하기 전/후, 가설 검증을 위해, 오류가 발견되었을 때, 트래픽이 꾸준히 떨어지는 구간이 발견 되었을 때, 성능 개선을 위해, 문제점의 원인파악 등등

 

출시 전 사용성 평가 Post Usability test

• 인하우스 리뷰: 우선 자체적으로 UI를 분석해보자. 모든 Usecase가 정상적으로 동작하는지, 오류가 발생하는 부분은 없는지!
  • UI analysis
  • Scenario review
  • Design system review
  • Consistency review
  • Performance review
• 사용자 테스트: 예상 사용자들을 대상으로 직접 테스트 해보자!
  • Usability test
  • In-depth interview
  • Open-question test
• 전문가 리뷰: 내부 또는 외부 UX전문가 또는 도메인 전문가를 섭외해서 평가를 의뢰하자!
  • Expert review
  • Heuristic evaluation

 

Research point: Happy Path Comparison

• 왜 바로바기 버튼을 인지하지 못했을까
• 왜 불필요한 스크롤을 했을까
• 왜 불필요한 루트로 이동했을까

 

Research point: Action time

• 우리가 기대했던 테스크 수행시간 → 실제 사용자가 소요한 시간이 더 많음
• 페이지 단위로 사용자의 소요시간과 행동을 기술
• 대체 어느 부분이 사용자의 시간을 더 오래 걸리게 했는가?
• 피츠의 법칙 Fitts’ law : HCI분야에서 인간의 행동에 대해 속도와 정확성의 관계를 설명하는 기본 법칙 (버튼의 거리가 멀 수록 오래 걸린다. 등등)

 

Research point: Informative components

• 과업 수행에 도움을 주는 기능이 적절하게 있는지
• 이해하기 힘든 정보에 대한 부가 설명

 

Research point: Problem solve

• 문제 발생 시 해결할 수 있도록 도와줄 정보 또는 기능을 제공해야 함
• 예) 취소 버튼이 없는 로딩 창에서 에러로 인해 무한 로딩이 된다면… , 결제에 실패했는데 무엇때문에 실패했는지 설명이 없다면…

 

주요 테스트 시나리오 정의 Primary use case

사용자 테스트에 사용할 주요 시나리오(Use case)를 도출.

이때 주요 시나리오는 제품의 핵심 기능 또는 자주 발생하여 대부분의 사용성에 큰 영향을 미치는 시나리오를 중심으로 선정.

• 시나리오를 기반으로 주요 관찰 포인트를 정의하고 예상 문제점 등을 정의할 수 있다.

 

사용성 평가 분석

사용성 평가 보고서에 포함되어야 하는 것

• 테스트 개요: 대상, 방식, 순서 등 summary
• 테스트 참가자 정보: 숫자, 참가자 특징
• 주요 발견점: Task에 대한 사용자의 생각, 해석
• 사용자의 주요 코멘트
• 설문, 만족도 평가 등의 결과
• 개선점 정의 + 우선순위

Google HEART metrics

구글 리서치팀에서 만든 사용자 경험의 질을 평가하기 위한 프레임워크

• Happiness: 사용자의 심리적 만족
• Engagement: 사용자의 참여도, 관여도
• Adoption: 사용자의 수렴도
• Retention: 사용자의 서비스 사용 지속도
• Task success: 사용자의 목표 달성도

 

Lean UT plan: 1 page UT planning

 

게릴라 사용성 테스트

사용자가 있는 곳으로 가서 즉석으로 사용성 테스트

• 언제하는게 좋을까? → 가설 검증 및 주요 사용성 이슈 발견할 때
• 준비는 가볍게: 데이터 신뢰성을 위한 일반적인 사용자 조사를 설계할 때처럼 할 필요는 없음. 겔릴라 테스트의 핵심은 ‘빨리 확인하기’이므로 최소한의 준비(테스트 범위, 테스트 시간, 주요 질문)만 끝내고 바로 필드로 나가야 함.
• E2E test는 안됨: E2E(End to End 제품 사용 시나리오의 처음부터 끝까지) 테스트는 5-10분안에 끝내야하는 게릴라 테스트의 성격과 맞지 않음. 확인하고자 하는 구체적인 시나리오를 뽑아서 집중적으로 테스트 해야함.
• (가급적) 촬영하거나 수필 기록을 너무 열심히 하지 말 것: 호손효과 Hawthorne effect(관찰되고 있다고 생각하면 평소보다 더 집중하여 좋은 결과를 내는 등 행동에 영향을 끼침)가 일어날 수 있으므로 가벼운 분위기 속에서 진행되도록 해야함.
• 참여자는 현장에서도 모집가능: 전통적인 느낌의 게릴라 테스트는 정말 현장에 가서 즉석으로 사용자를 모집하는 것이지만 실제로는 꽤 현실적인 어려움이 있다. (의외로 참여자를 찾기 쉽지 않음) 따라서 사전에 미리 모집하고 기본정보를 수집한 뒤 가볍게 테스트를 진행하는 것도 게릴라 테스트의 한 방법이 될 수 있음.
• No user screening guide: 게릴라 테스트는 광범위한 무작위 방식의 테스트를 지향하기 때문에 사용자를 모집할 때 정말 최소한의 조건만 따지게 된다. (예: 모바일 app 테스트라면 사용자가 최소한 스마트폰은 사용하고 있어야 함.)
• 사례도 가볍게: 그 장소에서 판매하는 제품을 사주거나, 이게 여의치 않다면 기프트카드도 좋은 아이디어 일 수 있다.