limitist

[limitist]

소위 'UX 디자이너'가 되기 위해 인정해야만 했던 세상의 순리

1. 문제 해결을 위한 ‘최적의 안’이 아니라 문제를 해결하는 ‘가장 작은 변화’가 채택된다. - 사람들은 변화를 끔찍이도 귀찮아한다.

2. 그러나 사실, 대부분의 경우 문제를 그냥 안고 살아가는 편을 택한다. - 변화가 너무나도 싫기 때문이다.

3. ‘논리적으로 명쾌하게 정리하기’ 보다는 ‘제일 자주 하는 것’ 하나를 위해 나머지를 모두 엉망으로 만드는 편이 낫다. - 대표적인 사례 : 당신의 책상 위 - 명쾌한 정리를 더 선호하는 소수의 예외적인 사람들도 있다. - 유감스럽게도 ‘디자인’을 하는 사람들 중 ‘예외적인’ 사람들이 많다.

4. 컴퓨터로 무언가를 하는 것은 보통 굉장히 고통스러운 일이다. - 컴퓨터로 일을 처리하는게 편하다고 느끼는 건 극히 일부다. 이 글을 읽고 있는 사람이라면 그 일부에 속해있다고 봐도 된다.

5. 늘 경쟁사랑 싸우는 것 같지만 ‘사람들의 습관’이 가장 큰 경쟁상대다. - 그래서 경쟁사 분석이 소용없을때가 많다. - 특히 새로운 영역의 서비스는 ‘경쟁사때매 망할 가능성’보다 ‘내가 속한 제품군 전체가 습관에게 무릎꿇을 가능성’이 더 크다.

6. 사실 ‘UX’가 비즈니스 성패에 결정적인 영향을 끼치지 않을 때도 있다. - 솔직히, 보통은 별로 안 중요하다고도 말할 수 있을 지경이다. - 증거 1. 쇼핑은 역시 최저가다. 싸면 견딜 수 있다. - 증거 2. 마케팅비를 쏟아부으면 결과는 나온다. (얼마 못갈지라도) - 증거 3. 그렇지 않고서야 이렇게 거지같은 경험들이 판을 칠 수가 없다.

7. 뭔가를 정말 편하게 만드는 것 보다 정말 불편해도 쓸수밖에 없는 무언가를 찾는게 훨씬 중요하다. - 훨씬 어렵기도 하다.

[limitist]

기능 추가는 나쁘다.

‘기능 추가는 나쁘다'

좀 과격하게 썼지만, 요즘 머릿속에 꼭꼭 넣고 있는 말이다. 좀 더 풀어쓰자면, 

‘기능 추가에는 생각보다 아주 큰 비용이 숨어있다. 그 비용을 잊지 말���' 는 것이다. 

‘기능 추가’가 나쁠 수 있을까? ‘기능’이 있으면 편해진다. 편해지는 것을 ‘추가’하면 당연히 더 좋아지는 것 아닐까?

결코 그렇지 않다. 모든 '기능 추가’에는 이런 비용이 ‘숨어있기' 때문이다.

1. 기능 추가에는 시간과 돈이 든다. 2. 기능 추가는 제품의 복잡도를 높여서 사용을 어렵게 만든다. 3. 기능 추가는 제품의 속도를 느리게 한다. 4. 기능 추가는 개발 진행 속도를 느리게 한다.

굳이 ‘숨어있다’는 표현을 쓴 이유는, 기능 추가를 진행할 때 이런 비용들이 쉽게 ‘간과’되기 때문이다. 하지만 가만히 생각해보면, 기능 추가를 왠만해선 하고 싶지 않을 만큼이나 기능 추가는 ‘비싸다’.

자, 1번 부터 - '기능 추가에는 시간과 돈이 든다' ‘시간과 돈’은 기능 추가의 비용에서 가장 먼저 떠올릴 수 있는 것이다. 기능을 추가하는 것은 무언가를 개발하는 것이고, 이를 위해 개발자는 시간을 쓴다. 무언가 다른 일을 할 수도 있었던 시간을 쓰는 것이다. 이 자체가 아주 큰 기회비용. 동시에, 기능 추가는 돈이 든다. ‘돈’은 특히 인하우스 업무 환경에서 많이 간과되는 부분이다. 개발자 월급을 자신이 주는 것이 아니기 때문에 기능 추가에 얼마의 비용이 들어가는지 정확히 계산할 일이 없기 때문. 기능 추가에 따라 추가되는 장비 비용이나 마케팅에 들어가는 비용은 산정하지만, 월급으로는 얼마가 들어가는지는 좀처럼 계산하진 않는다. (어차피 서로의 연봉이 비밀이기 때문에 알 수도 없고…) 계산하지 않다 보니 마치 비용이 없는 것 처럼 느껴진다. 시간과 돈만으로도 이미 기능 추가는 충분히 비싸다. 기능 추가 후, 성과가 0이라면 그건 0이 아니라 이미 심각한 마이너스다. 

