[학습일지] 221110 유저리서치 계획, 과제들, 강의노트)UX기초1-챕터7~8.UX디자이너 되기(完)

11.10(목) 체크리스트
■그룹프로젝트)계획서 보강, 구체적인 질문 작성, 폼만들기
□어플리케이션 불편요소찾기 과제 반 이상 하기(목표 9개) 몇시간동안 2개 반쯤 겨우 함
□레퍼런스찾기-화면 정하기, 화면구성 분석까지// 못했음..
■강의)UX기초1-남은거 듣기(7-4~8)
□강의)UX기초2-챕터7~12(완강) ㅎㅎ...

학습시간 6시간

 

---

그룹 프로젝트

조사에 앞서 구체적으로 설문지 질문을 만들고 보강했다. 데이터 수집이 충분하게 될 만큼 참여해줄지, 시간이 빠듯한데 잘 될지 다들 걱정하고있다 따흐흑. 잘 해낼 수 있기를!!!!

 

어플리케이션 불편요소,개선점 찾기

한 앱당 최소 5개를 찾아야하는데.. 5개까지 찾기가 너무 힘들다. 눈에 불을 켜고 찾으려해도 편한건 편해.. 앱을 관찰하면서 느낀건 불편한 점이 많은 앱은 그냥 수두룩하게 많고(불편하다는 의견에도 오랫동안 개선되지 않는 경우인 것 같다), 없는 건 1~2개정도로 끝인 느낌! 사용자 의견을 귀담아듣고 고민하는게 중요한 것 같다. 이거 다 제출할 수 있을까?하하.

강의 UX기초1 - 7~8챕터

기초1파트 완강~ A/B테스트의 가설 부분이 찾아봐도 헷갈렸었는데 해결되었다. 순서대로 이걸 먼저 다 들었어야 했네..ㅠㅠ 어디서나 다 그렇지만 당연한 얘기를 멋지게 정의하는게 많은 것 같다ㅋㅋㅋ 그래도 당연하지만 중요하니까.. 그리고 결과보다는 과정이 중요한 포트폴리오를 쓰는구나 느꼈다. 잘 할 수 있을까 히..히

 

여기까지.. 새벽까지 하고 학습일지를 쓰고있다.

오늘 하려 했던 학습량 다 못채우고ㅠㅠ 너무 슬퍼~!!

 

---

 

강의)UX기초1

 

Chapter 7. 디자인 평가 및 테스트

7-4. 사용성 평가

사용성 평가

사용자가 제품을 제작 의도에 알맞게 불편함 없이 사용할 수 있는지 확인 하는 것. 실제 사용을 관찰하고 발생할 수 있는 문제점 개선

딱딱한 병은 바닥이딱딱해서 잘 안나와서 기울여놨다 써야 한다. > 말랑이에 뒤집어서나옴 > 실제로 써봤더니 더러움  

1) 내부 사용자 테스트 - 내부 리뷰, UI 분석
Ui분석:  전문적 관점에서 뜯어보고 이해하기 쉬운 형태로 제공되고있는지 확인. 폰트,접근성 등 
전문가 평가(휴리스틱 검증) : 사용자가 모를 것들을 전문가 입장에서 찾아내기도 함. (대체로 사용자가 정보구조가 너무 복잡해. 하진 않으니까)

2) 사용자조사, 경쟁자비교분석
비교해서 알려주시겠어요? 이런 불편한 점들은 잘 개선 되었나요?
Feature coverage - 사용자가 원하는 기능이 다 들어있는가? 아웃포커싱기능을 좋아하는데 우리제품엔 없어. 어떡하지?
Ui comparison : 경쟁사의 UI는 어떻게 다른가 비교

 

사용성 평가는 언제 할까?

모든 시기에 다 할 수 있다. 왜 잘되는지 매력분석 - 더 극대화하여 장점을 부각시킬 수 있다.
특정 시점에서 이탈이 많다면- 이상사용현상의 원인파악

 

출시전 사용성 평가
1) 인 하우스 리뷰

자체적으로 UI 분석. 모든 발생가능한 Usecase가 정상적으로 동작하는지, 오류 발생 부분은 없는지

