UX 디자인사례와 커뮤니케이션

UX 디자인 사례와
디자이너-개발자의 커뮤니케이션
우 범 영 (pyramos@gmail.com)

1. UX 디자인 사례와
UX 디자인에서 사용자 이해의 중요성

Copyright © 2014 WOO, BEOM YOUNG. This document contains proprietary information and may not be used or disclosed except as authorized.
UX Examples - Huggies Wipes Pack
“I love the Huggies flushable wipes container -
it's small enough to throw into the diaper bag,
and super convenient. … grabbing a wiper in
the middle of a messy diaper change is as
easy as 1-2-3 and only requires one hand ...”

UX Examples - Elevator
엘리베이터 이용 경험

UX Examples - OXO Angled Measuring Cup
“Without bending over,
can be read from overhead.”
“They poured, bent down to measure,
poured again, bent down again …”

UX Examples – 화장품 용기 디자인
화장품을 어떤 순서로 사용하는가?
어떤 불편함이 있는가? 어떻게 뚜껑을 디자인 해야 할까?

UX Examples - LG “India Insight”
문화, 생활 환경, 학습 수준을 반영한 제품 디자인
인도 특화 냉장고 말하는 세탁기

User Experience의 구성 요소
source modified: “Abour Face 3.0”, Alan Cooper, 2007
“NOKIA, Designing User Delight”, Christian Lindholm, 2001
Form Function
Behavior
Industrial Design
Interaction Design
Interaction
Context
Content
Service +
Emotion
Feeling
Shape
CMF
Culture
Insight
Pleasure
Ethnography
Tradition/Convention
External & Internal
Overt “desire”
& Latent “needs”
Contents/Service Design
Physical Usability
Design considering context
“What customers don’t say ”
Information Architecture
UX

Square - Puts People in Business
휴대폰에서 신용카드 결제가 가능한 카드리더

More than Square - Square Wallet
카드를 긁을 필요 없이 결제할 수 있는 서비스
앱을 실행시키고 원하는 매장을 Tab한
후에
계산대에서 이름만 말
하세요
source: https://squareup.com/wallet

UX의 의미
WHY? : 밑바닥부터의 새로운 고민
• 이것이 왜 필요한가?
• 이것을 왜 하는가?
• 항상 하던 것에 대한 다른 그림을 그려보자
사용자에 대한 이해가 기본

어떻게 디자인 할 것인가?
스마트폰 스톱워치 앱 디자인을 위하여
무엇이 필요한가?

캘린더
어떤 앱이 가장 좋은 디자인인가?

캘린더
캘린더 이용 시나리오
친구와 약속시간 정하고 일정 등록하기
진민씨는 출근 시간에 버스 안에서 친구 경희와 메시지를 주고받던 중 저녁 시간에 만나자고 이
야기한다. 캘린더 앱을 꺼내어 달력을 살펴보던 중 급한 보고서가 마무리되는 다음달 첫 주 금요
일에 아무 일정이 없음을 확인하고 “5일 금요일에 시간 괜찮아?”라고 묻는다. 경희씨는 캘린더
앱을 열어 5일 금요일 저녁에 이미 약속이 있음을 확인하고 그날은 선약이 있다고 이야기하고,
다시 달력을 보던 중 그 다음주 수요일인 10일에 괜찮은지 진민씨에게 물어본다. 진민씨가 캘린
더의 10일을 찾아보자 캘린더에 무엇인가 일정이 있어 자세히 확인하니 점심에 팀원들과 식사
하는 약속이라서 10일 저녁에 만나기로 한다. 버스에서 내려야 할 때가 되어서 10일에 [등록하
기] 버튼을 눌러 ‘경희’라고 입력한 후 바로 일정을 저장한다. 진민씨는 퇴근 후 저녁 식사를 하고
침대에 누워 자유 시간을 보내다가 아까 급하게 저장했던 일정을 찾아 [수정] 버튼을 눌러 자세
한 시간과 장소를 입력한 후 다시 저장하였다.
Context Task

캘린더
Task 분석
날짜 보기 및 찾기
날짜와 요일 찾기 (1)
월 이동하기 (2)
일정 확인하기
특정 일에 어떤 일정이 등록되어 있나 없나 확인하기 (3)
특정 일에 등록된 상세 일정 확인하기 (4)
일정 등록/수정하기
일정 등록하기 (5)
일정 수정하기 (6)