2. 기능 추가는 제품의 복잡도를 높여서 사용을 어렵게 만든다. 기능 추가는 보통 제품의 사용을 ‘쉽게’, ‘더 편하게’ 만들기 위해서 하지만, 이는 매우 달성하기 어려운 목표이다. 기능이 추가되는 순간, 어쩔 수 없이 제품은 사용하기 더 어려워진다. 새 기능은 아무리 작더라도 화면의 어떤 부분을 차지하게 된다. 한 화면에 봐야할 것이 하나 더 늘어난다는 것은 그 화면을 보는 순간 생각해야할 것이 하나 더 늘어난다는 뜻이다. 처음 보는 기능이라면 그 기능을 이해하고 학습하는 노력도 필요하다. ‘기능 한 두개 정도 더 들어간다고 뭐가 그리 달라질까?’ 싶다면, 화면 전체에 버튼이 단 하나밖에 없는 상황을 생각해보자. 이 화면에서 생각할 것은 하나 뿐이다. 이 버튼을 누르거나 누르지 않거나. 이러한 화면에 두 개의 새 버튼이 들어간다고 생각해보자. 할 수 있는 일은 세 개로 늘어난다. 버튼 A를 누르거나 / 누르지 않거나, 버튼 B를 누르거나 / 누르지 않거나, 버튼 C를 누르거나 / 누르지 않거나. 거기에 더하여 B와 C 버튼이 무슨 역할을 하는지도 배워야하고, 이전에는 전혀 생각할 필요도 없었던 것도 생각해야 한다. ‘A 버튼은 무슨 역할을 하지?’ 단지 두 개의 버튼이 들어감으로써 복잡도는 3배 이상으로 늘어난다.

3. 기능 추가는 제품의 속도를 느리게 한다. 소프트웨어가 뭔가 하나를 더 해야하므로 그만큼 느려진다. 앱이 켜지는 속도든, 로딩 속도든 뭐든. 나중에 튜닝을 통해서 빨라지게 할 수는 있지만, 기능 추가가 없는 것 만큼 빠를 수는 없다. (제품의 속도를 빨라지게 하는 기능도 있긴 하지만) 

4. 기능 추가는 개발 진행 속도를 느리게 한다. 기능 추가는 제품 사용자만 헷갈리게 하는 것이 아니다. 그 제품을 만드는 사람도 헷갈리게 한다. 제품을 이해하는데 걸리는 시간이 늘어난다. 고려해야 할 케이스가 늘어난다. 새로 참여한 사람이 알아야 할 것이 늘어난다. 기능 추가는 또 어쩔 수 없이, 개발팀의 ‘다음 스텝’을 느리게 한다. 기능이 쌓이고 쌓이면 나중엔 이런 말이 나오게 된다. ‘그거 완전 꼬여있어서 아무도 못바꿀걸?' 

그럼 기능 추가는 절대 해선 안되는 것인가? 당연히 아니다.

그럼 어떤 기능을 추가해야 할까? 

다양한 판단 기준이 있겠지만, 나는 ‘대체 뭐가 문제야? (원제 : Are Your Lights On?)’ 라는 책의 방식을 따르려고 한다.

‘어떤 문제에 대한 해결책은 반드시 새로운 문제를 가져온다. 새로운 문제가 기존 문제보다 작을 때만 해결책을 채택하라.' 

이것을 기능 추가에 비춰서 생각해보면...

‘새로운 기능이 가져올 혜택(사용자의 만족이든 엄청난 성장이든)이 기능 추가의 비용을 충분히 상쇄하고도 남는다면, 그 기능을 추가하라.' 

기능 추가의 비용이 너무 비싸기 때문에, 저 기준을 통과할만한 기능은 솔직히 정말 찾기 힘들다. 그런 부분을 찾기 위해선 무척 예민하게 자신의 제품과 사람들의 행동을 관찰해야 한다. (라고 말은 하지만 솔직히 나도 성공한 적은 없다)

