[제로베이스]UIUX디자인스쿨 4주차_02

Chapter 7. 디자인 평가 및 테스트

7-4. 사용성 평가

 

사용성 평가란

사용자가 제품을 제작 의도에 알맞게 불편함 없이 사용할 수 있는지 확인하는 것

1. 내부 리뷰 및 UI 분석

내부 리뷰 일반적인 서비스일 경우, 내부 직원끼리 서비스 이용이 쉬운지 이해가 되는지 이야기 

UI 분석 전문가의 관점에서 UI에 대해 분석, 태스크를 수행하는 과정이 유저에게 잘 띄게 되어 있는가, 읽기 어렵지는 않는지, Accessability 확인, 전문가 평가 등

 

2. 사용자 조사 및 경쟁사 비교분석

사용자 조사 경쟁사 애플리케이션 사용자와 평소 사용하던 서비스의 불편함을 이야기 해보고 우리 서비스를 제시해서 어떻게 생각하는지 비교하는 자리 마련

Feature coverage  사용자가 원하는 기능이 다 들어있는가의 관점에서 우리의 서비스는 얼마나 포괄하고 있는가 검토

UI comparison 우리 제품과 경쟁사의 제품이 똑같은 기능을 제공하는데 서로 UI가 다를 때 사용자에게 뭐가 더 나은 결정인지 비교 분석

 

사용성 평가는 언제? 

Product Life Cycle 전반에 걸쳐 질문해보자   

Intoroduction  제품 출시 전 최종 점검 검증이 필요해!

제품 개발 완료 후 테스트 1. 인하우스 리뷰 : 구체적으로 UI 분석,  모든 Usecase가 정상적으로 동작하는지, 오류가 발생하는 부분은 없는지 - UI analysis - Senario review - Design system review - Consistency review - Performance review 2. 사용자 테스트 : 예상 사용자들을 대상으로 직접 테스트 - Usability test - In-depth interview - Open-question test 3. 전문가 리뷰 : 내부 또는 외부 UX 전문가 또는 도메인 전문가를 섭외해서 평가 의뢰(예: 금융, 증권 , 항공사 앱) - Expert review - Heuristic evaluation

Growth 성장 요인 분석 왜 잘 되지?

Maturity 업데이트 요건 파악 왜 정체 되어있지?

Decline 개선사항 도출 뭐가 문제지?

 

+ 새로운 VOC(Voice of Customers) 유입되었을 때

+ 업테이트 하기 전/후 비교분석을 위해 

+ 가설 검증을 위해 어떤 오류가 발견됐을 때 이렇게 하면 해결할 수 있겠다!하는 가설 등

+ 오류가 발견되었을 때 어디서 유발되었는지 알아보기 위해 등

+ 트래픽이 꾸준히 떨어지는 구간이 발견되었을 때 등 사용자의 이상사용 행동 분석을 위해 

+ 성능 개선을 위해

+ 문제정의 원인파악 등

 

사용성 평가 프로세스 

1. Research 

Research point : Happy Path Comparison

🤓 Happy Path? UI제작자의 관점으로 특정 태스크를 수행하기 위해 설계한 최적의 루트

💡우리가 기대하는 Happy Path보다 사용자의 실제 수행 단계가 많을 때, 왜 바로가기 버튼을 인지하지 못했을까? 왜 불필요한 스크롤을 했을까? 왜 불필요한 루트로 이동했을까?와 같이 분석을 해봐야 한다. 어떻게 UI를 변경해야 우리의 Happy Path대로 사용할 수 있을까?

 

Research point : Action time > Problematic UI 요소 도출, 또는 가설 수립

우리가 생각했던 태스크 수행시간과 실제 사용자가 소모한 시간에 차이가 발생할 때 페이지 단위로 사용자의 소요시간과 행동 기술

✏️Time(nn:nn:nn-nn:nn:nn / Duration : nn Sec.), User actions

 

Research point : Informative components

과업 수행을 위해 도움이 되는 기능을 잘 제공하고 있는지, 우리가 제공하는 버튼이 사용자가 이해하기 쉬운지 등

 

Research point : Problem solve

문제 발생 시 해결할 수 있도록 도와줄 정보 또는 기능을 제공해야 함 

예) 로딩이 너무 긴데 실행취소 기능이 없다면? 오류가 나서 수행을 실패했는데 이유에 대한 설명이 메시지창에서 생략됐다면? 그 자체로 사용성을 저하함

 

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

사용자 테스트에 사용할 주요 시나리오(Use case)를 도출, 주요 시나리오는 제품의 핵심 기능 또는 자주 발생하여 대부분의 사용성에 큰 영향을 미치는 시나리오를 중심으로 선정

🤓어떤 게 Primary이고 어떤 게 Secondary? 온라인 쇼핑이라면 사용자가 회원가입하고 상품을 탐색하는 과정이 Primary, 결제과정에서 카드 결제 서비스에 관한 게 Secondary라고 볼 수 있다. 시나리오 테스트는 상황에 맞게 Secondary를 생략하는 등 유연하게 진행

 

시나리오를 기반으로 주요 관찰 포인트, 예상 문제점 등을 정의 

 

사용성 평가 실행

UT Room 또는 책상에서 사용자와 함께!

요즘에는 UT Room 세팅 비용에 비해 효과는 책상에서 사용자와 함께 진행하는 것만큼 뛰어나지 않아서 특정한 경우가 아니라면 캐주얼하게 진행하는 경향으로 넘어가고 있는 것 같다. 

 

