매끄러운 UX의 비결은 어쩌면

최근 투자를 많이 받았거나 폭발적으로 성장하는 서비스들은 모두 군더더기 없고 몇몇 포인트에선 ‘오!’하는 감탄사를 자아내는, 매끄러운 사용자 경험을 제공한다.

최근 이런 느낌을 준 서비스는 Uber, 쏘카, 왓챠, Duolingo, Coin, Hyperlapse 등이 있었고, Instagram이나 Vine과 같은 서비스는 엄청난 성장에도 불구하고 여전히 심플함과 매끄러움을 유지하고 있다는 점에서 놀라움을 준다.

이는 제법 새로운 경험이다. ‘시너지’라는 명목하에, 또는 기존 사용자들의 눈치를 보느라 이것저것 하나도 버리지못한 포털식 UX와도 다른 것이고, 안쓰는 기능이 80%쯤 될듯한, 오랜 역사에 빛나는 데스크탑 어플리케이션이 주는 느낌과도 상당히 다른 것이다.

그 매끄러움은 어디서 오는 것일까? 많은 사람들이 ‘잘 된것’을 칭송하고 ‘심플’을 숭배하는 이 시대에도 왜 여전히 세상엔 ‘안 심플’한 것이 훨씬 많을까?

이것에 대해 생각해보다가 문득, 아래 문단이 생각났다.

저자 : 저자 1명입니다. 어떤 회사는 명세는 반드시 팀이 써야 한다고 생각합니다. 하지만 한 번이라도 공동저작을 시도해봤다면, 그보다 더한 고문이 없다는 사실을 잘 알고 있을 겁니다. … 명세는 1명이 전담해서 작성해야만 합니다. 큰 제품일 경우라면, 여러 부문으로 쪼갠 다음에 각각을 개인에게 할당해서 독자적으로 명세하게 합니다. … 사람들은 자신이 명세한 사항에 대해 책임감과 소유의식을 느껴야 합니다. 명세에서 무언가 잘못되면, 이를 수정할 책임있는 명세서 소유자를 지정해야 하며, 이 사람 이름이 바로 명세서에 찍혀 있어야 합니다.

- 조엘 온 소프트웨어, 6장. 손쉬운 기능명세 작성법 2강. 명세가 뭡니까? 중.

조엘 스폴스키는 그의 저서 ‘조엘 온 소프트웨어’에서 무려 세 개의 장에 걸쳐 기능명세서 작성의 필요성을 역설하며 어떻게하면 명세서를 잘 쓸수 있는가에 대해 설명하였는데, 위 인용한 문단은 ‘좋은 명세서 작성의 조건’ 중 하나에 대해 이야기하고 있다. 명세서를 ‘혼자’ 쓰라는 것이다.

난 여기에 크게 공감하며, ‘심플하고 매끄러운 UX’의 비결이 혹시 ‘최대한 적은 사람이 설계하는 것’에 있지 않을까 하는 생각을 해본다. 아래와 같은 생각.

  • 1명이 서비스 전체의 UX를 설계할 수 있다면 가장 좋다.
  • 아무리 많아도 3명을 넘지 않아야 한다. (하지만 3명도 별로 좋진 않다)
  • 피드백은 낱장의 와이어프레임이 아닌, 주요 Flow를 볼 수 있는 프로토타입을 공유한 후 받는다.
  • 단, 피드백을 받을 때 중요한 것 : ‘피드백’을 받야아 한다는 것이다. 결코 ‘컨펌’을 받아선 안된다. 최종 의사결정은 설계자가 내려야 한다.

