UIUX 스터디 1주차 학습일지 03 : UX 디자인 구현 - 3

프로토타입

효율적인 커뮤니케이션을 위해 가시적인 제품을 미리 만들어보는 것

빨리 만들어서 문제점을 발견하고 테스트하기 위해

프로토타입은 환경에 따라 Visual Fidelity, Functional Fidelity 두 가지 축에 의해 종류 결정

 

Lo-fi prototype의 장점

상상을 바로 현실로 구현가능

누구나 만들 수 있음

가볍게 수정할 수 있음

 

Hi-fi prototype의 장점

인터랙션 관점에서 검증할 수 있

디자인의 의도와 맞게 프론트엔드 개발이 되었는지 확인할 수 있음

소스코드상의 오류가 없는지 확인 가능

사용자가 사용할 수 있는 대부분의 옵션들이 구현되었기 때문에 엣지케이스를 찾고 다양한 시나리오를 검증할 수 있음

 

프로토타입 툴

손그림, 파워포인트, 발사믹(Balsamiq), 인비전(inVISION), 피그마, 프래이머(Framer)

 

프로토타입을 만드는 목적을 정해야 함

1) 내부 디자인 공유 - 내부적으로 효과적으로 디자인 공유, 피드백을 받고싶을 때

2) 테스트 & 외부 공유 - 사용자 테스트나 사용성 평가, 고객이나 외부 팀에 공유하기 위해

 

이후에 어디서부터 어디까지 만들지 제작 범위를 정해야 함

제작 범위는 하나의 흐름으로 이어지는 시나리오를 바탕으로

 

어디서부터 어디까지 만들 지 정했다면, 어떻게 만들지 정해야 함

현재 시점에 검증하고싶은 목적에 맞게 제작 툴을 정함

 

MVP (Minimum Viable Product)

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

 

기능을 먼저 정립하고 기능의 퀄리티를 높임 이후에 사용자가 의도에 맞게 사용할 수 있는지 usability를 추가. 이후에 또 사용하고싶어할 수 있는 지속적인 경험을 줄 수 있는 Delight를 추가

 

제품 개발 프로세스

MVP의 개념

 

MVP는 모든 측면에서 포함될 수 있게 만들어야 함

MVP는 '이 기능이 사용자에게 필요한가?'에 답하기 위해서 만드는 것이 아니라, 나중에 실제로 사용자에게 전달되었을 때 '사용자가 어떻게 받아들일까?', '우리의 Key Concept를 어떻게 수용할까?'를 보고자 하는 것이기 때문에 전체적인 형태로 만들어져야 함

사용자의 피드백을 듣고 가설을 검증하며 1)개선하거나 2)피봇하는 경우로 나뉨

 

MVP 디자인 프로세스

핵심기능 정의 > 제품 개발(Lo-fi, Hi-fi prototype) > 검증, 인사이트 도출(Semi-Structured Qualitative Interview)

MVP 검증 시엔 중간 단계의 사용자조사를 실행

사용자에게 적절히 제품을 보여주면서 물어보고 사용자가 실제 어떻게 생각하는지 넓게 들어봐야하기 때문

 

Dropbox의 MVP 데모 비디오 사례

- 우리 입장에서 가장  리스크는 아무도 원하지 않는 제품을 만드는 것이다

- 이 제품을 런칭하지 못하면 물론 슬프겠지만, 그것보다 우리가 이 과정에서 아무것도 배우지 못하는 것이 더 큰일이다

- 실제로 유저가 눈으로 보고 만져볼 수 있는 무언가를 손에 쥐어주고 나서 그들의 피드백을 가능한 한 빨리 얻는 것이 가장 중요하다

 

사용성평가

UI는 케찹을 잘 담을 수 있고 판매할 수 있는 형태를 만드는 것이라면, UX는 실제로 케찹을 먹는 사람들이 몇 달 동안 잘 먹을 수 있게 하기 딱딱한 유리병 대신 말랑한 소재를 사용하고 뒤집어진 형태로 디자인하는 것

사용성(Usability)은 UX디자인 과정에서 예상하지 못하는 것을 테스트해보고 실제로 어떻게 사용하는지 관찰해보고 발생할 수 있는 문제들을 발견해서 또 다시 개선하기 위해 필요

 

UI, UX, Usability

 

사용성 평가 경쟁사 제품 사용자를 모집하여 비교분석 하기도 함

사용자가 원하는 기능이 다 들어있는가(Feature coverage)

 

사용성평가 필요시기

 

사용성 평가는 제품의 생애주기 모든 순간에 필요할 수 있음

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

 

 

Research Point

Happy path - 사용자가 생각한 단계보다 더 많은 단계를 거쳐서 과업을 끝냈을 때