보통 기능 추가 비용은 극도로 과소평가되고, 새 기능이 가져올 혜택에 대한 기대감은 극도로 과대평가된다. 그래서 많은 제품에 지금도 (기준 이하의) 기능이 끊임없이 추가된다. (나중엔 버튼 두 세개 더한 정도는 티도 안날 만큼)

다시 과격하게 말하자면, '우리가 해야할 것은 기능 추가가 아니다.' 

사실 잘 생각해보면 우리가 해야할 일은, ‘문제를 해결하는 것'이다. 

기능 추가는 문제를 해결하기 위한 하나의 수단에 불과하다. (그러나 제일 쉬운 방법이기 때문에 우리는 기능 추가의 유혹을 쉽게 뿌리치지 못한다.)

어떤 문제가 생겼을 때, 기능을 추가하지 않고도 해결할 수 있을지도 모른다. (상당히 많은 경우에) 단지 문구를 바꾸는 것 만으로도 해결된다. 또 어떤 때는 기능을 ‘제거’함으로써 문제가 해결될 수도 있다. 가끔은 그냥 시간이 지나면서 저절로 문제가 해결되기도 한다.

그렇다면, 사용자들의 기능 추가 요구는 어떨까?

어떤 기능을 추가해달라는 사용자들의 요구는 늘 있다. 이것 마저 무시해야 하나? 이건 명백한 기능 추가 사유가 아닌가?

하지만 그들이 궁극적으로 바라는 것을 생각해봐야 한다. 어떤 기능을 넣어달라는 요구가 있을 때, 그들이 진정 바라는 것은 특정한 ‘기능'이 아니라 그들이 현재 겪고 있는 ‘문제'가 해결되는 것이다. 그 기능을 추가하지 않고도 문제가 해결된다면, 굳이 그 기능을 요구하진 않을 것이다. 그리고 원하는 기능을 넣었다고 해도 ‘문제’가 해결되지 않았다면, 또 다른 기능 요구가 유령처럼 다시 생겨나게 될 것이다.

어떤 기능을 추가할지 고민하지 말자. 그보다는, 무엇이 문제인지 찾자. 찾았다면, 그 근본적인 원인을 찾자.

(라고 매일 다짐한다) 

[limitist]

좋은 팀에 대하여

짧은 사회생활 동안, 나는 참 '팀운'이 좋았다. 특히 큰 조직에서는 좋은 팀을 만나기 더 어렵다는 점을 생각해보면 운이 굉장히 좋았던 것. 그냥 '좋다'라고만 생각해왔는데, 뭐가 그렇게 만들었던 것일까? 생각을 정리해본다. 지극히 주관적으로.

1. 팀원이 팀원으로부터 배운다. 정기적인 팀 스터디는 유지하기 쉽지 않지만 잘 돌아가면 효과는 대단히 크다. 서로가 서로를 존중하게 된다는 것. 이 팀에서 내가 뭔가 '배우고 있다'는 '느낌'을 준다는 점. (주니어의 경우, 이 느낌이 없어서 회사를 떠나는 경우가 정말 많다) 남을 가르치기 위해 스스로가 엄청 공부하게 되어서 성장하게 된다는 점 등. 리더의 의지 (정말 웬만한 일이 아니면 한다), 팀원들의 '적당한' 열의 (과열되면 오래 못간다), 스터디 할 공간 등 유지하기 위한 조건이 몹시 까다롭지만 팀웍 유지에 대단한 효과가 있다.

2. 사소한 공유 팀웍을 위해서는 서로 뭘 하고 있는지 파악하는 것이 중요한데, 거창하고 형식적인 것 보다는 사소하고 간접적인 것이 효과가 좋은 것 같다. 월요일 오전 티타임, 혹은 스터디 시간 전후의 잡담, 농담으로 시작하는 메일 쓰레드나 메신저 메시지, 아님 자리 옆이나 벽같은 곳에 슬쩍 결과물을 걸어두는 것 등... 주간보고 따위는 왠만해선 읽지 않지만 못보던 시안이나 재밌어보이는 문장, 프로토타입은 곁눈질로라도 보게 마련이다.