흐름, 디자인. 의도했던 형태로 잘 개발이 되었는가?

 

2)사용자 테스트

예상 사용자들을 대상으로 직접 테스트. 

 (1) Research point : Happy Path Comparison

우리(디자이너)가 생각할 때 task를 수행하기 위한 최적의 패스(지름길)

사용자가 쓸 때 다르다면 우리 해피패스와 비교하며 해피패스를 의도함.

 

 (2) Research point: Action time

사용자가 task를 수행할 때 까지의 시간.

30~40초면 될 거라고 예상을 했는데 68초가 걸린다면 그에 대해 분석

 

- 피츠의 법칙 (Fitts’ law)

HCI분야에서 인간의 행동에 대해 속도와 정확성의 관계를 설명하는 기본 법칙. 시작점에서 목표로 하는 지역에 얼마나 빠르게 닿을 수 있을지를 예측하고자 하는 것. 이때 결과는 목표 영역의 크기와 시작점과 목표점의 거리에 상관함.

내 손가락에서 버튼까지의 거리가 멀수록, 타겟이 작을수록 오래걸린다 (당연하다..)

 

 (3) Research point: Informative components

 

 (4) Research point: Problem solve

왼)로딩이 계속 도는데 취소하기 버튼도 없음  - 강제종료해야함

오)카드 등록이 잘못 됐는데 왜 잘못되었는지 설명이 없음.

 

 

3)전문가 리뷰

내부 또는 외부 UX전문가 또는 도메인 전문가(앱의 특성에 따라 금융,항공 등)를 섭외해서 평가 의뢰하기

 

-

 

주요 테스트 시나리오 정의 Primary use case

사용자 테스트에 사용할 주요 시나리오(Use case)를 도출. 이때 주요 시나리오는 제품의 핵심 기능 또는 자주 발생하여 대부분의 사용성에 큰 영향을 미치는 시나리오를 중심으로 선정. 첫번째 시나리오가 너무 길어진 경우 세컨더리는 생략하기도 함

사용자 테스트에 사용할 주요 시나리오(Use case)를 도출. 이때 주요 시나리오는 제품의 핵심 기능 또는 자주 발생하여 대부분의 사용성에 큰 영향을 미치는 시나리오를 중심으로 선정

 

테스트 실행

1) UT Room : 취조실처럼. 레코딩, 테스터, 테스트시스템, 모더레이터, 노트테이커, 옵저버  요즘은 잘.. 셋팅에 노력이 많이 들어가는데 비해 UT룸이 아니라도 딱히 차이 없어서 라이트하게 많이 하는 듯 하다

2) 책상에서 : 테스터, 모더레이터, 질문지+체크리스트, 레코팅, 테스트 시스템 

 

7-5. 사용성 평가 분석

사용성 평가 보고서에 포함되어야 하는 것

0) 표지

1) Executive summary : 개요 (요약페이지) 누구를 대상으로 어떤 순서로 진행되었다.

2) 테스트 참가자 정보: 10명을 잡았는데 노쇼해서 4명을 잡았습니다, 2년정도 배달서비스를 사용한 유저들이다. 모바일 쇼핑에 익숙했다. 페이서비스 경험도 가지고 있었다. 네명의 사용자가 어떤 특성을 가지고 있는지 

3) 주요 발견점: T1-사용자에게 준 태스크. 생각하는걸 소리내 말씀해주세요(think aloud 방법) 머릿속에 떠오르는 생각을 과감없이 소리내어 말씀해주세요.

긍정/부정/중립 답변 등으로 분류해 표기하기도 함. 해석을 추가로 달기도 한다.

4) 사용자의 주요 코멘트 (선택) : 실제 코멘트를 정리해서 넣기

5) 설문,만족도 평가 등의 결과 - 얼마나 어려웠는지, 평소에 하던 것들이었는지, 만족했는지

6) 개선점 정의+(우선순위)

 

 

다른 평가방법

1)Google HEART metrics

같은 팀원들이 다함께 참여해서 정의하는 식.

 

2)One page UT plan

중요하지만 부담스러워하는... 그래서 Lean UT plan 한 장에 진행하는 폼

 

 

3)게릴라 UT