Action time - 생각한 시간보다 더 오랜 시간이 걸린 경우 어느 부분이 태스크 수행 시간을 지연시켰는지 알아내는 

Informative components - 버튼이 사용자가 이해할 수 있는 형태로 제공되는지

Problem solve - UI가 아예 잘못 설계된 경우

 

시나리오를 기반으로 1)주요 관찰 포인트와 2)예상 문제점을 정의해야 함

 

사용성평가 보고서

Executive summary - 어떤 시나리오를 기반으로 언제, 어디서, 몇 명, 누구를 대상으로, 어떤 방식으로 했는지 간단 요약

> 데이터 결과를 해석할 때 사용자, 몇 번째인지, 어떤 순서인지 등 매칭해서 해석해야하는 경우가 많기 때문에 중

 

테스트 참가자 정보 (Participants summary) - 몇 명인지, 어떤 서비스에 능숙한지, 몇 년 정도의 경험을 가지고 있는지\

 

주요 발견점 - 태스크, 사용자의 의견

 

사용자의 주요 코멘트 (Quote users' comemnts) -  키팩터, 인사이트 등을 뽑을 때 사용자의 주요 행동과 말, 포인트에서 얻는 경우가 많음 문서를 통해서 현장감을 느낄 수 있음

 

설문, 만족도 평가 등의 결과 - 정성적 데이터

 

개선점 정의 (Enhancement) - 사용성평가의 모든 과정의 목표. 사용자들의 행동, 말, 제품을 바라보는 시선, 그래서 이러한 점이 개선되어야 한다 > 우선순위도 제안 (가로축 세로축 매트릭스)

 

Google HEART metrics

사용자 경험의 질을 평가하기 위한 프레임워크, 각 항목들에 대해 사용자들에게 얼마나 잘 제공하고 있는지 확인하기 위함

Hapiness - 사용자의 심리적 만족

Engagement - 참여도, 사용자가 우리의 시스템을 얼마나 자주, 깊게, 생활과 밀접하게 사용하는가

Adoption - 사용자의 수렴도, 우리 서비스 자체를 사용자가 어떻게 받아들이는가, 새로운 기능을 잘 이해하고 쓰는가

Retention - 얼마나 지속적으로 사용하는가

Task success - 사용자의 목표달성도는 얼마나 높은가

 

Goal이 어떻게 달성될 수 있는지 볼 수 있는 Signal을 정의하고 여기서 나온 데이터를 수집 분석하고 표로 만들었을 때, 객관적으로 평가하기 위한 지표(Metrics)를 설정

 

Lean UT plan

한 장에 UT에 필요한 모든 것들을 작성할 수 있게 정리한 폼

 

게릴라 테스트

사용자가 있는 곳으로 바로 가서 즉석으로 짧게 테스트 하는 것

개발에서 딜리버리로 넘어가는 시점에서 가장 필요

'우리가 어떤 디자인을 해서 어떤 제품을 만들 수 있을 것인가'가 눈에 보이는 시점 > 이게 맞을까?

가설 검증이나 주요 사용성 이슈를 발견하기 위해 게릴라 테스트 진행

5-10분 안에 끝나는 가벼운 테스트

 

A/B 테스트

가설이 명확해야 정확한 인사이트를 얻고, 명확한 통제변수를 설정 할 수 있음. 테스트 실시 시점은 시간 텀이 길면 안 됨

ex) 넷플릭스에서 CTA(Call to Action) 비율을 보기 위해 버튼 레이블 A/B 테스트를 진행

어떤 텍스트가 사용자들로 하여금 가장 누르고싶게 만드는가?

 

GOMS

사용자가 컴퓨터와 구체적으로 어떻게 상호작용하는지 조사하는 것

테스트프로그램에 코드를 심어야 함 사용자는 센서와 부가장비를 활용

 

Affordance

= 행동유도

언어적인 표현 대신 직관적으로 사용 방식을 인지할 수 있게 하는 것

 

Metaphor

친숙한 이미지를 가져와서 쉽게 인식할 수 있게 함

 

Heuristic evaluation

UXUI전문가나 특정 도메인 전문가의 입장에서 디자인 평가

시스템 상태의 시각적 표현, 현실에서 익숙한 단어와 문구, 사용자에게 통제권 제공, 일관성과 기준, 기억보다 직관, 에러 예방, 자유롭고 효율적인 사용 환경, 심미성, 에러 해결, 도움말

 

Design Contraint

디자인을 하는데 존재하는 현실적인 제약조건, 할 수는 있지만 사용자를 위해 설정하는 제약조건

ex) 카카오톡 미디어 전송 30개까지만 가능한 경우, 구글에서 대용량 파일 전송은 구글 드라이브로만 가능한 점

