사용자를 사로잡는 UX/UI 실전 가이드

사용자를 사로잡는 UX/UI 실전 가이드 - 시장에서 살아남는 화면 설계와 스마트한 데이터 활용법, 현실적인 브랜딩과 디자인 윤리까지
김성연 지음 / 루비페이퍼 / 2021년 12월

이 서평은 출판사로부터 도서를 지원받아 작성하였습니다.



언젠가 데이터 분석에 입문했을 때(사실 지금도 입문 수준인거 같긴 하지만요) 코딩만큼이나 도메인 지식이 중요하다고 강조하는 내용을 정말 귀에 피가 나도록 반복해서 들었습니다. 그 당시 코딩의 ㅋ자도 모르던(지금은 ㅋ자는 아는?!) 저는 우선 코딩 가지고 분석하는게 더 중요하고 멋있는 줄 알았습니다.

하지만 언젠가부터 도메인 지식이 왜 그토록 강조되는지 몸으로 체감하고 있습니다. 최근에 회사에서 UX/UI팀과 협업해서 데이터를 분석해야 하는 경우가 종종 있습니다. 로깅설계도 해야 하구요. 이 두가지 모두 UX/UI와 솔루션, 즉 도메인 지식을 탄탄히 갖추고 있지 않으면 접근하기도 어렵고 이리저리 분석을 해본다 해도 비즈니스 가치를 만들어낼 수 있는 좋은 분석을 내놓기 어려운거 같았습니다. 아니 분석 이전에 협업을 위한 소통조차도 어려운거 같더라구요. 저는 분석가로서의 언어와 행동을 훈련받았고, UX/UI팀은 해당 도메인을 잘 할 수 있도록 훈련받았으니까요. 

그래서 이 책을 잡고 지켜보기 시작했습니다. 모르는 UX/UI관련 개념들이 많다는 걸 알게되었고, 앞으로 꾸준히 공부해야겠다는 걸 느끼면서, 도메인 지식이 부족하니 좋은 분석이 나오지 않았다는 걸 다시금 느꼈습니다. 그럼에도 불구하고 출판사분들께는 죄송한 이야기를 드리자면, 이 책을 본 뒤에 엄청난 분석 인사이트를 뽑아낼 자신감이 솟구치진 않았습니다.

당연합니다. 이 책은 UX/UI 데이터 분석에 관한 책이 아니고 UX/UI 가이드 서적이기 때문입니다. 

다만 그 전에 파편적으로 알고 있던 UX/UI지식을 조금 더 연결시켜서 이해할 수 있었고, 특히 책 중간중간에 보이는 저자의 실무사례들을 보면서 회사 업무에 응용해볼 수 있지 않을까 기대감이 생겼습니다. 

책을 읽으며 UX/UI분석에서는 숫자에만 집착하기보다 숫자로 표현되지 않더라도 고객의 행동 흐름을 찾아내기 위해(물론 데이터로 입증하면 더더욱 좋지만) 그 흐름 속에서 분석을 하고 더 좋은 UX로 만들어내는 게 중요하다는 걸 배웠습니다. 

이 책에서 다른 부분은 수월하게 읽었습니다만, 픽셀 파트는 아무리 읽어도 제게는 복잡하고 난해하더군요. 이 부분은 전문가의 영역이라고 생각하고 스킵했습니다. 

꼭 UX/UI 담당자가 아니더라도, 데이터 분석가, 프론트 엔지니어와 같이 협업해야하는 포지션에 있다면 이 책을 읽어보시면 어떨까 싶습니다.

밑줄긋기

p.22

UX란 사용자가 어떤 제품이나 서비스와 상호작용하는 과정에서 얻는 총체적 경험을 의미한다. 가령 우리는 어떤 서비스를 사용하거나 관찰하고 또 교감할 때 행복감이나 편안함 혹은 불편함 같이 다양한 감정을 경험한다. 이러한 감정은 다음과 같은 요소들에 의해 형성된다.

- 배경(Context) : 사용자가 제품이나 서비스를 경험한 장소나 시간, 상황 같은 구체적 배경

- 요인(Motivation) : 행동을 일으키게 만드는 직접적인 요인

- 행동 방식(Behavior) : 제품 혹은 서비스를 사용할 때 발생하는 특정한 행동 방식

- 내적 욕구(Needs) : 어떤 것을 필요로 하는 내적 욕구

- 정서적 반응(Attitude) : 대상에 대해서 갖는 인지적, 정서적 반응

p.56~57

p.59

p.61