바로 즉석으로 테스트하는 것. 커피숍 앞에 앉아서 이거 해주시면 커피 하나 사드려요~

-언제 하는게 좋을까?

 Develop에서 Deliver로 넘어가는 시점 (구체적인 개발 사항이 나와있는 상태)

가설 검증 및 주요 사용성 이슈 발견

• 아이디어의 구체적인 효용성 확인

• 가설 검증을 위한 사용자 테스트

• 문제 도출을 위한 사용자 테스트

• 사용자 아이디어, 피드백 수집

 

게릴라 사용성 테스트 준비

1.준비는 가볍게

데이터 신뢰성을 위한 일반적인 사용자 조사를 설계할 때처럼 할 필요는 없음. 게릴라 테스트의 핵심은 ‘빨리 확인하기’ 이므로 최소한의 준비(테스트 범위, 테스트 시간, 주요 질문)만 끝내고 바로 필드로 나가야 함. 

 

2.E2E test 는 안됨 게릴라에선 x. 커피하나 준다하고 1시간 앉혀놓을 순 없자나

E2E(End to End 제품 사용 시나리오의 처음부터 끝까지) 테스트는 5-10분안에 끝내야하는 게릴라 테스트의 성격과 맞지 않음. 확인하고자 하는 구체적인 시나리오를 뽑아서 집중적으로 테스트 해야함.

 

3.(가급적) 촬영하거나 수필 기록을 너무 열심히 하지 말 것

호손효과 Hawthorne effect(관찰되고 있다고 생각하면 평소보다 더 집중하여 좋은 결과를 내는 등 행동에 영향을 끼침)가 일어날 수 있으므로 가벼운 분위기 속에서 진행되도록 해야함

 

게릴라 사용성 테스트 실행

1. 참여자는 현장에서도 모집가능 낯가리고..

전통적인 느낌의 게릴라 테스트는 정말 현장에가서 즉석으로 사용자를 모집하는 것이지만 실제로는 꽤 현실적인 어려움이 있다. (의외로 참여자를 찾기 쉽지 않음) 따라서 사전에 미리 모집하고 기본정보를 수집한 뒤 가볍게 테스트를 진행하는 것도 게릴라 테스트의 한 방법이 될 수 있음 

2. No user screening guide

게릴라 테스트는 광범위한 무작위 방식의 테스트를 지향하기 때문에 사용자를 모집할 때 정말 최소한의 조건만 따지게 된다. (예: 모바일 app 테스트라면 사용자가 최소한 스마트폰은 사용하고 있어야 함.)

3. 사례도 가볍게

그 장소에서 판매하는 제품을 사주거나 (커피나 햄버거), 이게 여의치 않다면 기프티카드도 좋은 아이디어일 수 있음.

 

 

 

Chapter 8. UX 디자이너 되기

1. UX 디자이너에게 필요한 개념 - part1

A/B Test

: As is to BE , Which do you prefer A or B?

 

넷플릭스의 A/B

넷플릭스에선 지역별로 형태에 맞는 것을 찾기 위해 대규모로 자주 한다. 로그인이 안 된 상태에서 보여주는 화면

비회원인 사람이 우리 서비스를 이용하게 하는데에 어떤 버튼의 UI텍스트가 가장 성공율이 높을까? Call To Action(CTA)

후보가 꼭 2개일 필요는 없다

 

A/B test Process

1)가설 수립: CTA button에 따라 클릭 카운트가 달라질 것 같다.

2)변수 설정: UI text만 변경 (버튼 위치,다른 디자인은 동일함)

3)A/B 시안 제작: 총 6개의 시안을 제작

4)조사 설계: 기간-2주, 대상-페이지에 접속하는 아시아 유저

테스트방식1_랜팅페이지 접속한 유저들에게 랜덤으로 6개 노출 / 테스트방식2_지역별로 각 시안을 2주동안 노출

지표 KPI-랜딩페이지 접속 후 CTA를 통해 회원가입 페이지로 이동한 유저의 비율

 

 

A/B test 유의사항