위와 같이 생각한 이유는…

  1. 여러 사람이 함께 서비스를 설계하면 결국 매끄럽게 연결되지 않는 부분이 생긴다. 서로의 생각을 완전 일치시킬 순 없다.
  2. 여러 사람이 함께 서비스를 설계하거나 누군가의 ‘컨펌’을 받는다면, 서비스에 대한 ‘소유의식’이 떨어진다. (위 인용문에 나온 것 처럼) ‘소유의식’이 떨어지면 ‘애착’이 떨어지고, 자신의 설계를 방어하는데 게을러진다. 그냥 해달라는대로 다 해주고, 지적받는대로 고치게 되며, 그러는 동안 남아있던 소유의식마저 사라지고 경험은 ‘덕지덕지 주렁주렁’ 상태가 된다.
  3. 전체 서비스가 돌아가는 모습과 그것이 줄 ‘느낌’, ‘경험’을 상상해낼 수 없다. 내가 설계한 건 ‘느낄 수’ 있지만, 솔직히 남이 설계한 건 그냥 ‘문서’일 뿐이다.

즉… ‘매끄럽고 군더더기 없는 사용자 경험’은 ‘프로세스’나 ‘방법론’, ‘원칙’, ‘철학’ 뭐 이런데서 나온다기 보다는 서비스에 대한 설계자의 ‘집착 수준의 애착’, ‘적어도 똥같은 의견은 확실히 무시할 수 있는 고집’, ‘전체를 통제하고 있다는 느낌’ (+ 개인의 역량)에서 나오는 것이 아닌가 하는 생각이 든다.

(솔직히 ‘프로세스’는 군더더기를 양산하는 주범이라고 생각한다)

UX책 좀 추천해줘

참 미천한 경력이지만, ‘UX’라는 단어가 들어간 팀에서 일하다보니 종종 ‘UX책 좀 추천해줘’라는 부탁을 받는다. 듣자마자 머리가 좀 깜깜해지는 부탁이다.

일단 나도 UX가 당췌 뭔지 별로 확신이 없는 것이 첫 번째 문제. 더 큰 문제는, UX라는 말이 붙은 (혹은 연관된) 책들 중 상당수가 대책없이 지루하다는 것이다.

그래서 저런 질문을 받으면 난 반사적으로 이런 저런 질문을 던진다.

"왜요?"

리스트를 팍 던지면 대여섯권 한 번에 산 후, 가장 제너럴한 제목을 가진 책을 100페이지 이하 읽고 나머지 읽기도 포기할 것 같아서이다. (내가 그랬다) 그래서 나름, 상황에 맞게 적절한 책을 던져보려고 노력한다. (결국 늘 실패하지만) 생각 정리도 할 겸, 나름의 기준에 따른 책을 정리해본다.

상황 1. 느긋하게 UX 디자인의 전체 과정을 훑어보고 싶다.
그렇다면 : UX 디자인 프로젝트 가이드

  • 장점 : 소위 ‘UX’한다는 것에 대한 가장 일반적인 프로세스 전체를 교과서적으로 정리
  • 단점 : ‘교과서적’이라는 것에 주목. 1. 교과서는 지루하다. 2. 세상은 교과서처럼 돌아가지 않는다.

상황 2. 인터페이스 설계의 개론을 보고싶다. (시간이 많다)
그렇다면 : 퍼소나로 완성하는 인터랙션 디자인 (About Face 3)

  • 장점 : 인터페이스의 수많은 컴포넌트들에 대한 상세한 분석. 이 책의 3장은 처음 설계 업무를 할 때 정말 많이 참고하게 된다. (사실 그 후에도 계속) ‘사용자 중심 디자인’이라는 말이 넘쳐나면서 들게된 의문 - 그럼 사용자 중심 디자인이 아닌건 뭔데? -에 대한 약간의 답을 얻게 된다. 그걸 여기선 ‘구현 모델’이라는 말로 설명한다. 사람 중심이 아니라 컴퓨터가 돌아가는 구조를 그대로 드러낸 것. 그래서 사람이 쓰기엔 뭔가 부자연스러운 것.
  • 단점 : 책을 딱 잡는 순간 읽기를 포기하게 된다. 한국어판의 번역이 좀 거칠다. (하지만 그 양을 보면 이해는 간다…) 이 책에 대해 두 가지 유형의 사람을 만나기 쉽지 않다. 1. 이 책을 모르는 사람 2. 이 책을 다 읽은 사람