캘린더
사용자들이 캘린더 앱에서 어떤 작업을 가장 많이 수행할까?
가장 중요한 과업을 잘할 수 있도록 디자인된 앱은?

지도
지도 앱의 시작 화면은 어떤 디자인이 좋을까?

지도
Task 분석
지도 보기(★★★★★)
현재 위치로 지도 이동하기
다른 위치로 지도 이동하기
지도 확장/축소하기
검색하기(★★★★)
검색어 입력하기
특정 종류의 위치 찾기(은행, 병원 등)
길찾기(★★★)
도착 위치 입력하기
출발 위치 변경하기
자동차로 길찾기
대중교통 길찾기

호텔 앱
모바일 호텔 앱 디자인에서 무엇을 고려해야 하는가?
누가 어떤 상황에서 가장 많이 이용하는 서비스인가?

호텔 앱
사용자에게 꼭 필요한 정보를 효과적으로 제공
적절한 기본값과 상황에 맞는 UI 구성요소 선택

페이스북 홈 화면
동일한 Task, Scenario에 따라 정보와 기능을 제공하는 경우에도
화면 디자인 및 스타일은 달라질 수 있다.
어떤 기준으로 다르게 구성할 것인가?

비행기 도착 시간 확인 기능 디자인
항공사 앱에서 비행기 도착 시간을 확인할 수 있는 기능을 어떻게 디자인할 것인가?
• 기능 중심의 접근: ‘비행기 도착 시간 알림’ 기능을 설계하자
• 시나리오 중심의 접근: 사용자가 어떻게 기능을 사용할 것인가?

비행기 도착 시간 확인 기능 디자인
기능 중심의 접근: ‘비행기 도착 시간 알림’ 기능을 설계하자
시나리오 중심의 접근: 어떤 사용자가 어떤 상황에서 어떻게 기능을 사용할 것인가?
사용자에게 무엇이 필요한가?
어떻게 디자인이 달라지는가?
T전자의 마케팅팀 과장 김미정씨는 중요한 손님인 미국 A 텔레콤사의 브라이언씨를 마중하
기 위하여 점심 식사 후 비행기가 정상적으로 출발하여 운항하고 있다는 것을 확인한 후 버
스를 타고 공항으로 향한다.
외근이 있다는 것을 어떻게 알았는지 오늘따라 비가 많이 내린다. 빗길에 길이 막히지는 않
을까는 생각에 서둘러 출발했더니 도착시간이 두 시간이나 남았다. 도착 게이트와 도착 시
간을 다시 한 번 확인한 후 근처의 커피숍으로 이동하여 노트북을 꺼내 오전에 작성하던 보
고서를 작성한다.
시간이 여유가 있을 때는 보고서에 집중했지만, 시간이 지나면서 도착 시간을 놓치는 것이
아닌가 신경이 쓰여 계속 시계를 보게 되고 보고서에 집중을 하기 어려워 노트북을 접고 휴
대폰으로 뉴스와 SNS를 보면서 시간을 보낸다.
예정 도착 시간 10분 전 미정씨는 도착 게이트로 이동하여 손님을 기다린다. 전광판에 비행
기가 도착이 표시된 후 약 10분 후에 브라이언씨를 만나 택시를 타고 회사로 향한다.

어떻게 디자인 할 것인가?
서비스 기획 정보
• 서비스 제공 대상
• 비즈니스 요구사항
(일정, 수익 모델, 홍보 방법 …)
사용자의 이해
• 누가: Persona
• 무엇을: Task
• 언제, 어디에서, 왜: Context
• 어떻게: Scenario
• 사용자의 기분은?
• 사용자가 원하는 것이 정말
무엇인가?
서비스/기기의 이해
• 경쟁/유사 서비스 Benchmarking
• 디지털 서비스 / 아날로그 기기
• 기존 서비스의 문제점, 불편한 점
• 모바일 기기에 대한 이해
디자인의 이해
• 디자인 트렌드, 좋은 디자인
• UI 원칙, 가이드라인
• 기기/OS별 디자인 가이드라인

2. 개발자와 디자인
그리고 커뮤니케이션

