사용자는 왕이다 하지만
스프링노트 서비스가 오픈을 했습니다. 오늘은 서비스 자체보다 개발 모델에 대해 이야기를 해보겠습니다.

스프링노트에는 사용자 커뮤니티가 있습니다. 간단한 게시판으로 구성되어 있는데, 거기에 사람들이 개선 아이디어와 버그 보고 등을 올리고 있습니다. 그리고 개선 아이디어에 대해서는 투표를 할 수 있습니다. 표를 많이 받은 아이디어는 우선적으로 구현이 되겠지요. 상당히 민주적인 시스템입니다(민주주의가 최선인지 아닌지의 문제는 차치하고). 또한 현재 개발팀에서 하고 있는 작업이 무엇이고 앞으로 무엇을 할 건지를 모두 공개하고 있습니다. 사용자 커뮤니티 첫 페이지에 가면 "완료된 작업", "현재 작업중", "작업 예정중"이라는 제목을 달고 있는 포스트 잇이 세 장 나란히 붙어 있습니다. 투명하고 개방적인 서비스 개발 모델입니다. 또한, 매일 매일 버그 수정이 있으며 2주에 한 번 씩 큰 기능 개선이 이루어집니다. 빈번한 릴리스와 지속적 개선이 이루어지고 있습니다. (이런 점들을 묶어서 저의 변화 유지 비결 글과 연결한 블로그 글 [1], [2]도 있네요)

투명성, 지속적 개선, 사용자 피드백 등 모두 여러가지 이유에서 실행에 옮기기 어려운 것들이지만 스프링노트는 고무적 결과들을 보여주고 있습니다. 국내의 다른 서비스들과 비교하면 매우 진보한, "웹2.0스러운" 개발 방식이라고 생각합니다. 정말로 사용자를 고려합니다.

스프링노트는 개발 초기부터 사용자와 긴밀한 관계를 가져왔습니다. 초기에 사용자 연구(user research)를 했고, 당시 참가자들을 대상으로 클로즈드 알파/베타를 하고 점차적으로 사용자 숫자를 늘려왔습니다. 이 과정에서 사용에 대한 구체적이고 값진 피드백을 얻었고 이는 다시 좀 더 가치있는 서비스를 만드는 비료가 되어 왔습니다.

하지만 보통 많은 서비스들은 사용자를 크게 고려하지 않습니다. 그게 문제가 됩니다. 사용자가 무엇을 생각하는지, 그 서비스를 어떻게 사용할지에 큰 관심이 없거나, 있다고 해도 상상을 하는 선에서 끝납니다.

사용성 전문가 제이콥 닐슨(Jakob Nielsen)의 역작, 사용성 공학(Usability Engineering)이라는 책에 다음과 같은 이야기가 언급됩니다.


Designers Are Not Users

...
A survey of 2,000 adults in Oregon showed that only 18% could use a bus schedule to find the time of departure [Egan 1991]. This finding does not indicate that the remaining 82% of Oregonians are less intelligent and should never be allowed on a bus. Instead, the likely explanation is that the bus schedule was designed by people with extensive knowledge of buses and local transportation who just knew the meaning of every element on the schedule, and therefore never considered that parts of it might be difficult to understand for people who rarely take a bus.

(강조는 김창준)


싸이월드의 C2 프로젝트는 "리드 유저"라는 용어를 쓰더군요. 리드 유저 프로세스(Lead User Process, LUP가 도대체 뭔지 궁금하시다면 이 동영상을 권합니다)를 사용하고 있는지는 모르겠습니다. 제가 보기에는 거의 테스트 단계에 이르러서 리드 유저로부터 피드백을 받는 것 같던데(서비스 기획/개발 과정에 대한 자세한 정보는 없기 때문에 전적으로 제 추측입니다), 문제는 그 시점에는 바꿀 수 있는 것들의 범위가 그리 많지 않다는 점이죠. 그러면 통상 그들의 피드백은 일종의 자기 정당화(self-justification) 목적으로 사용되기 쉽습니다.