상황 3. 상상력과 창의력 터지는, 멋진 과정을 원한다. (현실이 어떻든 간에)
그렇다면 : 사용자 경험 스케치 by 빌 벅스턴

  • 장점 : 가끔 UX라는 것이 긴긴 프로세스와 남의 불평을 묵묵히 듣고만 있어야 하는 답답한 무언가로 느껴질 때가 있는데, 여기서 잠시 벗어나서 ‘발산’의 즐거움을 느낄 방법을 얻을 수 있다. 또 ‘경험’을 디자인한다는게 정적인 시각적 결과물을 만들어 내는 것과 무엇이 다른지 살짝 느껴볼 수 있다.
  • 단점 : 당신이 꽉 막히고 딱 굳어진 조직 안에 있다면, 여기서 제시하는 방법을 처음 시도하는데 굉장한 용기가 필요할 것이다.

상황 4. 당장 설계서를 그려야 한다. (시간이 촉박하다)
그렇다면 : 웹 폼 디자인 by 루크 로블르스키

  • 장점 : 인터페이스 설계에서 가장 많은 사용성 문제를 일으키는 Form에 집중된 책. 집중되어있다는 뜻은 이 책이 별로 안두껍다는 뜻이다.
  • 단점 : 당신에게 일을 맡긴 사람이 ‘거 포인트가 딱~ 될만한 트렌디한 인터랙션으로 부탁합니다~’라는 식이라면 별 도움은 안될지도… + 모바일에 대한 내용이 좀 부족하다고 느낄 수도 있다.

상황 5. 준비도 없이 프로젝트 매니저가 되어버렸다.
그렇다면 : 마음을 움직이는 프로젝트 관리

  • 장점 : 이 책 자체에 마음이 움직인다.
  • 단점 : 사람을 상대하는 일을 글로만 배울 순 없다. 결국 시행착오가 필요.

상황 6. 개발자의 마인드를 이해하고 싶다.
그렇다면 : 조엘 온 소프트웨어

  • 장점 : 개발자가 무엇을 소중하게 여기는지, 어떻게 일하고 싶어하는지 간접적으로나마 알 수 있다.
  • 단점 : 개발자가 아니라면 분명히 전혀 이해할 수 없는 부분이 있다. (이런 부분은 알아서 적당히 넘어가야…)

상황 7. 시간은 촉박한데 뭔가 UX스러운 프로세스가 필요하다.
그렇다면 : 린 스타트업 (Running Lean)

  • 장점 : 별로 안두껍다. 당장 따라할 수 있을만큼 잘 정리되어있다. 실제로도 상당히 효과적이다. 프로세스가 아닌, 비즈니스 목표를 정조준한다.
  • 단점 : 일을 시킨 사람이 체계적인 과정이나 숫자를 중시한다면 이 방식을 싫어할 수도 있다. 실제로 이 책 그대로 하려면 진짜 몸이 힘들 것이다. (그래서 포기하고 싶을 듯…)

상황 8. 이리 치이고 저리 치이고 이게 다 무슨짓인가 싶다.
그렇다면 : 대체 뭐가 문제야? (Are Your Lights On?)

  • 장점 : 별로 안두껍고 엄청 재밌다. 그러면서도 뒤통수를 탁 때리는듯한 시원한 인사이트가 담겨있다. 뭔가 탁- 놓을 수 있는 기분을 선사한다.
  • 단점 : 이 책은 ‘문제의 해결에 대한 책’이 아니다. 문제 그 자체에 대한 책이므로 가벼운 마음가짐이 필요.

상황 9. 한국의 UX 상황 전반을 알고 싶다.
그렇다면 : 전략적 UX 디자인으로 성장하라.

  • 장점 : 해외 번역서들에는 담겨있지 않은 한국의 상황이 잘 들어있다.
  • 단점 : 상황을 안다고 해결책이 보이는 것 만은 아니다.

