ⓅⒶⓇⓉ ③ 1주차 학습일지 세번째 | UX이론•기초 파트 1 | Chapter 7~8 수강 | Chapter 7~8 정리

 

📋 오늘의 할 일 📋

💻 UX이론•기초 파트 1 Chapter 7~8 수강

💻 UX이론•기초 파트 1 Chapter 7~8 정리

 

 

---

 

 

💻 Chapter 7~8 정리

 

⚡️프로토타입이란?

프로토타입 (Prototype)은 미리 만들어 보는 시제품을 뜻한다. 프로토타입 하나로 수많은 미팅을 대체할 수 있는 만큼 빠르게 만들어서 테스트 후, 요구사항을 수용하고 빠르게 수정하는 것에 의의가 있다. 

 

 

⚡️프로토타입의 방식

❶ Lo Fi

∗ 프로토타입으로서 할 수 있는 역할은 최소한으로 기능할 수 있다. 프로젝트가 초기 단계라면 기본적인 UI 단계나 컨셉을 확인하기 위한 간략한 방식.

∗ 장점 : 머리 속에 있는 걸 눈으로 볼 수 있고 잡히는 물질적 형태로 구현 가능하다. 종이에 그리는 정도로도 충분해서 가벼운 마음으로 수정 가능.

∗ 단점 : 아카이빙을 위해 디지털화 작업이 수반된다는 번거로움이 있다.

∗ 프로토타입 Lo Fi 도구 : Balsamiq (발사믹)은 빠른 시간 내에 제작이 가능하나, Doodle의 느낌이 강해서 현실감이 떨어진다.

 

❷ Hi Fi

∗ Mockup 안에 인터렉션을 넣어 사용자의 인풋에 따라 시스템이 어떻게 움직이는가를 보여줄 수 있다.

∗ 장점 : 실제에 가까워서 현실적인 디자인 검증이 가능하며, 인터렉션 개발 리뷰가 가능하다.

∗ 단점 : 시나리오가 길어지면 화면이 복잡해지고 관리가 어렵다.

∗ 프로토타입 Hi Fi 도구 : Figma (피그마) 는 직관적인 사용이 가능하고, Sketch 파일로 import가 가능하며, 화면 단위 피드백 수집이 가능하지만 인터렉션이 제한적이고 디자인 기능이 부족하다. Framer (프레이머) 는 코딩을 할 줄 안다면 다룰 수 있는 툴이며, 디자이너가 머리에 그리고 있는 인터렉션의 구현이 가능하다.

 

 

⚡️프로토타입 제작 프로세스

❶ 프로토타입 목적 정하기 (디자인 공유, 개발 리뷰, 이해관계자 리뷰)

→ ❷ 제작 범위 정하기

→ ➌ 제작 툴 정하기

→ ➍ 프로토타입 만들기

∗ 프로토타입을 통해 사용자 테스트를 하고, 다양한 피드백을 수집하기 위해서는 정적인 화면보다 실제 인터렉션이 들어간 화면을 사용자가 썼을 때 효과적인 테스트가 될 수 있다.

 

 

⚡️MVP (Minimum viable product)

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

∗ 최소한의 제품 기능을 만들어서 가능한 빨리 사용자에게 보여주고 유의미한 피드백을 받아 빠른 개선으로 제품의 퀄리티를 올리겠다는 목적

∗ 네 가지 단계를 거쳐 확인

➊ Fuctionality 기능을 정하고 ➋ Reliability 기능이 안정적으로 돌아가는지 보고 ➌ Usability 제작자의 의도와 동일하게 제품을 사용하는지 ➍ Delight 사용하면서 긍정적인 경험을 주고, 지속적인 서비스를 제공하는지

→ 이후, 테스트하여 해당 가설이 맞지 않으면 완전히 프로젝트의 방향을 바꿀 수도 있는데, 이것을 Pivot (피봇) 이라고 한다.

 

 

⚡️사용성 평가?

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

∗ 모든 판단 기준은 사용자이지만, 전문가의 관점이 중요하지 않다는 건 아니다. 사용자들이 간과하고 넘어갈 수 있는 부분들을 전문가의 입장에서 보고 판단 가능하다. 여기서 조금 더 나은 방향성을 제시하는 것이 전문가의 역할.

 