이렇게 개발이 거의 완료된 시점에 하는 사용자 테스트를 총괄적(summative) 테스트라고 합니다. 주로 우리가 만든 것이 얼마나 좋은 반응을 받는지 확인하는 데 사용하죠. 반대로 형성적(formative) 테스트가 있습니다. 기획/개발 초기나 한참 진행 중에 실시하며, 이를 통해서 향후 개발 방향과 계획을 수정하게 하는 테스트입니다. 많은 서비스들이 너무 늦은 시점에 테스트를 합니다. 그러면서 사용자를 고려했고 피드백을 받았다고 말합니다. 하지만 상당수 표면적인 수정만 하게 됩니다. 결국 총괄적 테스트의 한계인 것이죠.

반대로 스프링노트는 초기부터 사용자들의 피드백을 형성적인 면에서 잘 활용했다는 점에서 특히 주목할만 합니다.

그렇다면 정말 사용자의 말만 잘 들으면 성공할 수 있을까요? 역시 제이콥 닐슨의 같은 책에 정 반대되는 이야기가 있습니다.


Users Are Not Designers

...
For example, Grudin and Barnard [1985] compared command abbreviations they defined with abbreviations defined by individual users, and found that users made about twice as many errors when using their own abbreviations. Even when given the chance to redefine their abbreviations after the experiment, six of seven test users kept their poor abbreviation sets virtually intact, typically explaning that while yes, they had some problems with it, it seemed as good as any other set they could think of. Of course, users have other jobs and do not work as user interface professionals.

(강조는 김창준)


저는 애자일의 미래에서 어떻게 보면 이와 관련이 있는 사례를 소개했습니다.


제트 스키를 개발한 가와사키(Kawasaki)사는 제트 스키 경험을 개선하기 위해 무엇을 해야할지 사용자들에게 물었다. 사용자들은 측면에 여분의 패딩을 추가해서 제트 스키를 서서 탈 때 자세가 더 편안하기를 원했다. 회사는 고객들이 요청한 것을 제공하는 데 집중을 했다. 그 동안 다른 제조사들은 앉아서 타는 모델을 개발했고, 가와사키를 시장 최고 자리에서 끌어내리게 되었다. 고객들이 원한 것은 제트 스키 이용시 더 편한 기립 자세였지만 그들은 앉아서도 탈 수 있다는 생각은 해내질 못했다. ‘앉아서 타는’ 모터싸이클 제조 업체였던 가와사키까지도.
이 외에도 VIP 고객의 이야기를 잘 들어서 오히려 반어적으로 실패하는 사례는 클레이튼 크리스텐슨(Clayton M. Christensen)이 그의 여러 저작을 통해 잘 소개해주고 있습니다.

사용자는 설계자가 아니고, 또 설계자는 사용자가 아닙니다. 사용자는 왕입니다. 하지만 사용자가 결정하는 것이 모두 정당화될 수는 없습니다. 사용자와 설계자는 서로 대화와 협력을 해야 합니다. 두 명의 왕이 협력해서 한 나라를 통치한다고 생각해보면 어떨까요?

--김창준
by 애자일컨설팅 | 2007/04/02 00:50 | 트랙백(3) | 핑백(3) | 덧글(11)
트랙백 주소 : http://agile.egloos.com/tb/3262432
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Tracked from 인간 중심의 혁신 at 2007/04/02 11:26

제목 : 신제품 개발업계는 소프트웨어 업계를 본받아야 한다.
업계라고 쓰긴 했으나 신제품 개발만 전담하는 회사를 말하는 것은 아니고 그 분야의 일을 하는 사람들 정도의 의미가 되겠다. 물론 새로운 사업 모델을 고민하는 나도 거기에 속한다고 할 수 있겠고, 기업 내부의 신상품 개발에 관련된 사람들로써 상품 기획 부서, 디자인 기획 부서, 다른 기업의 신상품 개발을 돕는 마케팅 리서치 분야나 관련 컨설팅 업계의 사람들이 거기에 포함 될 것이다. 전자 제품이나 일상 용품 식품등 다양한 분야에서 신상품의 개발은......more

Tracked from 인간 중심의 혁신 at 2007/04/02 14:08