1)가설 수립 : 명확한 가설은 A/B 테스트를 통한 정확한 인사이트를 얻기 위한 필수조건임. 가설이 없이 여러 디자인 시간을 단순비교 했을 경우, 특정 디자인이 트래픽을 증가시켰더라도 '왜' 증가했는지 해석할 수 없기 때문이다.

2)통제변수:  설정 두개의 시안을 제작한다고 가정 했을 때, 변수(=서로 다르게 만들 부분)는 하나만 적용하는 것이 좋음. 변수가 여러 개 일 경우 어떤 요인이 사용자의 행동에 영향을 끼쳤는지 파악하기 어렵기 때문임.

3) 테스트 실시 시점: 테스트는 가능한 동시에 실시하는 것이 권장됨. 시안별 테스트 시점이 다를 경우, 시간 자체가 변수가 되어 디자인 평가에 영향을 끼칠 수 있기 때문이다. 트렌드 변화 등으로 시간이 변수가 될 수 있기때문 ex)A안을 1월동안, B안을 2월동안

 

 

GOMS

목표(Goals), 조작(Operation), 방법(Method), 선택규칙(Selection rules)

사용자 인터페이스의 평가를 정량적으로 분석하기 위한 기법. 컴퓨터와 상호작용을 하나의 문제해결 행위로 보고 카드, 모란, 뉴웰이 제시한 모델링 분석 기법

누구나 아는 전설이지만 해본 사람은 많지 않은 방법이다. 실험적이고 수학적

 

 

테스트 설계 예시

지우려고자 하는 문장을 선택하여 하이라이트, - 1.셀렉트 딜리트 삭제하기 2.커서를 대고 한글자씩 지운다

모델의 예측과 실제 사용자의 수행 결과, 오브젝트의 위치에 따른 사용자 액션이 발생한 시간 (PDF를 보자..)

다양한 센서를 사용해 사용자 행동을 추적하고 시스템과 비교한다

visual..:내 시선이 이동하는 시간, 버튼을 볼 때 recognize: 인지하는 시간, tab: 클릭 등 탭에 걸리는 시간, recall:클릭 후 다음 액션까지 걸리는 시간, 확인하고 생각하는 시간

 

어포던스 (Affordance)

: 행동유도. 기표를 통해 직관적으로 사용 방식을 인지 할 수 있게 하는 것

어포던스가 약한 경우 - 물이 나오는 손잡이인데 어떻게 하는지 직관적으로 이해가 안되는 경우. 텍스트가 있어야 이해되는 경우

 

메타포 (Metaphor)

익히 알고있는 친숙한 이미지를 가져와 사용하는 것. 플로피디스크를 저장버튼으로 사용 등.

 

메타포를 사용하는게 항상 좋지만은 않다.

 

Heuristic evaluation (전문가 평가)

ux 전문가 뿐 아니라 도메인 전문가 등도 포함됨

 

UXUI전문가 관점에서 어떤 관점으로 평가해야 하는지 기술 (닐슨노멀)

1 시스템 상태의 시각적 표현 2 현실에서 익숙한 단어와 문구

3 사용자에게 통제권 제공 4 일관성과 기준

5 기억보다 직관 6 에러 예방

7 자유롭고 효율적인 사용 환경 - 사용자마다의 특성을 고려해 스타일에 맞게 사용할 수 있도록 제공(커스터마이징)

8 심미성 - 예쁜가

9 에러 해결 10 도움말 - 찾아볼 수 있는 무언가를 제공

 

 

 

2. UX 디자이너에게 필요한 개념 - part2

Design Constraint (디자인 제약사항)

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

 

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

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

한 번에 30장 까지만 보내게 제공하는 것, 용량 제한이 있는 것. 시스템의 쾌적한 환경을 위해 제약

 

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

버튼을 아기자기하게 만들고 싶어도 터치 기반에 맞는 최소 사이즈라는게 있다

 

Cognitive workload (인지부하)

짧은 시간에 많은 얘기를 들었을 때 아 머리아파 하는 것

과도한 자극, 너무 많은 정보량, 알 수 없는 아이콘 등

 

인지부하란 과업을 수행하는데 필요한 정보를 처리하는데 드는 비용을 말한다.

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

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

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

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

▪ 많은 사용자 입력을 요구할 경우 단계별 입력(Wizard UI)를 고려한다.

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

 

 

