UI 사용자 Feedback 수렴을 위한 사용성 테스트 Day 1 A to Z

2019. 11. 14. 22:06ㆍConference

안녕하세요 Terenz 입니다:)

 

지난 11월 11일~12일 2일간 동의대학교 부산IT융합부품연구소에서 주최하는 ‘UI 사용자 Feedback 수렴을 위한 사용성 테스트’ 교육에 참석하게 되었습니다.

 

교육은 테스트 프로세스 티큐컨설팅 이현주 대표님께서 사용자 경험을 이해할 수 있는 방법 중 하나인 ‘사용성 테스트’를 소개하며, 사용자 니즈에 부합하는 제품을 어떻게 제작하고 접근해야 할지에 대한 노하우를 공유해주셨습니다.

 

Agenda

· 사용자 중심 디자인과 사용성

· 사용성 테스트 개요

· 사용성 테스트 계획 및 준비

· 사용성 테스트 설계
· 실습1

 

 

《사용자 중심 디자인과 사용성》

 

■ 사용자 경험(User Experience, UX) 은 사용자가 어떤 시스템, 제품, 서비스를 이용하면서 느끼고 생각하게 되는 총체적 경험으로, 물건을 살 때부터 검색을 할 때부터 행위가 끝난 후까지 모두 포함되어 나타납니다. 사용자 경험은 단순히 편리하게만 해주는 것이 아니라 사용자의 심리까지 파악해야합니다.

 

■ 사용성(Usability)은 특정 사용자가 주어진 환경에서 특정 목적을 달성하는 효과성, 효율성, 만족도로 효율성이 떨어지면 사용성이 떨어지는 개념입니다.

 

  •  사용성 만족도(User Satisfaction)는 질문지를 통해 물어볼 수 있습니다. (사람들은 대부분 긍정적인 대답을 함. 불편한 말을 하는걸 꺼려함). 이러한 특징을 고려하여 좋은 질문을 만들어야 정확한 피드백을 얻을 수 있습니다.

 

  UX Usability
From where Expected and actual context of use While performing tasks
Measure User’s perception and response relevant to usage Effectiveness, efficiency, satisfaction

 

■ 사용자 중심 디자인(User Centered Design, UCD)은 사용자를 위해 연구하는 일련의 과정으로 시스템을 디자인 하는 ‘개발’을 말합니다.

  • UCD 과정:

   - 사용하는 현장은 어디인지

   - 페르소나 분석: 우리 제품을 사용하는 핵심 사용자의 연령대, 성별, 결혼유무 등 사용자의 스펙 분석

   - 공통적으로 사용하는 메이저 제품들의 비슷한 패턴을 분석+우리 제품만의 특별한 요소를 추가할 것

   - 사용자의 여러가지 시나리오를 예상해서 분석(유입되는 경로가 다양함)

   - 피드백을 요구할 때 워딩이 아니라 그림(시각적으로)으로 디자인 프로토타입을 만들어볼 것

 

핵심유저의 요구사항을 분석해야하며 명확한 피드백을 위한 인터뷰 스킬이 중요합니다. 요즘의 사용자들은 존재만으로 사용하지 않습니다. 

 

《사용성 테스트 개요》

 

■ 사용성 테스트 (Usability Test)는 테스트 참여자가 제품/서비스의 목적에 맞는 Task를 수행하면서 사용성 확보 정도를 점검하는 활동입니다. 다른 사람을 100% 이해할 수 없기 때문에 사용성 테스트를 통해서 알아낼 수 있습니다. 사용성 테스트는 테스트 시점/ 수행주체로 나뉩니다.

  • 테스트시점
    - 포머티브 테스트(Formative Test): 개발 과정에 테스트(개선 목적)
    - 서머티브 테스트(Summative Test): 개발 후에 테스트(사용성의 정도를 파악하는 목적, 목표에 달성했는지 확인)

  • 수행주체
    - 사용자 테스트: 제품의 잠재 고객이 직접 테스트하는 것
    - 전문가 리뷰: 사용자 테스트와 목적은 똑같지만 테스트 방법과 비용의 차이

 