➊ 사용성 평가는 언제 행해지는가? (Product life cycle)

∗ 제품 출시 전 최종 점검 (검증이 필요한 상태) → 성장요인 분석 → 업데이트 요건 파악 (이슈 발생 시 확인 필요) → 개선 사항 도출 

∗ Product life cycle 이라고 되어있지만, 사실 이슈가 있을 때마다 해당 사이클을 반복 

 

➋ Research Point

① Happy path comparison

∗ 해당 시나리오를 수행하기 위한 최단 단계. 제작자가 의도한 시나리오를 Happy path 라고 지칭하며, 실제 사용자의 행동을 관찰하여 비교한다.

 

➁ Action time

∗ 태스크 수행 시간 증가 구간을 확인할 것

 

 

⚡️사용성 평가 분석

∗ 평가 조사 이후, 수집된 데이터를 보고서 형태로 작성

 

➊ 보고서 항목

➀ 테스트 참가자 정보 : 비하인드 스토리도 함께 적어도 된다. 예시 : 10명을 모집했으나 6명의 갑작스런 불참으로 4명이 테스트에 참가.

➁ 주요 발견점 : 평가자에게 화면 위에서 아래로 순차적으로 얘기해달라고 요청 후, 어떤 이슈가 나왔는지 상세하게 기재. 별도로 해석을 추가할 시, 평가자의 의견과 헷갈리지 않게 주석을 달고 추가한다.

➂ 사용자의 주요 코멘트 

➃ 설문, 만족도 평가 등의 결과 : 얼마나 어려웠는지, 평소의 태스크 처리와 차이가 있었는지, 프로토 타입에 만족했는지 등등 항목을 만들어 점수를 매긴다

➄ 개선점 정의 & 우선 순위 설정

 

➋ 보고서 종류

➀ Google Heart Metrics

∗ 각 항목에 대해서 얼마나 만족하는지 확인하고자 구글에서 만든 프레임워크

∗ 항목 

- Happiness : 사용자의 심리적 만족

- Engagement : 사용자의 참여도 관여도

- Adoption : 사용자의 수렴도

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

- Task success : 사용자의 목표 달성도

 

➁ 1Page UT Planning (Usability Test)

∗ UT 과정은 중요하다는 것을 알지면 현실적으로 어려운 부분이 있기에 간소화한 방법이다.

∗ 테스트 절차, 목표, 실행 이유, 범위, 주제, 참여자 정보, 기준, 장비, 구체적인 태스크, 역할 정의, 장소, 시간을 한 페이지로 정리한 것이다.

 

➂ 게릴라 사용성 테스트

∗ 사용자가 있는 곳에 가서 즉석으로 짧게 테스트 하는 것을 뜻한다.

∗ 확인해야 될 게 있을 때는 언제든지 가능하다. (주로 개발에서 Deliver 로 넘어가는 시점)

∗ 참여자는 현장에서 모집 가능하고, 사용자를 모집할 때는 최소한의 조건만 갖춘 채 이뤄진다. (현장에서 모든 조건에 맞는 참여자를 찾기가 쉽지 않기 때문이다.)

 

 

⚡️UX디자이너에게 필요한 기본 개념

➊ A/B TEST

∗ A/B = As is / To be 혹은 A와 B중에 선호하는 것을 뜻한다.

∗ 지역별로 지역에 맞는 형태의 서비스를 찾기 위해 A/B 테스트를 대규모로 진행한다.

∗ 진행 과정

- 가설 수립 (사용자에게 크게 영향을 미칠 것 같은 부분 설정) → 변수 설정 (통제 변수 설정, 영향을 미칠 것 같은 부분 변경) → A/B 시안 제작 → 조사 설계 (기간, 대상, 테스트 방식, 지표 KPI)

 

➋ GOMS 

∗ 목표(Goals) + 조작 (Operation) + 방법 (Method) + 선택규칙 (Selection Rules)

∗ 특정 프로그램을 심어서 마우스 커서의 움직임, 클릭 순서 및 횟수 같은 것을 기록하고, 사용 모델과의 비교를 위한 대조군 모델, 센서를 이용해 사용자의 다양한 행동 정보를 수집하기에 수학적이고 굉장히 실험적인 방법이다.

 