ex) 자동 주차 가능 자동차를 개발해도, 사용자가 주차할 때 주변에 있어야 함

 

Fitt's Law

사용자가 목표로 하는 위치에 얼마나 빠르게 도달하는가

시작점에서의 거리와 목표의 크기에 따라 결정되며 행동의 범위가 정확할 필요가 없으면 수행 속도는 더 빨라짐

> 화면 상단보다 하단에 위치시키는게 더 빠른 액션을 유도할 수 있다

행동의 정확성

 

Hick's Law

사용자에게 제공되는 선택권이 많아질수록 사용자의 선택은 느려진다 사용자가 정보에 친숙하거나 헤비유저라면 오히려 많은 양의 정보를 제공하는 것이 사용성에 좋다

> 많은 정보를 불가피하게 제공해야 할 때는 그룹핑해서 제공해라

> 데이터에 익숙한 경우 그룹핑하지않고 한번에 보여주는게 오히려 사용성을 높일 수 있다

사용자의 전문성

 

포트폴리오

어떤 배경에서, 어떤 프로젝트를, 어떤 목적이나 문제를 해결하기 위해 진행했고, 그 과정에서 프로세스는 어떠했고, 그 과정에서 내가 고민했던 것은 무엇인지 모두 기술이 되어야한다

UX 프로세스의 포트폴리오는 결과물보다 어떤 주제에 대해 어떤 apporach로 고민했는가가 중요함

포트폴리오에 텍스트가 많아질 수밖에 없음

어떻게 만들어야 읽을 수 있도록 유도할 수 있을지 고민해야 함

 

1. 프로젝트에 대한 짧은 설명 + 프로젝트의 배경과 왜 우리가 이 디자인을 했어야 했는지에 대한 설

> 기본적인 콘텍스트를 제공해 사람들이 프로젝트에 대해 공감할 수 있게 하기 위해

 

2. 프로젝트의 목표 - 해결하고자 했던 문제가 무엇이었는지

 

3. 프로젝트의 배경과 본인의 책임과 역할 - 구체적으로 내가 기여한 부분이 무엇인지

 

4. 프로젝트의 시작 - 디자인 목표를 이루기 위한 나의 접근법은 무엇이었는지

> 디자인의 목표를 이루기 위해서 나는 어떻게 이 문제를 해석해서 문제를 풀기 위해선 어떤 어프로치가 좋을 것이라 생각했다 왜냐하면 ... (UX디자이너에게 가장 필요한 역량은 문제 해결능력이기 때문 + 현실의 제약조건을 고려해 최적의 접근법 제안) 저자의 경우 필드 리서치를 통해 기존에 알고있던 문제점들 이외에 다른 문제점을 알아보았음

 

5. 조사결과와 발견점 - 리서치를 통해 무엇을 알게 되었는가

 

6. 구체적인 문제 정의 - 구체적으로 생각했을 때 이것이 문제다라는 인사이트 도출

 

7. 실즈적 원인파악을 위한 발견점 구체화 (Deeper Insights) - 디자이너의 해석능력, 인사이트 도출 능력

 

8. 문제 해결을 위한 문제 재 정의 - 문제를 해결하기 위해서 이렇게 바라봐야 한다 > HMW

 

9. 유저 저니맵을 통한 Painful point 정의 - 현재 서비스 사용성, 만족도를 저하시키는 부분이 여기에 있다

 

10. 디자인과 데모 비디오

 

11. 주요 기능 설명과 디자인

 

12. 정보구조도

 

13. 프로젝트를 진행하며 힘들었던 점, 고민했던 부분들 - 문제 해결을 하던 중 예상치도 못한 이런 문제가 발생했다 그럼에도 불구하고 이렇게 고민해서 이런 결과를 얻었다

 

좋은 포트폴리오란?

1. 결과보다 과정

> 나는 어떤 고민하는 능력이 있는가

 

2. '나'의 디자인 철학이 보이도록

> 프로세스, 메소드를 선택할 때 나는 이 문제를 이렇게 바라봤고 이 메소드가 ~~해서 적합하다 생각했다

 

3. 보는 사람이 보고싶은 것부터 보여주는 구성

> 흥미를 잃지 않고 쭉 볼 수 있게

 

4. 디자이너 에세이 essay

> 레쥬메형식보다 에세이를 먼저 보여주면 글을 읽으면서 유대감이 생긴다

> 일종의 아이스 브레이킹

 

5. 간결하게

 

6. 내가 표현하고싶은 나의 이미지가 나타나는 사진

 

7. 저작권 있는 프로젝트는 블러 처리

 

포트폴리오는 나의 UX 디자이너로서의 능력Skills과 자세Attitude를 보여주는 것