포머티브 테스트(Formative Test)

  1. 목적: 요구사항을 사용자 시나리오로 만들어서 들려주는 것, 이 프로세스가 마음에 드는지 개선시키는 것, 사용자가 얼마나 직관적으로 이해할 수 있는지 점검하는 활동
  2. 수행단계: 시각적인 프로토타입이 완료된 시점으로 사용 시나리오가 정의된 이후 단계
  3. 수행방법: 반복적인 테스트 문제점을 발견하여 해결하고. Think aloud(생각하며 말하기) 방식으로 계속해  서 질문을 통해 들어야합니다. 생각하고 정연할 시간을 주면 거짓말을 하는 경우가 많으므로 끊임없이 질문하여 진실을 듣도록 노력하고, 참여자가 어떤 flow로 움직이는지 화면상에서 어떤 flow를 기대하는지 확인합니다.
  4. 수행 공식성: 비공식적(수시로 반영을 한다)
  5. 기대효과: 제품/서비스의 흐름을 파악하는 것, 사용자가 왜 그렇게 행동했는지 정성적인 파악, 추가적인 상세작업이 진행되기 전 개선 가능

 

서머티브 테스트 (Summative Test)

  1. 목적: 목표에 달성했는지 비교, 경쟁대비 성능비교
  2. 수행단계: 알파테스트(관계자와 가까운 사용자의 테스트, 필드 테스트)/ 베타 테스트(일반 사용자)
  3. 수행방법: 효율성 효과성 만족도 측정, 에러 개수, 과제 소요시간 측정, 사용자가 어떤 테스트를 할지 너무 깊게 아는것은 좋지 않습니다.(bias 제거)
  4. 수행 공식성: 공식성
  5. 기대효과: 정량적인 데이터로 나타낼 수 있습니다.(수치적으로)

 

사용자 테스트

테스트 참여자가 상품의 존재 목적에 맞는 Task를 수행하면서 사용성 확보 여부를 판단하게 됩니다. 사용자가 정답을 찾을 수 있는 경우의 수들을 만들고 사용자에게 정답을 찾도록 수행시키고 난 후 정의된 사용성 평가 체크 리스트에 답하는 방식입니다.

  • 테스트 시기
    - 포머티브 테스트: 화면 설계시
    - 서머티브 테스트: 배포 및 오픈시점 

 

전문가 리뷰

보다 근본적이고 문제점을 파악하는데 유용합니다. 단 사용해보지 않은 인터페이스일 경우 해결방안 조언이 어려울 수 있습니다.

 

《사용성 테스트 계획 및 준비》

 

■ 사용성 테스트 계획 

  • 테스트 목표 설정
    - 테스트를 통해서 확인하고자 하는 사항 및 방향성에 대한 정의
    - 일반적인 사용성 속성(효과성, 효율성, 유용성, 만족도 등)내에서 대상 제품/서비스가 요구하는 주요 속성을 식별

  • 테스트 대상 결정
    - 사용성 검증 시기에 따라 검증 작업 대상이 달라집니다.

  포머티브 테스트 서머티브 테스트
테스트 대상

· 개발을 위해 작성된 설계문서(Wireframe)

· 개발이 완료된 제품/서비스
테스트 용이성

· 용이하지 않음

· 사용자가 설계 문서를 보고 추가적으로 상상하면서 사용상의 문제점을 파악해야함

· 용이함

· 시스템이 사용자가 조작/이용할 수 있는 수준으로 완성됨

  • 테스트 시기
    - 포머티브 테스트: 화면 설계시
    - 서머티브 테스트: 배포 및 오픈시점

  • 테스트 환경구축
    - 사용자의 평상시와 똑같은 환경으로 방해 요소들이 없도록 해야합니다. (like 미러룸)
    - 테스트 시간은 2시간 미만으로 설정해야합니다. 시간 엄수! (10개의 Task를 설정했는데 7개 밖에 못했다 하더라도 시작과 종료 시간을 맞춰야함)
    - 테스트 시간이 2시간이면 1시간 40분을 테스트하고 20분은 개발자가 궁금했던 부분들을 사용자와 함께 얘기합니다. (단, 그전에 테스트과정을 개발자가 지켜보고 있다는 것을 몰라야함)
    - 고려사항: 테스트 과정 녹화, 모더레이터(진행자)외에 서기도 있어야합니다. 서기는 사용자 관찰을 열심히 해아하고, Task를 미리 정해놓고 파일럿 해야합니다.

