태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.


'디테일'에 해당되는 글 5건

  1. 2018.08.27 [UI 디테일] 모바일 동영상 플레이어 내 Gesture UI 살펴보기 by 위승용 (uxdragon)
  2. 2018.03.15 [UI 디테일] 신한카드 Fan 앱카드 약관 동의 UI의 불편함 (2) by 위승용 (uxdragon)
  3. 2013.09.27 퍼소나의 디테일이 중요한 이유 (2) by jun.ee
  4. 2011.05.13 [UI 디테일] 웹사이트 로그인, 어떤 방식으로 하는것이 좋을까? (4) by 위승용 (uxdragon)
  5. 2010.09.20 [UI 디테일] 아이폰4와 아이팟터치 UI 디테일 비교 (8) by 위승용 (uxdragon)
2018.08.27 07:50

[UI 디테일] 모바일 동영상 플레이어 내 Gesture UI 살펴보기

시작하며

우리의 일상에서 동영상 시청이 차지하는 비율이 점점 높아지고 있다. 필자 또한 예전보다 동영상을 감상하는 시간이 많이 늘어난 것을 실감하고 있다. 그리고 집에 있는 TV보다는 모바일로 영상을 감상하거나 이동 중에도 수시로 영상을 감상한다. 어느 날은 모바일로 유튜브 영상을 보다가 우연히 플레이어 영역을 ‘두 번 터치’ 한 경우가 있었는데 '10초 다음으로 이동’ 기능이 제공되어 놀랐었던 경험이 있다.