3. 외향성과 내향성의 밸런스 언뜻 생각하면 외향적인 사람과 내향적인 사람은 함께 일하기 힘들 것 같다. 목소리크고 성질 급한 사람과 일하는 내향적인 사람은 얼마나 스트레스를 받을까? 좀처럼 말이 없고 혼자 조용히 뭘 만들고만 있는데 잘 보여주지 않는 사람과 일하는 외향적인 사람은 얼마나 답답할까? 하지만 같은 성향의 사람들이 파트너가 되어 일할 때, 더 큰 스트레스가 찾아올 수 있다. 문제 해결에는 내향성과 외향성이 동시에 요구되는 경우가 많기 때문이다. 어떤 발표 준비를 한다고 했을 때, 넓은 인맥을 동원하거나 얼굴에 철판깔고 자료를 요구하는 일도 해야하고 오타하나 없이 정돈된 자료를 만드는 일도 해야한다. 같은 성향의 사람들 끼리 여가���간을 보내는 것은 즐겁겠지만, 일은 꼭 그렇지 않다. 내가 제일 하기 싫은 일은 파트너에게도 제일 하기 싫은 일이기 때문이다. 누군가는 그 일을 해야만 한다. 미묘한 신경전이 생긴다. 반면 외향적인 사람과 내향적인 사람이 파트너가 되어 함께 일하는 것은 마치 악어와 악어새의 관계같은 것이다. 내가 제일 하기 싫은 일이 상대에겐 할만한 일이고, 내가 좀 할만한 일은 상대가 제일 하기 싫은 일이다. 파트너를 좋아하게 될 수 밖에 없다. 내가 제일 하기 싫은 일을 도맡아 처리해주니까. (물론 둘 사이에 '존중'이 형성되었을 때의 이야기다. '내가 이런거 다 하는데 쟤는 저거 하나하고 진짜 유세떠네' 요런 분위기면 망.)

4. 자체적인 결과물 생산  팀 자체적으로 '흥미로운 결과물'을 생산할 수 있다면 좋다. 팀 전체가 최종 결과물을 만들어내는 '중간 단계'의 일만 한다면 성취감을 얻기 힘들 수도 있다. 다른 팀에 의존 없이, 혹은 최소한의 협업으로 어떤 결과물을 만들 수 있는 팀 구성이라면 빠르게 움직이고 더 자주 결과물을 만들어내고 더 많이 성취감을 느낄 수 있을 것이다.  내가 속해있던 팀들은 사실 이 부분에서 많이 아쉬움을 느꼈기 때문에 이것은 희망사항에 가까운 것이다. 이런 팀을 생각하게 된 것은 Linkedin의 Data Science Team의 설립을 다룬 글을 읽고나서였다. 데이터 사이언티스트들만 모아두었을 때는 회사 내에서 별다른 성과를 거두지 못하여 좌절하였으나 직접 서비스를 런칭할 수 있는 팀으로 구성하자 뛰어난 제품을 만들어내며 성장했다는...  논란(?)의 여지는 있지만, 개인적으로 '업무별'로 나눈 팀 보다는 '제품' 혹은 '목표'로 나눈 팀이 더 좋다고 생각하는 이유이기도 하다. '기획팀', '디자인팀', '개발팀' 보다는 'OO제품 팀'.

5. 유머 개인적으로는 팀이 가지고 있는 '유머'의 총량이 어마어마하게 중요하다고 생각한다. 팀이 가지고 있는 유머는 정말 많은 것을 내포하고 있기 때문이다. - 팀원들 간에 '대화의 결'이 잘 맞는다. - 팀원들 중 언어나 제스처에 탁월한 감각이 있는 사람이 많다. - 팀원들이 이 팀에서 행복을 느끼는 순간이 있다. - 팀원들 끼리 서로의 말을 들어주고 또 열려있다. 유머의 중요성에 대해 다시 한번 강조하고자, 문구를 인용해본다.

"뭔가 중요한 일이 일어나고 있을 때 이를 알리는 방법 중 한 가지는 웃음이다. 실험실에서 뭔가 대단히 흥미로운 일이 발생하고 있을 때 그 옆을 지나가면, 가장 먼저 웃음소리를 들을 수 있다. 웃음은 놀라움과 연결되어 있다. 웃음소리를 들으면, 모든 것이 잘 되어 가고 있고, 뭔가 가치 있는 것이 실험실 안에서 발생하기 시작했다는 것을 알 수 있다."  웃음은 사람들이 새로운 아이디어에 대해 두려움 없이 편안해함을 의미한다.