제목 : 사용자에게 무엇을 물어볼 것인가?
앞서 애자일컨설팅의 김창준님 블로그를 보면서 하고 싶은 말이 더 있었다. 오픈마루는 초기 기획 단계 부터의 형성적인 유저리서치로 쓸만한 서비스를 만들어 냈다는 김창준님의 글도 있는 반면, 유저 리서치는 능력없는 디자이너가 하는 것이라고 말하던 IDAS에서 제품디자인을 가르치는 프랑스교수님도 계셨듯이 유저 리서치는에 대한 대접은 하늘과 땅을 오간다. 유저 리서치는 왜 그런 취급을 받고 있을까 생각해보자. 사용자 그러니까 고객은 왕이다라는 말은 경......more

Tracked from dobiho on HCI at 2007/04/23 01:03

제목 : 사용자 니즈의 진실
애자일 이야기의 사용자는 왕이다 하지만 이란 글에 대한 의견입니다. 사용자에게 직접 물어보는 것이 문제 닐슨이 얘기한 "디자이너는 사용자가 아니다" "사용자는 디자이너......more

Linked at 완소 웹서비스 오픈 러시 ~~ at 2011/12/10 09:57

... 에서 지원해주는 서비스입니다. 이미지만 놓고보면 얼추 비슷한 느낌이 나는 것 같기도 합니다. 서로 성격이 다르지만 어찌보면 비슷한 모습도 있습니다. “사용자는 왕이다 하지만“(애자일이야기)이라는 제목으로 올라온 글을 보면 스프링노트 개발과정의 투명성에 대해서 평가한 글이 있습니다. 지속적인 개선을 약속한 부분도 상 ... more

Linked at 소프트웨어 프로세스 이야기 :.. at 2013/06/11 18:09

... nbsp;애자일 이야기의 "사용자는 왕이다 하지만" 은 사용자의 말을 ... more

Linked at 요구사항 분석보다 사용자와의 .. at 2013/06/13 09:12

... 질에 대한 기준조차도 주관적인 경우가 많습니다. 애자일 이야기의 “사용자는 왕이다 하지만” 은 사용자의 말을 잘 듣는 것이 오히려 실패로 이어졌던 ... more

Commented by mrkiss at 2007/04/02 09:56
소프트웨어 분야에서 계시는 분들이 어쩌면 디자인 리서치 분야 사람들 보다 더 디자인을 잘 이해하고 계시는 것 같습니다.
올 때마다 동감에 동감입니다.
(여기서 말하는 디자인은 설계에 가깝겠죠.. 사실 디자인이란 용어가 내포한 뜻이 너무 여러가지이고 넓어서 오는 혼란이적지 않죠 --;)
Commented by SuJae at 2007/04/02 10:12
소비자를 왕삼기에는 모셔야 할 왕이 너무 많은 점이 오히려 "웹2.0스러운 개발 방식"의 맹점이 되지 않을까 싶어요.
소비자가 원하는 서비스를 구현한다는 것은 결국 익숙한 타서비스와 동일해 질수도 있구요.
그런의미에서 저는 서비스 개발자 주도 + 소비자의 의견 접목시키는 형식이 좋다고 생각합니다.
Commented by kspil at 2007/04/02 12:51
형님 오랜만입니다~

질문이 있는데요~

LUP관련 링크된 동영상을 보니깐 Lead User가 무어의 곡선에서 나오는 Innovator와 같은 위치에 포지셔닝하고 있네요~

혹시 같은 개념인가요? 아니면 Innovator중에 Feedback을 열심히 보내는 그룹이 Lead User가 되는건가요?
Commented by 어이 at 2007/04/02 14:10
베타 테스트 초기에 제가 비슷한 내용을 물어본 적이 있었어요. http://www.springnote.com/post/89
그때 이미 생각하고 계시다고 하더군요. ^^
Commented by 이노메이커 at 2007/04/02 14:50
사용자는 디자이너가 아니고, 디자이너는 사용자가 아니다. 논리적으로 따져보면 약간의 모순이 있지만 서로 대변이 잘 된다고 생각이 되네요.

모든 제품 및 서비스는 사용자(고객)을 타겟으로 설계되어야 하고 만들어져야 합니다.