상황 10. 우린 기술력이 없어서 안될거야 아마…
그렇다면 : 피플 웨어

  • 장점 : 일은 기술이 아니라 사람이 한다는 것을 알려준다.
  • 단점 : 글쎄…

이상, 지극히 주관적인 리스트 정리.

*베스트 책들을 뽑았다기 보다는, 얼마 안되는 ‘읽은 책’들을 정리한 것에 불과한 것 같다.

Tags: UX books

"'UX적으로'라는 표현이야말로 UX의 적이다."

— 나

Tags: UX

오래된 제품을 리뉴얼하는 것은

진정 ‘하위 호환성’과의 싸움이구나.

이렇게 하나, 저렇게 하나 붙어서 ‘거대해진’ 레거시들을 이렇게 대응, 저렇게 대응하다보면 복잡도는 높아지고 버그는 늘어가고 개발기간은 길어지고. 그만큼 새로운 것을 시도하는 것은 버거워지고.

이렇게 당하고 있자니 왜 Getting Real류의 제품개발론에서 ‘기능 추가’를 그토록 ‘죄악시’하는지 이해가 간다. 기능이 하나 추가될 때 마다, 정책이 하나 추가될 때 마다 유지비용은 배로 늘어나고, 결국 아무도 전체를 이해할 수 없을 만큼 복잡해진다.

그때가서는 아무리 ‘속도가 생명!’이라고 주장해도 소용이 없는 것이다.

하지만 이미 돌이킬 수 없는 상황일지라도 ‘과거를 털어버리고 심플함을 되찾자!’는 것은 결코 답이 될 수 없다. (리뉴얼을 진행할 때 이 유혹을 떨치지 못하고 피를 보는 경우는 역사적으로도 적지 않은 듯 하다) 리뉴얼은 제품 제공자의 욕망일 뿐, 쓰는 사람은 결코 ‘새롭게 바뀌는 것 = 좋은 것’이라고 생각하진 않기 때문이다. 바뀌는 건 그냥 성가시고 귀찮고 다시 배워야하는 것일 뿐… 없던 기능이 생긴다고 기뻐하기보다는 있던 기능이 사라지거나 바뀌는 것에 분노할 뿐이다.

Tags: UX Renewal

사용성 테스트의 비유, 현재까지의 경험 정리

직접 설계한 서비스를 가지고 직접 사용성 테스트를 수행해보는 기분은, 눈을 가리고 목적지까지 걸어가다가 잠깐 가리개를 들어서 앞을 보는 찬스를 얻은 것과 비슷하다.

눈을 감고 앞으로 걸어가면, 한 걸음 한 걸음마다 두려움이 몰려온다. 바로 앞에 장애물이 있진 않은지, 이 방향이 맞긴 한건지. 실제로 눈을 가리고 걸어가면 바로 발 아래있는 맨홀에 빠질 수도 있고, 완전 엉뚱한 방향으로 걸어갈 수도 있다.

그래서 사용성 테스트는 왠만하면 해보는게 좋다고 본다. 전혀 안하면, 아무나 잡고 한 번만 물어봐도 알 수 있을 정도로 치명적인 실수도 전혀 대응하지 못하고 걸어가게 될 수도 있다. ‘눈을 가렸다’라는 비유를 썼지만, 사실 이건 ‘비유’가 아니다. 실제로 프로젝트를 한 달 정도만 참여하면 그 결과물에 대해선 눈이 멀게된다. 설계한 당사자는 모든 기능을 너무나 능숙하게 쓸 수 있기 때문이다. (아니 여기서 이걸 딱 누르면 이렇게 딱 되는건데, 이걸 왜 몰라? 다 바보 아냐?)