해상도의 기준은 서비스를 이용할 사용자가 되어야 한다. 사용자를 고려하지 않고 '요즘 많이 쓰인다'는 이유로 해상도를 결정한다면 문제가 발생한다. 예를 들어 새로운 기기 보급률이 상대적으로 낮은, 중장년 또는 노년층을 대상으로 한 서비스의 해상도에 최신 기기만 고려한다면 문제가 생길 수 있다. 반대로 MZ 세대가 대상인 서비스에선 지나치게 낮은 해상도까지 고려할 필요가 없을 것이다.

p.63

만약 하나의 앱에서 각 페이지를 디자이너 A는 픽셀 100개로 디자인을 하고 디자이너 B는 픽셀 200개로 디자인을 하면 어떻게 될까? 들쑥날쑥한 선명도에 이용자는 혼란과 불편을 겪을 것이다. 따라서 면적당 몇 개의 픽셀을 써야 한다는 기준이 생겨났다. 픽셀이 들어가는 최소 면적을 1인치(2.54cm)로 정한 것이다. 이 최소 면적을 단위로 만들었는데 이 단위를 가리켜 픽셀 밀도 혹은 ppi(pixel per inch)라고 한다. 앞서 두 원의 1인치당 픽셀 수를 이 단위로 표현하면 왼쪽 원은 10ppi, 오른쪽 원은 20ppi다. 같은 면적이라도 ppi가 높을수록, 즉 픽셀이 더 많을수록 세밀한 표현을 할 수 있다.

그렇다면 1인치당 픽셀 밀도가 높으면 무조건 좋은 걸까? 그렇지는 않다. 웹은 보통 72ppi를 기준으로 디자인한다. 이 수치의 기원은 애플에서 출발한다. 1983년 겨울, 애플의 최초 프린터인 ImageWriter는 144ppi로 설계됐다. 당시 디자이너들은 모니터에서 보이는 이미지의 크기와 출력물의 크기가 같으면 좋겠다고 생각했다. 모니터에서 볼 때와 달리 정작 출력하면 이미지 크기가 작거나 큰 경우가 빈번했기 때문이다. 이때 프린터 해상도의 절반인 72ppi 모니터에서 디자인하고 인쇄해 보니 모니터에서 본 이미지와 인쇄물에서의 이미지 크기가 거의 일치하는 것을 알 수 있었다. 이러한 정확도는 대중으로부터 큰 호응을 얻었다. 인쇄에서 시작된 기준이 오늘날 디지털 픽셀 밀도의 기준까지 연결된 것이다.

p.64

ppi가 가장 큰 영향을 미치는 요소는 이미지 크기다. 예를 들어 같은 모니터 두 대의 해상도를 각각 2560 x 1440과 1600 x 900으로 설정했을 때 2560 x 1440 해상도에서 아이콘이 더 작아지는 것을 알 수 있다. 이는 같은 면적이라도 픽셀 밀도가 높으면 픽셀이 압축돼 크기가 작아지는 속성 때문이다.

p.66

디스플레이 기술이 진화할수록 사용자들은 더 선명한 화면을 선호했다. 그렇게 2010년 대중의 요구와 기술이 만난 사건이 일어났다. 바로 애플이 발표한 '레티나 디스플레이'를 탑재한 아이폰 4의 출현이었다. 당시 아이폰 3G의 픽셀 밀도는 162.97ppi였다. 이는 모바일 적정 시청 거리에 필요한 픽셀 밀도보다 모자라 지금 보면 다소 흐릿하게 느껴진다. 레티나 디스플레이는 인치당 픽셀 밀도를 2배 늘려 탁월한 선명도를 보여 주었다.

초기 레티나 디스플레이의 픽셀 밀도는 2배에 불과했지만 기술이 발전함에 따라 3배로 점차 늘어나기 시작했다. 현재 iOS는 1x, 2x, 3x까지, 수많은 디바이스를 가진 안드로이드는 0.5x, 1x, 1.5x, 2x, 3x, 4x까지 픽셀 밀도를 지원한다. 실제 우리가 디바이스에서 보는 픽셀 밀도는 논리적 해상도, 물리적 해상도 그리고 다운 샘플링이라는 단계를 거쳐 기기에 적용되는데 이를 픽셀 밀도 변화과정이라고 한다.

p.71

안드로이드의 기준 단위에는 DP와 SP가 있다.

DP는 'Device independent pixel'의 약자로, 픽셀 밀도로부터 독립된 단위다. SP는 'Scale independent pixel'의 약자로, 글자 크기와 폰트만 독립적으로 변환이 가능하다는 뜻이다.