개발자와 디자이너
디자이너: “펜으로 원하는 색깔의 물체를 찍으면
그 색깔이 펜으로 나옴”
엔지니어: “우와~ 아이디어 쩌는데?
이거 원리가 뭐임?”
디자이너: “그건 니가 할 일이지 ”
엔지니어: “xxxxxxxxxxxxxxxxxxxx”
달라도 많이 달라요

개발자와 디자이너
왜 싸우는가?
• 남자와 여자의 싸움과 비슷하다
• 디자이너는 논리적이고 구체적인 개발자의 용어로 설명하기 어렵다: 그려서 보여주세요
• 용어에 대한 차이
• 디자인에 대한 의견의 차이
• 디자이너는 무엇이든 손을 대려고 한다 -> 개발자는 기본 UI가 익숙하다
• 개발자가 맘에 안드는 디자인 -> 어떻게 해결할까?

이러면 해결이 될까요?

UX/UI 디자이너?
제품 개발 프로세스의 HISTORY
• 최초에는 개발자들이 노키아폰 보고 문서를 만들었다. 물론 대표 화면만...
• UI를 하는 사람들이 등장했다. 적인가? 아군인가? 잘 모르니 일단 경계를 하자.
 UI 디자이너의 출신들 : 심리학, 산업공학, 디자인, 조선, ...
 더 어려울 수도 있다
• 우리의 문서 작업을 줄여주는건 좋지만, 요구 사항이 많아지고 새로운 디자인이 늘어나서 구
현할게 많아진다 - 여전히 경계모드
• 그래도 아직은 맘대로 구현해도 시비를 크게 걸지는 않는다. 일단 출시하면 그만이다.
• 언제부터인가 품질 부서가 UI 문서대로 구현을 했는가를 확인하기 시작한다. 문서와 구현 상
태를 맞추기 위한 전쟁이 시작된다.
• 여전히 애증의 관계. 잘 지내면 정말 좋고, 잘 못 지내면 정말 안 좋다.

UX/UI 디자이너?
내가 봐왔던 좋은 개발자들
• UI 문서를 정말 열심히 본다. (비키니 수영복 사진 목록?)
• 문서의 논리적인 문제에 대하여 이야기해준다. 심지어 오타까지.
• 문서에 정의되지 않은 부분이 무엇이고 어떻게 할지를 이야기해준다.
• 더 좋은 디자인에 대한 의견을 이야기해준다. 다른 사례와 함께 - 물론 과하면 안 된다.
• 디자인을 할 때 기술적인 이해를 설명해준다
• 디자인을 이해하려고 노력한다. (개발과 전혀 관계 없는 것도) 많이 물어보고 관심을 갖는다.
• 나의 작업을 존중해준다. 이건 참 좋네요. 더 좋아진 것 같아요
• 구현이 왜 안 되는가를 자세히 설명해준다. (UI 디자이너도 이해할 수 있다 - 물론 일부는) 그리고
같이 해결 방안을 먼저 찾아본다.
• 어느 정도 구현이 된 상태에서 먼저 연락해서 보여준다. 그리고 그것이 맞는가를 확인한다 (특히
맘에 안 드는 경우에는 더)
• 프로젝트 성공에 대한 공을 UI 디자이너와도 함께 한다.
• 회식할 때도 끼워준다.
• 기술의 발전으로 더 잘할 수 있는 방법을 이야기해주고 보여준다. 새로운 모델은 이 정도의 터치
반응, 그래픽/애니메이션 처리, 저장공간이 가능하다고 이야기한다.

UX/UI 디자이너?
내가 봐왔던 안 좋은 개발자들
• 무조건 안 된다고 한다. 안 되는 이유를 이야기하지 않는다.
• 되면서도 안 된다고 한다. 그리고 이렇게 버티라고 다른 개발자들에게 이야기한다.
• 직접 포토샵 작업을 한다 (이미지를 직접 만든다) - 자랑이 아니다
• 일정 문제, 실패의 문제에 대한 책임을 UI 담당자에게 떠넘긴다.
• 술도 안 마셔준다.
• 디자인에 대한 견해를 강하게 이야기한다.
• 다른 개발팀과 싸운다
 UI 디자인은 전체의 일관성을 바라봐야 한다. 따라서 기능간 일관적인 조작 방법을 적용해야 한다
 누군가는 바꿔야 한다 - 누가 바꿀 것인가? “ 왜 우리가 바꿔야 해요? ㅜㅜ”

