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

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

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

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

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

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

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

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

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

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

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

위와 같이 생각한 이유는…

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

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

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

문제 정의와 문제 해결에 대한 단상

"사실 고객의 문제가 무엇인지 알고 있다면, 그 문제를 해결하는 것은 쉬운 일이다."

— 실전 웹사이트 분석 A to Z (Web Analytics : An Hour a Day) - p. 57

제품을 개발하는데 있어 ‘문제 정의’의 중요성을 강조하는 시각이 많다. 위 인용 문구도 그것을 강조한 것이며, 린 스타트업 방법론에서도 전체 과정 중 가장 중요한 것으로 ‘문제 정의’를 꼽고 있다. (스타트업의 가장 큰 위험은 ‘아무도 원하지 않는 제품’을 만드는 것이다 - 라는 문장으로 대표되는)

문제 정의의 중요성을 강조하는 글이나 발표에서는 우리에게 항상 이런 주문을 한다.

당신에게 주어진 문제를 그대로 받아들이지 말고, 문제를 새로운 관점에서 바라보고 ‘진짜 문제’를 찾아라!

그리고 이를 증명하기 위해 수많은 성공 사례들을 나열한다.

OOO한 문제가 있어서 의뢰가 들어왔는데, 우리는 리서치 결과 XXX하다는 것을 발견하였고, 진정한 문제가 ***라는 것을 깨달았습니다. 그래서 우리는 ###를 하였고, 그 결과 @@성과가 00% 상승하였습니다!

이건 정말 명확해보이고, 우리는 발표가 끝난 후, 그동안 제대로 성과를 내지 못한 자신을 원망하게 된다. 그런데, 뭔가 이상하다.

이 세상엔 똑똑한 사람들이 많고, 이들은 진정한 문제 해결을 위해 문제를 다른 관점에서 해석해야한다는 사실을 알고 있고, 또 그렇게 하려고 노력한다. 그런데 왜 진짜 문제를 해결하고 큰 수확을 거두는 경우는 여전히 많지 않은 걸까? (그리고 왜 난 문제 정의부터 다시 하는데도 성과를 거두지 못하는 걸까?)

성공적인 문제 해결책은 괜찮은 문제 정의에 기초하는 것은 맞지만, 모든 기막힌 문제 정의가 성공적인 해결책을 보장하는 것은 아니다. 그럼 그 사이엔 어떤 것이 있는걸까?

그래서 성공 사례의 주인공을 향해 이런 질문을 해본다.

"그 새롭고 창의적인 문제 정의가 옳다는 것을 언제 확신하게 되었습니까?"

과연 그 시점이 ‘리서치 결과를 보았을 때’ 였을까? 요즘엔 문제 정의를 위한 기반 리서치도 엄청 많이 하지만, 탄탄하고 방대한 리서치 역시 성공을 보장하진 못한다. 문제 정의가 옳다는 것을 증명할 수 있는 때는 ‘해결책이 성공을 거두었을 때’ 뿐이라는 것이 나의 생각이다.

이것은 다시 말해, ‘문제 정의’와 ‘해결’을 명확히 나눌 수 없다는 것을 뜻한다.

해결책을 만들어보는 과정 자체가 ‘문제 정의가 옳았는지 검증하는 과정’이며, 따라서 ‘문제 정의는 끝났고 해결책에 집중하자’라는 말은 무척 위험하다.

'문제 정의'에 대한 강조는 자칫, '뭔가 일단 만들어보는 것'의 가치를 필요 이상으로 평가절하하는 결과를 불러올 수 있다. 앞으로 나아가지 못하고 지루한 말꼬투리 잡기에 머무르게 될 수도 있다.

'뭔가 일단 만들어보는 것'의 가치는 특히 디지털 서비스 제작 영역에서 더욱 크다. 다른 분야에 비해 '해결책을 만들어보는' 가격을 극적으로 낮출 수 있는 방법이 많기 때문이다. 컴퓨터가 할 일을 사람이 한동안 직접 해본다든가, 아직 구현되지 않은 기능이지만 마치 되는 것 처럼 데모 비디오를 만들어본다는가 하는 것들이 바로 그것이다.

작게나마 문제 정의를 해보았다면 일단 뭔가를 만들어보는 실행력과 용기를 가져보자. 유관 부서를 죄다 모아놓은 회의에서 쏟아지는 질문 공세 속에서도 내 논리를 무사히 방어한다고 문제 정의에 대한 검증이 끝나는 것은 아니다.

Tags: essay 문제

큰 회사에서 하는 일

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

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

예상치 못한 문제

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

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

Data-driven에 대한 단상

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

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

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

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

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

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

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

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

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

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

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