p.74

초기 스마트폰 시장은 네이티브 앱을 중심으로 형성되었고 지금도 가장 대중적인 모바일 개발 형식이다. 사용자 기기에 저장된 사진, 카메라, 캘린더, 주소록에 접근 권한을 가질 수 있다는 점도 네이티브 앱의 큰 장점이다. 덕분에 기기에 저장된 고유 정보를 활용해 사용자가 일일이 정보를 입력해야 하는 번거로움을 줄일 수 있다. 이러한 특징 때문에 네이티브 앱은 고성능 게임이나 카메라, GPS 등 센서를 활용한 앱 제작에 많이 활용된다.

p.75

하이브리드 앱은 네이티브 앱과 웹앱의 장점을 모두 가진 형태다. 겉으로 보기에는 네이티브 앱 같지만 실제로는 웹을 기반으로 하고 있다. 콘텐츠는 HTML 방식으로 제작하며 최종 앱 배포에 필요한 패키징 처리는 안드로이드, iOS에서 개발한다. 때문에 앱스토어나 구글 플레이 스토어 같은 플랫폼에서만 다운로드할 수 있다. 

하이브리드 앱은 앱 안에서 웹 페이지를 불러오는 방식이므로 한 번 설치하면 네이티브 앱이 가지고 있는 업데이트의 번거로움이 해결된다. 하지만 사용자의 네트워크 환경에 따라 속도가 일정하지 않다는 단점이 있다. 그럼에도 하나의 앱으로 다양한 웹 환경에 대응할 수 있다는 점은 하이브리드 앱의 매력이다. 대형 쇼핑몰이나 포털 사이트가 하이브리드 앱을 선호하는 이유이기도 하다.

패키징 : 최종 앱 배포를 위해 기능별로 실행 파일을 묶어 만든 설치 파일. 예를 들어 안드로이드 패키지 파일의 확장자는 .aab .apk다.

p.76

방식별 특징	네이티브 앱	모바일 웹앱	하이브리드 앱
디바이스 고유기능 접근	높음	낮음	중간
UI의 유려함	높음	중간	중간
업데이트 유연성	낮음(항상 앱스토어)	높음	높음
개발 난이도	높음	중간	높음

p.79

와이어프레임이 설게 도면에 가까웠다면 프로토타입은 실제와 비슷하게 입체적으로 구현한 모형에 가깝다. 이때 구현 단계에 따라 피델리티 레벨(Fidelity level)을 나눌 수 있다. 피델리티란, '성실도' 또는 '충실도'라는 뜻으로, 말 그대로 구현한 프로토타입의 기능과 디자인을 얼마나 충실하게 구현했느냐를 뜻한다. 구현한 수준에 따라 low fidelity와 high fidelity로 구분한다.

p.86~87

효과적인 유저 스토리 작성법

와이어프레임 제작이 끝났다면 이를 개발자에게 효과적으로 전달할 필요가 있다. 이때 '유저 스토리'라는 설명 방식을 알아두면 용이하다. 유저 스토리란 개발에서 '요구사항'이라고 부르는 시스템의 기능 설명을 '사용자 관점에서 이야기하는 것'을 말한다. 서비스를 만들다보면 다양한 태스크가 생기는데 이를 각각 유저 스토리로 작성해 두면 개발자와 완성도 높은 커뮤니케이션을 할 수 있다. 유저스토리의 기본 틀은 다음과 같다.

{사용자}는 {태스크}를 수행할 수 있다.

지금부터 인스타그램 하이라이트에 사진을 추가하는 예시를 통해 유저 스토리 작성법을 자세히 알아보자.

<인스타그램 하이라이트 업로드 과정>

1. 인스타그램 앱을 연다

2. 하단 탭의 프로필 사진을 눌러 프로필로 이동한다.

3. 프로필 바이오 아래에서 <새로 만들기>를 선택한다.

4. 게시해 둔 스토리 중에서 하나를 선택한다.

5. 표지를 추가하고 하이라이트의 이름을 쓴다.

6. <만들기>를 클릭한다.

이 과정을 유저 스토리의 기본 틀로 만들면 다음과 같다

{우디}는 {인스타 하이라이트에 사진 업로드}를 수행할 수 있다.

As a (사용자) -> {우디}

I want to (무엇을 원하는지) -> {인스타그램에 하이라이트를 업로드하고 싶다}

So that(수행함으로써 얻는 이득) -> {일상을 기록하기 위해서}