개인적으로 UCC(User creative contents) 중심 UI는 Youtube가 선도적이라고 생각하는데, 그도 그럴 것이 동영상 플레이어 관련한 새로운 기능들은 대부분 Youtube에서 출발한 것들이 많다. (세로 모드로 영상 시청 중 화면을 아래로 쓸어내리면 '미니 플레이어’로 전환되는 방식도 Youtube에서 먼저 제공했던 것으로 알고 있다. 현재는 해당 멀티태스킹형 UI가 표준화되었지만 말이다)

이와 맞물려 시간이 지남에 따라 모바일 플레이어 앱 서비스는 점점 고도화되고, 사용자의 편의를 위해 한정된 영역에서 다양한 기능을 활용할 수 있는 다양한 방식들이 고려되고 있다. 이에 각종 모바일 동영상 플레이어에서 Gesture를 어떤 식으로 활용하는지 사례를 간단하게 찾아보았다. 사실 IT 업계가 그렇듯 1~2년만 지나도 새로운 것이라고 생각하던 서비스들이 옛날 것으로 바뀌는 것이 현실이다. 하지만 현시점에서의 UI가 나중에 또 어떤 방향으로 변화하는지 살펴보는 것도 흥미로울 것 같다.

[그림1] Youtube 동영상 플레이어 : 미니 플레이어 전환


조사 개요 : 2018년 8월 21일 기준, iOS 모바일 앱, VOD(Video on demand) 콘텐츠 위주로 조사

(Youtube, 페리스코프, TVING, 옥수수, 비디오포털)

해당 조사는 ‘실시간 TV' 화면은 포함하지 않았다. 그 이유는 실시간 TV의 경우 구간탐색 기능을 제공하고 있지 않아 VOD 플레이어보다 상대적으로 적은 기능을 제공하기 때문이다. (국내 VOD 제공 서비스에서는 보편적으로 실시간 TV에서 좌/우 Swipe 시 이전/다음 채널로 이동하는 UI를 제공한다)

또한, 해당 글에서는 손가락을 댄 후 한쪽 방향으로 드래그하는 동작을 편의상 Swipe로 용어를 통일하였다. UI설계를 하다보면 해당 용어를 혼용해서 사용하는 경우가 있는데, 필자도 설계할때마다 헷갈리는 부분 중 하나이다.

  • Swipe : 손가락을 댄 후 일직선으로 드래그하는 동작
  • Flick : 손가락을 댄 후 빠르게 한쪽 방향으로 긋는 동작



1. Youtube

Youtube VOD는 기본적으로 영상을 한번 탭 하면 관련 버튼들이 호출되고, 다시 탭 하면 사라지는 방식으로 제공된다. (다른 동영상 플레이어도 유사한 방식을 제공한다) 그리고 VOD 영상의 좌측 영역을 두 번 탭 하면 10초 이전으로, 우측 영역을 두 번 탭 하면 10초 다음으로 이동한다. 또한, 세번 탭 하면 20초, 네번 탭 하면 40초 단위로 이동한다. 즉 해당 기능을 재생구간 이동 용도로 활용하고 있다. 이건 최근에 추가된 기능인데, 영상에서 하→상 방향으로 Swipe 하면 관련 동영상 목록을 불러올 수 있다. 이는 단순히 하나의 영상을 감상하기만 하는 것이 아니라 다양한 영상을 쉽게 탐색할 수 있도록 하는 기능을 강조하려는 의도라고 생각한다.

유튜브 플레이어(Web)의 과거


그렇다면 건너뛰는 플레이 타임을 어떤 기준으로 잡는것이 좋을까?

한상택 | Youtube 웹에서는 더블 클릭은 전체화면 전환 기능으로 제공되며, 화살표 좌/우 키 선택 시 5초 단위로 제공된다. 그 외의 사례를 보면 동영상 서비스의 원조 격인 Tivo 의 instant replay는 8초 단위로 제공된다. 또한, Roku는 7초 단위로 제공한다.

문한별 | 건너뛰는 플레이 타임을 어떤 기준으로 잡아야 할까 생각해보다가, 영상을 만들 때 각 컷은 몇 초를 기준으로 편집하는지 알아보았다. 일단 드라마와 영화가 상황이 조금 다르다고 한다. 영화는 한 컷 자체 농도가 짙다. 그래서 컷 하나에도 더 심혈을 기울여서 많은 것을 보여주어야 하며, 컷 전환이 너무 빠르면 몰입을 해친다고 한다. 반면 드라마는 짧게는 1초 단위로 컷 전환이 이뤄진다고 한다. 인물과 환경을 설명하는 설정 숏트라는게 있는데 이게 보통 3초 정도 된다고 한다. 설정 숏트 이후부터는 주인공 A의 모습 2초, 말하는 모습 클로즈업 1초, 그 말을 듣는 B의 반응을 1초로 보여주는 식이다. 그래서 10초 이상은 아예 다른 씬으로 뛰어넘을 수 있는 시간이 되기 때문에 "3초에서 7초 정도가 플레이어에서 건너뛰기로 적당하지 않나?" 는 업계 관계자의 의견을 들을 수 있었다. 물론 일반화하긴 어려운 얘기다.

[그림2] Youtube 동영상 플레이어 : 주요 Gesture



2. 페리스코프 (Periscope)

실시간 개인방송을 지향하는 페리스코프에서도 VOD를 제공한다. 페리스코프는 기본적으로 세로 모드 영상을 제공하는 것이 특징이다. 페리스코프에서는 VOD 영상을 Long Tap 하면 구간 탐색 기능을 제공한다. 조금 특이한 방식이고, 재미있기는 한데 전체 영상 시간을 직관적으로 알 수 없고, Gesture를 이어서 진행하기에는 불편한 느낌이다. 구간탐색 모드에서 구간탐색은 좌/우 Drag로 이동하고, 좌/우 구간탐색을 하는 중에 상/하 이동을 같이 수행하면 미세 조정이 가능한 방식으로 되어있다.

[그림3] Periscope 동영상 플레이어 : 주요 Gesture



3. TVING

TVING VOD에서는 좌측영역을 상/하 Swipe 하면 밝기조절 기능을, 우측영역을 상/하 Swipe 하면 음량조절 기능을 제공한다. 그리고 좌/우 Swipe를 하면 추천 채널 및 회차 이동 UI를 제공한다. 좌→우 Swipe 하면 '인기 Live 채널' 호출을, 우→좌 Swipe 하면 '회차, 최신방송'을 호출한다.

[그림4] TVING 동영상 플레이어 : 주요 Gesture



4. 옥수수 (Oksusu)

옥수수 VOD에서는 좌측영역을 상/하 Swipe 하면 밝기조절 기능을, 우측영역을 상/하 Swipe 하면 음량조절 기능을 제공한다. 그리고 좌/우 Swipe 하면 재생구간 이동 기능을 제공한다. 이 외에 타사에 없는 새로운 기능을 제공하는 것이 하나 있다. 화면을 Double Tap 하면 가로 모드에서 세로 모드로 전환, 세로 모드에서 가로 모드로 전환한다. 확실히 특이하긴 하지만 유용한 기능인지는 잘 모르겠다.

[그림5] 옥수수 동영상 플레이어 : 주요 Gesture



5. 비디오포털

비디오포털 VOD에서는 좌측영역을 상/하 Swipe 하면 밝기조절 기능을, 우측영역을 상/하 Swipe 하면 음량조절 기능을 제공한다. 그리고 좌/우 Swipe 하면 재생구간 이동 기능을 제공한다.

[그림6] 비디오포털 동영상 플레이어 : 주요 Gesture



정리하며

다음과 같이 모바일 동영상 플레이어 내 Gesture UI를 간략하게 살펴보았다. 예전에는 동영상 플레이어에서 Gesture를 잘 활용하지 않았지만, 요즘에는 고객의 시청 경험을 향상하기 위한 부가요소로 Gesture가 적절히 활용되고 있는 것을 알 수 있다.

[그림7] 각 VOD 서비스별 Gesture를 통한 UI 호출방식


한 가지 흥미로운 점은 대부분의 국내 서비스는 상/하 Swipe 하면 밝기조절과 음량조절을 제공한다는 것인데, 정작 해외 사례를 보면 상/하 Swipe를 다른 부가적 기능으로 활용(관련 동영상 호출)하거나, 해당 Gesture를 사용하지 않는 것을 파악할 수 있었다. 또한, 대부분의 국내 서비스에서는 좌/우 Swipe는 구간 탐색 기능이나 관련 영상 호출 기능으로 활용하는데 해외 사례에서는 좌/우 Swipe Gesture를 활용하지 않는 경우가 대부분이었다. 상/하/좌/우 Swipe 기능이 잘 활용이 되면 유용하겠지만, 사용자의 입력 오류를 발생시킨다는 점을 고려해 신중히 활용되어야 할 것이다.

N Player의 경우 좀 더 나아가서 Gesture를 별도로 커스터마이징 할 수 있는 기능을 제공한다. 모든 설정이 귀찮듯, 커스터마이징을 사용자에게 전부 맡길 수는 없겠지만 필요에 따라 사용자의 성향과 상황에 맞는 Gesture를 제공할 수도 있겠다.

[그림8] N Player : Gesture 커스터마이징


물론 Gesture 사용에 있어서 단점도 존재한다. Gesture는 직접 사용해보지 않고는 해당 기능이 있는지 알기 어렵고, Gesture 자체가 익숙하지 않은 경우도 있다. 이러한 문제를 해결하기 위해서는 ‘도움말’ 같은 팝업 화면을 활용하여 안내할 수도 있다. 팝업 형태의 안내도 있겠지만 Youtube에서는 프로그래스 바의 Knob을 잡고 Drag & drop을 했을 때 상단에 구간이동 Gesture에 대한 간단한 설명을 제공한다. 이런 방식으로 자연스럽게 사용자에게 기능을 안내하는 것도 바람직한 방향이라고 생각한다.

[그림9] NaverTV 동영상 플레이어 : Gesture 이용 가이드


[그림10] Youtube 동영상 플레이어 : 재생구간 Gesture 이용 가이드


반면 넷플릭스의 동영상 플레이어는 Gesture 기능이 제공되지 않는다. Gesture 기능이 제공되지 않는다고 해서 특별히 사용이 불편한 것도 아니다. 만약 동영상 플레이어의 Gesture UI를 기획해야 한다고 하면, 이러한 점을 함께 염두에 두어야 할 것이다. 마지막으로 단순히 타사를 참고하기만 할 게 아니라, 어떤 Gesture와 기능을 활용할 수 있을지 깊이 있게 고민해야 한다. 좀 더 나은 UI를 기획하기 위해서는 당연하게도 더 많은 고민이 필요하고, 그것은 결국 사용자의 편의를 위한 것이어야 한다. ⓦ



[참고##UI 디테일##]



팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 0
Ad Test...
2018.03.15 07:50

[UI 디테일] 신한카드 Fan 앱카드 약관 동의 UI의 불편함


최근에 우연한 기회로 신한카드 Fan 앱카드를 가입하게 되었다. 가입 중에 약관 동의 페이지를 접했는데 입력해야 할 항목이 많아서 깜짝 놀랐다. (약관 동의 UI 화면은 하단 이미지를 참고하길 바란다.) 해당 페이지에서 느꼈던 UI 상의 불편함은 다음과 같다.


[신한카드 Fan 앱카드 약관동의 UI]

[신한카드 Fan 앱카드 약관동의 UI (동의 체크시 Flow)]


1. 입력의 불편함

일단 기본적으로 해당 약관 동의 UI는 체크박스가 너무 많다. 물론 '전체 동의’ 버튼을 누르면 모든 약관에 동의가 되기는 한다. 하지만 선택 약관을 해제하기 위해서는 일일이 선택해서 동의 해제를 해야 한다.

그리고 해당 약관은 대 카테고리 약관과 소 약관이 있는 구조로 되어있는데, 대 카테고리 약관에 동의하면 화면에 보이지 않던 소 약관들까지 한 번에 펼쳐지는 구조로 되어있다. 펼쳐지기 전 보이는 화면이 복잡해서 그러려니 했지만 약관이 펼쳐지는 순간 갑자기 복잡한 화면이 등장하는 바람에 혼란스러웠다.

(타사 사례로) 좌측 이미지는 카카오 뱅크의 약관 동의 UI이다. 카카오 뱅크 약관 동의 UI는 전체 동의 버튼을 하나만 두고, 기타 약관의 경우 동의 표시만 주고 있다. 또한 전체 동의 버튼 선택 시 선택 동의가 추가로 보이는 구조로 되어있다.

[좌-카카오 뱅크 / 우-신한카드 Fan 앱카드]


2. 레이블의 문제

해당 약관 동의 UI는 어떤 기준인지는 모르겠지만 [선택] 카테고리 하위에 [필수] 약관 동의와 [선택] 약관 동의가 섞여 있는 구조로 되어있다. 그래서 해당 약관이 선택 가능한 약관인지, 필수로 해야 하는 약관인지 혼란을 준다.

자잘한 이슈이지만 [선택], [필수] 약관 표시 전 약관 명과 띄어쓰기가 통일되어있지 않아 보이는 것도 신경 쓰인다.

약관을 동의하고 나서 추천인을 등록하는 UI가 있는데, 분명 [선택] 항목이라고 되어있으나 선택하지 않으면 다음 단계로 진행되지 않는 것도 문제이다.

좌측 이미지는 자사 신한카드 약관 동의 UI이다. 신한카드 약관 동의 UI는 필수 약관과 선택 약관을 분리하였다. 필수 약관에 전체 동의 체크박스를 두어 필수 약관 우선 전체 동의하고 그 이후에 선택 약관을 고를 수 있게끔 한다. 또한 필수 약관과 선택 약관의 구분이 비교적 명확하게 되어있다.

[좌-신한카드 / 우-신한카드 Fan 앱카드]


3. 항목 구별의 문제

해당 약관 동의 UI는 [필수] 약관과 [선택] 약관이 시각적으로 명확하게 구별이 되지 않는다. 그래서 필수 약관인지 선택 약관인지 주의 깊게 살펴보아야 하는 문제가 있다.

또한, 대 카테고리 약관과 소 약관의 구별이 잘 되지 않아 시각적으로 더 복잡해 보이기도 한다.

[접기] / [펼치기] 버튼과 약관 상세정보 [더보기] 버튼 스타일이 동일하게 되어있어 내용을 주의 깊게 살펴보고 버튼을 눌러야 한다.

(타사 사례로) 좌측 이미지는 K뱅크 약관 동의 UI이다. 필수 약관과 선택 약관의 구별이 시각적으로 명확하게 구별되어 있으며, 필수/선택 항목을 약관 명보다 우선해서 보여줘 빠르게 인지를 할 수 있다.

[좌-K뱅크 / 우-신한카드 Fan 앱카드]


정리하며

다음과 같이 신한카드 Fan 앱카드 약관 동의 UI의 문제점을 살펴보았다. 신한카드의 경우 잘 하고자 하는 ‘의지’는 있지만 뭔가 다른 문제로 인해 사용성에 문제가 생긴 경우라고 볼 수 있다.

UI 기획을 하다 보면 서비스마다 약관 동의 화면을 기획하게 된다. 약관 동의 화면은 정책적인 이슈로 인해 화면 기획을 보수적으로 설계해야 하는 어려움도 있고, 상대적으로 중요한 페이지에 밀려 기획의 고민이 소외될 수밖에 없는 영역이다. 하지만 약관 동의 화면을 제대로 설계하지 않을 경우 사용자는 이 서비스에 대한 인상이 나빠질 수밖에 없다. 약관 동의 화면은 앱 사용에 있어 최전선에 있는 화면이고 좋든 싫든 간에 마주할 수밖에 없는 화면이다. 해당 UI의 제약점을 알고 조금 더 사용자 친화적으로 설계했으면 하는 바람이다.

마지막으로 매력적인 약관 동의 UI를 찾아보았다. 좌측은 Toss 약관 동의 UI이고, 우측은 카카오페이 약관 동의 UI이다. 물론 실제로 서비스에 적용하기에는 제약점이나 한계가 있을 것이다. 내가 어떤 약관에 동의하는지 안내하고 [동의] 버튼을 누름으로써 갖가지 약관에 즉시 동의할 수 있게 하는 UI가 현재로서는 그나마 이상향에 가까운 UI라고 생각한다.

[좌-Toss / 우-카카오페이]


[참고##UI 디테일##]



팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 2
Ad Test...
2013.09.27 00:54

퍼소나의 디테일이 중요한 이유

이 글은 제가 발제한 글에 대해서 사내메일 상으로 토론한 내용을 정리한 것입니다. 발제글에는 편의상 경어를 생략했으니 양해바랍니다 :)

발제글

퍼소나의 디테일이 중요한 이유

2010년 마이크로소프트(이하 MS)의 윈도우7 팀은 퍼소나를 포기했다고 한다. 앨런쿠퍼의 정신병원에서 뛰쳐나온 디자인(The Inmates Are Running the Asylum)책의 출간이후 2000년 초기 MS의 사무실 벽마다 퍼소나가 붙어있던 것에 비하면 상전벽해 같은 일이다.

퍼소나를 포기한 이유는 어차피 디테일하게 퍼소나를 만들어봤자 아무도 안 보기 때문이라고.
심지어 37signals 같이 퍼소나가 필요없다는 의견을 주장하는 곳도 있다. 자기들의 문제를 해결하는데 퍼소나가 왜 필요하냐는 것이다.

그러나 이런 안티퍼소나 입장을 취하는 의견이나 태도들은 사실 퍼소나를 제대로 이해하지 못하기 때문에 발생한다고 본다.
퍼소나는 커뮤니케이션 도구이기도 하지만 추론도구이기도 하며, 디자이너에게는 이 추론도구로서의 역할이 더 중요하다.

추론도구로서의 퍼소나

Cooper사의 인터랙션 디자이너인 Chris Noessel이 퍼소나가 통하는 또 다른 이유에 대해 글을 썼는데, 내 나름대로 편역 및 요약하자면 이런 내용이다.

철학자 Daniel Dennett에 따르면, 인간은 추론(reasoning)을 할 때 다음 3가지 스탠스 중 하나의 스탠스를 취한다.

  1. 물질적(Physical) 스탠스 - 내가 이 모래를 불 위에 끼얹으면 어떻게 될까? 와 같이 기본적인 물질적 감각을 사용하여 일이 어떻게 일어날지에 대한 짐작
  2. 디자인(Design) 스탠스 - 새의 날개는 새가 날 수 있도록 만들어진건데, 그럼 저 새가 날개를 펄럭이면 어떻게 될까? 와 같이 사물이 만들어진 용도, 기능, 디자인에 대한 이해를 바탕으로 짐작
  3. 의도적(Intentional) 스탠스 - 나를 쫓고있는 저 호랑이는 내가 저 동굴 안으로 몸을 피하면 어떻게 행동할까? 와 같이 의도를 가진 생물(intentional agent)이 원하는 결과를 얻기위해 무슨 의도로, 어떻게 행동을 바꿀지에 대한 짐작

그럼 이것들 중 인터랙션 디자인에 적합한 추론방식은 무엇일까.
우선 사용자의 행동을 물질적으로 규정하는 일은 없으므로 물질적 스탠스는 맞지 않다.
다음으로, 디자인 스탠스는 바이메탈의 물질적 동작원리는 모르더라도 바이메탈이 특정 온도에서 휘는 기능(function)에 대한 이해를 바탕으로 그것을 온도계로도, 전기다리미의 부품으로도 쓸 수 있게 한다. 하지만 이렇게 기능에 따라 입맛에 맞게 바꾸는 특징은 인터랙션 디자인에서는 elastic user문제를 낳는다. ‘사용자’라는 특정 기능을 가진 존재가 이럴 땐 이렇게 행동하고 저럴 땐 저렇게 행동할 것이라고 입맛에 맞게 추론해버리기 때문이다. 이처럼 디자인 스탠스는 대부분의 사람들이 디자인을 할 때 취하는 기본적인 스탠스지만 틀린 방식이다.
따라서 인터랙션 디자인을 할 때는 End Goal - 잘 변하지 않는 사용자의 목표 - 을 이루기 위해 사용자가 어떻게 행동을 할지 그 의도를 추론하기에 적합한 의도적 스탠스를 취해야 한다.

3가지 스탠스가 철학적 관점으로도 충분히 납득가능 하지만, 실제로 Glasgow Caledonian University와 MIT의 공동연구 결과에 따르면 각 스탠스에 따라 추론을 할 때 뇌의 각기 다른 부분을 사용한다고 한다.
출처 : http://www.lrdc.pitt.edu/

당신은 디자인을할 때 어떤 스탠스를 취하고 있는가?

이 중 이슈가 되는 2가지 스탠스를 내 방식대로 설명해보면 이렇다.

  • Design stance - 이성적 이해
  • Intentional stance - 감성적 공감

디자인 스탠스는 추론대상의 용도, 기능, 디자인에 대한 이해를 바탕으로 그 대상을 이성적이고 논리적으로 분석하고 그에 따라 추측을 한다. 반면, 의도적 스탠스는 대상을 의도를 지닌 생물(intentional agent)로 여기고 ‘이런 의도를 가지고 있는 저 대상은 어떻게 행동할까’라는 공감에 기반한 감성적 추론을 한다.

여기서 중요한 점은 의도적 스탠스를 취하기 위해서는 추론의 대상이 의도를 지닌 생물로 여겨질 수 있도록 충분히 실제적이어야 한다는 것이다. 충분하지 못하면 감성적 공감을 할 수 없다. 예를 들어 불릿(Bullet)으로만 구성된 퍼소나는 대상을 무형의 논리적 존재로 인식하게 만들며, 심지어 ‘식스팩 조’같은 별명을 붙인 퍼소나는 대상을 실제 세상에 없는 존재로 인식하게 해, 결국 디자인 스탠스에 갖혀 추론을 하게 만든다. 따라서 이러한 함정을 피해 퍼소나가 실제 사람처럼 느껴지도록 하려면 디테일을 충분히 채워야만 한다.

그럼 디테일을 충분히 채우는 방법은 무엇인가? 바로 내러티브(Narrative)이다. 좋은 스토리텔링은 퍼소나에 새 생명을 불어넣어 살아숨쉬는 실제 사람처럼 느껴지도록 만들어준다. 이해를 돕기위해 다음 2가지 버전의 퍼소나 예시를 보자. 첫 번째는 불릿(Bullet)으로만 구성된 퍼소나이고 두 번째는 내러티브(Narrative)가 가미된 퍼소나이다. 어떤 버전에서 해당 퍼소나가 충분히 실제적인 사람으로 느껴지는지 그리고 감정적으로 공감이 가는지 스스로 생각해보기 바란다.

*아래의 퍼소나 예시는 <인간중심UX 디자인> 11장에 나온 퍼소나 예시를 조금씩 고친 것임을 밝힌다.
에밀리 모티머 (불릿버전)
- 34세
- 그래픽 디자이너
- 캘리포니아 거주
- 이전 자동차: 혼다 시빅 하이브리드 모델
- 컴퓨터: Mac
- 웹사이트 영향: 아마존
- 쇼핑 이유: 현재 소유 중인 차의 할부기간이 끝나서

현재 소유중인 자동차: 2010 미니쿠퍼
- 좋은 점: 좋은 연비, 트렁크 공간, 좁은 데에서도 주차하기 쉬움
- 함께 고려했던 차종: 포드 포커스, 폭스바겐 비틀
- 비용 지불기간: 2년
- 언제부터 보아왔는지: 영화에서 보고 나서 부터
…(중략)…

목적
- 자동차를 원하는 이유가 분명해야 한다.
- 바로 차를 받고 싶다.
- 차를 구입하는 과정 자체를 즐길 수 있어야 한다.
- 구입 후에도 지속적인 서포팅을 받고 싶다.

에밀리 모티머 (내러티브 버전)
34살의 에밀리 모티머는 2주 안에 새 차를 구매하려고 한다. 2010년 첫 번째 차(혼다 시빅 하이브리드 모델)의 비용을 다 갚은지 얼마되지 않아, 영화 <이탈리안 잡>을 VOD로 보고 나서 미니쿠퍼의 활력넘치는 디자인의 매력에 빠져버렸다. 한 주가 지나고 캘리포니아를 차를 타고 돌아다니면서 에밀리는 자신이 길에서 만난 모든 미니 들을 동경하고 있음을 깨달았다.
에밀리는 배너광고 작업을 한 뒤 점심시간을 이용해, 평소 읽던 메트로폴리스 잡지대신 미니쿠퍼 웹 사이트를 확인하기로 마음먹었다. 미니쿠퍼 사이트의 분위기는 그녀가 계속 사이트를 탐색하게끔 부추겼다. 구매를 위한 조사를 한다기 보다는 마치 놀러다니는 듯한 느낌이었다. 에밀리는 마음이 끌리는 모델을 구입하는 것이 합리적 구매가 될 수 있는 이유들을 찾기 시작했다. 그 모델은 충분히 작아서 도시 주차가 쉬웠고, 트렁크가 넓어서 여러 쇼핑백들을 넣기에도 충분했고, 좋은 연비를 가지고 있어서 하이브리드를 구매하지 않는 것에 대해 가책을 느끼지 않아도 되었다.
…(중략)…
구입 몇 달 후, 에밀리는 언제 자동차 정비를 해야할지 의문이 들었다. 그래서 미니쿠퍼 제조사 사이트의 오너(Owner) 섹션에 로그인했지만 매우 실망했다. 차에대한 모든 정보를 입력했음에도 어떤 서비스가 제공되는지 언제 정비를 해야할지 아무런 정보를 제공하지 않았기 때문이다. 그 후 그 사이트에 다시 접속하지 않았다.
미니쿠퍼가 좋기는 하지만 비용도 지불이 다되었고, 에밀리의 관심은 다시 다른데로 쏠리고 있다.

에밀리의 목적
- 자동차를 원하는 이유가 분명해야 한다. 그녀의 선택이 해당 모델의 스타일이나 감성적인 매력에 끌렸기 때문이더라도 에밀리는 스스로 합리적인 사람이라고 느끼고 싶다. 
- 바로 차를 받고 싶다. 그녀는 새 차를 구매할 준비가 되면 바로 행동을 취하고 싶어한다.
- 차를 구입하는 과정 자체를 즐길 수 있어야 한다. 자동차 쇼핑은 재밌어야 한다. 일이 아니다. 새로운 자동차는 그녀에게 특별한 선물이다.
- 구입 후에도 지속적인 서포팅을 받고 싶다. 오너(Owner)에 대한 미미한 지원은 제품의 이미지와 경험을 떨어뜨린다.

실제로 에밀리 모티머를 위한 웹사이트를 디자인한다고 가정해보자. 다양한 솔루션을 발상하는 것도, 여러 솔루션 중 선택을 하는 것도 모두 에밀리 모티머는 이렇게 행동할/판단할/생각할/좋아할 거야 라는 추론에 근거하여 결정해야 한다. 그렇다면 어떤 버전의 퍼소나가 이러한 추론과정에 적합하겠는가? 

위의 예에서 알 수 있듯이, 불릿으로 된 퍼소나는 이성적이고 논리적인 이해를 하는 디자인 스탠스로 추론을 하게 하며 디테일을 갖춘 퍼소나는 감성적 공감을 통해 퍼소나의 머리 속을 들여다보고 의도적 스탠스로 추론을 할 수 있도록 돕는다. 퍼소나의 디테일이 중요한 이유가 바로 여기에 있다.


디테일은 잘못이 없다

앞서 MS에서 퍼소나의 디테일을 포기한 것에 대해 해당 아티클에서는 ‘Abby가 Soccer mom이라는 사실은 윈도우 비스타의 검색기능을 만드는데 아무런 쓸모가 없다’라고 얘기한다. 이건 디테일의 문제를 논하기 전에 자신들이 퍼소나를 제대로 만들고 있는지 부터 되돌아 봐야할 문제다.

퍼소나의 디테일이 중요하다는 것은 해당 프로젝트 도메인과 관련이 없는 픽션을 마구잡이로 넣어도 좋다는 얘기가 아니다. 퍼소나가 해당 도메인에서 과업을 수행하는데 행동에 영향을 미치는 것들을 다분히 의도적으로 내러티브를 살려서 넣어야 하는 것이다. Soccer mom이라는 디테일은 자녀와 자신의 일정을 함께 관리해주는 일정관리 어플과 같은 도메인에서나 의미가 있을 것이다. 그런 디테일을 아무렇게나 채워넣는다고 알아서 의도적 스탠스로 추론이 될 것이라고 생각했다면 그렇게 퍼소나를 만든 디자이너가 정말 우스운 풋내기였다라고 할 수 밖에 없다. (아마 개발자들이 퍼소나의 디테일을 무시하게 된 것도 이런 쓸모없는 디테일들 때문일지도 모르겠다.)

그리고 37signals가 퍼소나를 쓰지 않아도 잘나가는 이유는 간단하다. 자기 자신이 퍼소나이기 때문이다. 솔루션을 발상할 때는 자신을 되돌아 보면된다. 자기 자신은 실제 사람이기 때문에 의도적 스탠스를 취해서 추론을 한다. 너무나 당연한 이치이다. 그런데도 해당 아티클에서는 Persona don’t vs People do라는 도발적인 비교를 하고 있는데 이 또한 퍼소나에 대한 몰지각에서 오는 반응이 아닐까.

퍼소나의 디테일은 퍼소나를 제대로 사용할 줄 아는 자에게만 의미를 부여한다. 당신은 어떤 사람인가?

jun.ee
제 개인 블로그에 생각을 정리해본 글인데, 다른 분들의 의견을 듣고 싶어서 공유합니다.
비판, 지적 모두 환영합니다. 무엇보다 어떻게 생각하시는지 그게 젤 궁금하네요.


Aiden Park
퍼소나의 디테일이 중요하다는 점에는 원론적으로 동의하고요.
다만, jun.ee님의 글을 보면 퍼소나를 불릿 버젼 vs. 내러티브 버젼으로 구분하고 상대적으로 내러티브 버젼이 디테일을 가지고 있기 때문에 추론 도구로써 적합하다는 글의 흐름인데, 이 부분에 있어서는 디테일을 어떻게 채우고 표현하느냐, 퍼소나를 어떤 목적으로 활용할 것이냐에 따라 여러가지 접근이 가능하다고 봐요.
실제로 프로젝트에서 퍼소나를 사용하다 보면, 개인적으론 내러티브 형태의 퍼소나를 잘 사용하지 않습니다. 왜냐하면 클라이언트가 보기에 핵심 포인트가 잘 보이지 않기 때문이죠.
그렇다고 내러티브 없이 만들지는 않습니다. 단지 내러티브를 부각하여 강조하지 않을 뿐이죠. 때론 내러티브를 강조하는 프로젝트도 있고요.
그때그때 상황에 맞게, 퍼소나의 목적에 따라 정보를 시각적으로 표현하기도 하고 비교할 수 있는 표를 만들기도 하고 시나리오를 만들기도 합니다.
이렇게 한다고 해서 이 퍼소나가 내러티브가 없다고 생각되지는 않습니다.

그리고 퍼소나 활용 측면에서 보아도, 퍼소나의 디테일은 여러가지 관점에서 접근할 수 있습니다.
새로운 기능에 대한 가치판단 관점이냐, 타겟을 명확하게 하는 타겟 비교와 분리의 관점이냐, 프리젠테이션의 관점이냐 등등에 따라 퍼소나의 디테일은 다양할 수 있고, 여러 데이터와 컨텍스트로 채워질 수 있죠. 표현방식도 달라질 수 있고요.
추가로 전성진님이 예전에 HCI학회에서 발표하신 '퍼소나 활용하기' 를 참고하시면 좋을것 같습니다.

다시 퍼소나의 근본으로 올라가보면, 결국 디테일의 시작은 C.C(Critical Characteristics)라고 생각해요.
C.C를 제대로 뽑을 수 있다면, 그 각각의 C.C에 많은 디테일이 담겨 있죠. (C.C 구성에 대한 것은 또 다른 주제이니 여기선 논외로 하고요.)
결국 잘못되거나 부족한 C.C를 뽑아서, 스테레오 타입의 퍼소나를 만들게 되고, 억지로거나 뻔한 디테일을 채우다 보니 퍼소나에 공감을 하지 못하고 퍼소나가 필요없다는 식의 이야기가 나오는 것이라고 생각하고요.

Lean UX에서의 프로토퍼소나 역시, 수행하는 사람이 얼마나 숙련되게 C.C를 빠른 시간에 도출할 수 있냐가 매우 중요하다고 봅니다.


mango01
저도 앞의 의견에 동의합니다.
불릿이냐 내러티브냐.
만들어진 퍼소나를 어떻게 전달하냐에 대한 이야기 인것 같습니다.

물론 이런 부분도 의미는 있겠지만, 중요한 것은 얼마나 핵심을 짚은 퍼소나를 만들었는가.
즉, C.C를 제대로 뽑았고 모델링 했냐가 관건이라고 생각합니다.

명확히 핵심을 짚었다면, 제 경험상 단 한 두단어로도(퍼소나 이름만으로도) 관련자들의 공감을 불러일으킵니다.
긴 설명은 필요 없겠지요.


이 재용
퍼소나는 불릿보다 더 강력할 것이다. (이 때 불릿은, 불릿형 퍼소나가 아니라, 불릿형 기능 요구 사항)는 연구가 있었습니다.
만약 ‘공감’이 중요한 부분이라면, 디자이너는 사용자 요구사항(불릿)만 보고 디자인 했을 때, 공감을 덜 할 것이고, 잘 만들어진 퍼소나를 보면 공감을 잘 할 것이다. 따라서 잘 만들어진 퍼소나를 보고 디자인했을 때 더 좋은 결과가 나올 것이다.
연구 결과는? 안타깝게도 상황에 따라 다르더라… 연구 결과 자체를 100% 믿을 순 없지만, 하여간 이러한 추리를 해 보는 건 의미있다고 봅니다. 제가 만약 학자(교수)였다면 그런 연구를 많이 해 보고 싶었어요.
 
여기 38페이지 보시면 나옵니다.


jun.ee
논문을 읽어봤는데, 솔직히 실험설계가 형편없는 수준 같습니다.
우선, User Requirement와 Persona를 직접비교를 하는 것은 말이 안된다고 봅니다.

알고 계시다시피, 목적지향 디자인의 프로세스는
퍼소나 도출 -> 솔루션 발상 -> 컨텍스트 시나리오 도출 -> 시나리오 기반 요구사항 도출 -> 프레임워크 디자인
과 같은 순서로 진행됩니다.

따라서 요구사항은 퍼소나를 기반으로 나오는 결과물이지, 퍼소나와 그대로 비교할 동등관계가 아닙니다.
또한 요구사항이 (제대로만) 주어져 있으면 당연히 요구사항 그대로 디자인하면 되지만, 퍼소나만 가지고 디자인하려면 발상단계를 추가로 거쳐야하니 직접비교를 하는 건 말이 안된다고 봅니다.
만일 실험의 퍼소나는 요구사항을 내러티브 형태로 삽입했기 때문에 비교할 수 있다고 한다면, 그건 퍼소나가 이미 아니므로 틀린 실험설계라고 답할 수 있겠네요. 퍼소나는 요구사항을 풀어서 설명하는게 아니라, 리서치를 통해 발견된 행동패턴을 묶어서 유형화 한 것 이니까요.

그리고 저수준 공감 퍼소나의 예시를 보니 더 실험이 엉망처럼 보이는데요.
하이브리드 자동차 구매자를 타겟으로 하는 서비스에서, 저수준 공감 퍼소나를 만들기 위해 디스크립션을 일부러 '싫어하는 동료들이 최근에 도요타 하이브리드를 구매했기 때문에 프랭크(주인공)는 하이브리드 기술에 대해 편향된 시각을 가지고 있다' 라고 만들었다라는 부분에서 실험의 신뢰도가 팍팍 떨어지네요.

마지막으로, 실험이 Memory vs Empathy가 포커스가 되어서 참가자들에게 요구사항과 퍼소나를 1~3분만 보여줬다는 것도 현실과는 너무 동떨어진 것 같고요.

제가 실험설계를 한다면, 불릿형 퍼소나 vs 내러티브형 퍼소나 각각을 가지고 솔루션 발상을 하게 하되 fMRI를 이용해서 두뇌의 어느 쪽을 사용하는지를 측정할 것 같습니다.
제 발제글의 링크 중에 디자인 스탠스와 의도적 스탠스는 각기 다른 두뇌 영역이 활성화 된다고 나오는데, 실제로 내러티브형 퍼소나로 추론을 할 때 의도적 스탠스를 취하는지 확인해보고 싶어서요.
근데 아마 실제로도 그럴 것 같습니다. 이건 그냥 제 추측이고, 사실 이 부분에 대한 의견이 궁금했던 것이었어요.


無異
퍼소나의 서술적인 디테일이 있으면 도움이 되긴하겠지만
그게 없이 특징들만 블릿으로 잡았다고 해서 감성적인 공감을 못한다(매우 어렵다)는 주장은 동감하기 어렵습니다.

저는 퍼소나를 사용하면 퍼소나라는 가상의 인물 하나를 위해 디자인 한다고 생각하지 않거든요.
퍼소나를 통해서 대상을 포커싱하기는 하는데, 그때 만들어내고 이름 붙인 가상의 인물 한명이 아니라 사용자조사를 하면서 만났던 실제 사람들, 뽑아낸 특징과 유사한 패턴의 내가 살면서 경험했던 주변 사람들, 영화나 드라마 등에서 보았던 주인공들의 보다 풍부한 내러티브에서 생각을 하게 됩니다. 
특징으로 만들어진 추상화된 모델과 그 모델을 만들기 위해서 차용한 많은 사람들의 구체적이고 실제적인 모습들 간을 계속 왔다갔다 하면서 생각을 해요.
다양한 실제의 인물에서 내러티브에서 얻어내는 것 보다 하나의 가상 인물을 토대로 만든 소설에서 얻는게 더 의미가 있다고 하긴 어렵지 않을까요?

또 원문에서는 뭔가 두리뭉실하게 쓴 것 같고, jun.ee님은 이러한 태도(intentional stance)로 솔루션을 생각해야 한다고 쓰셨는데요.
다양한 솔루션을 발상하는 것도, 여러 솔루션 중 선택을 하는 것도 모두 에밀리 모티머는 이렇게 행동할/판단할/생각할/좋아할 거야 라는 추론에 근거하여 결정해야 한다. - jun.ee

전 솔루션을 생각할때는 뭔가 사용자의 입장에서(walking in my shoes) 해답을 찾지 않는 것 같아요.
사용자 입장에서 공감을 통해서 문제를 찾으면 가급적 더 한번 추상화해서 근본적인 문제를 찾고 그 문제를 순수하게 분리해 내어 다양한 도메인에서 답을 찾으려고 하는 것 같아요. 이때는 오히려 그런 구체적인 맥락이 방해가 될 수 있는 것 같거든요.
구체화와 추상화 단계를 반복해야 더 좋은 문제해결을 할 수 있고요.
검증을 할때도 역시나 가상의 인물 한명이 아니라 더 많은 사람들의 진짜 맥락을 적용해서 검증하려고 합니다.


jun.ee
불릿으로 잡는 것이 감성적 공감을 하기 어렵다는 데에 동의를 못하시는 이유가 무엇인지요?
그 뒤에 쓰신 내용은 또 다른 내용이라, 왜 그렇게 생각하시는지에 대한 설명이 없어서 궁금합니다.

제가 생각하는 퍼소나는 단순히 '가상의 인물 하나'가 아닙니다.
퍼소나는 리서치를 통해 발견한 다수의 잠재적/실제적 사용자들의 행동패턴들 중 유사한 것들을 모아서 유형화 시킨 것이니까 허구적으로 만들어낸 한 명의 인물이라고 볼 수 없다고 생각합니다.

또, 리서치와 인터뷰에서 나온 Raw 데이터들을 그대로 다 가지고 가기엔 기억하기도 어렵고 정제도 되지 않았기 때문에 모델링을 하는 것인데요.
특징으로 만들어진 추상화된 모델과 그 모델을 만들기 위해서 차용한 많은 사람들의 구체적이고 실제적인 모습들 간을 계속 왔다갔다 하면서 생각을 해요. - 無異
라는 건 모델링을 해놓고 다시 또 Raw데이터들을 상기시켜서 솔루션 발상을 한다는 얘기로 보여서 이상하게 들립니다.
구체적이고 실제적인 모습이라고 말씀하셨지만 사실 그 단계 쯤에서 머리 속에 남는 것은 디자이너 개인 취향에 맞는 흥미로운 몇 가지 사실 정도이고, 심지어 왜곡되고 단편적으로 남은 기억일 가능성도 있고요.

사용자조사를 하면서 만났던 실제 사람들, 뽑아낸 특징과 유사한 패턴의 내가 살면서 경험했던 주변 사람들, 영화나 드라마 등에서 보았던 주인공들의 보다 풍부한 내러티브에서 생각을 하게 됩니다. - 無異
그리고 퍼소나는 실제 개개인의 독특한 취향들을 중성화시키고 일반화시킨 것인데 위와 같이 개별적인 내러티브들로 생각을 다시 하신다면 퍼소나를 만드는 의미가 없어지는 것 같습니다. 무엇보다도 주변사람과 영화 드라마에서 뽑은 내러티브는 다분히 디자이너의 기호에 따라 매우크게 달라질 것 같아서 위험한 방식같아 보이고요. 
정확한 퍼소나는 데이터에 기반해야 하는 것 아닐까요.

뭔가, 無異님이 퍼소나를 가상인물의 소설이라고 표현하신 부분에서 왠지 퍼소나를 모델링의 결과가 아니라 디자이너가 맘대로 정한 타겟유저라고 보고계시는 게 아닐까라고 생각이 듭니다. 

그래서 정확하게 퍼소나를 만들었다면 가상의 인물 한 명에 대한 소설이 아니라, 리서치 데이터를 기반으로 여러 사람의 행동패턴을 잘 유형화한 일반화된 사용자의 서술이라고 보는게 맞는 것 같아요.

그리고 답변 뒷 부분에서 '사용자 입장에서 해답을 찾지 않는다. 구체적인 맥락이 방해가 되므로 추상화해서 근본 문제를 찾는다' 라고 하신 부분은 제가 잘 이해를 못했어요.
혹시 무슨 말씀인지 예를 들어주실 수 있을까요?


無異
제가 받아들이는 퍼소나는 대상 사용자를 제한 한다는 컨셉까지 입니다. 
제가 퍼소나를 위해서 디자인한다고 하면  가상의 인물이 아니라 그런 특징을 공유하는 진짜 사람들의 문제를 해결해 주는 것으로 생각하거든요.
그런 모델 유형에 해당하는 진짜 사람들에 공감하려고 하지 만들어진 퍼소나에 몰입하고 공감해서 디자인 하지 않는 것 같아요.

퍼소나가 모델링의 결과면 공통되는 c.c.를 빼고는 people의 일반적인 특징을 가져왔다고 하겠지만 결국 임의로 선택한거잖아요.
 c.c.와는 상관없지만 우선 남자인지 여자인지 선택 하잖아요.

사용자 입장에서 해결을 찾지 않는다는 건 문제정의와 해결을 분리하겠다는거에요.
문제를 잘 해결할 수 있는 건 도메인의 전문가지 사용자가 아니거든요.
사용자는 자기의 문제를 찾는 것 까지는 할 수 있겠지만(잘 못하지만) 문제 해결의 전문가는 아니거든요.
좋은 집(UI)를 설계할 수 있는건 건축가지 그 집에 살 사람은 아닙니다.

문제 해결을 전문가에게 맡기려면 문제를 추상화해서 구체적 맥락과 분리해 내는게 더 좋습니다.
내 말은 빨리 달리지 못해. 발이 휘었어. 발굽이 두꺼워. 뭐 그런 사용자의 구체적 맥락 안에서 해결을 생각할게 아니라 빨리 이동하지 못한다고 문제를 추상화해서 분리해내야 자동차를 발명하기 쉽다는 거지요.


전성진
제가 항상 하는 말이지만, 주장하는 바를 선명히 하기 위해 주변을 까대면 역풍을 맞습니다. 선명히 하려면 필요한 일이긴 하지만 괜한 소모성 논쟁을 불러일으키기도 하죠. jun.ee님의 예시에서 주장하고자 하는 바는 '디테일이 중요하다'는 것이지 '불릿형 기술'이 나쁘다는 아닐겁니다.

쿠퍼의 크리스 노이셀(Chris Noessel)이 강조하는 내러티브는 디자인과정에서의 '발상'도구로서의 퍼소나를 말하는 것 같습니다. 사용자의 니즈나 불편사항을 잘 캐치하고 목표를 설정하고 핵심문제를 해결해주는 과정은 대체로 논리적 추론의 과정입니다. 하지만 훌륭한 솔루션을 만들기 위해서는 여기에서 '점프'가 필요하죠. 창의적 발상 말입니다. 이를 위한 다양한 툴들과 프로세스가 있는데 쿠퍼의 퍼소나를 이용한 디자인프로세스는 퍼소나에 전적으로 의존하는 것 같아요. 창의적 발상을 하려니 사고의 블랙박스가 필요하고, 인격체로서의 퍼소나에게로 공감을 하여 '퍼소나가 어떻게 행동할까....?'라고 창의적 발상을 하는 것이죠. 창의적 발상 프로세스가 나름 잘 갖추어진 디자인 조직은 퍼소나에 크게 의존하지 않고 나름의 브레인스토밍과 코웍샵을 통하여 이걸 해결하는 것 같아요. 여하간...쿠퍼에서 퍼소나를 창의적 발상툴로 생각보다 크게 비중을 두는구나라고 다시금 깨닫게 됐네요.

저도 초기 퍼소나에서는 교과서대로(?) 내러티브를 서술했었는데 몇번 해보다가 불릿으로 정리하게 되더군요. 하지만 jun.ee님이 예시로 들은 그런 감정없는 불릿이 아니라 의도와 목표가 드러나도록 행동패턴을 일목요연하게 정리하는 것이죠. 내러티브로 서술해놓으니 고객이 잘 안읽더라구요. 또 퍼소나를 발표하고 전달하는 과정에서도 갈 길 먼데 구구절절 퍼소나의 인생에 몰입하게 하려니 어렵고요. 또 핵심이 잘 안드러나고 문장 속에 섞여 있으니 갈 길 바쁜 사람에게는 답답해 보이는 것이죠. 하지만 발상의 단계에 있는 디자이너에게는 필요한 것 같아요. 가장 공감을 잘 해야하는사람들이고 이들을 위해서는 잘 정리된 이야기 하나는 필요하죠. 고객에게는 이 이야기를 틈나는대로 구전해주고요. 이참에 생각을 다시해보니 불릿 이전에 내러티브 방식의 잘 정리된 스토리를 꼭 쓰는게 좋겠다는 생각이 들었습니다.

이 외에도 퍼소나를 '이름'으로 불러줄거냐, '별명'으로 불러줄거냐의 이슈도 있어요. '이름'으로 불러주고 이것이 익숙해지면 공감에는 분명 더 도움이 됩니다. 하지만 '내러티브 방식'이 스토리에 몰입하게 되기까지의 어려움이 있는 것과 마찬가지의 문제가 발생하더군요. 이게 잘 안되면 퍼소나가 '남의 자식' 같이 되어 몰입/공감에 더 방해가 되기도 합니다. 그래서 다소 객관적인 행동패턴을 설명하는 '별명'을 붙여주는데 이렇게 하면 단시간에 능률을 올릴 수 있거든요. 커뮤니케션도 쉽고. 하지만...저는 '이름'을 불러주는 것이 초반에 힘들어도 더 맞다고 생각해요. 이를 위해서는 프로젝트 과정에서 클라이언트가 훨씬 더 깊이 관여를 해야만 합니다. 사용자조사도 같이하고 인사이트도 함께 발견하고, 퍼소나도 함께 만들어야 하는 것이죠. 그리고 이렇게 하는 것이 결과도 더 좋고요.

이상 제 견해를 정리하면....

- 내러티브가 확실히 공감이 잘 된다.
- 내러티브 방식은 디자인 과정에서의 '창의적 점핑'에 도움이 된다.
- 하지만 클라이언트와의 커뮤니케이션 과정에서의 몰입과 전달이 어렵다. 이를 극복하려면 클라이언트를 프로젝트 과정에 깊이 관여시켜야 한다. 성공하면 결과는 더 좋다.
- 프로젝트 상황에 따라 불릿방식의 보완된 형태가 능률적일 수 있다. 현실적으로는 이 방식이 더 유용하기도 하다.
- 앞으로는 내러티브와 불릿을 다 사용하는 것이 좋겠다.
- 비슷한 이슈가 퍼소나의 '이름'과 '별명'에도 존재한다. 

덕분에 저도 생각을 정리했네요. ^^


mango01
제 생각을 조금 덧대어 봅니다.


정확한 퍼소나는 데이터에 기반해야 하는 것 아닐까요.
그리고 제가 생각하는 퍼소나는 단순히 '가상의 인물 하나'가 아닙니다.
이전 쓰레드에도 쓴 내용이지만, 퍼소나는 리서치를 통해 발견한 다수의 잠재적/실제적 사용자들의 행동패턴들 중 유사한 것들을 모아서 유형화 시킨 것이니까 허구적으로 만들어낸 한 명의 인물이라고 볼 수 없다고 생각합니다.
뭔가, 無異님이 퍼소나를 가상인물의 소설이라고 표현하신 부분에서 왠지 퍼소나를 모델링의 결과가 아니라 디자이너가 맘대로 정한 타겟유저라고 보고계시는 게 아닐까라고 생각이 듭니다 - jun.ee

퍼소나는 정확한 데이터에 기반해야 합니다.
또한 사용자들의 행동패턴들 중 유사한 것을 모아서 유형화 시킨 것도 맞습니다.

그러나 실제로 퍼소나를 자주 만들다보면, 많이 보이는 패턴 중에 중요도에 따라 발췌해야 하고, '이 것이 패턴이다' 라고 명명하는 사람 자체가 디자이너이다 보니, 디자이너의 관점. 시야. 배경지식. 숙련도를 무시할 수 없습니다.

즉, 일전에도 한번 이야기 했듯이 누가 만들었냐(디자이너가 누구냐)에 따라 상당히 퍼소나가 달라집니다. 같은 데이터라도 객관적 정답이 없다는 이야기입니다. 단지, 모든 이해관계자가 동감하고 사용자마저 동의할 만한, 중요한 C.C들이 충분히 부각되었냐의 점검이 가능하겠지요.

또, 리서치와 인터뷰에서 나온 Raw 데이터들을 그대로 다 가지고 가기엔 기억하기도 어렵고 정제도 되지 않았기 때문에 모델링을 하는 것인데요.
특징으로 만들어진 추상화된 모델과 그 모델을 만들기 위해서 차용한 많은 사람들의 구체적이고 실제적인 모습들 간을 계속 왔다갔다 하면서 생각을 해요. - 無異
라는 건 모델링을 해놓고 다시 또 Raw데이터들을 상기시켜서 솔루션 발상을 한다는 얘기로 보여서 이상하게 들립니다.
구체적이고 실제적인 모습이라고 말씀하셨지만 사실 그 단계 쯤에서 머리 속에 남는 것은 디자이너 개인 취향에 맞는 흥미로운 몇 가지 사실 정도이고, 심지어 왜곡되고 단편적으로 남은 기억일 가능성도 있고요. - jun.ee

그래서 無異님 이야기는 다 적절합니다. 
추상화된 모델과 실제적 모습을 왔다갔다하면서 솔루션을 냅니다. 
모델링의 목적은 '단순하고 쓰기쉽게 무엇이 중요한지' <핵심>을 파악하기 위해서지, Raw데이터 자체를 쓰지말도록 하는데 있지 않습니다. 도리어 <핵심>을 파악하고 나면, 원래 알고 있던 Raw데이터가 다르게 보입니다. 그래서 프로젝트 막판까지 사용자 조사 내용을 리마인드해가며 솔루션을 내기도 합니다.

사용자조사를 하면서 만났던 실제 사람들, 뽑아낸 특징과 유사한 패턴의 내가 살면서 경험했던 주변 사람들, 영화나 드라마 등에서 보았던 주인공들의 보다 풍부한 내러티브에서 생각을 하게 됩니다. - 無異
그리고 퍼소나는 실제 개개인의 독특한 취향들을 중성화시키고 일반화시킨 것인데 위와 같이 개별적인 내러티브들로 생각을 다시 하신다면 퍼소나를 만드는 의미가 없어지는 것 같습니다. 무엇보다도 주변사람과 영화 드라마에서 뽑은 내러티브는 다분히 디자이너의 기호에 따라 매우크게 달라질 것 같아서 위험한 방식같아 보이고요. 
정확한 퍼소나는 데이터에 기반해야 하는 것 아닐까요. - jun.ee

디자이너가 2~3달 조사 했다고 해서, 그 분야에 대해 충분한 리서치를 했다고 할 수 없습니다. 즉, 자기 개인적 경험을 배제한 체 2~3달 조사한 데이터만 활용하겠다는 생각은 위험해 보입니다. 
구체적 자기 경험들, 주변 사람들과의 관계, 사건들을 활용해 최소 30년의 내공을 넣어서 사람을 이해하고 솔루션을 만들어야 합니다.
<모델링>은 핵심을 파악하기 위한 도구이자, 기준이 되어 줍니다.
<모델링> 아이디어를 내는데 영감이 되어주고 분별력과 힘을 실어주지, 혁신적 아이디어 자체를 내는데 필요충분 조건은 아닙니다. 
혁신적 아이디어는 디자이너의 경험에서 나오는 경우가 많습니다.
드라마에서 뽑은 내러티브가 위험하다고 하셨는데, 저 역시 병원관련 프로젝트를 할때, 병동별 특성 차이에 대한 이해와 솔루션에서 '하얀거탑'의 도움을 많이 받았습니다.
우리는 사회과학자가 아닙니다. 데이터만으로 그림을 그릴 수 없습니다.
데이터의 <재해석> 과정의 주체가 디자이너인 이상, 혁신적 솔루션을 내는 주체가 디자이너인 이상, 디자이너의 기호, 경험, 취향 모두 엄청 중요합니다. 그것을 배제하고 데이터만 가지고 정답을 찾으려는 태도가 더 위험합니다.
(물론 jun.ee님이 지적한대로, 데이터를 무시하고 자기 경험만 중시하는 태도도 엄청 위험하지요^^)

리서치로 현실을 잘 파악한 만큼, 디자이너인 자신의 능력과 한계를 잘 알고 솔루션을 내는게 좋다고 생각합니다.
<모델링>은 그 중간 도구 중 꽤 중요한 하나일 뿐입니다. 

이게 옳다는 말은 아니고, 그저 개인적인 생각입니다. 

퍼소나의 디테일이 주요한 역할을 한다는 점에서는 대체적으로 동의하지만 그 중요도와 활용방법에 대해서는 토론에 참여하시는 분들마다 약간씩 다른 모습을 보여주셨습니다.

여러분은 어떻게 생각하시나요? :)

그럼 퍼소나를 창시한 앨런쿠퍼가 그 당시 어떻게 퍼소나를 만들게 되었는지에 대한 글의 발췌문으로 포스팅을 마무리 하겠습니다.
I was writing a critical-path project management program that I called “Plan*It.” Early in the project, I interviewed about seven or eight colleagues and acquaintances who were likely candidates to use a project management program. In particular, I spoke at length with a woman named Kathy who worked at Carlick Advertising. Kathy’s job was called “traffic,” and it was her responsibility to assure that projects were staffed and staffers fully utilized. It seemed a classic project management task. Kathy was the basis for my first, primitive, persona.
나는 Plan*It 이라는 크리티컬 패스 프로젝트 관리 프로그램을 작성하고 있었다. 그리고 프로젝트 초기 단계에서 해당 프로그램의 사용자라고 볼 수 있을 만한 7~8명의 동료들과 지인들을 인터뷰했다. 나는 그 중 Kathy라는 Carlick Advertising에서 근무하는 여성과 많은 얘기를 나눴는데, Kathy의 직업은 교통정리자(traffic)라고 불렸다. 그녀의 임무가 프로젝트들에 제대로 인력이 충원되고 모든 인력이 제대로 활용되도록 하는 것이었기 때문이다. 그건 전통적인 프로젝트 관리 업무였고, Kathy는 나의 최초의 원시 퍼소나가 되는 기반이 되었다.

In 1983, compared to what we use today, computers were very small, slow, and weak. It was normal for a large program the size of Plan*It to take an hour or more just to compile in its entirety. I usually performed a full compilation at least once a day around lunchtime. At the time I lived in Monterey California, near the classically beautiful Old Del Monte golf course. After eating, while my computer chugged away compiling the source code, I would walk the golf course.  During those walks I designed my program.

1983년에는 오늘날과 비교해서, 컴퓨터가 매우 느렸기 때문에 Plan*It과 같은 대형 프로그램은 컴파일(역주: 소스코드를 실제 프로그램으로 만들어내는 과정)하는데 에만 1시간 이상이 걸렸다. 나는 보통 점심시간에 프로그램 전체의 컴파일을 걸어놓았다. 그 당시 나는 Monterey California에 살았는데 근처에 아름다운 Old Del Monte 골프 코스가 있어서 컴퓨터가 컴파일을 하는 동안 나는 점심을 먹고 골프코스를 따라 산책을 했다. 그렇게 걸으면서 내 프로그램에 대한 디자인을 했다.

As I walked, I would engage myself in a dialogue, play-acting a project manager, loosely based on Kathy, requesting functions and behavior from my program. I often found myself deep in those dialogues, speaking aloud, and gesturing with my arms. Some of the golfers were taken aback by my unexpected presence and unusual behavior, but that didn’t bother me because I found that this play-acting technique was remarkably effective for cutting through complex design questions of functionality and interaction, allowing me to clearly see what was necessary and unnecessary and, more importantly, to differentiate between what was used frequently and what was needed only infrequently. 
나는 그 길을 따라 산책하면서, Kathy를 떠올리며 내 자신을 그 프로젝트 매니저라고 생각하며 일종의 연극을 하며 가상의 대화를 나눴다. '이러한 기능이 있어야하고, 이러한 인터랙션(행동)들이 프로그램에 있어야 합니다' 라는 식의 대화말이다. 나는 종종 그 대화 속에 깊이 빠져서 큰 소리로 얘기를 하고, 팔을 사용해 제스쳐를 취하고 있는 내 자신을 발견하고는 했다. 몇몇 골퍼들은 내가 그러고 있어서 깜짝 놀라기는 했지만 나는 크게 개의치 않았다. 왜냐하면 그렇게 연극을 하며 대화를 나누는 그 기법이 기능과 인터랙션에 대한 복잡한 디자인적 의문을 한방에 해결하는데(cutting through) 너무나도 효과적이었기 때문이다. 그 기법은 나에게 무엇이 필요하고 불필요한지, 무엇이 더욱 중요한지, 무엇이 자주 사용되고 덜 사용될 것인지에 대한 것을 명확히 알게 해주었다.


[참고##퍼소나##]
[참고##사내 토론##]

팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 2
Ad Test...
2011.05.13 12:55

[UI 디테일] 웹사이트 로그인, 어떤 방식으로 하는것이 좋을까?

최근, 미투데이의 miriya 님이 올려주신 UX movement 링크를 보게 되었습니다.
http://uxmovement.com/forms/innovative-techniques-to-simplify-sign-ups-and-logins 



웹사이트의 회원가입과 로그인을 어떻게 하면 쉽게 할 수 있을지에 대한 몇가지 테크닉에 관한 글입니다.
그 중에도 인상깊었던 부분은 '웹사이트 로그인을 할때 어떤 정보를 통해서 로그인을 하게 할 것인가?' 였습니다.

로그인 방식은 다음과 같이 몇가지 유형이 있습니다.

1. ID + Password 로 로그인 하는 방법
국내 웹사이트에서는 거의 이 방식을 사용하고 있습니다.
이 경우에는 사용자가 ID를 기억해야 한다는 부담감이 있습니다.
ID 입력 방식도 사이트에 따라 천차만별이기 때문에 한 사람이 여러개의 ID를 가질 수 있습니다.(첫 글자가 숫자면 안된다는 규칙, 6자리에서 12자리 사이로 입력해야 한다는 규칙같은것들 때문이죠.) 저의 경우 4~5개의 ID와 마찬가지로 4~5 개의 Password가 있어서 상황에 따라 조합해서 가입하는 경우가 있습니다.
또한 회원 가입시에는 별도로 E-mail 정보를 입력해야 한다는 부담이 있습니다.(E-mail 정보를 ID, Password 확인 용도나, 이벤트 알림 용도로 사용할 수 있죠.) 

미투데이의 로그인 방식


2. E-mail + Password 로 로그인 하는 방법
외국 웹사이트에서는 거의 이 방식을 사용하고 있습니다.
이 경우에도 마찬가지로 사용자가 E-mail을 기억해야 한다는 부담감이 있습니다.
또한 상대적으로 ID보다는 긴 형태이기 때문에 입력하는데 시간이 걸리며, 인지하는데도 어느정도의 어려움이 있습니다. E-mail을 몇 개나 사용하고 있는지도 마찬가지로 천차만별입니다. 저의 경우를 비추어보자면 E-mail을 4~5개 정도 보유하고 있어서 이 경우에도 어떤 E-mail로 가입했는지 고민을 해야 합니다. 그렇지만 E-mail을 한 개만 사용하는 경우에는 크게 문제는 없을것 같습니다.  

또한 웹사이트에서는 E-mail 입력이 편한 반면, 모바일에서는 E-mail 주소 입력이 상대적으로 불편합니다. 이런 여러가지 생각들속에서 올바른 가치판단을 해야겠습니다.

페이스북의 로그인 방식



그렇다면 회원 가입 시 E-mail 인증 및 E-mail 중복 체크를 해야될까요?
E-mail 중복 체크는 꼭 해야 할것으로 보입니다. 하나의 E-mail로 두 명이 사용할 수는 없기 때문입니다. E-mail 인증 절차도 복잡하지않게 설계한다는 전제하에서 필요할 것으로 보입니다. '인증을 해서 사용자를 불편하게 할 것인가?' vs '인증을 하지 않아 입력단계를 편하게 하지만, 이메일을 잘못 입력했을 경우에는 사용자의 책임으로 전가할 것인가?' 를 사이에 두고 가치판단을 하여야겠습니다.

3. E-mail or ID + Password 로 로그인 하는 방법
E-mail 혹은 ID 둘 중 하나만 입력해도 로그인 하는 방법입니다. 이 경우 E-mail 과 ID 둘다 입력되어있다는 전제하에서 로그인이 성립 될 것 같습니다. E-mail 통해 가입하는걸 원하는 사람 혹은 ID를 통해 가입하는걸 원하는 사람이 있을 수 있으므로 둘 다 지원하자는건데, 개인적으로는 부가적인 방법으로 상황에 따라 적용하는 것이 좋다고 생각합니다.

4. 아예 회원가입을 하지 않고 로그인 하는 방법
회원 가입대신 Facebook이나 Twitter 로그인으로 대신 하는 방법이 있습니다. 원래는 이 방법이 보안을 위해 특정 어플리케이션에서 직접 ID, Password를 입력받지 않고 사용자의 정보에 접근하기 위한 표준이었습니다. 그러나 요즘에는 개인정보가 많이 필요하지 않은 경우 페이스북, 트위터 OAuth로 사용자 인증을 하는 서비스가 많아졌습니다. 

그 전에는 통합아이디 개념의 Open ID 가 하나의 방법이었는데, 요즘에는 이 방식이 점점 줄어들고 있는 것 같습니다. 미투데이에서도 Open ID를 지원하다가, 최근 어떤 이유로 인해 Open ID를 지원하지 않고 있습니다.

5. 전화번호로 로그인(인증)하는 방법
이 경우는 웹사이트보다는 모바일에서 적합한 방식으로 보입니다. '카카오톡'에서 이 방식을 사용하고 있지요. 이 방식은 회원가입 없이도 로그인을 할 수 있다는 장점이 있습니다. 하지만 전화번호가 바뀌거나 없어질 경우에는 이 방식이 문제가 됩니다. 카카오톡의 경우 문자를 주고받는 커뮤니케이션 앱이기 때문에 전화번호가 바뀌어도 크게 이상하지는 않습니다. 하지만 다른 종류의 앱들이 전화번호로 로그인을 할경우에는 다시 친구를 맺어야 하는 문제가 생길 수 있습니다. 
또한 어떠한 연유로 두 개의 전화번호를 가지고 있는 사용자의 경우를 고려할 필요가 있습니다. 카카오톡은 한번에 한 개의 전화번호를 인증하기 때문에 두 개의 전화번호를 인식할 수 있는 방법이 없습니다.

또한 카카오톡은 전화번호 정보밖에 가져오지 않기 때문에, 다른 서비스(이를 테면 웹)에 접목시키기가 매우 어려운 실정입니다. 추가적으로 ID를 입력하게 하는것도 이 때문으로 보여집니다. 

카카오톡의 로그인(인증) 방



웹사이트 로그인, 어떤 방식으로 하는 것이 좋을까요?
저는 요즘 'E-mail + Password' 방식이 좋은 것 같다는 생각이 듭니다. 여러분들의 생각은 어떠세요?


PS. Log in vs Sign in 어떤 용어를 쓰는것이 좋을까요? 
http://legendre.tistory.com/entry/Log-in%EA%B3%BC-Sign-in




* 본 블로깅은 PXD 사내메일의 글을 일부 포함하고 있습니다.
(글 쓰는데 많은 도움주신 이재용님, 無異님 감사합니다.)
* 좋은 자료 링크해주신 miriya님 감사합니다. 


[참고##UI 디테일##]



팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 1 Comment 4
Ad Test...
2010.09.20 23:47

[UI 디테일] 아이폰4와 아이팟터치 UI 디테일 비교


최근 아이폰4를 구매하였습니다. 그 전에는 아이팟 터치(2세대)를 사용했었는데, 아이폰4를 몇 일 동안 사용하면서 약간의 차이를 발견할 수 있었습니다. 이 차이는 아이팟 터치 (2세대)와 아이폰4의 차이라기 보다는 애플 OS 3.0과 4.0 의 차이로도 해석이 되겠지요. 기능상의 차이점은 스티브 잡스의 키노트나 다른 블로깅에서 잘 다루고 있습니다만, 저는 기능상의 차이점보다는 잘 알려지지 않은 디테일의 차이점들을 비교해보려고 합니다.

그림1. 잠금 화면 비교 - 좌) 아이폰4 우) 아이팟터치 2세대

메인화면은 이렇게 바뀌었습니다. 아이팟 터치에는 요일에 괄호를 치지 않았지만 아이폰4에는 요일에 괄호를 치고 있습니다.[각주:1] 이는 날짜와 요일의 구분을 용이하게 하는 것으로 생각합니다. 또한 잠금해제 아이콘도 디테일을 살렸습니다. 기존의 평평한 화살표 모양에서 그라데이션이 들어간 형태로 모양이 바뀌었습니다.

그림2. 검색 화면 비교 - 좌) 아이폰4 우) 아이팟터치 2세대