➌ Affordance

∗ Affordance =행동 유도

∗ 기표를 통해 직관적으로 사용방식을 인지할 수 있게 하는 방법

∗ 텍스트를 읽지 않아도 “아, 이거구나” 하게 되는 것 (예시 : 문 한 쪽에만 손잡이를 달아서 한 쪽은 밀거나 당길 수 있게 하는 것)

 

➍ Metaphor

∗ 실제로 우리가 알고 있는 이미지의 형태를 갖고 와서 친숙하게 기능을 받아들이도록 하는 것 (예시 : 저장 버튼 = 플로피 디스크 (요즘은 쓰지 않지만 여전히 아이콘으로써는 쓰이고 있다.)

 

➎ Heuristic evaluation

∗ Heuristic evaluation = 전문가 평가

∗ 해당 전문가는 UXUI 전문가가 될 수도 있지만 특정 도메인 전문가의 평가가 될 수도 있다.

∗ 10가지의 기준

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

 

➏ Constraint

∗ 법률적/시회적 요구사항에 의한 디자인 제약

- 예시 : 만약에 자동 주차 기능을 넣을 시, "자동주차 실행 중 사용자가 2미터 이내에 대기해야 함" 이라는 조건을 추가 (긴급 상황 발생 시 운전자가 직접 개입해야 할 필요성이 있으므로)

∗ 퍼포먼스를 위한 디자인 제약

- 메신저에서 대용량 파일을 보낼 시 시간이 오래 걸릴 수 있기 때문에 시스템에 대한 이상이라고 생각할 수도 있다. = 불쾌한 경험으로 생각

∗ 플랫폼 특성에 의한 디자인 제약

- 사람이 버튼을 누르기 위한 최소한의 사이즈를 유지해야 한다.

 

➐ Cognitive Workload

∗ Cognitive Workload = 인지 부하

∗ 한까번에 갑자기 많은 정보가 주어질 때 과도한 자극으로 받아들이기 힘듦을 의미한다.

∗ 인지 부하의 고려 사항

- 과업을 수행하는데 필요한 정보를 처리하는데 드는 비용

- 사용자가 과업수행을 포기하거나 잘못된 판단을 내리도록 한다.

- 시각적 혼란을 피하기 위해 표준화되고 일반화된 메타포를 사용한다.

- 한번에 표시하는 정보의 양을 잘 고려해야 한다.

- 많은 정보를 표기해야 할 경우 정보의 그룹핑과 강약조절을 반영한다.

- 많은 사용자 입력을 요구할 경우 단계별 입력을 고려한다.

- 강조를 위해 너무 많은 중복메뉴를 제공하는 것을 지양한다.

 

➑ Fitt’s law

∗ 사용자가 목표로 하는 위치에 얼마나 빠르게 도달하는지에 대한 법칙

∗ 시작점에서의 거리와 목표의 크기에 따라 결정되며 행동의 범위가 정확할 필요가 없을 경우 수행속도는 더 빨라진다.

(대부분의 유저가 오른손잡이라서 과업에 빨리 도달하려면 왼쪽 하단에 버튼을 두는 것이 좋다.)

 

➒ Hick’s Law

∗ 선택 가능한 양과 선택에 걸리는 시간에 대한 법칙

∗ 사용자가 선택지가 많을수록 선택에 소요되는 시간이 증가한다. 따라서 한번에 적은 양의 옵션을 제공하거나 계층화 구조로 제공하여야 한다.

∗ 하지만 숙련도가 높은 사용자에게는 오히려 한꺼번에 많은 정보를 제공하는 것이 더 효과적일 수 있다. 

 

 

⚡️UX디자이너의 포트폴리오

∗ 사람들이 내 포트폴리오를 보는 시간 3분

∗ 3분 내에 임팩트를 줄 수 있어야 디테일하게 본다.

∗ 문서 자체가 포트폴리오인 경우가 많아서 텍스트가 많다.

∗ 좋은 포트폴리오 : 직관적 이해와 시선을 끌기, 무엇을 어떻게 왜 했는지

∗ 프로젝트 개요 → 프로세스 → 리서치 → 문제정의/컨셉정의 → 디자인 → Appendix

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