《사용성 테스트 설계》

■ 사용성 테스트 방법

수행 방식별은 방벙은 3가지가 있습니다.

    - 일반적 테스트 방법: Task를 수행하면서 어떤 문제점이 있는지 파악하는 방식

    - 특화된 테스트 방법: 벤치마킹의 목적으로 두 개 이상의 시스템을 놓고 비교 평가

    - 정량적 테스트 방법: 포머티브 혹은 서머티브 단계에서 5명 이상의 참여자들이 정량적인 메트릭을 기반으로 테스트 수행 

 

☞ 참여자가 많으면 좋다고 생각하지만 투자대비 극대화되는 효과 명수는 5명이 적당합니다. 시간 측정이 중요하다고 생각되면 Think aloud(생각하며 말하기) 방식을 중단해야합니다. 기존의 제품/서비스와 차별화가 없다면 Task의 만족도는 높아도 후평가는 낮을 수 있습니다. 

 

    - 정량적 테스트: 관찰자가 중요. 5명이 적당(오류가 생길 수 있으므로 +1)

    - 정성적 테스트: 2-3명. 인덱스 인터뷰

 

Tip! 사용자가 되어서 테스트를 해보면 아이디어와 기획에 대한 피드백을 얻을 수 있다.

이현주 대표님


■ 테스트 프레임워크(Test Framework)는 제품/서비스의 테스트 목표에 따라 무엇을 평가 할 것인지를 정의하는 평가 기준입니다. 평가 기준들이 구글에 기준이 많이 나와있지만 본인 회사의 가중치와 우선순위로 설정해야 합니다.

   

heuristics 경험을 통해서 알게 된 것

knowledge 지식을 통해 알게 된 것

  •  Jacob Nilsson's 10 Heuristics
    1. 시스템 가시성(Visibility of system status)
    2. 사용 환경과의 매치(Match between system and the real world)
    3. 실수 보정 편리성(User control and freedom)
    4. 일관성 표준(Consistency and standards)
    5. 에러 예방(Error Prevention)
    6. 사용을 위한 외우기 최소화(Recognition rather than recall)
    7. 사용 편의를 위한 기능(Flexibility and efficiency of use)
    8. 핵심 중심의 디자인(Aesthetic and minimalist design)
    9. 에러메시지의 활용(Help users recognize, diagnose, and recover from errors)
    10. 적절한 도움말의 활용(Help and documentation)

  •  ISO/IEC 25010
    1. 이해용이성(Appropriateness Recognization)
    2. 사용자 오류보호(User Error Protection)
    3. 학습성(Learnability)
    4. 접근성(Accessibility)
    5. 운영성(Operability)
    6. 사용자 인터페이스 미학(User Interface Aesthetics)

《실습1》

 

※ 사용성 평가요소에 해당하는 테스트 체크리스트를 작성하시오. (테스트 프레임워크)

평가요소 체크리스트
사용자 인터페이스 미학 제품의 이미지와 전체 인터페이스의 컬러감이 매칭되는지
재미적인 요소로 흥미를 유발하는지
이해 용이성 단순 명확한 아이콘과 flow로 구성되어 있는지
알기 쉬운 용어로 핵심 서비스가 노출되어 있는지
사용자 오류보호 오조작시 오류를 정정할 수 있는 도움말이 표시되는지
데이터 입력의 유효성 체크 및 오류 메시지가 표시되는지

 

'Conference' 카테고리의 다른 글

UI 사용자 Feedback 수렴을 위한 사용성 테스트 Day 2 A to Z  (0) 2019.11.15
APN Live Busan A to Z Review  (0) 2019.09.24
AWS Cloud Day in Busan A to Z Review  (0) 2019.09.17

관련글

티스토리툴바