그리고, 가급적이면 빠른 시간내에 해보는 것이 좋다고 본다. 눈을 가리고 있기 때문에, ‘완전 엉뚱한 방향’으로 가고 있을 가능성도 있다. 이 때는 둘 중 하나다. 반대 방향으로 가고 있다는 것을 빨리 알아채고 제대로된 방향을 찾느냐, 아주 늦게 알아채고 절망하느냐. 조금이라도 빨리, 눈가리개를 들어서 확인해봐야 한다. 빠른 시간내에 꼭 해봐야 한다. 눈을 감고 시작하기 때문에, 사실 제대로 된 방향으로 가고 있을 확률이 지극히 낮기 때문이다.

그럼 왜, 왜 테스트를 안하게 될까? 크게 두 가지 경우가 있다.

1. 귀찮아서.
사용성 테스트와 인터뷰를 하는 것은 무지무지 귀찮다. 사실 눈가리개를 들어올리는 정도로 설명이 안될 정도로 무지무지 귀찮고 힘들다. 시간도 꽤 걸린다.
인터뷰나 테스트가 쓸모없다고 주장할 근거는 너무나 많다. 통계적으로 무의미한 숫자다, 사용자들은 자신이 원하는 것을 모른다(여기선 꼭 포드와 잡스의 격언이 함께함), 조작이나 유도가 너무 쉽다 등등. 하지만 역시 가장 근본적인 이유는 ‘귀찮음’이라고 본다.
일단, 백만명을 만날 수 없기 때문에 단 한명도 만날 필요가 없다는 것은 말이 안된다. (통계적 의미를 찾는 이에게는 딱 10명만 만나보라는 말을 해주고 싶다. 5명 넘어가면서 계속 똑같은 대답을 듣는 것이 지겨워지기 시작할 것이다. 누구한테 물어봐도 나오는 똑같은 말이 바로 찾아야할 ‘그것’이다)
사용성 테스트는 애당초 사용자들이 원하는 것을 알아내기 위해서 하는 것도 아니다. 그냥 만든걸 주고, 이거 해봐 저거 해봐 하는 것이다. 잘 하면 OK인 것이고, 못하면 거길 수정해야한다는 것을 발견하는 것으로 끝이다. 거기서 ‘그럼 어떻게 하면 잘 할 수 있을거같아?’라고 물어보는 것도 큰 의미는 없다.
조작이나 유도. 무척 쉽긴 하지만, 자기가 직접 설계하고 진심으로 잘되길 원하는 경우라면 굳이 조작이나 유도도 하지 않을 것이다. (반대의 경우가 더 많겠지만, 반대의 경우는 그냥 눈을 가리고 쭉 걸어가는 거라고 보면 된다. 뭐 눈을 감고 걸어가도 운이 좋으면 도착할 수도 있는것 아닌가)
결국 근본적인 원인은 귀찮음인 것… 사용성 테스트나 인터뷰를 완강히 거부하는 사람들을 보자. 혹시 한번도 테스트나 인터뷰를 직접 수행해보지 않은 사람이 아닌가?

2. 잘못 온거면 어떡하지?
잘못온걸 알았다 해도 이미 돌이킬 수 없는 상황에선 위와 같은 두려움이 생기게 된다. (사실 일찍 해도 생긴다) 그래서 그냥 모른척, 끝까지 가보게 된다.

어떻게 할까

여러가지 방법으로 테스트를 진행해봤지만, 음… 일단 지금까지의 미천한 경험으로 미루어봤을 때, 상당히 심플한 테스트 설계 + 최대한 자세한 프로토타입 + 5~7명 정도를 빠르게 여러번 수행하는 것이 가장 효과적인 것 같다. 테스트에서 너무 많은 것을 알아내기 위해 너무 많고 깊은 질문을 하는 것, 페이퍼 프로토타입으로 진행하는 것은 효과가 많이 떨어질 것 같다.

상세하고 깊은 질문의 문제