여기서 다음과 같은 인수 조건을 유저스토리에 추가한다면 디자이너가 원하는 기능을 더 확실하게 전달할 수 있으니 참고 바란다.

Acceptance Criteria(인수 조건)

Where {인스타 프로필 페이지에 진입한 상태에서}

When {프로필 하단 "+"버튼을 확인 후 클릭하면}

Then {사진 선택 후 하이라이트를 추가할 수 있다}

or {사진을 복수 선택하고 싶을 때}

And {하이라이트에 있는 기존 사진에서 1개 이상 선택할 수 있다}

p.104

주요 경쟁사들을 토대로 파악한 기능 비교 표

경쟁사/기능	영상 불러오기	영상 효과(필터)	영상 길이 조절	수정 기능	움직이는 스티커	배경효과	움직이는 템플릿	사진 다중 선택
Unfold	O	O		O	O	O	O	O
Made	O	O	O	O		O		O
Tezza	O	O		O				O
Instories	O	O	O	O	O	O	O	O
Sean	O	O			O		O
Story chic	O	O	O	O		O	O
Ash	O	O		O				O

p.120~122

p.123

정육점에서 직접 고기를 구매할 땐 눈으로 고기 두께를 볼 수 있지만, 온라인에선 고기 두께에 관한 정보를 수치로만 볼 수 있다. 당시 정육각을 비롯한 대부분의 온라인 정육점이 이런 방식으로 두께를 표현하고 있었다.

하지만 사용자들의 리뷰나 문의 전화에서 "상품은 좋은데 두께가 머릿속에서 잘 그려지지 않는다"라는 의견이 다수였다. 디자인적인 개선이 필요한 상황이었다. 당시 해당 수치들(11mm/16mm/24mm)은 육류 전문가는 널리 사용하는 익숙한 두께 표기였지만 일반인들에게는 낯선 수치였던 것이다. 용도를 표기하긴 했지만 글자만 있어 한눈에 잘 들어오지 않았다.

따라서 두께를 쉽게 비교할 수 있도록 누끼 컷을 활용해 육류의 두께를 시각적으로 보여주는 새로운 UI를 만들어 신속히 업데이트를 진행했다.

업데이트 이후 얼마 지나지 않아 두께에 대한 사용자 문의나 부정적 의견이 대폭 줄었고 이후 축산 서비스에서 널리 통용되는 UI 패턴이 되었다.

p.127~128

어피니티 다이어그램 진행 과정

1단계 : 수집한 정성적 데이터를 노란색 포스트잇에 적어 쭉 나열한다. 이 포스트잇 하나하나를 어피니티 노트(Affinity Note)라고 부른다(포스트잇 개수는 보통 50~100개가 적당하다).

2단계 : 연관성이 높은 어피니티 노트끼리 그루핑한다(중복되거나 가치 없는 포스트잇은 제거한다)

3단계 : 그루핑한 그룹들의 연관성을 고려해 파란색 포스트잇으로 어피니티 헤더(Affinity Header)를 만든다

4단계 : 몇 개의 어피니티 헤더가 생겼다면 빨간색 포스트잇으로 전체를 총괄하는 주제인 어피니티 슈퍼헤더(Affinity Super Header)를 만든다.

5단계 : 포스트잇 하나하나에선 보이지 않았던 인사이트나 패턴을 도출하고 완성된 어피니티 다이어그램 월(Affinity Diagram Wall)을 보며 리뷰를 한다(필요시 사진으로 남긴다)

어피니티 다이어그램의 가장 큰 장점은 여러 사람이 하나의 벽 앞에서 데이터를 식별하고 우선순위를 함께 만들어가는 것이다. 덕분에 보이지 않던 패턴과 인사이트를 발견해 문제를 보다 잘 해결할 수 있게 된다.

p.131~135

p.136~137

사용자 니즈를 중심에 두고 아이디어를 도출하는 대표적인 질문법으로 HMW(How Might We Questions?)가 있다. 이는 "어떻게/우리가/~할 수 있을까?"로 질문을 던져보는 것이다. 이 질문법은 미국의 다국적 기업인 프록터 앤드 갬블 사에서 시작되었다. 다음은 당시 프록터 앤드 갬블이 경쟁사 제품을 따라잡기 위해 사용한 HMW의 유명한 예시다.

- 어떻게 하면 더 나은 초록색 스트라이프 비누를 만들 수 있을까? (X)

- 어떻게 하면 소비자에게 조금 더 상쾌한 느낌을 주는 비누를 만들 수 있을까? (O)

