큰 회사에서 하는 일

1.
프로세스 정립 프로세스를 수립하기 위한 위원회를 구성하고자 전체 담당자 회의를 가지고자 하오니 가능하신 시간과 아젠다를 적어 본 메일에 회신주시기 바랍니다

2.
본 건에 대한 상세 내용을 수합하고자 수합 담당자를 수합하고자 하오니 이를 진행할 담당자를 지정하는 협조전을 작성하여 보내주시기 바랍니다

예상치 못한 문제

예상치 못한 문제를 발견하는 방법
-> 예상하는대로 실행하고 문제가 발생할 때 까지 진행한다.

분명히 ‘해봐야 발견하는 문제’가 많은데
문제가 발견되면 ‘왜 예상하지 못했나’를 따지고 들게 된다.

Data-driven에 대한 단상

요즘은 데이터 드리븐이 어디서나 화제다.
A/B테스트, MAB, 코호트 분석, 퍼널 분석, 세그멘테이션, 전환율, 이탈율…

숫자를 보는 건 중요하다. 무척 중요하다.
하지만 숫자만 보는 건 무척 위험하다.

모든 결정을 철저히 숫자의 ‘크기’에 따라 내리다보면, 누구도 선뜻 ‘직관’을 내세우기 어려운 분위기가 조성된다. 그리고 타인의 직관에 대해 기계적으로 숫자에 기반한 근거를 요구하게 된다.

기계적이라는 것은, 어떤 의견을 들었을 때 그 의견이 ‘좋은가 아닌가’가 아닌 ‘근거의 유무’에 집중한다는 뜻이다. 근거가 있는 그저 그런 의견이 근거는 부족하지만 멋진 아이디어보다 높이 평가받게 되는 것이다.

이러한 상황은 숫자가 주는 명확성과 안도감에 매몰되면서 발생한다.  아주 중요한 사실 하나를 잊게 되는 것이다. 숫자는 어쨌든 ‘결과’이고, 숫자를 읽는 것 그 자체는 ‘생산’이 아니라는 것.

이런 상황에 빠진 조직의 목표는 변질된다. ‘멋진 것을 만들어내는 것’에서 ‘높은 숫자를 얻어내는 것’으로.

궁극적으로는 중요한 것은 숫자를 읽어내는 것 자체가 아니라, 숫자를 통해 알아낸 새로운 사실을 바탕으로 무언가를 만들어내는 것이다. 그걸 만들어내는 순간엔 반짝이는 직관이 필요하다. 그건 숫자가 아닌 사람에게서 나온다.

'높은 숫자를 얻어내는 것'이 목표인 조직의 문제는, 이 조직이 더 이상 즐겁거나 흥분되지 않는다는 것이다. 멋진 걸 만드는데 온 신경을 집중하는 사람들은 더 즐거운 곳을 향해 떠나고, 조직 안에는 숫자 높낮이 비교와 숫자 해석에 대한 끝없는 회의만 남게 될 것이다.

A/B테스트에서 가장 중요한 것은 A와 B중 무엇이 더 높은 숫자를 기록하는가가 아니라, 무엇하나 선뜻 선택하기 어려울 정도로 멋진 A/B안을 만드는 것이다.

디자인 어워드 수상에 관한 기사를 볼 때마다 드는 한 가지 의문.

'왜 진짜 세상을 바꾸고 사람들이 살아가는 방식에 영향을 준 것들은 수상자 리스트에서 볼 수 없는걸까?'

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

첫 시도를 다루는 방식

뭔가 많이 아쉬운, 혹은 욕나오는 제품들을 만나는 순간이 있다. 그럴 때 마다 그 이유에 대해 생각해본다.

  • 그걸 만든 개인/조직의 능력이 형편없어서
  • 윗분들이 무자비하게 밀어붙인 말도 안되는 일정때문에

전자의 경우는 사실 흔치는 않다. 유독 뛰어난 천재나 낙하산으로 떨어진 바보가 있을 수 있긴 하지만, 대체로 조직은 ‘충분히 잘 하는’ 사람으로 꾸려진다. (특히 크고 안정적인 기업의 경우 더욱 그런 경향을 보인다)
후자의 경우는 비일비재 하지만, 핵심적인 문제라고 보기는 좀 어렵다. 일정이 무자비하지 않은 프로젝트 자체를 찾아보기 힘들고, 널널한 일정이 프로젝트의 성공을 보장하는 것도 아니기 때문이다.

안 좋은 제품이 나오는 이유는 그 외에도 너무나 많겠지만, 오늘은 이 이유에 대해 생각해본다.

  • 처음 해본거라서

이런 경우가 별로 없다고 생각할지도 모르지만, 상당수의 프로젝트들은 여러가지 이유로 ‘첫 시도’이다. (새로운 시도가 아니라면 ‘프로젝트’라고 불릴 이유도 없지 않은가)

  • 기존 제품에 대한 새로운 접근 방식
  • 새로운 프로세스를 적용한 첫 프로젝트
  • 조직 개편 후 첫 프로젝트
  • 부서장이 바뀐 후 첫 프로젝트
  • 새로운 협력업체와의 첫 프로젝트
  • 처음 시도해보는 크기의 프로젝트
  • 기타 등등…