- from '이노베이션 신화의 진실과 오해' by 스콧 버쿤

6. 좋은 리더 위 다섯 가지 조건을 만들어내는 가장 큰 요인은 결국 '리더'일 것이다. 좋은 팀 리더는 어떤 것일까? 내가 이것에 대해 논하기엔 아직 한참 이르지만, 딱 하나 느낀 것이 있다면 이것이다.

좋은 리더는 '일을 잘하는 사람'이 아니라 '프레임을 잘 짜는 사람'이다.

일을 잘하는 사람이 아니라 다른 사람이 일을 잘 할수 있게 만들어내는 사람. 좋은 아이디어를 내는 사람이 아니라 다른 사람들로 하여금 편안하게 아이디어를 낼 수 있는 분위기를 만들어내는 사람. 규제나 프로세스를 만들어내기 보다는 그게 없이도 잘 돌아가게 만들 수 있는 사람. 같은 이름의 시간을 가져도 리더가 다른 접근을 하면 그 시간이 완전히 달라진다. 같은 팀 워크샵을 가도 어떤 리더는 숙취와 잔소리만 남기지만, 어떤 리더는 술 한방울 없이도 감동의 눈물을 흘리게 한다. (비유가 아니라 실제로 있었던 일. 프로젝트 이야기를 공유하다가 서로 너무 고마워서 펑펑 울었다는...)

얼마전 새로운 팀에 합류하였는데, 아무래도 나의 운은 아직 꽤 많이 남아있는 모양이다. 이번 팀에선 또 어떤 것들이 업데이트 될지 벌써 기대가 된다.

[limitist]

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

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

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

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

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

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

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

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

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

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

1명이 서비스 전체의 UX를 설계할 수 있다면 가장 좋다.

아무리 많아도 3명을 넘지 않아야 한다. (하지만 3명도 별로 좋진 않다)

피드백은 낱장의 와이어프레임이 아닌, 주요 Flow를 볼 수 있는 프로토타입을 공유한 후 받는다.

단, 피드백을 받을 때 중요한 것 : '피드백'을 받야아 한다는 것이다. 결코 '컨펌'을 받아선 안된다. 최종 의사결정은 설계자가 내려야 한다.

위와 같이 생각한 이유는...

여러 사람이 함께 서비스를 설계하면 결국 매끄럽게 연결되지 않는 부분이 생긴다. 서로의 생각을 완전 일치시킬 순 없다.

여러 사람이 함께 서비스를 설계하거나 누군가의 '컨펌'을 받는다면, 서비스에 대한 '소유의식'이 떨어진다. (위 인용문에 나온 것 처럼) '소유의식'이 떨어지면 '애착'이 떨어지고, 자신의 설계를 방어하는데 게을러진다. 그냥 해달라는대로 다 해주고, 지적받는대로 고치게 되며, 그러는 동안 남아있던 소유의식마저 사라지고 경험은 '덕지덕지 주렁주렁' 상태가 된다.

전체 서비스가 돌아가는 모습과 그것이 줄 '느낌', '경험'을 상상해낼 수 없다. 내가 설계한 건 '느낄 수' 있지만, 솔직히 남이 설계한 건 그냥 '문서'일 뿐이다.

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

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

[limitist]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[limitist]

큰 회사에서 하는 일

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

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

[limitist]

예상치 못한 문제

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

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

[limitist]

Data-driven에 대한 단상

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

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

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

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

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

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

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

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

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

[limitist]

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

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

[limitist]

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. 우린 기술력이 없어서 안될거야 아마... 그렇다면 : 피플 웨어

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

단점 : 글쎄...

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

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

[limitist]

첫 시도를 다루는 방식

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

그걸 만든 개인/조직의 능력이 형편없어서

윗분들이 무자비하게 밀어붙인 말도 안되는 일정때문에

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

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

처음 해본거라서

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

기존 제품에 대한 새로운 접근 방식

새로운 프로세스를 적용한 첫 프로젝트

조직 개편 후 첫 프로젝트

부서장이 바뀐 후 첫 프로젝트

새로운 협력업체와의 첫 프로젝트

처음 시도해보는 크기의 프로젝트

기타 등등...

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

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

아 이거 담당자가 대체 누구야

그거 예전에 해봤는데 안되는거라고 내가 몇 번이나 말했는데

와 이거 안되는거 봐. 테스트는 해본거야?

이런 제품이 나오다니 부끄럽습니다!