아이팟 터치 검색화면의 크롤바는 어색하게 최우측에 위치했습니다. 반면 아이폰4는 스크롤바의 위치가 리스트 안쪽으로 변경되었습니다.

그림3. 메일 리스트 화면 비교 - 좌) 아이폰4 우) 아이팟터치 2세대

메일 리스트 화면에서는 UI 가 약간 바뀌었습니다. 아이팟 터치의 메일 UI는 메일의 흐름을 파악하기 힘들었습니다. 아이폰4의 메일은 답글이 오고갔다면 답글의 히스토리를 관리해서 숫자로 보여줍니다. 리스트를 선택 하면 시작글과 해당 답글들의 목록이 보여집니다. 

그림4. 음악 리스트 화면 비교 - 좌) 아이폰4 우) 아이팟터치 2세대

음악 리스트 화면은 어떻게 바뀌었을까요? 다음 화면은 음악 재생시 우측 상단의 앨범 커버를 눌렀을때 나오는 화면입니다. 앨범 리스트 숫자에 점이 붙고 공간이 넓어졌습니다. 공간이 넓어진 이유는 숫자가 100단위 이상으로 생길 때를 대비한 것 같습니다.

그림5. 앨범 리스트 화면 비교 - 좌) 아이폰4 우) 아이팟터치 2세대