이렇게 질문을 바꾸는 것만으로 몇 시간 동안 수백 개의 가능성 있는 아이디어가 도출됐고 결국 프록터 앤드 갬블은 성공적인 제품을 만들 수 있었다.

이처럼 질문을 바꾸는 기법, HMW는 활용성이 무궁무진하다. 가령 실무에서는 사용자 시나리오를 평서문 형태로 작성한 뒤 사용자 여정 스텝으로 변환해 HMW를 함께 활용하는 경우가 많다. 또, 어피니티 다이어그램의 슈퍼 헤더(사람들은 배송에 있어 기능적인 디자인을 추구한다)를 HMW(어떻게 하면 소비자에게 더 기능적으로 배송 디자인을 제공할 수 있을까?)로 바꿔볼 수도 있다. 다음은 소비자가 겪고 있는 문제를 짧은 시나리오로 만들어 HMW를 적용해본 예시다.

A는 혼자 자취하는 1인 가구로, 피자를 무척 좋아한다. 주말이면 피자를 한 판 시키지만 늘 끝까지 먹지 못해 반을 남기게 된다. 남은 피자는 소분 포장을 해서 냉동실에 얼려 두고 먹고 싶을 때마다 꺼내서 해동해서 먹지만, 처음 시켜 먹을 때의 피자 맛에는 많이 미치지 못해 늘 오래된 피자를 버리게 된다.

이를 사용자 여정 스텝으로 나눈 다음 HMW로 질문할 수 있는 부분을 작성하면 다음과 같다.

1. 배달 앱을 켜서 동네 피자 가게를 검색한다.

    - 어떻게 우리가 1인 가구 전용 피자 가게를 발굴하고 소비자와 연결할 수 있을까?

2. 먹고 싶은 피자를 주문한다.

    - 어떻게 우리가 주문한 피자는 남지 않을 것이라는 확신을 줄 수 있을까?

3. 피자가 도착한다.

4. 피자를 먹는다.

5. 남은 피자를 소분 포장해 냉동실에 얼린다.

    - 어떻게 우리가 남기지 않고 한 번에 다 먹을 수 있는 1인 피자를 제공할 수 있을까?

6. 다음날 먹는다.

    - 어떻게 우리가 다음날 먹는 피자도 맛있게 먹는 방법을 제공할 수 있을까?

7. 오래된 피자는 버린다.

이렇게 추출한 HMW 질문에서 다음과 같은 아이디어를 도출할 수 있다.

- 1인 가구라면 1인 피자를 구매할 수 있는 가게를 상단에 노출시키는 기능

- 1인용에 적당한 양, 형태의 피자 개발

- 남은 피자를 다음날에도 맛있게 먹는 방법 또는 다른 요리로 활용할 수 있는 레시피를 QR로 제공

만약 아이디어 도출에 고민이 된다면 다음 세 가지 방법을 고려하면 좋다.

- Crazy 8's : 구글 디자인 스프린트에서 등장한 아이디어 도출법으로, 팀이 모여 각자 8분 동안에 8등분한 종이에 빠르게 아이디어를 스케치한다. 이때 중요한건 질보다 양이다.

- 역 브레인스토밍 : 해결하고자 하는 과제를 한 문장으로 정의한 뒤, 해결에 완전히 반대되는 질문을 한다. 예를 들어 '어떻게 하면 최악의 랜딩 페이지를 만들 수 있을까요?' 같은 식이다. 이후 원래 해결하고자 했던 문제로 다시 돌아가 보면 더 나은 대안이 떠오를 수 있다.

- 스캠퍼 : 브레인스토밍 기법으로 7가지 원칙에 맞춰 질문하고 발상하는 기법이다. 첫 글자를 모아 SCAMPER라고 명명한다.

1) 대체하기(Substitute) : A를 B로 대체할 수 있을까?
2) 결합하기(Combine) : A와 B를 합칠 수 있을까?

3) 응용하기(Adapt) : A를 B로도 사용할 수 있을까? A와 비슷한 건 없을까?

4) 수정 확대 축소하기(Modify Magnify Minify) : A를 수정하거나 확대 혹은 축소하면 어떨까?

5) 전혀 다른 용도로 사용하기 (Put to other uses) : A를 Z로도 사용할 수 있을까?

6) 제거하기(Eliminate) : A의 일부를 제거하면 어떨까?

7) 반전 재정렬하기 (Reverse Rearrange) : A와 B의 역할을 바꿔보면 어떨까?