그럼 그렇지... 내 이럴 줄 알았지~

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

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

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

문제와 의견들이 서로 상충한다 : "이게 문제에요!" "아니 그게 왜 문제에요!"

우선순위에 대한 의견도 상충한다 : "이게 제일 급해요!" "그건 쓰는 사람도 별로 없잖아요!"

한 문제에 대한 해결책은 수 없이 많고, 그 중 무언가를 선택해야 한다 : "이건 이렇게 해결하면 되잖아요?" "이런 방법이 더 낫지 않나요?" "무슨 근거로 그런 말씀을?"

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

출시 이후 개선 일정이 전혀 고려되지 않음 : "이거 개선 진행하자" "투입되었던 디자이너랑 개발자 다 다른 프로젝트 들어갔는데요"

지쳐서 다 나가버림 : "담당자 누구야?" "이거 끝나고 빡쳐서 이직했어요"

개선이 아닌 성과를 요구받음 : "출시 후 성과 일단위로 보고하라십니다"

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

제품을 직접 만들었고, 그 제품에 애정을 가진 사람

문제를 정리하고 개선을 진행할 시간

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

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

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

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

초점없는 비난에 흔들리지 않고 진짜 문제를 발견하기

출시에 지친 조직원들을 다독거리고, 단기적인 성과에 실망하지 않도록 하기

신중하게 해결책을 탐구하기 (단기적으로 쏟아져나오는 해결책들의 대부분은 '하지 않는 것' 보다 못한 것들이다)

가장 효과가 크고 적은 노력으로도 구현할 수 있는 개선책을 빠르게 실행히기

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

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

출시 직후 사용자들로부터 폭풍 비난 받음. 당장 해당 기능을 제거하라는 내/외부의 강력한 압력

주커버그는 뉴스 피드가 먹히지 않는다면 소셜 네트워크에 대한 자신의 모든 가설이 틀리게 되는 것이라고 생각하여 제거를 고려하지 않음.

비난 여론은 거셌지만, 뉴스 피드 출시 이후, 특정 그룹이나 정보가 엄청난 속도로 확산되는 것과 사용자의 사용 시간이 급격히 늘어남을 발견

출시 3일만에 게시물의 공개 범위를 설정할 수 있는 기능을 빠르게 개발하고, 주커버그의 사과와 함께 배포

[limitist]

2014.

2014년의 첫 포스팅.

한 동안 포스팅에서 손을 놓고 있었다고 생각했다. 확인해보니 12월 한달간 아무것도 쓰지 않았다. 12월은 처음으로 '무직'상태로 전환되는 시점이었다. 새해를 활기차게 맞이하기 위해 12월에 했던 생각들을 간단히 정리해본다.

1. IT 회사가 잘 돌아가는데 있어서 가장 중요한 것은 '리더'의 역량이다. 좀 더 정확한 느낌은... 진짜 개 미친 뛰어난 리더도 실패할 수 있지만, 평범한 리더가 이끄는 IT 회사가 잘 될 수는 없다. 하물며 평균 이하의 리더들이 이끄는 회사의 미래는 뭐... ^^ (내가 현재 무직인 이유가 꼭 이건 아니겠지)

2. 뛰어난 리더가 가져야 할 제일 중요한 역량 중 하나는 '어떤 조직으로 하여금 열정을 불태우게 만드는 기술'이다. 뛰어난 리더가 이끄는 조직의 사람들은 시키지 않아도 막 야근 막 하고 막 그러고 불만도 없고 막 별로 피곤한 기색도 없고 다 자기 일 처럼 매달리고 한다. 그러면서 '자존감'을 느낀다. 보통 리더가 이끄는 조직은 시키는 일을 한다. 목표는 '성과'나 '죽이는 제품'이 아니라 '이슈 없음'과 '제시간의 퇴근'이다. (근데 '죽어라 일하고 싶은' 워커홀릭들은 이런 사람들 아래서 더 큰 피로를 느낀다) 최악의 리더는 혼자 열정을 불태운다. (주위 사람들은 그냥 '탄다')

3. 큰 회사의 실패는 '느려서' 가 아니라 '잘못된 선택을 해서' 발생한다. 큰 회사들이 '스피드'를 더 강조한다. 자기가 느린 걸 알기 때문이다. 근데 '스피드'를 강조한다고 큰 회사가 빨라지는 건 아니란 사실은 잘 모르는 것 같다. 덩치가 큰데 스피드를 엄청 강조하면 그냥 '조급함'이 되고 잘못된 의사결정을 하고 그래서 망하더라... (내가 다니던 회사를 보며 '위대한 기업은 다 어디로 갔을까'를 읽고 든 생각)