아티스트에서 앨범을 선택하면 나오는 리스트 화면도 바뀌었습니다. 아이팟 터치에서는 기본적인 리스트 구조를 가지고 있습니다. 반면 아이폰4는 앨범 UI가 좀 더 앨범의 리스트인양 바뀌었습니다.

그림6. 동영상 재생 화면 비교 - 좌) 아이폰4 우) 아이팟터치 2세대

동영상 재생 화면 에서는 우측 확대 축소 버튼이 삭제되었습니다. 확대 축소 버튼은 동영상 크기가 제공하는 화면보다 작을 경우 늘려서 보여주는 버튼입니다. 그러나 인코딩을 화면 사이즈에 딱 맞게 했을때는 이 버튼이 무의미합니다. 그래서 이 버튼을 제거하지 않았나 생각합니다. 화면 사이즈에 맞지 않는 동영상인 경우에도 동영상 확대 축소 버튼을 제공하지 않는지에 대해서는 확인해보지 않았기 때문에 알 수 는 없지만 아마도 제공하고 있지 않을까라고 조심스럽게 추측해봅니다.

그림7. 알람 설정 화면 비교 - 좌) 아이폰4 우) 아이팟터치 2세대

그 외에도 알람 설정 화면을 보시면 레이블의 변경, 날짜 규칙, 날짜 폰트 크기, 설명 문구의 제거 등을 보실 수 있습니다. 애플 인터페이스 가이드라인을 보시면 설명 문구에 대한 가이드라인이 있습니다만, 그것을 굳이 제거 한 이유는 설명 문구가 불필요하기 때문이라고 생각이 됩니다. 적어도 이 화면에서는 '이벤트의 자세한 내용 설정' 이라는 문구가 없어도 이해하는데는 문제가 없으니까요. 이 설정 화면 말고도 이런 방식으로 레이블, 폰트 크기, 규칙 등이 알게 모르게 개선되고 있음을 알 수 있습니다.


정리하며...

다음과 같이 아이폰 4와 아이팟 터치 2세대의 UI 화면 디테일을 비교해 보았습니다. '가이젠(改善)'은 생활의 모든 면을 계속 고쳐나간다는 일본의 생활철학에서 유래한 말입니다. 애플의 철학은 하나의 제품에서 끝나는 것이 아니라, 그것이 제대로 사용될때까지 끊임없이 디테일을 갈고 닦는것일지도 모르겠습니다. 끝은 존재하지 않습니다. 다만 끊임없는 수정과 개선이 존재할뿐입니다. 오늘도 디테일을 갈고 닦을 애플에게 한 수 배웁니다.


[참고##UI 디테일##]


  1. PXD 사내메일의 '[정보디자인] 아이폰 락스크린 요일표시' 라는 글에서 인용 [본문으로]

팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 8
Ad Test...