이렇게 하면 어떨까요?
이해하기
• UI 담당자는 밤을 새지 않는다. 다만 제품을 출시한 후에도 다른 모델이 남아있다.
• 개발자도 일정이 부족하지만 UI 디자이너도 일정이 턱없이 부족하다. (밤을 샌다고 해결되
는 일이 아니다)
 문서의 품질이 처음부터 완벽할 수 없다.
• 책임감에 대한 수준이 차이가 나 보이지만, 같은 책임감을 갖고 있다.
 UI 디자인 문서는 품질 오류가 나지 않는다. 그렇지만 개발은 코드가 에러 나면 큰일난다. 그래서 쉽
다고 생각한다.
 그렇지만 UI 디자이너는 수많은 부서들과 커뮤니케이션도 해야 하고, 한번에 두세 개의 모델을 하기
도 하고, 사용자도 이해해야 하고…
• 고생 많이 한다. (물론 안 그런 사람들도 많다 ㅎ)
• 아무리 뛰어난 UI 담당자도 개발자만큼 디테일 할 수 없다

요구하기
• 이건 이렇게 저건 저렇게 해 주세요 - 너무 구체적으로 요구하지 말라. 해결책은 디자이너가
찾아야 한다
• 숫자보다는 사용자 입장에서 이야기하자 -
• 디자이너에 맞추어 요구하라
• 무슨 전공자인가? 디자이너 출신과 개발자 출신은 성향이 전혀 다르다
• 디자이너의 개발 지식 수준과 디자이너의 성향을 고려하라
 직접적으로 요구하기를 원하는 디자이너 vs. 문제를 던져주고 직접 해결하기를 원하는 디자이너 vs.
큰 방향 설정을 좋아하는 디자이너

모든 개발자들도 잘 하고 싶다
• 자신이 개발한 것이 사람들에게 편리하게 사용되기를 바란다
• 칭찬을 받으면 뿌듯하다
• 욕심과 열정이 있다.
좋은 팀은 함께 한다
• 애플: 조너선 아이브와 페데리기가 가까운 곳에서 일하고, 함께 같이 토의한다. 작은 디테일 하나
하나에 대하여 같이 이야기한다.
• 페이스북 paper 팀: 디자이너, 기획자, 개발팀이 처음부터 끝까지 고민하고 만들어낸다.
사람이 하는 일. 존중과 관계가 가장 중요
• 역할이 나뉘어있지만 관계가 가장 중요함
• 관계가 정말 어려우면 대기업에서, 특히 UI 개발은 하지 마라 -> 스타트업 해도 된다
서로에 대한 이해를 바탕으로 의미있는 논쟁을 하라
• 마지막에 웃을 수 있는 프로젝트
• 서로에 대한 이해와 존중 (디자인 일에 무관심하라는 이야기가 아니다)

Project Cartoon : 커뮤니케이션의 어려움
고객의 대답 기획 분석 및 디자인 개발 결과 투입된 비용
source: project cartoon (www.projectcartoon.com)

Project Cartoon : 커뮤니케이션의 어려움
기획 – GUI디자인 – 개발 사이의
커뮤니케이션 문제
UI 디자이너 역할의 중요성
실제 고객이 (머릿속에서)
필요로 한 것

디자인이란
• “사람들은 ‘디자인’하면 검은 터틀넥을 입고 뿔테 안경을 쓴 사람들이 혼자 해내는 것이라고 생
각한다 하지만 진짜 디자인은 세상의 문제를 해결하기 위해 모두와 함께 고민하는 일이
다”
(Tim Brown, CEO of IDEO)

무엇이 좋은 UX를 만드는가?
좋은 UX를 만드는 요소는?
좋은 UX를 만들기 위하여 필요한 것은?
• New Technology?
• Aesthetic Design? 3D Graphics?
• Creativity? Innovative?

무엇이 좋은 UX를 만드는가?
“Focus on the user, and all else will follow” – Google

UX 디자인사례와 커뮤니케이션

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to UX 디자인사례와 커뮤니케이션

Similar to UX 디자인사례와 커뮤니케이션 (20)

UX 디자인사례와 커뮤니케이션