[W1_D6] 7.디자인 평가 및 테스트
1 ) 프로토 타입
1-1 ) 프로토 타입이란?
** 미리 만들어 보는 것
말은 상대방이 어떻게 듣는지에 따라 많이 달라지기 때문에, 러프하게 이미지로 만들어보는 것
?프로토 타입은 왜 필요할까?
Test early, Test often!
최대한 빨리 자주 수집하고, 고쳐야 될 것을 빨리 도출해서 다시 개선하기 위해서
프로토타입은 강력한 커뮤니케이션 Tool이다
Lean project에도 프로토 타입은 너무 유용한 툴이다
** Lo-fi prototype
No time + Early stage = Concept evaluation
시간이 없거나, 재정이 부족하거나 프로젝트의 초기 단계일 때
기본적인 UI 와 컨셉 도출을 위해서
( 실제에 가깝다기 보다는 누가봐도 프로토 타입이라고 생각할 정도 )
장점: 상상을 현실로 / 저렴한 제작 비용 (종이 or 파워포인트 사용) / 손 쉬운 수정
** Hi-fi prototype
Time + (Almost) Final stage = Realistic usability
목업과 Interaction 이용해서 디지털화 한 경우 (진짜처럼 만드는 경우)
사용자의 in/put 에 따라서 전환효과를 눈으로 바로바로 확인 할 수 있음
장점: 현실적인 디자인 검증 / 인터랙션 개발 리뷰 / 시나리오 검증 (예상치 못한 방향으로 사용될 수 있기 때문에 _ edge case를 찾는 경우)
1-2 ) 프로토타입 제작 툴
** Lo-fi
종이나 화이트보드에 그리기
- 장점: 빠르게 수정 가능
- 단점: 디지털화로 다시 작업해야됨
파워포인트
- 장점: 많은 사람들이 사용하고 있음 / 쉬운 공유 / 스탠실을 통한 빠른 제작
- 단점: 제한적 인터랙션 / 업데이트의 어려움
발사믹 Balsamiq
- 장점: 아주쉬운 사용 / 직관적으로 UI를 표현하기 쉬움 / 빠른 제작 시간 / 쉬운 공유
- 단점: 제한적 인터랙셕 / 비현실적 표현
** Hi-fi
인비전
- 장점: 오래되고 안정적인 툴 / 공유와 제작이 쉬움 / 라이브러리 등록 / 직관적인 사용 / 화면단위 피드백 수집가능
- 단점: 제한적 인터랙션 / 디자인 기능 부족 / 자유도가 떨어짐
피그마
- 장점: 클라우드 기반으로 제공하는 기능이 많고 빠름 / 직관적인 사용 / 스케치 파일 Import / 다양한 인터랙션 지원 / 화면 단위 피드백 수집
- 단점: 긴 시나리오는 제작/관리가 어려움
프래이머
- 장점: CLI(command line interface)지원 / 높은 자유도 / 넓은 호환성(facebook pop, native, Uikit, Rebound..) / 커피 스크립트
- 단점: 커피 스크립트 (자바스크립트 보단 쉽지만 .. 그래도 어려움)
2 ) 프로토타입의 제작과 활용
2-1 ) 프로토 타입 제작
#Step 1 : 제작 목적 정하기
내부 디자인 공유
- 효과적인 디자인 공유
- 개발 리뷰
- 이해관계자 리뷰 (요구사항 검증)
테스트 또는 외부 공유
- 사용자 테스트
- 사용성 평가
- 고객 또는 외부 팀에 공유
#Step 2 : 제작 범위 정하기 (Prototyping scope)
중구난방으로 만들어서 보내주는 것이 아닌, 범위를 하나의 흐름으로 이어지는 시나리오를 정해서 제작하기
#Step 3 : 제작 툴 정하기
어떻게 만들것인가를 생각해 보고 툴을 정해야 된다.
(인터랙션이 필요한지 불필요한지에 따라_무조건 Hi-fi 만든다고 좋은게 아님)
#Step 4 : 프로토타입 만들기
2-2 ) 프로토타입 공유하기
프로토타입을 통해..
** 사용자 테스트
** 다양항 피드백 수집
명확하게 comments를 받을 수 있음
** 개선사항 도출
프로토타입을 생략하고 싶은 경우가 있지만, 나중에 개발자의 작업물과 다를 수 있기 때문에.
(전체 개발 계획을 보았을 때, 시간을 줄인다고 했다가 더 딜레이 될 수 있는 가능성이 큼 = risky)
3 ) MVP (Minimum Viable Product)
3-1 ) MVP란
** MVP (Minimum Viable Product) = 최소 기능의 제품
최소한의 노력을 최대한의 유의미한 사용자 피드백을 얻기 위한 최소한의 제품
"A Minimum Viable Product is that version if a new product
which allows a team to collect the maximum amount of validated learning
about customers with the least effort"
(Lean UX Design 에 기반되어 진 것)
** MVP의 개념
1. Functionality : 기능적인 부분을 만든다
2. Realiability : 현실적으로, 안정적으로 잘 돌아가는지 퀄리티를 높인다
3. Usability : 실제사용자가 우리 제품의 기능을 잘 사용하는지 아닌지 (개선부분을 파악)
4. Delight : 사용자들이 계속 제품을 찾을 수 있도록 (지속적인 경험을 줄 수 있도록_재미적인 요소를 줄 수 있도록)
3-2 ) MVP Process
1. Idea
2. 프로토타입 만들기(MVP)
3. 측정(사용자들에게 피드백 받기)
4. User Research 분석 (사용자들 Key factors,Insight 기회요소 도출)
5. Persevere-> 약간 개선을 하는 방향
Pivot -> 방향을 완전히 바꾸는 것 (처음 아이디어부터 다시시작)
?MVP 와 프로토타입의 다른점?
제품을 만드는 목적만 다를 뿐, 겉으로 보기에 다른 점이 거의 없다
#Step 1 : 핵심 기능 정의
주요기능을 품은 시나리오를 중심으로 목적과 범위를 정할 수 있음
#Step 2 : 제품 개발
Lo-fi 프로토타입을 만들거나, Hi-fi 프로토타입
또는 데모 비디오나 컨셉 시나리오 만으로도 가능함
#Step 3 : 검증, 인사이트 도출
사용자조사를 해야 함.
** In-depth Interview : 마주앉아서 깊은 대화를 나눔
** FGI (Focus Group Interview) : 다대일 인터뷰
** Concept studies&Desirsability studies : 우리가 배운다는 관점에서 사용자가 어떻게 이해하고 있는지 확인하는 방법
@Best practice : Dropbox 사례_MVP 데모 비디오 공유해서 배움_ 만족스러운 사용경험을 통한 유저 증가@
4 ) 사용성 평가
4-1 ) 사용성 평가란 ?
**사용자가 제품을 제작 의도에 알맞게 불편함 없이 사용할 수 있는지 확인하는 것
- 내부 사용자 테스트
- UI 분석
- 사용자 조사 및 경쟁사 비교분석
- Feature Coverage (사용자가 원하는 기능들이 다 들어가 있는가? 관점에서 보는 것)
& UI comparison (경쟁사 회사에서 같은 기능을 제공할 때 좀 더 나은 UI를 제공하기 위해서 어떻게 해야하는가?)
?사용성평가는 언제? (from Product Life Cycle)
제품의 생애주기 모든 시기에 할 수 있음.
4-2 ) 사용성 평가 프로세스
출시 전 사용성 평가 Post Usability test
** Research point
1) Happy Path Comparison
사용자의 행동을 보고 우리의 Happy Path 를 비교하면서
사용자가 왜 이러한 행동을 했는지
사용자의 UI를 수정하면 사용자가 우리의 Happy Path 대로 사용할까
관점에서 분석하는 것
2) Action time
순수하게 사용자가 하나의 Task 수행할때까지의 시간(예상했던 것보다 시간이 길어질 수 있는데, 길어진 이유에 대해서 분석 하는 것)
** 피츠의 법칙 : 내 손가락이 있는 곳에서 지금 내가 눌러야 하는 곳까지의 거리가 멀수록, 타겟이 작을 수록 시간이 오래 걸린다
3) Informative components
과업수행에 도움을 주는 정보, 버튼이 사용자가 이해할 수 있는 형태로 제공되는지 관찰 하는 것
3) Problem solve
문제가 발생했을 시, 해결할 수 있도록 UI 적으로 케어를 해줘야됨
4) Primary use case 주요 테스트 시나리오 정의
사용자 테스트에 사용할 주요 시나리오(Use case)를 도출
이때 주요 시나리오 제품의 핵심 기능 또는 자주 발생하여 댑분의 사용성에 큰 영향을 미치는 시나리오를 중심으로 선정.
4-3 ) 사용성 평가 실행
5 ) 사용성 평가 분석
5-1 ) 사용성 평가 분석
** 사용성평가 보고서에 포함되어야 하는 것
1. 테스트 개요
2. 테스트 참가자 정보
3. 주요 발견점 (Think aloud_생각하는 바를 그대로 입 밖으로 내는 것)
4. 사용자의 주요 코멘트
5. 설문, 만족도 평가 등의 결과 (Likert scale)
6. 개선점 정의 + 우선순위(매트릭스 그래프를 만들어서)
5-2 ) Google HEART metrics
구글 리서치팀에서 만든 사용자 경험의 질을 평가하기 위한 프레임워크.
- Happiness 사용자의 심리적 만족
- Engagement 사용자의 참여도, 관여도 (사용자가 얼마나 자주 우리의 시스템을 생활과 밀접하게 사용하는가?)
- Adoption 사용자의 수렴도 (우리의 서비스를 사용자가 어떻게 받아드리는가?)
- Retention 사용자의 서비스 사용 지속도 (얼마나 꾸준히 지속적으로 사용하는가?)
- Task success
5-3 ) One page UT(Usability Test) plan
해야될 일이 많은 UT가 중요한데, 하는데 너무 어려워서 덜하게 되서
UT를 캐주얼하게 빨리 자주하기 위해서 준비과정을 생략하고 한장에 Lean UT plan 을 할 수 있음
5-4 ) 게릴라 UT
** 게릴라 사용성 테스트란?
테스트를 하고 싶을 때, 사용자가 있는 곳으로 가서 즉석으로 짧게 테스트를 하는 것
?게릴라 사용성 테스트는 언제 하는게 좋을까?
디자인프로세스 중에 필요할 때 언제든지 해도 좋은데,
그중에도 많이 하는 시점을 찾는다면
개발에서-딜리버리로 넘어가는 시점 (어느정도 디자인도 나와있고, 구체적인 개발 상황들도 나와있음)
** 게릴라 사용성 테스트 준비
1) 준비는 가볍게
데이터 신뢰성을 위한 일반적인 사용자 조사를 설계할 때처럼 할 필요는 없음. 게릴라 테스트의 핵심은 '빨리 확인하기'이므로
최소한의 준비(테스트 범위, 테스트 시간, 주요 질문)만 끝내고 바로 필드로 나가야 함.
2) E2E test 는 안됨
E2E (End to End 제품 사용 시나리오의 처음부터 끝까지) 테스트는 5-10분 안에 끝내야 하는 게릴라 테스트의 성격과 맞지 않음.
확인하고자 하는 구체적인 시나리오를 뽑아서 집중적으로 테스트 해야함.
3) 가급적 촬영하거나 수필 기록을 너무 열심히 하지 말 것
호손효과(Hawthorne effect 관찰되고 있다고 생각하면 평소보다 더 집중하여 좋은 결과를 내는 등 행동에 영향을 끼침)가 일어날
수 있으므로 가벼운 분위기 속에서 진행되도록 해야함.
4) 참여자는 현장에서도 모집가능
전통적인 느낌의 게릴라 테스트는 정말 현장에가서 즉석으로 사용자를 모집하는 것이지만 실제로는 꽤 현실적인 어려움이 있음.
(의외로 참여자를 찾기 쉽지 않음) 따라서 사전에 미리 모집하고 기본정보를 수집한 뒤 가볍게 테스트를 진행하는 것도 게릴라
테스트의 한 방법이 될 수 있음
5) No user screening guide
게릴라 테스트는 광범위한 무작위 방식의 테스트를 지향하기 때문에 사용자를 모집할 때 정말 최소한의 조건만 따지게 된다.
(예_모바일 app 테스트라면 사용자가 최소한 스마트폰은 사용하고 있어야 함.)
6) 사례도 가볍게
그 장소에서 판매하는 제품을 사주거나, 이게 여의치 않다면 기프티카드도 좋은 아이디어
1-6. A/B Test '조사 계획서'작성: 과제1-5의 '다시 선물하기' 기능에 대하여
오늘 과제도 클리어
가설과 변수에 대해서 생각하느라 시간을 좀 많이 썼다..
나도 카카오톡의 사용자이지만, 이번 과제에 대해서 생각해 본적이 없어서 가설과 변수가 잘 떠오르지 않았다
다시 선물하기 기능이 있으면 내가 일일히 나에게 준 사람을 찾아서 선물해주지 않고
한번에 편하게 줄 수 있을 텐데. 이 서비스도 release 되었으면 좋겠다