그러나 고객들이 원하는 기능 및 서비스만을 제공하다보면 너무 익숙해져버린 기능을만 추가할 수 있고, 필요없는 기능이 오히려 추가되어 불편을 줄 수도 있습니다.

디자이너는 고객의 의견을 수렴하되 그 의견이 충분히 반영이 되도록 좀 더 새로운 관점으로 접근하고 생각을 해야된다고 생각합니다.

그래야 고정관념을 깨는 더욱 좋은 아이디어도 나오고 신선한 제품 및 서비스가 나오지 않을까요?

Commented by 無異 at 2007/04/02 16:38
애자일 방법론과 비교하며, 37signals의 getting real에서의 사용자 피드백에 따른 시행착오식 개발 방법을 재밌게 읽었습니다. 인상 깊은 그들의 사용자 요구 사항 대처방법은 1. 쌩깐다. 2. 또 쌩깐다. 3. 더 이상 쌩까지 못할 정도가 되면 반영한다. 였던것 같습니다.
결국 포지셔닝의 문제인데, "모든 사용자"를 왕으로 모실 수는 없겠죠. 신기술을 요구하는 "리드 사용자"를 왕으로 모시는 엘리트주의도 문제가 있고 "정말 다수의 사용자"를 왕으로 모시는 민주적 해결 방법이 가장 현명(얍삽^^)한 대처가 아닐까 싶습니다.
Commented by 라면 at 2007/04/02 20:07
창준님이 지적해주신 것처럼, 무조건 다수결에 의해서만 기능을 채택하거나, 사용자가 말한 그대로를 구현하려 들지는 않으려 합니다. ^^
예를 들어, 투표에 의해 Top 10을 당장 구현한다고 하면, 최고 미인들의 눈 코 입을 뒤섞어놓은 괴물 서비스가 될 수도 있구요~.
사용자들이 타 서비스에서 기본으로 제공되는 기능들을 우선 요구하는 경우가 많아, 서비스의 방향성을 정하는데, 장애가 될 수도 있을 것 같아요~.

하지만, 그럼에도 대략의 방향성과 테마를 가지고, 테마별로 사용자들이 많이 이야기하는 불편사항이나 아이디어를 묶어서 채택/반영하는 것은 큰 의미가 있을 것 같습니다.
그들의 outcome이 무엇인지를 분석하여, 대안을 찾아보아야되겠지요. 저는 잘만 한다면, 이 고민의 과정도 오픈하여 사용자들과 함께 고민할 수 있을 것 같다는 희망도 갖고 있답니다.

궁극적으로는, 모든 사용자들이 불편을 느끼거나 아이디어가 생긴 바로 그 시점에 (사용하던 중에), 바로 자신을 위해 필요한 기능들을 직접 만들어서 붙일 수 있는 모델이 가장 좋을 것 같습니다. 이런 날은 언제 올지 모르지만, 아직 새싹이니 차차 자라나보면서 방법을 찾아보렵니다. ㅎㅎ
Commented by 카페모카 at 2007/04/02 21:20
사용자와 설계자가 대화와 타협을 하지만 결국 칼은 설계자가 쥐고 있다는 건가요?
칼을 휘두르기 전에 사용자의 말을 충분히 듣고(각도와 방향,힘조절 등등 고려) 휘두르겠다는 말인지...(표현이 좀 그런지..)
Commented by 박PD at 2010/04/07 17:48
가와사키(Kawasaki) 사례를 소개한 책이 클레이튼 크리스텐슨 저서 중에 나오는 건가요? 일화를 소개하고 싶은데, 정확한 출처를 모르겠네요. :)
Commented by 애자일컨설팅 at 2010/04/07 18:30
HBR 2002년 1월호에 실린, 앤터니 울윅(Anthony Ulwick)의 Turn Customer Input into Innovation이라는 기사입니다. 인용하실 때 이 정보를 처음 접하신, "애자일의 미래"(http://agile.egloos.com/3182427 )나 혹은 이 블로그 글을 같이 인용해 주시면 감사하겠습니다.
Commented by 박PD at 2010/04/08 12:38
네. 감사합니다.

:         :

:

비공개 덧글

< 이전페이지 다음페이지 >