TIL_8W1D_UX Planning and Research 4~5st Week
디자인 카타
컴포넌트란?
웹이나 앱의 화면을 구성하는 재사용 가능한 요소
사용자가 화면과 상호작용할 수 있도록 도와주는 UI요소이며, 여러 개의 컴포넌트를 조합해 UI화면 구성할 수 있음
또한, 효율적인 개발과 협업을 가능하게 하며 유지 보수를 용이하게 하는 중요한 역할
컴포넌트를 사용하면 좋은 점?
재사용성
컴포넌트를 재사용 시 매번 새롭게 UI요소를 만들 필요 없이 만들어 놓은 컴포넌트를 조합해 빠르게 개발할 수 있기 때문에 작업 시간 절약할 수 잇음
한 번 만든 컴포넌트를 여러 화면에 반복적으로 사용할 수 있어 효율성이 향상
모듈화
작은 단위로 나눌 수 있어 관리가 용이
컴포넌트를 독립적으로 개발/디자인하고 테스트할 수 있음
일관성
컴포넌트 사용 시 일관된 UI로 디자인 할 수 있어 사용자의 혼란을 줄일 수 있음
디자인 시스템과 함께 사용 시 UI의 스타일과 UX 일관되게 유지
확장성
새로운 기능 추가 및 수정 시 유연하게 확장 가능
컴포넌트를 조합해 앱을 쉽게 확장할 수 있음
유지 보수 용이
한곳에서 수정 시 모든 곳에 자동 반영 및 유지 보수가 쉬워짐
컴포넌트 이름 : 버튼 컴포넌트
컴포넌트 기능 : 버튼 컴포넌트는 사용자가 사전에 설정해 놓은 동작을 수행 시 사용하며, 사용자가 버튼 클릭 시 어떤 동작이 발생할지 직관적으로 알 수 있음
UI에서 클릭 가능한 버튼을 재사용 가능하도록 만든 독립적인 요소
컴포넌트를 통해 사용자가 할 수 있는 것 :
1. 클릭 후 동작 실행 - 사용자는 버튼을 클릭해 특정 작업을 실행할 수 있음(예 : 상품 구매, 페이지 이동, 프로필 편집 등)
2. 상태 확인 - 버튼이 활성화 되는지, 비활성화 되었는지 또는 로딩중인지 확인이 가능함
컴포넌트가 언제, 왜 사용되는지 :
사용자가 특정 작업 수행 시 : 예를 들면 로그인이나, 회원가입, 프로필 편집 등 기능을 실행 시 사용
일관된 디자인 유지 시 : 여러 페이지에서 동일 스타일과 기능 유지를 위해 재사용 가능한 버튼 컴포넌트 사용
Ux를 개선 시 : 버튼의 로딩 상태, 비활성화 상태 등 활용해 사용자가 현재 버튼을 클릭할 수 있는지, 처리중인지 알기 쉽게 함
버튼 컴포넌트는 기능과 디자인에 따라 다양한 종류로 나뉘며 각각 특정 목적과 역할을 가지는데,
1. 기본 버튼 (Button)
이름: 기본 버튼 (Primary Button, Default Button)
기능: 일반적인 클릭 이벤트를 처리하며, 가장 흔히 사용되는 버튼 유형
특징: 기본 스타일을 가지며, 주요한 작업을 수행하는 버튼에 사용됨
2. 액션 버튼 (Action Button)
이름: 액션 버튼 (Floating Action Button, FAB)
기능: 앱이나 웹 페이지에서 가장 중요한 작업을 수행하는 버튼.
특징: 원형 디자인이 많으며, 사용자 인터페이스에서 강조되는 위치에 배치됨
3. 텍스트 버튼 (Text Button)
이름: 텍스트 버튼 (Text Button, Ghost Button)
기능: 배경색 없이 텍스트만으로 클릭이 가능한 버튼.
특징: 보조적인 작업을 수행하며, 강조가 필요하지 않은 버튼에 사용됨
4. 아이콘 버튼 (Icon Button)
이름: 아이콘 버튼 (Icon Button)
기능: 아이콘만 포함된 버튼으로, 빠르고 직관적인 액션을 제공
특징: 작은 크기로 디자인되며, 시각적으로 직관적인 동작을 유도.
4st Week UX 기획 및 디자인 이해
02. UX 기획 구체화 : 유저 사용 맥락 반영
1) 유저 시나리오 (User Scenario)
제품 또는 서비스에 대한 유저 경험을 스토리텔링으로 기술하는 방법
디자인 초기 단계에서 유저에 대한 공감을 바탕으로 유저 중심 솔루션을 찾을 때 유용
유제 페르소나와 결합해 작성 시 유저 동기와 목표를 감성적으로 이해하는데 도움
유저 시나리오의 구성 요소
유저 : 유저의 페르소나
목표 : 무엇을 달성하려고 하나요?
동기 : 왜 달성하려고 하나요?
외부 요소 : 어떤 것에 영향을 받나요?(사용 상황, 사용 시간 등)
두가지 키워드로 정리하자면 스토리텔링, 감성적 이해
2) 고객 여정 지도 (Customer Journey Map)
제품 또는 서비스를 유저가 이용하는 흐름을 시각화해 분석하는 방법
타임라인에 따른 유저 여정을 시각적 표현해 특정 시점에서의 경험을 파악하고 개선점을 찾을 때 사용
전체 유저 경험을 한눈에 파악할 수 있음
고객 여정 지도의 구성 요소
Zone A : 관점
1. 유저 페르소나 : 여정을 체험하는 유저
2. 유저 시나리오 : 여정 지도가 다루는 상황 묘사, 유저의 목표와 기대치와 연결
Zone B : 경험
3. 여정 단계 : 타임라인 기반으로 분류
4. 행동 : 유저가 특정 단계에서 취하는 행동
5. 생각 : 유저의 생각, 질문, 동기, 정보에 대한 니즈
6. 감정 : 단게에 걸쳐 단일 선으로 표현
Zone C : 인사이트
7. 기회 : 유저의 경험을 어떻게 최적화할 수 있는지에 대한 인사이트
8. 담당 팀이나 부서 : 해당 인사이트를 적용해볼 수 있는 협업자 코멘트
고객 여정 지도 시각화 방법
목적 설정
어떤 유저의 여정을 시각화할 것인지 명확한 목적을 설정
유저 페르소나 정의
어떤 유저를 대상으로 할 것인지 결정
유저 페르소나별로 각각의 유저 저니맵에 나올 수 있음
유저가 여정을 통해 이루고자 하는 목표와 가지고 있는 기대를 작성
여정 단계 분류
유저가 시간의 흐름에 따라 언제 어떤 행동을 하는지 분류
터치 포인트 파악
유저가 제품 또는 서비스와 상호작용 하는 지점, 즉 터치 포인트를 파악
유저가 터치 포인트에서 어떤 페인 포인트를 가지고 있고, 어떤 감정을 느끼고, 어떤 생각을 하는지 작성
기회 파악
유저의 타임라인별에서 문제 파악 및 개선점을 찾음
두가지 키워드로 정리하자면 여정 단계, 시각화
3) 유저 스토리 (User Story)
특정 기능을 실제 개발 구현 가능한 작은 단위로 기술하는 방법
주로 애자일(Agile) 방법론에서 사용
특히 엔지니어가 개발 작업 시 기능을 이해하고 구현하는 데 유용하게 활용
문서에서 일일이 모든 내용을 정의하기에는 한계가 있기 때문에
유저 스토리를 통해 구현할 사항에 대한 구성원 간 합의를 도출
실무에서는 협업 시 유저 시나리오, 유저 저니맵보다 빈번하게 활용됨
유저 스토리의 구성 요소
As a {user} : 유저
I want {goal} : 유저가 원하는 기능 또는 행동
So that {benefit} : 이를 통해 유저가 얻을 수 있는 이득
걸킨 문법 활용하여 유저 스토리 구체화하기
걸킨 문법(Gherkin Syntax)은 유저의 행동에 중점을 맞추어 개발하는
행동 주도 개발(Behavior-Driven Development) 환경에서 널리 활용되는 특수한 문법
As a, I want, So that만으로는 기능 구현 여부를 명확히 판단하기 어려워서
테스트 케이스를 구체적으로 정의하기 위한 용도로 활용하기도 함
걸킨 문법을 활용한 유저 스토리 구체화 요소
Given {주어진 상황} : 유저에게 주어진 상황
When {조건 및 행동} : 유저의 특정 액션 또는 이벤트
Then {결과} : 특정 결과나 상태
네가지 키워드로 정리하자면 개발 구현 가능 단위, 합의 도출, 걸킨 문법, 테스트 케이스
03. UX 기획 구체화 : 논리적인 흐름 설계
1) 유저 플로우 (User Flow)
유저가 제품이나 서비스를 이용하는 과정을 유저의 행동 및 화면 간의 이동에 초점을 맞추어 시각화하는 단계
유저가 최종 목표에 도달하기 위해 서비스 내에서 어떤 경로로 이동하며, 어떤 행동을 하는지 구체화하는 도구로 활용할 수 있어요
'해피 패스’에 매몰되지 않고 다양한 경로를 고려해볼 수 있다는 장점이 있음
해피 패스(Happy Path)란?
유저가 제품이나 서비스에서 원하는 목적지까지 아무런 문제를 겪지 않고 도달했을 때의 경로
유저 플로우와 와이어프레임은 상호보완적인 도구로 활용할 수 있으며, 작업에 정해진 순서가 있는 것은 아님
유저 플로우의 구성 요소
원형 : 시작/끝
프로세스의 시작이나 끝을 표현하기 위해 사용
사각형 : 동작/프로세스
유저의 입력이나 액션을 표현하기 위해 사용
마름모 : 조건
특정한 조건이나 결정 지점을 표현하기 위해 사용하며,
여기서 유저의 행동이나 시스템의 상태에 따라 플로우가 여러 가지로 나뉠 수 있음
화살표 : 플로우의 방향
한 상태나 단계에서 다음 상태나 단계로의 흐름을 표현하기 위해 사용
핵심 키워드는 화면 간의 이동
2) 와이어프레임 (Wireframe)
화면의 레이아웃과 플로우를 단순한 선과 도형으로 설계하는 과정
로우 피델리티(Lo-fi)로 작업되어 작업자들이 부담 없이 아이디어에 자유롭게 참여하고 의사결정에 기여할 수 있도록 도와주는 도구로 활용
그래픽 요소 및 기술적인 세부사항을 배제하고 신속하게 결과물을 생성해 작업자 간 커뮤니케이션을 위한 초기 비주얼을 제공할 수 있다는 장점이 있음
변경되는 요구 사항에 대응해 빠르게 구조 검토 및 수정하기가 용이
논의의 초점이 레이아웃과 플로우에 집중되도록 최소한의 색과 디자인을 사용해 작업
와이어프레임에 화면 이동에 대한 정보를 추가했을 때는 ‘와이어 플로우(Wire Flow)’라고 부르기도 함
손으로 그린 와이어프레임
신속하게 제작하고 손쉽게 수정할 수 있음
회의 중 간단한 종이나 보드에 함께 스케치하며 아이디어를 즉각적으로 공유하고 토론하기 용이
손으로 그리는 과정 중에 아이디어를 발산하기 용이
디자인 툴로 작업합 와이어프레임
손으로 그린 와이어프레임보다 비교적 정확하고 일관된 와이어프레임을 만들 수 있음
디자인 툴로 작업할 경우 링크를 공유해 피드백을 받기 용이
물리적으로 같은 공간에 있지 않더라도 실시간으로 함께 작업하는 것이 가능해짐
핵심키워드는 로우 피델리티, 아이데이션
3) 정보 구조도 (Information Architecture)
제품이나 서비스를 구성하는 요소들의 구조를 도식화하는 것으로, 유저가 길을 잃지 않고 원하는 정보를 쉽게 찾고 작업을 완료할 수 있도록 돕는 과정
유저가 자신의 현재 위치와 다음 장소로 가기 위해 무엇을 해야할 지 인지할 수 있도록 설계할 때 활용
정보 구조가 효과적으로 설계될 경우 유저의 접근성이 향상되지만, 부적절하게 설계될 경우 유저의 이탈과 오류를 발생시킬 수 있음
상위와 하위 개념을 효과적으로 그룹핑하고 올바른 라벨링을 하는 것이 중요
정보 구조도의 기반이 되는 구성 요소
Organization : 조직 및 구성 시스템
목적 정보를 체계적으로 정리하고 구성하기
예시 웹사이트의 메뉴 계층 구조, 콘텐츠 그룹화
Labeling : 라벨링 시스템
목적 정보를 명확하고 이해하기 쉽게 표현하기
예시 메뉴 항목의 명칭, 버튼 레이블, 카테고리명
Navigation : 내비게이션 시스템
목적 유저가 정보를 찾고 이동함
예시 웹사이트의 메뉴 바, 내비게이션 바
Searching : 검색 시스템
목적 유저가 원하는 정보를 검색하여 찾기
예시 웹사이트의 검색 기능, 검색 결과 페이지, 필터 및 정렬 옵션
핵심 키워드는 그룹핑 라벨링
04. UX 기획 문서화 : 화면 설계서 및 QA 문서
1) 화면 설계서
프로젝트의 복잡도가 높고, 이해관계자가 많을 경우
원활한 히스토리 파악 및 유지 보수를 위해 화면 설계서를 작성하기도 함
와이어프레임과 기능 상세 정의를 합친 문서로, 화면에 존재하는 각 요소를 분리하여 설명함
변경된 내용은 작성일과 함께 기록하여 버전을 관리
회사나 프로젝트의 성격에 따라 화면 설계서를 작성하는 경우도 있고, 아닌 경우도 있음
회사에 따라 화면 설계서를 작성하는 직군이 다르기도 한데,
예를 들면, 사업기획부에서 작성하기도 하고, PO/PM이 작성하기도 하고, UX/UI 디자이너가 작성하기도 함
2) QA 문서
QA(Quality Assuarance)는 기능 배포 전에 기능을 테스트하는 과정으로,
크게 테크니컬 QA와 디자인 QA으로 나뉠 수 있음
제품팀에서 오너십을 가지고 테크니컬 QA와 디자인 QA를 수행하는데 이 때, 보통 작업자가 직접 QA를 진행
별도의 QA 팀이 있는 경우, 협업을 통해 예상치 못했던 버그나 사이드 이펙트를 발견해 보완하기도 함
테크니컬 QA는 의도대로 기능이 잘 동작하는지에 초점을 맞추어 이루어짐
보통 테스트 케이스를 작성하고, 요구 사항이 충족하는지 확인
테스트 화면, 조건, 테스트 케이스, 기대하는 결과, 테스트 환경, 테스트 결과(PASS/FAIL) 등이 포함될 수 있음
뎁스가 많은 화면일 경우 대분류/중분류로 구분하여 화면을 그룹화하기도 함
디자인 QA는 의도대로 디자인이 잘 구현되었는지에 초점을 맞추어 이루어짐
AS-IS(구현된 화면)와 TO-BE(의도한 화면)를 명확하게 전달하는 것이 중요
📌 QA 문서에서 개별 반영 여부와 최종 확인 여부를 구분해서 최종적으로 이슈가 해결되었는지 명확하게 추적하는 것을 추천
디자인 QA 이슈 리스트에는 우선순위, OS, 발생 화면, 이슈 내용, 개발 반영 여부 및 최종 확인 여부, 리뷰어 등의 정보가 포함될 수 있음
📌 AS-IS와 TO-BE를 명확하게 설명
5st Week 사용성 테스트 방법
01. 사용성 테스트의 개념과 중요성
1) 사용성 테스트의 개념
사용성 테스트(Usability Test; UT)는
프로토타입이 있다면 제품 개발 단계 중 언제든 활용할 수 있음
유저가 제품이나 서비스를 실제 사용할 때 의도한 시나리오에 따라 테스크를 수행하는 지, 문제점은 없는지 관찰하기 위해 진행
유저가 제품이나 서비스를 사용할 때 어떤 생각을 가지고 어떤 혼란을 겪는지 파악할 수 있음
제품 개선 전에 진행 시 유저가 불편하게 생각하는 부분을 파악할 수 있고,
제품 개선 후에 진행 시 유저가 실제 어떻게 사용하는지를 파악할 수 있음
2) 사용성 테스트의 중요성
사용성 테스트를 하는 이유는 우리가 사용자가 아니기 때문임
오히려 우리는 프로젝트에 대해 너무 많이 알기 때문에 편향을 가지고 있음
유저가 화면을 직접 조작하면서 마주치는 문제를 식별할 수 있음
이를 통해 디자인을 유저 중심적으로 개선하는 데 도움을 받을 수 있음
예산이 제한적이거나 시간이 촉박한 경우에 캐주얼하게 카페에서 진행하는 사용성 테스트로도 유용한 인사이트를 얻을 수 있음
02. 사용성 테스트 준비
1) 사용성 테스트의 구성 요소
진행자 (Moderator)
참가자에게 사용성 테스트의 목적과 절차를 안내함
참가자들이 편안한 분위기에서 자연스럽게 행동할 수 있는 분위기를 조성
참가자들에게 테스크를 지시하고 테스크를 수행하는 참가자를 관찰
동시에 참가자가 생각하고 있는 것을 말로 표현할 수 있도록 유도
테스크 (Task)
참가자가 테스트 과정 중에 현실적으로 수행할 수 있는 활동으로 구성
테스크 지시는 참가자에게 구두 또는 안내지로 전달될 수 있음
참가자가 수행할 테스크를 직접 소리 내어 읽도록 안내하기도 함
이렇게 하면 참가자는 이해도를 높이고, 관찰자는 현재 진행 중인 테스크를 파악하는 데 도움 됨
참가자 (Participant)
참가자는 유저를 대표할 수 있어야 함
이미 출시된 제품에 대한 사용성 테스트를 진행할 때는 참가자가 해당 제품을 사용한 경험이 있거나, 유사한 경험이 있는 것이 좋음
아직 출시되지 않은 제품에 대한 사용성 테스트를 진행할 때는 참가자가 유저 페르소나와 유사한 특성을 가지고 있어야 함
프로젝트 지식이 있는 내부 구성원이나 페르소나와 완전히 무관한 사람을 대상으로 테스트를 진행하면 좋은 데이터를 얻을 가능성이 낮아짐
관찰자 (Observer)
사용성 테스트가 진행되는 동안 참가자의 행동과 반응을 관찰하고 기록함
테스트를 진행하는 방에 진행자와 함께 둘이가서 기록하기도 하고, 원격으로 참가자의 화면과 참가자를 실시간으로 관찰하면서 기록하기도 함
2) 사용성 테스트 공간 환경 구성
📌 사용성 테스트를 위해 테스트가 진행되는 공간과 실시간으로 관찰할 수 있는 공간이 필요함
테스트 공간에서 참가자와 진행자가 테스트를 진행
관찰 공간에서 관찰자들이 테스크 공간에서 일어나는 일들을 실시간으로 관찰하고 기록함
관찰자들은 참가자가 어떤 말을 하면서 화면을 조작하는 지 알 수 있어야 함
테스트 공간이 따로 구비되어 있는 조직의 경우 단방향 거울을 활용하기도 함
관찰 공간과 테스트 공간에는 단방향 거울이 있어서 관찰 공간에서는 테스트 공간을 볼 수 있지만, 테스트 공간에서는 관찰 공간을 볼 수 있음
줌과 구글밋 등을 활용해 원격에서 사용성 테스트를 진행하기도 함
실시간으로 참가자의 얼굴과 참가자가 조작하는 화면을 보면서 진행자가 질문을 할 수 있음
별도의 관찰 공간이 없는 경우 테스트 공간에 진행자와 서기를 담당하는 관찰자 1명이 들어가기도 함
3) 사용성 테스트 준비하기
📌 사용성 테스트 준비 과정에서 파일럿 테스트를 최소 1회 시행하는 것을 추천
사용성 테스트 목적 설정
사용성 테스트를 통해서 확인하고 싶은 사항을 정함
참여자 리크루닝 & 스크리닝
사용성 테스트의 목적, 방식, 일정, 보상 등에 대한 정보가 포함된 공지를 함
필요한 경우 지원자의 적합 여부를 사전 질문 등을 통해 스크리닝함
테스크 선정
실제 사용성 테스트에서 수행할 수 있는 현실적인 테스크를 선정
여기에서 테스크란, 유저에게 주어지는 미션 같은 것
사용성 테스트 시나리오 작성
여러 개의 테스크들이 모여 사용성 테스트 시나리오가 구성됨
사용성 테스트 시나리오에는 테스크의 수행 요청 순서, 후속 질문 리스트 등의 내용이 담김
파일럿 테스트
실제 테스트 환경과 동일한 환경에서 사전 테스트를 진행해보는 것을 의미함
예상치 못한 현장 변수를 미리 확인하고, 제 3자 입장에서 질문 관련 피드백을 받을 수 있음
테스트 공간에서의 화면과 오디오가 관찰 공간에 실시간으로 잘 송출되는지 체크해야 됨
사용성 테스트 중 소요 시간은 적절한지 체크함
무의식적으로 전문 용어를 사용하지 않는지 피드백을 받아보도록 해야 함
사용성 테스트 시나리오는 진행자가 어떤 절차에 따라 테스트를 진행할 것인지 참조할 수 있는 가이드 문서임
분위기를 편안하게 만들기 위해 참가자에게 아이스브레이킹 질문을 한 후에 테스트를 시작하는 것을 추천함
테스크 수행 순서의 경우 참가자가 순서대로 진행하기 용이한 순서대로 현장 상황을 고려해 구성하는 것을 추천
참가자에게 미리 공유된 시간 내에 마무리할 수 있도록 시간을 고려하여 테스크와 질문을 구성해야 함
03. 사용성 테스트 실행
1) 사용성 테스트 실행 과정
사용성 테스트 안내
사용성 테스트의 목적, 진행 방법, 주의 사항에 대해 안내
영상/사진 촬영 동의 여부를 체크하고, 기밀 프로젝트인 경우 보안 서약서를 작성
테스크 안내
참가자가 수행해야 할 테스크를 알려줌
테스크 수행 & Think Aloud
참가자는 안내받은 테스크를 수행
이 때, 진행자는 참가자에게 테스크를 수행할 때 자신의 생각과 감정을 말로 표현해줄 것을 요청
사후 인터뷰
사후 인터뷰를 진행하면서 이용 만족도를 측정
사후 인터뷰를 통해 참가자가 테스크 수행 전에 기대했던 것이 수행 후와 비교했을 때 어느 정도 차이가 있는지, 불편하게 하는 오류 요인은 무엇이 있는지 등을 파악함
사후 인터뷰는 각 테스크가 종료된 직후에 진행하는 것이 바람직함
마무리
참가자에게 테스트 종료를 알리고, 참여 보상을 증정
📌 관찰자로 참여하는 인원의 경우에도 테스트에 들어가기 전에 사용성 테스트 시나리오를 숙지하는 것이 바람직함
2) Think Aloud 이해하기
테스크를 수행하면서 머릿속에서 어떤 생각이 드는 지 말로 표현하도록 하는 방법임
Think Aloud를 통해 얻을 수 있는 정보 예시는 아래와 같음
유저가 메뉴나 버튼, 아이콘을 클릭한 의도
어떤 행동을 했을 때 기대하는 결과값
테스크 수행 중 유저가 겪는 어려움
테스크 수행 중 유저가 실수를 한 이유
유저의 실제 의도와 인지 과정을 이해하고 설계에 반영할 수 있다는 장점이 있음
편안한 분위기에서 자연스럽게 생각을 말할 수 있는 분위기를 조성하는 것이 중요함
Think Aloud를 진행하는 방법에는 크게 두 가지가 있음
Think Aloud
테스크 수행과 동시에 진행
장점 정보를 찾고자 할 때 참가자의 의도를 명확히 파악
단점 말과 행동을 동시에 하려다보니 수행 집중력이 떨어질 수 있음
진행자가 능숙하지 않다면 실수로 참가자에게 다음 행동을 암시하는 힌트를 줄 수 있음
Retrospective Think Aloud
테스크 종료 후 기억을 되살리며 진행
장점 테스크 수행 중에는 테스크에만 집중
단점 이전에 한 행위를 기억 못 할 수 있음
사소한 오류에 대해 적극적으로 표현하지 않으려는 경향이 있음
📌 보통은 테스크 수행과 Think Aloud를 동시에 진행하는 첫 번째 방식을 채택
Think Aloud 유의사항
📌 테스트 중에는 참가자가 말을 많이 하도록 유도해야 함
중간에 참가자가 질문을 할 때 최대한 답변을 주지 않아야 함
중간에 참가자가 실수를 한다고 해서 힌트를 주거나 고치려고 하지 말아야 함
“왜 그렇게 생각하세요?”, “어떻게 해야할 것 같으세요?” 등의 열린 질문으로
참가자의 생각을 알아보는 것이 바람직함
04. 사용성 테스트 결과 정리
1) 사용성 테스트 결과 정리하기
문제점 도출 → 원인 도출 → 개선 방향 도출
문제점 도출
참가자의 생각과 행동에 대한 기록을 종합해 문제점 파악
진행자와 관찰자의 기록을 종합해 문제점을 파악
원인 도출
유저가 예상하는 경험과 실제 경험이 어떻게 달랐는지 확인
유저가 이해하고 기대하는 내용과 실제로 어떻게 달랐는지 확인
개선 방향 도출
데스크별로 개선이 필요한 부분 리스트업
정보 구조 관점에서 개선이 필요한 부분을 리스트업
2) 우선순위 논의 TIP
사용성 테스트에서 유저의 이용 만족도와 행동 데이터 수집해 우선순위 논의 시 의사 결정 근거로 활용
테스크 수행 후 참가자의 이용 만족도를 측정
전체 테스크 중 이용 만족도가 높은 경우와 낮은 경우를 파악할 수 있음
참가자의 테스크 성공/실패 여부를 측정
특정 테스크가 유독 실패 비율이 높다면 이용에 불편함이 있다고 볼 수 있음
참가자가 테스크를 쉽게 달성할 수 있었는지를 측정
이 때 참가자의 이동 동선을 살펴보면 어떤 창에 요인이 있었는지 원인을 파악할 수 있음
05. 제이콥 닐슨의 휴리스틱 평가 방법
1) 휴리스틱 평가 이해하기
휴리스틱 평가(Heuristic Evaluation)란, 전문가가 인터페이스를 검토하여
사용자 인터페이스의 문제점을 발견하는 방법
사용성 테스트와는 달리 유저를 대상으로 하지 않고, 디자이너나 사용자 경험 전문가가 특정 휴리스틱을 기반으로 평가함
디자인 초기 단계에서 비교적 쉽고 빠르게 적용해볼 수 있다는 장점이 있음
전문가 중심의 평가이기 때문에 실제 유저의 경험을 완벽하게 대변하지는 못한다는 단점
2) 제이콥 닐슨의 10가지 휴리스틱 평가 항목
휴리스틱 평가 중 닐슨 노먼 그룹의 제이콥 닐슨이 1994년 개정한
10가지 휴리스틱 평가(10 Usability Heuristics)가 제일 대중적으로 활용
시스템 상태 가시성 Visibility of System Status
유저가 현재 무엇을 하고 있는지 정확한 상태를 보여주고 있는가?
시스템과 실제 세상 매칭 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
유저에게 충분한 도움말을 제공하고 있는가?