꼭 신제품이 아니더라도, 어디에나 뭔가 모르게 ‘처음’인 것이 섞여들어가 있다.

처음 해보는 것은 뭐든지 좌충우돌이다. 문제가 많을 수 밖에 없다. 수많은 개선사항이 널려있고, 주위에선 비난이 쏟아진다.

  • 아 이거 담당자가 대체 누구야
  • 그거 예전에 해봤는데 안되는거라고 내가 몇 번이나 말했는데
  • 와 이거 안되는거 봐. 테스트는 해본거야?
  • 이런 제품이 나오다니 부끄럽습니다!
  • 그럼 그렇지… 내 이럴 줄 알았지~

대부분의 프로젝트는 일정 부분 ‘첫 시도’이고, 그로 인해 문제가 많이 발생하는 것이 자연스러운 것이라면, 핵심은 ‘어떻게 문제 없이 완벽한 첫 시도’를 해내는가가 아닌, ‘얼마나 빠르게 문제를 개선해내는가’하는 것이다.

문제 개선은 무척이나 쉬워보인다. 문제와 의견들을 ‘취합’하고 우선순위에 따라 ‘줄 세우고’, 최대한 빨리 해결책을 구현해나가면 되는 것 아닌가? 하지만 현실은 그렇지 않다. 개선은 사실 최초 출시만큼이나 (혹은 그보다 더) 힘들다. 크게 두 가지 이유로.

첫 번째. 수 많은 의견 충돌.

  • 문제와 의견들이 서로 상충한다 : “이게 문제에요!” “아니 그게 왜 문제에요!”
  • 우선순위에 대한 의견도 상충한다 : “이게 제일 급해요!” “그건 쓰는 사람도 별로 없잖아요!”
  • 한 문제에 대한 해결책은 수 없이 많고, 그 중 무언가를 선택해야 한다 : “이건 이렇게 해결하면 되잖아요?” “이런 방법이 더 낫지 않나요?” “무슨 근거로 그런 말씀을?”

두 번째. 사람은 떠나고 시간은 없음

  • 출시 이후 개선 일정이 전혀 고려되지 않음 : “이거 개선 진행하자” “투입되었던 디자이너랑 개발자 다 다른 프로젝트 들어갔는데요”
  • 지쳐서 다 나가버림 : “담당자 누구야?” “이거 끝나고 빡쳐서 이직했어요”
  • 개선이 아닌 성과를 요구받음 : “출시 후 성과 일단위로 보고하라십니다”

위와 같은 문제를 보면, 출시 후 개선을 이루어 내기 위해 두 가지를 확보해야 함을 알 수 있다.

  1. 제품을 직접 만들었고, 그 제품에 애정을 가진 사람
  2. 문제를 정리하고 개선을 진행할 시간

그리고 한 가지를 제거하는 것도 필요하다.

  1. 너도 나도 하나씩 던지는 의견(을 가장한 비난)

출시 직후 비난은 별로 쓸모가 없다. 출시된 제품에서 크고 작은 문제를 찾아내는 건 너무 쉬운 일이다. ‘내 그럴 줄 알았지’라고 말하는 건 사후 확신 편향에 불과하다. 

진짜 어려운 건 그걸 개선해나가는 것이다. 이건 아무나 할 수 없는 일이다.

  • 초점없는 비난에 흔들리지 않고 진짜 문제를 발견하기
  • 출시에 지친 조직원들을 다독거리고, 단기적인 성과에 실망하지 않도록 하기
  • 신중하게 해결책을 탐구하기 (단기적으로 쏟아져나오는 해결책들의 대부분은 ‘하지 않는 것’ 보다 못한 것들이다)
  • 가장 효과가 크고 적은 노력으로도 구현할 수 있는 개선책을 빠르게 실행히기

멋진 신제품 출시 사례는 많이 볼 수 있지만, 훌륭한 개선 사례는 그리 쉽게 찾아볼 수 없다. 그만큼 참 어려운 일이라는 뜻이 아닐까.

*개인적으로, 페이스북의 ‘뉴스 피드’ 출시 직후 대응은 대단히 모범적인 사례 중 하나라고 생각한다.

  • 출시 직후 사용자들로부터 폭풍 비난 받음. 당장 해당 기능을 제거하라는 내/외부의 강력한 압력
  • 주커버그는 뉴스 피드가 먹히지 않는다면 소셜 네트워크에 대한 자신의 모든 가설이 틀리게 되는 것이라고 생각하여 제거를 고려하지 않음.
  • 비난 여론은 거셌지만, 뉴스 피드 출시 이후, 특정 그룹이나 정보가 엄청난 속도로 확산되는 것과 사용자의 사용 시간이 급격히 늘어남을 발견
  • 출시 3일만에 게시물의 공개 범위를 설정할 수 있는 기능을 빠르게 개발하고, 주커버그의 사과와 함께 배포

Tags: 조직론