Fit's Law

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

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

 

 

 

Hick's Law

선택 가능한 양과 선택에 걸리는 시간에 대한 법칙. 사용자가 선택지가 많을 수록 선택에 소요되는 시간이 증가한다.

따라서 한번에 적은 양의 옵션을 제공하거나 계층화 구조로 제공하여야 한다. 하지만 숙련도가 높은 사용자에게는 오히려 한꺼번에 많은 정보를 제공하는 것이 더 효과적 일 수 있다.

 

- 많은 정보를 불가피하게 제공해야 할 경우에는 그룹핑을 이용하자

- 전문가 입장에서는 이미 그 데이터가 친숙하고 다 알고 있기 때문에 한 번에 많은 데이터를 보여주는 것이 오히려 좋다

 

 

 

3. UX 디자이너의 포트폴리오

UX 포트폴리오

만드는데 오래걸리지만 보는 사람은 3분 걸린다. 훑어볼 때 인상을 남길 수 있어야 꼼꼼히 본다

 

UX디자이너 포트폴리오의 특징

1)문서 자체가 포트폴리오

포트폴리오의 정보구조, 가독성을 위한 레이아웃, 콘텐츠의 강약조절

 

2)텍스트가 많음

디자인의 배경, 컨셉, 검증과정등이 기술되어야 하기 때문

하나의 이미지로 설명되기 보다 고민했던 것, 프로세스 등 과정에 대한 것들

 

좋은 포트폴리오 벤치마킹

 

-섹션 3개. 디자인 웍, 논문, 나의 디자인 철학

-채도가 낮은 톤 사용으로 디자인 웍에 집중하게 함.

-짧은 설명, 배경, 왜 했는가, 목표, 배경과 R&R 내가 구체적으로 기여한 부분, 나의 책임과 역할을 명확하게 표기. 참여하지 않은 부분 명시. 빼먹을 경우 본의아니게 부풀린다는 느낌을 줄 수 있음

-프로젝트의 시작: 목표를 이루기위해 이 문제를 어떻게 해석해서 이런 접근법이 좋을거라 생각했다

-필드리서치 : 리서치를 통해 발견한 것

문제 해결능력이 중요한 역량이기 때문에 그런게 포트폴리오에 나타나도록

-조사결과와 발견점, 구체적 문제 정의

+작은 글자들은 사실상 읽지 않고 그림만 보면서 봐도 이해되게 만들어져있다.

-실증적 원인파악을 위한 발견점의 구체화: 개선능력과 인사이트 도출 능력을 볼 수 있는

-문제해결을 위한 재정의, HMW(How Might We), 유저저니맵

내가 알고있는 지식들을 포트폴리오에 자연스럽게 녹임 (실제로 프로젝트에 써봤구나~)

-디자인과 데모비디오, 주요 기능 설명과 디자인

의외로 포트폴리오를 보는 사람들은 기능적인 면은 잘 안보는 경우가 많다. 기능평가하기엔 잘 모름

얼마나 핫한 기능인가보다 얼마나 이해하기 쉬운 형태로 보여주는가를 더 봄

-정보구조

-프로젝트를 진행하며 힘들었고 고민했던 부분. (그럼에도 불구하고 좋은 결과를 얻었다!)

-문제 해결을 위한 디자인적 관점에서 어떻게 접근했는가

전략적 appendix. 넣어야 하는데 잘못하면 흐름이 끊기게 되는 부분들. (pdf 더 봐~)

 

좋은 포트폴리오의 기준

1. 결과보다 과정

2. ‘나’의 디자인 철학이 보이도록 : 다들 이렇게 한다해서 했다(x)

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

 

포트폴리오 TIP

1. 디자이너 에세이 essay

앞페이지에 나의 철학을 보여주는 짧은 글을 넣어주면 좋다.

2. 에픽을 만들지 말 것

서른개를 했다고 서른개를 다 넣지 말 것. 주요 프로젝트를 넣고 나머지는 간략하게 넣기 등

3. 사진 선택은 신중하게

4. 정보 보안

문제가 될 것 같은 경우는 사전에 확인, 블러 처리할 것