4. 회사는 어쨌건 잔인한 곳이다. 근데 그렇다고 뭐 정을 주지 말자거나 철저히 받은 만큼만 일하거나 그렇게 생각할 필요도 없는 것 같다. 어떤 방법으로든 자기 만족을 찾는게 중요하지 않을까.

조만간 '2013년 올해의 OOO' 시리즈를 정리해봐야 겠다.

[limitist]

Best of Best - iOS7

사실, 2013년에 UI의 모든 것을 바꾸어 버린 것은 애플이다.

불가능해 보이는 디자인을 가능한 것으로 만들었고, UI디자인의 방향과 스타일이 모두 바뀌었다. 그 변화가 지대한 나머지, 이후의 모든 리디자인이 대부분 iOS7에 종속된 것처럼 보일 지경이었다.

출시와 함께 플랫 디자인 스타일에 대해 비난이 난무했지만,

욕하다 정신을 차려보니 플랫하지 않은 것들이 모두 촌스러워 보였다.

플랫폼 사업자가 모든 것을 만든다는 진리를 다시 확인했다.

UI -...

[limitist]

두 접근법

내가 좋아하는 걸 만든다 vs 타인의 문제에 깊이 공감하고 최적의 해결책을 제시한다 끊임없이 교차하는 두 접근법. 닮은 듯 다른 듯 될 듯 말 듯 어쨋든, 타인의 삶에 집중하는 건 상당히 피곤한 일

[limitist]

요컨대, 일중독자들의 실제 성과는 오히려 정상인들보다 못하다. 많은 일중독자들이 완벽주의자를 자처한다. 하지만 그들이 말하는 완벽주의는 진정한 완벽주의가 아니다. 별로 중요하지 않은 세부사항에 집착하여 다음 작업으로 나아가지 못하는 것일 뿐이다. 일중독자들은 영웅이 아니다. 그들은 세상을 구원하지 못한다. 단지 쓸데없이 자기 몸만 학대할 뿐이다. 진짜 영웅은 벌써 일을 끝내고 집에서 쉬고 있다.

똑바로 일하라 Rework p.32

알았어. 집에 가자.

[limitist]

단상

'전략'이 아닌 '비전'으로 일해보고 싶다

[limitist]

편리함을 추구하는 행동도 충분히 이해됩니다. 사람도 물처럼 저항이 가장 적은 경로를 따라 흐르는 경향이 있어요. 나이키의 고객에 대해 언제나 적용하는 가정이죠. 하지만 우리 스스로에게는 절대 적용하지 않습니다. 타인의 삶을 쉽고 편리하게 만들려면 자신의 삶은 고달파야 합니다. 쉬운 해결책을 제시하려면 피땀 흘리며 열심히 노력해야 한다는 말은 속도전의 세계에서는 너무 당연한 진리입니다.

from 벨로시티 Velocity (p.133)

Getting Real류의 소프트웨어 개발 방법론(또는 철학?)에서는 소위 '기능 추가'를 거의 '죄악'시 한다. 그것은 출시 일정을 늦추고 비용을 증가시키고 소프트웨어를 더 쓰기 어렵게 한다.

아마 많은 사람들이 저 의견에 동의할 것이다.

하지만 위 논지는 악용될 우려가 있다. 뭔가를 '추가'하는 것은 '무조건 나쁘다'는 주장을 펴며 '아무것도 하지 않을 것'을 주장하거나 '우리의 제품은 극도로 심플하며, 경쟁 제품은 우리의 것에 비해 무척이나 복잡하고 구차하다'며 승리를 자신하는 것이다.

물론 위와 같은 제품이 승리한 사례는 없다. ('조엘 온 소프트웨어'의 39장 '전략 메모 IV : 블로트웨어와 80/20 미신'에서 그 이유를 잘 말해주고 있다) 노먼 아저씨 말처럼 '심플은 정답이 아닌' 것일까?

책 '벨로시티'를 훑어보다가, '진짜 심플'과 '가짜 심플'을 판단할 수 있는 기준을 발견한 것 같아 인용하였다.

'그 해결책을 만들기 위해 경쟁사보다 더 많은 피와 땀을 흘렸는가?'