7-5. 사용성 평가 분석

 

사용성 평가 분석 수집된 데이터를 내부적으로 보기 때문에 문서형식으로 작성

테스트 개요

출처 제로베이스 강의

누구를 대상으로 어떤 방식으로 진행됐는지, 테스트는 어떤 순서로 진행됐는지 포함되게 작성

데이터 결과를 해석할 때 사용자가 누구이기 때문에, 몇 번 테스트 했기 때문에, 어떤 순서로 테스트 했기 때문에 이런 결과가 도출됐구나 매칭시켜 해석하기 때문에 중요하다. 

 

테스트 참가자 정보

출처 제로베이스 강의

어떤 태스크를 잘하거나 못하는 이유에 대해 백그라운드를 설명할 수 있는 내용이 포함되게 작성(참가자들이 어떤 특성을 가지고 있는지, 얼마나 오래된 사용자인지, 서비스 이용 숙련도는 얼마인 사용자들인지 등)

 

주요 발견점

출처 제로베이스 강의

어떤 태스크를 주고 사용자들이 대답할 때 Think aloud를 요청해야 한다. 사용자들은 결론만 말하는 경향이 있는데 결론보다는 어떤 사고를 통해 해당 결론이 나왔는지 이해하는 게 중요하다.

 

사용자의 주요 코멘트

실제로 사용자들이 태스크를 수행하면서 한 말을 정제 없이 사용(사용자의 감정과 테스트 현장감을 느낄 수 있음)

 

설문, 만족도 평가 등의 결과(Assessment by Likert scale 5점 척도 질문)

이 태스크들이 얼마나 어려웠나요? 

이 태스크가 당신이 하려던 태스크와 얼마나 관련이 있나요? 

그 태스크를 수행하기 위한 프로토타입에 얼마나 만족했나요? 

 

개선점 정의 + 우선 순위

 

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

1. 목표

Happness 사용자의 심리적 만족

Engagement 사용자의 참여도, 관여도(사용자의 생활과 얼마나 밀접한가)

Adoption 사용자의 수렴도(사용자가 우리의 서비스를 어떻게 받아들이고 사용하고 있는가)

Retention 사용자의 서비스 사용 지속도

Task success 사용자의 목표달성도

2. 각 목표에 맞는 측정 방법

3. 각 목표에 맞는 측정 지표

💡 같은 프로젝트 팀원들이 다함께 각 목표와 시그널을 작성한다. 하나의 방향으로 모든 팀원들이 프로젝트를 수행할 수 있도록!

출처 https://clevertap.com/blog/google-heart-framework/

 

 

Lean UT plan (1 page UT planning)

전통적인 UT를 수행하는 것이 어렵기 때문에 캐주얼하게 자주 할 수 있도록 고안

Usability Test plan Dashboard * 테스트 목표 * 테스트 실행 이유 * 테스트 범위, 주제 * 참여자 정보, 기준  * 테스트에 필요한 장비 * 쿠체적인 테스트 태스크 * 역할 정의(모더레이터, 노트테이커, 관찰자 등)  * 장소와 시간 * 테스트 절차

 

게릴라 사용성 테스트

언제?

 

어떤 디자인을 통해 어떤 서비스인가가 시각적으로 보이는 시점 디자인 프로세스 안에서 확인해야할 게 있으면 언제든지 진행할 수는 있으나, 개발에서 딜리버리로 넘어가는 시점이 적당하다. 

 

그래서 어떻게?

 

가설 검증 및 주요 사용성 이슈 발견

- 아이디어의 구체적인 효용성 확인

- 가설 검증을 위한 사용자 테스트

- 문제 도출을 위한 사용자 테스트

- 사용자 아이디어, 피드백 수집

 

준비는 가볍게

데이터 신뢰성을 위한 일반적인 사용자 조사를 설계할 떄처럼 할 필요는 없음. 게릴라 테스트의 핵심은 '빨리 확인하기'이므로 최소한의 준비(테스트 범위, 테스트 시간, 주요 질문) 만 끝내고 바로 필드로 가야 함

 

E2E는 안 됨

E2E(End to End 제품 사용 시나리오의 처음부터 끝가지) 테스트는 5-10분 안에 끝내야하는 게릴라 테스트의 성격과 맞지 않음

확인하고자 하는 구체적인 시나리오를 통해서 집중적으로 테스트 해야함

 

(가급적) 촬영하거나 수필 기록을 너무 열심히 하지 말 것

호손효과 Hawthorn effect(관찰되고 있다고 생각하면 평소보다 더 집중하여 좋은 결과를 내는 등 행동에 영향을 끼침)가 일어날 수 있으므로 가벼운 분위기 속에서 진행되도록 해야 함

 

참여자는 현장에서도 모집 가능

현장 모집 방식이  의외로 참가자를 찾기 어렵기 때문에  현실적으로 어렵다. 따라서 사전에 미리 모집하고 기본정보를 수집한 뒤 가볍게 테스트를 진행하는 것도 게릴라 테스트의 한 방법이 될 수 있음

 

No user screening guide

광범위한 무작위 방식의 테스트를 지향하기 때문에 사용자를 모집할 때 정말 최소한의 조건만 따진다.(예 : 모바일 app 테스트라면 조사 대상이 최소한 스마트폰만 사용하고 있으면 됨)

 

사례도 가볍게

그 장소에서 판매하는 제품을 사주거나, 여의치 않다면 기프티카드 등