긴 시간동안 많은 질문을 퍼부어도, 결국 남는 것이 그리 많지 않다는게 일단 문제. 그리고 데이터가 많아져서 분석시간이 오래걸리는 것도 문제. 그리고 질문이 깊어지면 깊어질 수록 인터뷰 대상자는 상상의 나래를 펼치기 때문에 왜곡도 깊어진다는 것이 문제…
무의식적으로 보인 행동을 조용히 관찰하다가, 행동이 딱 끝나면 ‘방금 왜 그렇게 하셨죠?’ 하는 정도의 간단한 질문 까지만 하는게 좋다. 그것도 뭔가 ‘어…’하면서 생각하기 시작하면, 그때부턴 거짓말을 하는걸로 의심해도 될 것이다.
(만약 사용자의 삶이나 실제 사용 패턴을 알아봐야 하는 경우라면, 인터뷰 전에 그 사람의 로그 데이터를 분석해보거나, 다이어리 데이터를 수집하는 것을 병행해야 한다. 인터뷰 대상자가 나쁜 마음을 먹고, 나를 속이려 들기 때문이 아니다. 자기 자신에 대한 기억은 생각보다 엄청나게 부정확하다는 것이 문제다.)

페이퍼 프로토타입의 문제

페이퍼 프로토타입은 프로젝트 내부에서 소통하는데는 쓸 수 있지만, 외부 참가자에게 테스트할 때는 별로 효과적이지 않은 것 같다. 실제 사용성 이슈는 아주 작은 아이콘이나 미묘한 색의 차이에서도 발생하는데, 이런건 페이퍼 프로토타입으로 잡아낼 수는 없다. 그리고 가짜인게 너무 티가 나서 몰입이 쉽지 않다는 것도 문제.

Tags: UX usability Test

야후에 가입하고 두 번째 로그인할 때 나오는 화면.이런 페이지를 보면 이 회사가 잘 돌아가고 있구나라는 느낌이 든다. 정보 수집에 있어 지극히 ‘모범적인’ 모습을 구현하고 있기 때문이다.
가입 시 Form을 최소화하되 ‘점진적’으로 정보를 수집한다.
정보를 모을 때는 그 이유를 명확히 한다.
페이지를 구성할 때 몇 초 안에 사람을 움직일 수 있는 핵심 메시지를 가장 먼저 전달한다.
개인 정보의 경우, 안심시키는 것도 중요하다.
이런 교과서적인 이야기들을 실무에서 구현하는 것은 매우 어려운 일이다. 그리고 야후는 하고있었다.
개인적으로 ‘What if you lost access to your Yahoo! account?’라는 메시지가 너무 훌륭하게 느껴진다. 무뚝뚝하게 수십줄의 약관을 들이밀면서 전화번호를 적는 폼을 세 개 뚫어놨다면, 난 별로 내 전화번호를 내놓고 싶지 않았을 것 같다. 하지만 저 짧은 한 문장 때문에 난 바로 전화번호를 내어주었다.
그래, 비번 까먹으면 어떻게해…

야후에 가입하고 두 번째 로그인할 때 나오는 화면.
이런 페이지를 보면 이 회사가 잘 돌아가고 있구나라는 느낌이 든다. 정보 수집에 있어 지극히 ‘모범적인’ 모습을 구현하고 있기 때문이다.

  • 가입 시 Form을 최소화하되 ‘점진적’으로 정보를 수집한다.
  • 정보를 모을 때는 그 이유를 명확히 한다.
  • 페이지를 구성할 때 몇 초 안에 사람을 움직일 수 있는 핵심 메시지를 가장 먼저 전달한다.
  • 개인 정보의 경우, 안심시키는 것도 중요하다.

이런 교과서적인 이야기들을 실무에서 구현하는 것은 매우 어려운 일이다. 그리고 야후는 하고있었다.

개인적으로 ‘What if you lost access to your Yahoo! account?’라는 메시지가 너무 훌륭하게 느껴진다. 무뚝뚝하게 수십줄의 약관을 들이밀면서 전화번호를 적는 폼을 세 개 뚫어놨다면, 난 별로 내 전화번호를 내놓고 싶지 않았을 것 같다. 하지만 저 짧은 한 문장 때문에 난 바로 전화번호를 내어주었다.

그래, 비번 까먹으면 어떻게해…