UXlog: User Experience Blog

과연 애플은 App store를 통해 얼마나 많은 수익을 얻고 있을까요. 결론부터 말씀드리면 직접적인 수익은 “거의 없다.”입니다. 30억 회 이상의 애플리케이션 다운로드라는 규모 때문에 막연히 많은 수익을 거둘 것이라고 상상하기 쉽지만, 실상을 보면 그렇지 않습니다.

애플은 앱스토에서 얼마나 이윤을 창출하는지 정확하게 발표하고 있지 않습니다. 그래서 공개된 자료들을 통해 추측한 내용이 있을 뿐인데, 작년 4월에 10억 회 다운로드를 초과 후 약 한 달 뒤 쓰인 기사에서는 최대 4천5백만 달러의 매출을 얻었다고 추정합니다. 2009년 2분기 당시 매출이 80억 달러였음을 돌이켜보면 앱스토어가 전체 매출에 이바지한 정도는 분기매출의 0.5% 정도밖에 되지 않습니다. 올해 초 분석된 내용은 약간 더 호의적입니다. 2009년 12월 한 달간 7천5백만불을 얻었다고 합니다. 2009년 4분기 매출이 156억이었음을 고려하면, 전체 매출에 차지하는 비율은 역시 1.5%밖에 되지 않습니다. 물론 절대적으로 보면 결코 작은 돈은 아니지만, 사실 비용을 제외하고 나면 거의 남는 것이 없습니다.

앞서 언급된 내용에서 이익을 추정한 방법은, 1불짜리 어플리케이션이 100개 다운로드 되었다고 하면, 총 100불의 매출이 발생하고 그중 개발자가 가져가는 70%를 제외한 나머지 30불을 애플의 수익으로 계산하는 방식입니다. 그런데 2006년 10월호 하버드 비지니스 리뷰에 실린 "iPod vs. Cell Phone: A Mobile Music Revolution?" 케이스를 보면. 0.99불짜리 MP3의 경우, 음원제공자에게 로열티로 돌아가는 비용이 $0.67, 신용카드 수수료 등 기타 variable costs가 $0.29이고 애플이 남기는 이윤은 불과 $0.03이라고 합니다. ($0.99의 곡을 신용카드로 구매하면 $0.15가 카드 수수료로 빠져나갑니다. ) 표현을 그대로 빌리면 iTunes에서는 “barley broke even”. 대신 iPod 판매에서는 약 25%의 비교적 높은 이윤을 남기고 있는데 결국, 애플은 아이튠에서 음악을 팔아서 돈을 벌고 있지 않습니다. 이러한 상황을 잘 아는 애플이 App store를 오픈하면서 개발자에 주는 비용을 CP에게 로열티로 주던 비율과 같은 70%로 정한 것은, 30%를 먹겠다는 의미가 아니라 애초에 iTunes로 돈을 벌 생각이 없었다고 보는 것이 맞을 것 같습니다. iPad 발표 후인 최근의 뉴스를 보면, Apple은 e-Book 역시 출판사와 판매 금액의 30%를 수수료로 부과하는 내용의 계약을 체결했다고 합니다.

[Digital Music Economy by Service Model – A la Carte Download]

지금은 모두가 아무런 의심 없이 iTunes와 같은 서비스와 연동된 디바이스를 이야기하고 있습니다. 스마트폰도 구글 안드로이드 마켓, RIM 블랙베리 앱월드, 노키아 OVI 스토어, MS 윈도 마켓플레이스, 그리고 삼성 어플리케이션 센터. 모두가 같은 방향으로 가는데 과연 이것만이 유일한 답일까요. 저 역시 사용자경험을 연구하는 사람이라 소프트웨어의 중요성을 너무나 잘 알고 있고, 애플 앱 스토어의 매력도 잘 알고 있습니다. 만약 누군가 앱스토어가 답인가? 라고 물으신다면 주저 없이 Yes라고 말하겠습니다. 하지만, Only 앱스토어 만이 답인가? 라는 질문에는…. 글쎄요. 세상에는 아이폰을 들고도 팩토리 디폴트 그대로 사용하는 사람들 역시 존재합니다. 앱 스토어의 15만 개 애플리케이션? 그런 거 관심도 없고 필요도 없는 사람들도 많습니다.

이러쿵저러쿵해도 결국 제조사인 Apple은 단말기를 팔아서 돈을 벌고 있으며, iTunes 스토어는 이를 도와 차별화해주는 역할을 하고 있을 뿐입니다. 만약 iTunes 과 같은 투자가 없어도 iPod, iPhone처럼 이윤 높고 잘 팔리는 단말기를 만들 수 있다면 그게 최선이라고 생각합니다. iTunes가 아직 세상에 없던 그 시절로 돌아가서 생각해보면 과연 iTunes만이 유일한 답이었을까요. 애플이 이미 진을 구축해 놓은 전쟁터에 뒤늦게 들어가서 불리한 정면 싸움을 하는 것 외에는 다른 방법은 없는 걸까요. 물론 저는 답을 갖고 있지 않습니다. 다만, 머지않아 App store라는 판이 뒤집히는 시점이 올 때 사라지는 시장에 함께 머물러 있을 것이 아니라, 그 시장을 뒤엎어 버리는 Disruptive Innovation을 주도하는 것이 바로 우리면 좋겠다는 바람이 있을 뿐입니다.

 

 

P/S 얼마전 사내 인트라넷 블로그에 썼던 글인데, 여차저차 해서 회사공식 블로그(Turn on Tomorrow)를 통해 외부에도 포스팅 되었습니다. 회사 공식블로그에는 개인적인 대응을 하는것은 적절치 않기도 하고 다른분들의 의견도 듣고 싶어서 uxlog로 포스팅을 옮김니다.

위 그래프는 장기기증의사 있는 사람들의 비율을 보여주고 있습니다. ‘상식 밖의 경제학’의 저자인 행동경제학자 댄 애리얼리 교수가 TED에서 소개한 사례인데요. 같은 유럽인데도 왼쪽 네 개의 국가는 참여 비율이 낮고 오른쪽 일곱 개의 국가는 참여 비율이 높네요. 왜 이런 일이 벌어졌을까요? 국민성? 종교? 흔히 말하는 Cultural Difference? 비슷한 문화권인 독일과 오스트리아, 네덜란드와 벨기에, 덴마크와 스웨덴이 서로 다른 그룹에 속해있는 것을 보면 그건 아닌 모양입니다. 그 이유는 바로 설문지의 차이였습니다.  “장기 기증프로그램에 참여하려면 체크 하세요” 라는 설문지를 받은 사람들은  체크를 안 하고, 프로그램에 참여하지 않았죠. 반면, “장기기증 프로그램에 참여하지 않으려면 체크하세요” 이런 설문지를 받은 사람들 역시 체크를 안하고, 이번에는 프로그램에 참여하게 됩니다. 댄 애리얼리 교수는 이 사례로 사람들이 얼마나 비이성적인 판단을 하는가를 설명했는데, 어떻게 보면 설문지를 디자인한 한 사람이 얼마나 큰 영향력을 행사했는지를 보여주는 사례가 될 수도 있을 것입니다.

자동차들이 정지선을 지키게 하려면 어떻게 하는 것이 좋을까요. 이경규가 나타나서 양심 냉장고를 건네주면 될까요 아니면 안전벨트 때 처럼 강력하게 캠페인을 벌여 단속하는 것이 좋을까요. 스페인에서 운전을 하던 중에 가끔 신호등을 보려면 고개를 뒤로 젖혀야 할 때가 있었는데 그 이유는 알고 보니 신호등의 위치 때문이었습니다. 자동차용 신호등이 횡단보도 지나서 있는 것이 아니라, 횡단보도 전에 있습니다. 즉, 정지선을 지키지 않으면 물리적으로 보이지 않는 위치에 세워져 있습니다. 오른쪽 사진을 보면 더 확실한데요, 정지선 우측으로 옆에 나란히 신호등이 있습니다. 만약 정지선을 지나서 횡단보도 바로 앞에 선다면 운전석에는 신호등을 볼 수가 없습니다. 한마디로 ‘정지선을 지킬 수밖에 없게’ 만든 신호등이죠.

뉴욕에서의 사진들인데요 각각 제목을 붙여 봤습니다. 이 사진들을 보고서 한 친구는 ‘참 뉴욕스럽다는’ 표현을 하더군요, 비록 무시무시해 보일지는 몰라도 저는 애착이 갔습니다. “말이 필요없는” 디자인이기 때문이죠. 그리고 오히려 인간적으로 생각되더군요. 앉기 좋은 높이와 형태로 만들어놓고 ‘앉지 마시오’라는 사인을 걸어 놓는것이 다리 아픈 사람들에게는 오히려 더 가혹할 수도 있습니다. 앉지 못하게 하려면 앉지 못하는 형태로 만드는 것이 더 좋은 디자인이 아닐까요.

 

대부분 들어보셨을 텐데, 잘못된 UI 디자인으로 인한 사례로 자주 언급되는 것들 중 하나가 2000년 미국 대선시 Palm Beach에서 사용된 투표용지가 있습니다. 출구조사에서 낙승이 예상됬던 Al Gore가 개표결과에서 George Bush에게 지게 되는데 그 원인이 바로 잘못 디자인된 투표용지에 있었죠. 양쪽으로 배치된 10명의 후보자들중 원하는 위치에 구멍을 뚫어서 투표를 하는 방식입니다. 즉, 왼쪽 두번째 후보자 Al Gore를 선택하려면 세번째 구멍을 뚫어야 합니다. 두번째가 아니고요. 실제로 두번째 후보인 Buchanan은 특별한 연고도 없는 이곳에서 몰표를 받았고, 실험을 통해서도 약 4%의 확률로 Al Gore를 찍으려는 사람이 실수로 2번째 구멍에 투표를 한다는 결과가 나왔다고 합니다.

 

Xerox PARC 시니어 UI 리서쳐 Stuart Card는 다음과 같은 말을 했습니다.

"우리가 살 세상은 신중하게 만들어야 한다.
(We should be careful to make the world we actually want to live in.)"

Rich Gold가 말한 것처럼 우리는 일생동안 정크족을 위해 쓰레기를 더 만드는 일을 하고 있는지도 모릅니다. 기왕 무언가를 만들어 내는 직업을 택했으면 적어도 세상에 도움이 되는 것들을 만들고 싶다는 생각이 새삼 들었습니다.

 

브레인스토밍이나 다른 아이디어 발상회의를 할 때 써 볼만한 방법들을 모아봤습니다. 여기에 있는 정보를 주로 참조 했고 회의중 혹은 혼자 사용해 보고 효과를 본 방법 중심으로 소개 드립니다. 위쪽부터 일반적인 Ideation 방법들을 적고, 그다음에는 발상법 위주로, 아래쪽은 확장 및 분석하는 툴 중심으로 나열했습니다.

 

1. Brainstorming

대표적인 Ideation 방법. 통상적으로 Ideation을 목적으로 하는 모든 미팅을 Brainstorming 이라고 부르기도 함. Brainstorming의 창시자인 Alex Osborn의 4가지 원칙은,  
  1. 아이디어의 양을 늘리는데 집중
  2. 비판은 보류
  3. 별난 아이디어 환영
  4. 아이디어에 더하고 합한다.
일반적으로 진행자는 아이디어를 제안하는 것이 금지되며, 10~15분 후 휴식하는 사이클을 3번정도 수행.

브레인 스토밍을 할때 색깔이 다른 포스트잇을 한장씩 주어서 그곳에는 터무니없는 아이디어를 적도록 할수도 있다. 보통 포스트잇들의 분류를 마친뒤, 어처구니없는 아이디어들을 그럴듯한 아이디어로 정제하는 과정을 거친다.

 

2. Brainwriting

각 멤버는 종이에 아이디어를 적는다. 3분정도 시간이 지난뒤 종이를 옆사람에게 넘기면, 적혀있는 아이디어를 보충하거나 디딤돌로 삼아 새로운 아이디어를 적는다. 브레인스토밍 세션에서 말을 잘 안하는 사람들의 의견을 받는데 좋지만 너무 정적인 분위기로 진행되기 쉬움.

 

3. 6-3-5 method
Brainwriting의 한 방법. 6명의 사람이 각각 3장의 종이에 5분이내에 아이디어 하나씩을 적는다. 다 적은 종이는 옆사람에게 건네주고 옆사람은 적혀있는 아이디어를 힌트로 새로운 아이디어를 더해 적는다. 모든종이에 6개씩 적히게 되면 상황종료. 제대로 진행됬다면 5분x6명=30분 동안 모두 3장x6명x6개=108개의 아이디어가 생긴다. 물론 꼭 6명일 필요는 없음

 

4. Circular Response
해결하고자 하는 Problem을 그룹원들과 공유한다. 문제를 확실히 하여 종이에 적어두고, 자유롭게 토론하는 동안 종이를 돌려보며 자기 순서가 되면 코멘트를 하나 이상씩 적는다. 통상적으로 15~20분간 실시. 시간이 되거나 더이상 토론이 시들해지면, 종이를 회수.

 

5. Nominal Group Technique
아이디어를 적고 이를 보팅해서 선정하는 방법.
1. 5~10분정도 각자 조용히 주제에 대한 아이디어를 종이에 적는다.
2. 각자 처음 아이디어를 진행자에게 말하고, 진행자는 이를 칠판에 받아 적는다.
3. 각 아이디어를 명확히 하거나 서로 토의할 시간을 준다.
4. 멤버들은 몇개를 선정하여 순위와 해당 아이디어를 무기명으로 적는다.
5. 진행자는 이 순위 카드를 걷어서 하나씩 읽으며 결과를 공개하고 칠판에 적는다

 

6. Six Thinking Hat
아이디어회의중 "지금부터 모두 검정모자"와 같은 식으로 활용하거나 각자 다른 종류의 모자를 쓰고 생각하는등의 방법으로 활용한다.
1. White Hat: 객관적인 정보에 집중함. 데이터 중심으로 생각하고 어떻게 부족한 Information을 얻을 수 있는지도 생각해본다.
2. Red Hat: 직관, 감정, 본능에 충실한다. 이유는 필요없음
3. Black Hat: 왜 안되는지, 무엇이 약점인지 부정적인 면을 중심으로 본다.
4. Yellow Hat: 긍정적으로 생각함. 아이디어의 benefit 위주로 본다.
5. Green Hat:  창조적인 생각을 통한 아이디어 생성. 자유로운 사고. 크리틱금지
6. Blue Hat: 미팅을 주관하고 모더레이션한다. 어떤 모자를 써야하는지도 정하는사람

 

7. Alternative Words
간단하지만 의외로 유용한 방법. 아이디에이션 주제의 동의어 혹은 반대말 리스트를 작성해서 새로운 시각으로 생각을 해본다. 영어단어라면 리스트는 http://www.thesaurus.com/ 를 사용해 작성하면 좋음

 

8. Backward Mapping
Problem solving을 위한 Ideation을 할 때, 지금 고민중인 문제가 이미 해결되어 사라져버린 미래를 상상한다. 그리고 가상의 타임라인을 그리면서 현재까지 거꾸로 내려오면서 생각하는 방법.

 

9. Break the Rules
주제와 관련되어 널리 알려진 정설, 학설, 표준, 규범, 법칙 등을 적어두고 이를 제거했을 때 새로운 아이디어의 가능성을 찾아본다

 

10. Bunch of Bananas
미팅중에 갑자기 "신제품 고민하는 것 그만두고 마술사나 고용할까?"와 같은 엉뚱한 말을 던짐으로써 고의적으로 혼란하게 만든다. 참석자들의 생각이 그냥 흘러가는 대로 가게 두지 않고 뒤흔들어 새로운 돌파구를 찾는 방법. 심리학자들이 말하는 Pattern interruption.  몇 번 시도해 봤는데 적절하게 사용하기 어려우며 분위기만 썰렁하게 만든 경우가 많음.

 

11. Change the Setting
해변, 산, 인기 있는 카페, 갤러리 등 활기차고 영감을 불러 일으키는 장소를 찾아간다. 장소를 바꾸는 것만으로도 영감을 얻을 수 있음. Fresh insights을 얻기 위한 다양한 기법 
- Street Excursion: 길을 걸으며 보이는 모든 것들을 Trigger로 삼는다.
- Example Excursion: 지역, 기후 등이 다른 환경을 고려해본다.
- Career Excursion : 우주비행사, 간호사 등등 자신과는 전혀 다른 직업의 입장에서 생각해본다.
-  Imaging Excursion : 임의의 단어를 고른 뒤 편안한 자세와 마음으로 명상을 하면서 이미지를 떠올린다. 몇 분간의 명상 뒤 떠오른 이미지들을 아이디어와 연결 시킨다

 

12. Force Field Analysis
사회과학에서 사용되는 방법. 목표에 도달하기 위한 순방향의 영향을 주는 Driving force와 목표도달을 방해하는 Restraining force이 만나는 지점을 현재 상태로 정의하고, 원하는 목표에 도달하기 위해 Driving force를 강화하기 보다는 Restraining force는 약하게 하는 방법을 사용한다. 
1. 먼저 Driving force를 나열한다 팀의 생산성 증가가 목표라면 이에 대한 Driving force의 예는 인센티브 제공, 팀원간 경쟁, 팀장의 압력 등이 될 수 있다.
2. 다음으로 Restraining force를 나열한다. 예를 들어 무관심, 갈등, 지원부족 등이 될 수 있다. 
3. Critical Restraining force를 선정하고 제거한다.

 

13. Force Fit
1. 문제를 가장 잘 표현하는 단어를 선정한다. 예를 들어 누군가 마음에 안드는 사람이 있다면 '대립'을 선택
2. 다음에는 그 단어의 반대의미를 선정한다. '대립'과 반대되는 '조화'.
3. 두개의 단어를 합쳐본다. '대립적 조화' 나 '조화로운 대립'
4. 합친 문구에 해당하는 예를 생각해본다.

 

14. 이미지 검색
아이디어와 관련된 키워드로 구글 이미지 검색 을 해본다. 검색되어 나오는 이미지들을 보면서 영감을 받는다. 결과로 나오는 썸네일 이미지들을 클릭해 키워 보기가 귀찮다면 묻지마 이미지 검색 을 사용, 스크롤 하기가 귀찮으면 Bing 추천.

 

15. Po
불가능하고 정신 나간듯한 아이디어로부터 출발해 현실적인 아이디어를 뽑아내는 방법. 금기를 깨는 것이 유용한데, 비논리적이고 불법이거나 사회적으로 수용되기 힘든 아이디어들을 내보는 것. 이러한 아이디어를 "Po"(Provocative Operation)라고 한다. 새로운 커피잔에 대한 Po의 예를 들면 바닥이 없는 컵, 손잡이가 안쪽으로 달린 컵, 잡기에 너무 뜨거운 컵등이 될 수 있음.

 

16. Other People’s Shoes
화성인, 5살짜리 아이, 심슨, 람보, 박애주의자, 제임스본드, 회장님등의 다양한 캐릭터를 설정하고 그 사람이 되어본다. 문제를 어떻게 해결하고 목적을 달성하는지 상상해봄.

 

17. 속담과 명언
여러 가지 속담이나 상용구를 적어서 상자에 채워두고 뽑는다. 해당 문구와 현재 다루고 있는 주제가 어떻게 연관되는지 생각해 본다.

 

18. 문장 만들기
일단 임의의 단어를 선택한다. 그리고 10분간 그 단어를 사용한 문장들을 최대한 길게 작성해본다. 시간이 지나면, 그 문장들을 트리거로 얼토당토않은 아이디어를 뽑아내고 그 아이디어를 바탕으로 feasible한 솔루션을 생각본다.

 

19. Free the genie
Idea Champions 이라는 컨설팅 회사에서 제공하는 툴. attend, intend, ,suspend, extend, connect의 다섯가지 카테고리로 모두 55개의 영감을 제공한다. 온라인에서 무료로 게임을 하면 20장밖에 나오지 않지만 카드 이미지 번호가 일렬번호라서 직접 주소 입력을 하면 다른 이미지들도 볼 수 있음.

 

20. 아트 갤러리
텍스트대신 사진이나 이미지를 그려서 갤러리처럼 벽에 붙여둔다. 그룹작업을 해도 됨. 갤러리를 둘러보면서 새로운 아이디어나 문제해결을 위한 시작지점을 찾아본다. Ice braking용으로 사용해도 좋으며, 우뇌를 자극하는데 유용하다고 함.

 

21. 5W1H
누가(who)? 무엇을(what)? 언제(when)? 어디서(where)? 왜(why)? 어떻게(how)?에 대한 대답을 찾아봄으로써 영감과 아이디어를 얻는다. 단, Why 라는 질문은 조심해서 사용할 것. 가장 자주 묻는 질문이기도 하지만 제일 쓸모 없는 질문이기도 하다.

 

22. Five Whys
풀려는 문제의 근본 원인을 찾기 위해서 해당 문제의 원인에 대해서 꼬리에 꼬리를 계속 물어가는 방법이다. 예를 들어 최초의 문제가 '매출이 감소하고 있다' 였다면 > Why? > 가게에 오는 손님이 적어서 > Why? >우리 제품 가격이 높아서 > Why? > 이윤 마진을 높게 잡아서 > Why? > 오버헤드가 많아서 > Why? > 스텝들이 삥땅 쳐서 와 같이 근본적인 원인을 발견하면서 아이디어를 확장한다.
또 다른 Five Whys 는, 최초 제기된 문제에 대해서만 Why 의 대답 5가지를 찾는 방법이다. 아까의 '매출이 감소하고 있다' 에 대한 Five Whys의 예를 다시 들면 이번에는 손님이 줄어서, 경쟁업소가 생겨서, 광고를 멈춰서, 서비스할 직원이 부족해서, 물품이 제한적이라 의 독립적인 5가지 이유를 생각해 볼 수 있다.

 

23. How-How Diagram
목표를 이루는 방법에 대한 아이디어를 Hierarchy 구조로 늘려 나간다. 목표에 도달하기 위한 처음 how에 대한 방법을  2가지 적고, 각각의 방법에 또 2가지씩 How를 생각하여 늘린다. 질문을 3번하면 23=8가지의 방법이 나온다. 

 

24. Laddering
어떤 아이디어에 대해 이것의 예로 무엇이 있을까? 또는 이것은 무엇의 예가 될수 있을까? 라는 질문을 통해 사다리를 오르내리듯이 단계별 정의를 한다. 교통수단 > 자가운전 > 렌터카 > 컴팩트카 > 푸조 370 등. 그밖에 Input / Output을 정의하거나, Why? How? 등의 질문을 통해 Laddering이 가능

 

25. Morphological Analysis
가능한 모든 조합을 고려해보는 방법. 마치 슬롯머신처럼 각 열에 다른 항목들을 나열하고 돌려보는 방법도 있다.  Wired 매거진 2006년 9월호에 소개된 Build a Web2.0 Startup이 한 예. 

위 항목들을 조합하면 다음과 같은 사이트가 나올 수 있음.
Music - Ajax & Streaming - Recommendations - Social Network : LAST.FM
Photo - Tagging & RSS - Search - Community : Flickr.com
Productivity - Ajax & Ruby on Rails - Publishing - Wiki : Basecamp
주사위를 만들어서 굴리면서 아이디어를 내볼 수 있음.

 

26. SCAMPER
대체(Substitute), 결합(Combine), 개조(Adapt), 수정/확대/축소(Modify/Magnify/Minify), Put to other uses, Eliminate, Reverse/Rearrage 의 약자.
- Substitute: 사람, 장소, 시간이나 상황들을 다른 것으로 대체해본다.
- Combine: 여러 가지 다른 요소들을 더하고 섞고 통합해본다.
- Adapt: 기능을 변경하거나 다른 요소를 사용하는 등 아이디어를 개조해봄
- Modify: 스케일을 줄이거나 늘려보고, 모양을 바꾸어보거나 색깔 등의 특성을 수정
- Put to other uses: 일부분의 사용법을 대체해봄
- Eliminate: 일부 기능이나 요소를 제거해본다
- Rearrage/Reverse: 요소들의 순서를 바꾸거나  앞뒤, 위아래를 바꾸어본다.

 

27. 메타포 활용하기
아이디어와 연관 없어 보이는 것들로 은유적 생각을 해본다. 예를 들어 냉장고와 고양이의 공통점? 이라면 둘 다 생선을 속에 넣고, 둘 다 꼬리가 있고, 둘 다 그르렁 거리고 둘 다 다양한 색이 있으며, 둘 다 수명이 15년 정도... 공통점을 찾는 방법으로 생각을 확장시킬 수 있다. 우리는 낯선 것들을 이해할 때 이미 알고 있는 것들과 비교한다. 최초의 자동차는 '말없는 마차 (horseless carriages)'라고 불렸고 초기 기차들은 '철마 (iron horses)'라고 불렸다. 은유(Metaphor)는 여러 문제나 상황에 새로운 영감을 줄 수 있다. 현재 이슈에 대해 어떤 metaphor를 만들 수 있을까? 라는 질문을 해보자.

 

28. ALO (Advantages, Limitations and Way of Overcoming Them)
해당 아이디어가 사용자에게 주는 이득(Advantages)이 무엇인지, 그 아이디어의 부족한 점이나 단점(Limitations)이 무엇인지, 그 결점을 극복하기 위한 방법(Overcoming)은 무엇이 있는지를 생각해본다

 

29. Concept Sheet
A4나 A3용지에 아이디어 별로 일정한 Form을 만들어 채우는 방법. 양식에는 다음과 같은 내용을 채울 수 있다.      
  1. Title  
  2. Description
  3. Benefit (for Whom?)
  4. Sketch
  5. 평가 항목들

 

30. Creative Whack Pack

64장의 카드로 이루어진 Ideation 툴. Exploer, Artist, Judge, Warrior카드가 각각 16장씩 있으며 각각의 카드는 서로 다른 기능을기능을 한다.  더 자세한 내용은 여기 http://blog.favorite.kr/298
 1. Explorer:  idea를 만들기 위한 재료를 탐색. 새로운 정보를 찾는 방법 제안
 2. Artist: Resouce를 new idea로 만든다. 아이디어 발상법을 제공.
 3. Judge:  아이디어를 평가하고 그걸로 뭐할지 결정함. 의사결정 도와줌
 4. Warrior : Idea의 Implementing 담당. idea를 action으로 바꾸어 준다.

 

 

이외에도 방법은 무수하게 많습니다. 하지만 너무도 당연한, 간과해서는 안 되는 일은 툴은 단지 툴일 뿐이고 툴을 사용해서 아이디어를 내는 것은 사람이라는 사실이죠. 툴이 아이디어를 만들어 주지는 않습니다. Steve Jobs는 “Creativity is just having enough dots to connect.” 라는 말을 했습니다. Kent Beck은 “Design is beneficially relating elements”라고 정의 했고요. 디자인마인드로 무장한 CEO와 Guru 개발자가 각각 한 말에서 ‘연결하다’라는 공통적인 키워드가 보였습니다. 회의실에 앉아서 시간을 아무리 보낸다고 해도 애초에 연결한 dot들이 없으면 Creativity는 나오지 않습니다. 일상 생활에서도 개개인이 다양한 경험과 꾸준한 학습을 통해 새로운 점들을 계속 생성해 가야만 새로운 아이디어도 떠오를 것입니다.

 

효과적인 브레인스토밍을 위해서 첫 번째로 필요한것은 구체적인 주제, 즉 적절한 제약입니다. 자유로운 브레인스토밍을 위해서라며 주제에 대한 제한을 두지 않는 경우가 있습니다. 물론 주제가 아예 없지는 않겠지만 “차세대 웹서비스”, “미래의 모바일 기기”와 같이 없는 것과 마찬가지인 주제를 놓고 아이디에이션 하는 경우도 있죠. 흔히 가능성을 더 많이 열어두면 더 많은 아이디어가 나올 것 같지만, 실상은 그렇지 않습니다. 넓은 평원 한복판에 서 있으면 어느 방향으로도 갈 수 있지만, 오히려 어디로 가야 할지 모르겠는 것처럼요. 때로는 색이라는 요소를 없애 버린 흑백사진이 칼라사진보다 더 많은 메시지를 표현하기도 하고 피아노 삼중주, 현악 사중주등과 같은 제한된 형태의 연주가 오케스트라보더 더 깊이 있는 음악을 전달하기도 하는 것처럼, 한정된 주제로 이야기할때 더 깊이 있고 다양한 아이디어가 떠오르기도 합니다.  

존 마에다는 “디자인 분야에서는 제약조건이 많을수록 결과가 더 좋아진다.” 라고 했습니다. 이어령은 "수 백장에 쓸 수 있는 내용을 원고지로 몇 장의 분량으로 줄이는 제약은 고통스럽지만 그런 것이 글을 쓰는 재미이며, 넓은 마루 두고 좁은 평형대에 올라가 체조를 해야 상상할 수 없는 기량이 나온다"고도 했고요. 브랜다 로럴은 "열려진 가능성의 수를 줄임으로써 상상력이 증대되며, 결국 그것이 맘놓고 상상이라는 점프를 할 수 있도록 하는 안전망의 구실을 한다"고 했습니다. 작곡가 이고르 스트라빈스키는 "제약이 많을 수록 영혼을 옭아매는 족쇄로부터 더 많이 해방된다"고 했으며, 시인 T.S 앨리엇은 "엄격한 틀 안에서 작품을 쓸 때 상상력이 최고로 발휘되며 아이디어도 넘치며 자유가 지나치면 작품은 응집력을 잃는다"고 했죠. 브레인스토밍도 많은 자유를 두고 광의의 주제로 여러번 실시하는 것 보다는, 적절한 제약을 두면서 구체적인 주제로 각각 하는 것이 더욱 효과적입니다.

두번째로 필요한 것은 즐거움 입니다. 얼마 전 무릎팍 도사에서 안철수 교수가 나와서 이런 말을 했습니다.

효율적이라는 입장에서 보면 나는 비효율적인 사람입니다. 14년간의 의사생활이 거의 쓸모없어졌으니까요. 프로그램 개발하던 것도 경영할 때는 쓸모가 없어지고. 효율적인 인생이 성공이라면 저 같은 사람의 인생은 실패입니다. 하지만, 인생은 효율성이 전부가 아니더군요. 자기에게 정말 맞는 분야를 찾기 위해 쓰는 시간은 값진 시간인 것 같아요. 자신에게 기회를 주는 게 가장 중요해요. 내가 어떤 사람인가, 어떤 일을 잘 할 수 있고 어떤 일을 하면 재미있는지 그런 것을 알 수 있는 기회를요.

모든 생명체는 본능적으로 효율을 추구합니다. 에너지를 적게 쓰는 쪽으로요. 앉으면 눕고 싶고 누우면 자고 싶은 것처럼 말이죠. 비단 육체적인 활동뿐 아니라 두뇌 활동도 마찬가지입니다. 우리 몸의 20%의 에너지를 소모하는 두뇌는 생각에 몰두하게 되면 열량 소비량이 급격히 증가합니다. 그래서 고정관념이라는 것을 만들어두고 한번 판단한 것에 대해서는 다시 생각하지 않고 기존의 고정관념을 꺼내 쓰려고 하죠. 에너지 효율을 위해서입니다. 하지만, 동물과는 달리 인간의 삶은 효율만으로는 설명이 안 되는 행동이 있는데 재미를 위한 놀이 활동이 그렇습니다. 아름다운 경치를 보려고 먼 길을 돌아가는 것도 ‘아름다움’이라는 넓은 의미의 재미를 추구하려는 것으로 볼 수 있겠죠. 안철수 교수 역시 자신의 인생은 효율적인 측면으로 보면 실패지만 자기에게 정말 맞고 재미있는 일을 해왔다고 했습니다. 일이 재미있어야 더 성공적이라는 예를 인생에서의 성공과 같은 거창한 가치 말고 일상생활에서의 일로 끌어내려 생각해보면, 아이디어회의도 그 중 하나가 될 수 있습니다.
점심먹고 나른한 시간 아이디어 회의를 위해 포스트잇이 여기저기 붙어 있는 아이디어룸에 5~6명의 사람이 커피를 들고 하나둘씩 모여 잡담을 시작합니다. ‘자 오늘은 ㅇㅇ을 주제로 자유롭게 브레인스토밍을 시작합시다.’라고 회의 진행자가 운을 떼고 참석자들은 하품을 합니다. 한두 마디 간헐적으로 아이디어가 나오는 상황에서 맥을 끊지 않으려고 진행자는 애써 말을 이어 갑니다. 이런 재미없는 분위기에서는 좋은 아이디어가 나오지 않습니다. 차라리 유행하는 동영상 클립이라도 함께 보고 웃고 시작하는 것이 훨씬 효과적입니다. 즐거운 분위기에서 진행되는 브레인스토밍과 그렇지 못한 분위기에서 나오는 아이디어의 차이는 질적, 양적으로 많은 차이가 납니다. 여러 가지 아이디어 발상법이 있지만, 그 전제는 즐거움 입니다. 육체적인 일이라면야 눈으로 쉬고 있는 것이 금방 보이지만 머리를 쓰는 협력은 멍하니 있다고 해도 겉으로 봐서는 잘 티가 나지 않습니다. 그렇기 때문에 동기가 제공되지 않으면 에너지 효율을 위해 별 생각 안하고 싶어 집니다. 생각을 많이 하면 확실히 지치거든요. 다른 회의는 용건만 간단히 시간을 아껴 짧게 효율적으로 하더라도, 브레인스토밍 시간이라면 Ice braking 하는 시간을 시간낭비라고 생각하지 마세요. 참가자들이 즐거운 마음을 가져야 이런저런 방법들도 비로소 의미가 있게 되기 때문입니다.

E3덕에 게임UI 관련 뉴스가 자주 들리고, 최근 uxfactory의 “웹디자이너가 게임 기획에서 배울만한 요소들” 이라는 글을 보고 예전 HCI2003에서 발표했던 내용이 생각나서 적습니다. 몇 년전에는 게임기획자분들과 함께 프로젝트를 진행하기도 하는등 게임 디자인에서 배울 수 있는 점을 찾으려고 시도했었는데요, 재미도 있었지만 어렵기도 했었던 기억이 남습니다. 어렵다고 말씀드린 이유는 제품과 게임, 두 가지 인터랙션의 근본적인 차이 때문이었죠.

Computer as Theatre에서 저자 Laurel은 인간-컴퓨터 활동을 생산적인 것과 경험적인 것으로 나눕니다. (Human-computer activity may be divided into two broad categories: productive and experiential.) 흔히 말하는 HCI에서의 UI는 생산적인 것이고 게임은 경험적인 것에 속합니다. 게임은 특정 과업을 수행하기 위한 과정이라기보다는 상호작용을 통한 경험 그 자체를 위한 것입니다. 경험적인 활동인 게임에서 Efficiency만을 최적화한다면 어떤 상황이 벌어질까요. 게임 패드로 캐릭터 이름을 직접 입력하게 하는 것은 비효율적이니까 캐릭터이름은 일괄 적용될 테고, 대전게임의 ‘→+LP,RP,RP,RP,RK,RP,LK,RK,RP,LP+RP’ 10단 콤보 입력명령은 비효율적이니까 단축명령키를 만들지도 모릅니다. 물론 실제로는 그래선 안 되고 그럴 리도 없지만요.

재미가 있고 없고가 어떤 차이를 가져다주는지의 명확한 예는 사용성 테스트입니다. 게임에서의 베타테스트는 게이머들의 자발적인 참여로 이루어집니다. 인기 게임의 경우 엄청난 경쟁을 통해 선발되며, 수천 명의 테스터가 헌신적으로 수십, 수백 시간을 미완성의 게임을 플레이하는데 투자합니다. 그래서 여러 가지 오류들을 잡아내고 문제점을 보완할 수 있게 되지요. 반면 사용성 테스트는 어떤가요. 상황에 따라 다르지만, 일반적으로 10명 안쪽의 사람들을 섭외해 길어야 한두 시간의 테스트를 위해 적지 않은 비용을 지급합니다. 수많은 게이머의 목소리를 어떻게 분석하고 요구 사항을 추출하여 이를 시스템에 적용할까요? 분명히 UX 프로세스에 적용할만한 부분이 있을것입니다.

워드프로세서에서 문서를 완성하는 경우와 롤플레잉 게임을 시작해 엔딩을 보는 경우를 비교해보면,

일반적으로 게임플레이를 할때는 한 개 이상의 세이브 파일을 생성하고 워드프로세서를 사용하는 경우는 계속 덮어쓰면서 하나의 파일을 생성합니다. 물론 게임에서도 계속 덮어쓰면서 하나의 파일을 만들 수도 있고 워드에서도 Save as로 버전관리를 할 수 있지만 기본적으로 대부분의 게임 UI 에서는 슬롯이라는 개념이 있어서 손쉽게 다른 세이브 파일을 생성할 수 있도록 지원하죠. 이런 비슷한 화면을 제품 UI에서도 본 적이 있습니다. 디지털 카메라의 설정화면이었는데요 사용자는 주어진 3 개의저장 공간에 현재 상태의 모든 설정 정보- 예를 들면 이미지의 크기나 해상도, 플래시모드, 화이트밸런스, 셔터스피드와 조리개 크기, 노출모드, 카메라 감도등 수십 가지에 달하는 설정 정보들을 저장해 두고 필요할 때 다시 불러올 수 있습니다. 이렇게 생성된 여러 개의 세이브파일은 원하는 시점의 상황으로 돌릴 수 있도록 해줍니다.  ‘자동저장’ 기능에도 차이가 있습니다. 워드는 일정 시간 간격으로 저장되는 반면 게임의 경우, 자동저장은 어떤 이벤트가 일어났을 때 예를 들어 중간보스를 크리어하거나 맵을 이동했을 경우에 이루어지는 것이 보통입니다. 한참 놀다가 잠깐 동안 불타올라 열심히 작성했는데 마침 그때 오류가 발생해 10분 전으로 돌아간다면 아무것도 남지 않게 됩니다. 워드에서의 자동저장 옵션도 몇 분 간격이 아니라 몇 자 간격이라면 어떨까 하는 생각을 해본 적이 있습니다.

만약 한참 작업한 문서를 저장하지 않고 워드프로세서를 종료하였을 때, 사용자의 명령대로 즉시 종료된다면 어떨까요. 직후에 시스템으로부터 “문서가 저장되지 않았습니다.”라는 메시지까지 받는다면 확실히 절망적이겠죠. 워드프로세서를 종료하는 사용자의 행동은 저장 여부를 묻는 대화 상자를 표시함으로써 제한됩니다. 사용자의 행동 가능 범위를 적절하게 제한함으로써 사용자의 다음 행동을 유도하는 방법 역시 게임에서는 자연스럽게 사용됩니다.

예를 들어 주인공이 마을 장로와 대화를 하지 않았다면 문지기가 막아서서 밖으로 내보내지 않는 다던지 특정 아이템을 취하지 못했다면 봉인된 문을 열수 없는 경우 등이 이에 해당합니다. 마을 밖으로 나가서 한참을 진행하고 나서야 ‘아 그때 장로와 대화를 했었어야 하는데… ” 라는 사실을 안다면 게이머가 얼마나 당혹스러울지 게임 디자이너는 알고 있기 때문입니다. 아직도 생생하게 기억나는 루카스아츠사의 1990 년작 ‘원숭의 섬의 비밀 (Secret of Monkey Island’)은 ‘제한’의 효과를 잘 활용한 사례로 들 수 있습니다. 다른 게임과는 달리 이 게임의 주인공 가이브러시는 낭떠러지에서 떨어져도 다시 퉁겨져 올라오며 식인종에게 잡혀서 갇히더라도 탈출하는 방법이 제공되는 등 결코 죽는 일이 없었는데, 그래서 불필요한 걱정 없이 주어진 문제를 해결하는데 몰입할 수 있었습니다. 

어떤면에서는 적절한 Metaphor와도 관련이 있습니다. 주인공이 낭떠러지에서 떨어지면 사망하는 것이 실제의 상황이라면, 다시 퉁겨져 올라오는 것은 게임디자이너가 실제와 다른 매핑을 하는 경우입니다. 실제 공책과 똑같이 워드프로세서를 구현하려고 한번 지워진 글은 영원히 되살리지 못하게 만들어서는 안 되는 것과 같이 UI 디자이너들은 실제와는 다른 매핑을 적용하기 위한 논리적인 상황을 늘 고려해야 합니다. 워드프로세서의 잘못된 메타포로인해 얼마나 많은 사람이 작업물을 잃어버려서 좌절을 맛보았을까요. 워드프로세서를 사용하면서 사용자가 떠올리는 메타포는 펜으로 글을 쓰는 노트이기 때문에 이미 적은 글들이 저장하지 않았다면 메모리에서 사라질 수 있다고 인식하지 못합니다. 알고 있다고 하더라도 망각하게 되죠. 이런 사용자모델과 시스템모델이 차이가 나면, 시스템을 사용자모델에 맞추어주거나 다른 사용자모델을 제공해 줘야 합니다. 사용자모델을 바꾸기위해 저장되지 않은 영역과 저장된 영역을 구분해서 표시해주면 어떨까요. 마지막 저장 이후 작성된 부분은 흐린 잉크로 곧 지워질것 같은 느낌으로요. 반면 스프링노트처럼 실시간으로 계속 저장되는 것은 시스템모델을 사용자모델과 같게 해준 예가 될 수 있습니다.

 그 밖에 사용설명서의 도움 없이 조작을 익히고 몰입할 수 있게 해주는 직관적인 UI, 고급사용자와 일반사용자의 격차를 절충하는 방법 등 게임 UI에서 배울만한 것들은 넘쳐납니다. 그리고 게임UI에서는 일반적인 응용프로그램들보다 훨씬 자유롭고 창의적인 인터페이스를 발견할 수 있습니다. HCI 분야에서의 UI와는 달리 게임 UI에서는 일정한 표준이 거의 존재하지 않습니다. 아직 텍스트기반의 인터페이스가 대부분이었을 시기에도 게임에서는 3D를 지향하고 있었고 현재에도 AR, Gesture등 새로운 인터페이스의 시도가 계속 되는 부분이 바로 게임입니다.

무엇을 재미있게 만드는 것은 무엇을 효율적으로 만드는 것보다 훨씬 어렵습니다. 만약 궁극의 UI라는것이 있다면 가장먼저 게임분야에서 나오지 않을까요.

새로운 상품을 기획하는 프로젝트를 하다 보면, 다음과 같은 말을 듣는 경우가 종종 있습니다. “그거 OOO 대학 연구소에 유사한 과제가 있습니다.”, “작년 XXX 전시회에서 본 것과 비슷한데요.”, “제가 알기엔 △△△기업에서 관련 특허를 보유하고 있습니다.” … 비단 타인에게서 듣는 경우뿐 아니라, 웹서핑하다가도 유독 비슷한 컨셉제품이나 연구과제들이 눈에 잘 들어오기도 하고요.

이처럼, 현재 구상 중인 아이디어와 비슷한 아이디어들을 발견했다면 어떤 생각을 하시는지요? 긍정적으로 생각하면 ‘와 우리와 같은 생각을 하는 사람들이 또 있다니 프로젝트 주제를 잘 잡았구나!’라고 생각할 수도 있고 부정적으로 생각하면 ‘이거 레드오션이네. 다른 아이디어를 찾아봐야겠는걸’이라고 생각할 수도 있겠죠. 저는 전자 처럼 긍정적이지는 않더라도 적어도 비슷한 아이디어가 있다고 포기하지는 않습니다. 그 이유는,

첫째, 어차피 처음부터 이 아이디어가 유일하다고 확신하지 않기 때문입니다. 발견되지 않았다고 존재하지 않는 것은 아니죠. 아주 어렸을 때 읽은 어떤 책에서 본 삽화 중 아직도 기억나는 것이 있는데요, 하얀색 까마귀가 ‘내가 발견되기 전에는 모든 까마귀는 검은색인 줄 알겠지!’라며 웃고 있는 그림이었습니다.  ‘모든 까마귀는 검다.’라는 명제를 증명하는 역설을 설명하는 내용이었거든요. 그런데 최근에 흰색 까마귀가 실제로 존재한다는 사실을 알았습니다. 있을 리 없다고 생각한 것의 발견이었죠. 자유로운 분위기의 아이디어 회의에서 나온, 모두가 터무니없다고 생각했던 아이디어도 바로 회의가 끝나자마자 누군가 ‘이런 게 있었네요.’라면서 비슷한 것을 찾아 보내기도 합니다. 하물며 ‘될성싶다.’라고 선정한 아이디어라면 말할 것도 없겠죠.

둘째는, 그렇지만 우리의 아이디어가 독창적이기 때문입니다. 아니, 비슷한 아이디어가 있다면서 독창적이라니 무슨 소리냐 하실 수도 있지만, ‘독창적이다.’라는 의미는 ‘차별된다.’와는 다릅니다. 스스로(獨 ) 창조해낸(創 ) 아이디어라면 독창적이죠. 그 독창적인 아이디어와 유사한 다른 누군가의 아이디어가 있을 수도 있지만,  타인의 아이디어를 표면적으로 단순히 모방한 것이 아니라 우리 스스로 일련의 프로세스를 거쳐 생성해낸 아이디어라면 고유한 컨셉이 있는 것이고 충분히 진행해볼 가치가 있습니다.

마지막으로, 무엇을 만드느냐보다 어떻게 만드느냐가 중요하기 때문입니다. Ideation 과정에서 나온 초기 아이디어가 완벽히 일치해도 Concept development 단계를 지나면 가치가 달라집니다.  똑같은 아이디어 Seed에서 출발했다고 해도 Design Iteration을 몇 번 돌고 Implementation을 하면 이게 정말 처음에 같은 아이디어에서 출발했나 라는 생각이 들 정도로 다른 결과물들이 생깁니다. 그래서 비록 유사한 아이디어를 발견했다고 하더라도 확신이 있다면, 다른 아이디어를 찾는 시간에 그 아이디어를 어떻게 잘 발전시킬까를 고민하는 게 생산적이라고 생각합니다. 애플의 iPhone이 출시되고서 Time 지는 “The Apple Of Your Ear “라는 기사에서 다음과 같이 말합니다.

“따지고 보면, 아이폰에 새로운 기능은 별로 없다. 스티브 잡스가 음성 메일이나 텍스트 메시지, 모바일 웹브라우징을 발명한 것도 아니고 말이다. 하지만, 잡스는 그 기능들이 엉망이라는 것을 알아챘고, 그것들을 고쳐냈다.”

애초에 문제는 무엇을(What) 제공해 줄 것인가가 아니었습니다. 이미 있는 기능들을 어떻게(How) 제공해 줄 것인가 였죠.

그래서 아이디어 선정(Screening)의 방법은 아이디어의 평가(Evaluation)가 아니라 아닌 전망(Forecast)입니다. 아이디어를 선정하는 간단한 방법의 하나는 시장성, 경쟁우위, 유용성, 합리성 등의 기준 및 기준별 가중치를 정하고 각각의 아이디어를 평가하는 방법이 있죠. 하지만, 이러한 방법은 몇몇 아이디어들을 걸러낼 수는 있어도 ‘정말 할만한’ 아이디어를 선정하는 데는 무리가 있습니다. 더 깊은 통찰이 필요합니다. 왜냐하면, 현재 아이디어 수준의 상태에서는 아직 How에 대한 가치가 부여되어 있지 않기 때문입니다. 그래서 아이디어를 선정할 때는 그 아이디어들이 발전 되어, 인터페이스 방식이나 시스템설계, 서비스제공 방법 등 아직 개발되기 전인 구체적인 요소들이 덧붙었을 때의 미래를 예상하여 전망할 수밖에는 없습니다. 마치 수확할 열매를 상상하며 씨를 뿌리 듯이 말입니다. 남의 씨앗이 나의 씨앗과 비슷하다고 농사를 포기하기보다는 어떻게 더 잘 키울지를 고민하는 것이 좋겠죠.

차별성보다는 독창성, What과 함께 How도 고려 , 평가보다는 전망을 통한 선택이 Ideation 단계에서 마음에 두어야할 항목들 입니다.

이전 포스트에서 UX design 프로세스는 다양한 스킬과 툴을 준비해 두고, 필요할 때 적절하게 꺼내 쓰는 것이라는 말씀을 드린 적이 있는데요, 얼마 전에는 수많은 UX design 방법론중 주로 어떤 도구를 사용해야 하나요? 라는 질문을 받은 적이 있었습니다. 그때 저는 ‘상황에 따라 달라요.’ 라는 원론적이고 무책임한 대답을 할 수밖에 없었지만요. 그래도 제가 고려하는 몇 가지 가이드가 있습니다.   

애플의 디자인 프로세스를 보면 Paired Design Meetings이라는 것이 있습니다, 매주 두 종류의 미팅이 있는데 하나는 모든 제한을 무시하고 아이디어를 내는 "Go crazy" 미팅과 다른 하나는 이것과는 완전히 반대로 제품을 만들어내기 위해 모든 것을 "Nail down"하는 미팅이라고 합니다. 

IDEO의 Brainstorming 방법에는, 전통적인 확장 도구인 브레인스토밍 방법 (다다익선, 비판 금지, 별난 아이디어 환영, 합치고 더하고)과는 좀 구별되는 “주제에 집중하기 (Stay focused on the topic)” 라는 항목이 있는데요, Wild Idea들을 종용하면서 동시에 목표에 집중해야 한다는 것은 얼핏 듣기에 당연하고 어려운 일은 아닌 것 같지만, 실제 상황에서는 이 두 가지 원칙이 종종 충돌하기도 합니다. 누구는 다양한 아이디어를 내자는 차원에서 이야기했는데 누가 듣기에는 회의시간에 농담 따먹기 하자는 거냐고 여길 수도 있거든요. 어느 것이 주제에 벗어나는 아이디어고 어느 것이 아닌지 명확히 획을 긋기는 불가능합니다. 그래서 제 경우에 일단은 펼치고 나중에 집중하는 주로 방법을 사용합니다.

수많은 UX design 방법론 중 어느 것을 선택해야 하는지에 대한 이야기로 다시 돌아가서 여기 한가지 예를 들어보겠습니다. 위 그림은 즉흥적으로 만들어본 프로세스인데, 프로젝트는 요즘 유행하는 친환경 제품을 만들어 보는 것으로 가정하면, 일단 무식하니까 공부하자는 차원에서 리서치를 수행합니다. 다양한 리서치 결과들로 Affinity diagram 등을 통해 몇 가지 테마를 발굴 할 수 있겠죠. 다음에는 FGD등의 사용자 조사를 통해 사용자의 다양한 의견을 듣고 타겟 사용자가 될 수 있는 페르소나를 작성합니다. 여러 가지 방법의 Ideation을 진행해 많은 아이디어를 뽑고 그것들을 평가해서 몇 가지 후보를 선정합니다. 마지막으로 선정된 아이디어들을 간단히 프로토타이핑해보고, 다시 테스트를 거쳐 최종 후보를 실제로 개발구현하는 프로세스입니다. 

위 그림을 다시 그려봤습니다. 다양한 리서치 결과들을 몇 가지 테마로 함축. 사용자 조사를 통한 여러 가지 사용자 요구와 라이프스타일을 몇 개의 퍼스나로 함축. 수많은 아이디어를 뽑아내고 묶고 연결하고 평가해서 후보 아이디어를 선정. 몇 개의 후보아이디어를 빠르게 프로토타입 한 뒤에 최종적으로 하나를 구현. 발산과 수렴의 반복입니다. 제목에 ‘UX Design Process는 담금질’이라는 비유를 한 이유가 그것입니다. 어떻게 보면 생명체의 진화와도 유사합니다. 진화가 지속되기 위해서는 돌연변이와 같은 유전적 변이가 증가되는 기작과, 자연선택과 같은 유전적 변이를 감소시키는 기작이 반복되어야 하는데, 위에서 말한 발산과 수렴의 반복과 유사한 부분입니다.

정량적인 도구와 정성적인 도구를 잘 섞어 쓰는것이 바람직 하듯이, 확장과 수렴도 잘 배합해서 써야 합니다. 적당한 수렴없이 확장만 계속 하면 배가 산으로 가는 프로젝트가 되어버리고, 반대로 확장 없이 수렴만 하는 프로젝트에서는 혁신을 기대하기가 힘들겠죠.

언젠가 픽사(PIXAR)의 연구원으로부터 애니메이션 개발 프로세스에 대해서 들을 기회가 있었습니다. 애니메이션 개발 프로세스를 간단하게 말하면 ,

1) 이야기가 진행될 그럴듯한 세계를 먼저 디자인하고 
2) 그 세계에 있을법한 매력적인 캐릭터를 창조한 뒤 
3) 스토리를 구성하는 3단계로 이루어진다고 합니다.

즉, 환경->캐릭터->스토리 순으로 한다는 것인데요, UX 디자인프로세스에서 환경과 사용자를 먼저 고려하고 나서 제품이나 서비스를 기획하는 것과 유사하다는 생각이 들더군요.또한, 스토리 작가와 그 스토리를 3D 로 코딩하는 개발자 사이의 관계가 항상 경험하는 Designer와 Engineer 간의 관계와 흡사한것을 발견했습니다. 스토리는 엉망이고 그래픽만 뛰어난 애니메이션은 관객들이 좋아하지 않습니다. 반대로 스토리는 좋지만, 만족할만한 비주얼이 제공되지 않는 경우도 마찬가지이고요. 마치 제품디자인과 기능처럼요. 둘 다 만족 시키는 일은 항상 어려운 일이지만 Pixar는 둘 다 훌륭히 해내고 있죠.

Pixar의 ‘스토리작가-아티스트-디벨로퍼’의 관계와 우리 회사의 ‘기획자-디자이너-엔지나어’와의 관계를 비교해 보는 것도 흥미로웠지만 가장 인상에 남는 것은 Iteration 디자인과 관련된 교훈이었습니다. 스토리작가가 머리를 쥐어짜 콘티를 완성해가면 스토리를 검토하는 과정에서 이 사람 저 사람이 마구 뜯어고쳐 결국 기존의 줄거리는 완전히 뒤집혀 버리고 다시 처음부터 이야기를 꾸려가야 한다면서 이런 말을 했습니다.

Remember, Storyboarding is actually Stor-re-boarding.

잠깐 화제를 돌려, 한때 세계계 2%만 풀 수 있다는 아인슈타인이 냈다고 (잘못) 알려진 퀴즈가 돌던 적이 있었죠. 저는 이 문제를 한 교육과정에서 풀어볼 기회가 있었는데, 그때 강사가 이야기해준 이 문제를 풀기 위한 힌트는, 한 번에 완벽한 답을 찾아내려고 하지 말고, 일단 한가지 가정을 세운뒤 진행 해야 한다는 것이었습니다. 그 가설이 맞으면 다행이고 아니면 다시 그 가정을 세웠던 곳으로 돌아와 다른 선택지로 진행을 해보는 것이죠. 이것은 지뢰 찾기 게임을 할 때나, Sudoku 퍼즐을 풀 때도 마찬가지였던 것 같습니다.

과제를 진행할 때도 비슷한 상황에 놓일 경우가 종종 있습니다. 예를 들어 여러 가지의 아이디어 중 몇 개를 선정해야 하는 상황이라고 가정하면, 누군가는 일단 Affinity diagram을 통해 몇 가지 그룹으로 만들고서 평가를 하자는 사람이 있을 수 있고, 누구는 엑셀도표에 넣고 Criteria와 비중을 정해서 모든 아이디어를 일단 voting 해보자고 할 수도 있고, 누군가는 아직 평가할 수준이 아니니 좀 더 구체화가 필요하다고 하는 사람도 있고, 누구는 외부 전문가나 소비자를 불러서 의견을 들어보는 것이 필요하다고 할 수도 있습니다. 어떤 날은 온종일 이러자 저러자 이야기만 하다가 결론을 맺지 못하고 끝나기도 합니다. 이런 상황에서는 어떤 방법이 좋을지 계속 따지는 것보다는 일단 아무것이나 한 가지 방법을 빨리 정해서 앞으로 가는 것이 낫다고 생각합니다. 그 이유는 어차피 현 시점에서는 아무리 머리를 쥐어짜 봐야 어떤 방법이 최선인지 알 수가 없기 때문이고, 선택한 방법으로 원하는 결과가 나오지 않았다면 빨리 되돌아가서 다른 방법으로 할 시간을 벌어야 하기 때문입니다.

한가지 에피소드를 말씀드리겠습니다. 몇 년 전 기존에 진행했던 과제와는 다른 형태의 결과물을 내야하는 과제에 참여한 적이 있었는데, 그래서 따라할만한 프로세스도 없었고 당장 다음 주에 해야 할 일이 명확하지 않은 상태였습니다. 어느날은 리서치를 통해 백여 가지의 사회현상들을 정리하고 이것을 어떻게 요리해야 할까를 고민하고 있었는데, 누군가 이런 제안을 합니다. “이것을 재료로 현상별로 3개씩 아이디어를 내자. 그리고 그 아이디어별로 또 3개씩 아이디어를 내자. 그럼 정말 많은 아이디 풀을 얻을 수 있을 것이다.” 저를 비롯한 다른 디자이너들은 “어떤 항목은 아이디어가 많이 나올 수도 있고 어떤 아이디어는 하나도 나오지 않을 수 있는데 그게 무슨 무식한 방법이냐?” 라면서 당장 반박을 했지만. 어떻게 결국 그대로 진행하기로 했고, 결론적으로 그 과정을 끝내고 나니 모두가 만족할 만한 결과를 얻을 수 있었습니다. 그 방법이 옳았는지 틀렸는지가 중요한 것이 아니라, 우리가 잘한 것은 일단 앞으로 진행 했다는 것이지요. 그때 누군가 그런 방법을 제안하지 않았더라면 다음에 무슨 일을 해야 하는지를 정하려고 또 많은 시간을 소비했을 것입니다. 

 
이전에 작성한 “사용자 경험 디자인 프로세스” 포스트에서 세부 Activity들이 포함된 자세한 프로세스는 과제 결과보고서를 할 시점에야 미리 계획하기 보다는 지나온 길을 되돌아 보면서 작성이 가능했다는 이야기를 드린적이 있습니다. 프로세스가 일련의 작은 언덕들을 넘어서 목적지에 도착하는 과정이라면, 이정표가 없는 언덕 밑에서 어느길로 가야 할지 의논할 시간에 손바닥에 침 튀겨서 일단 앞으로 가는 것이 중요하다고 생각 합니다. 일단 언덕위에 올라서야 다음 진행할 방향이 보이고 잘못된 길이라면 빨리 돌아갈 수 있을 테니까요.  

I want to fail as quickly as possible  - Andrew Stanton (토이스토리, 벅스라이프, 니모를찾아서, Wall-E의 Director)

사실 Iteration 이야말로 UCD(User Centered Design) 프로세스에서 가장 중요한 요소중 하나지만, 시간이 부족하다는 핑계, 혹은 이미 지나온 일들을 뒤집는 것이 두렵거나, 내 과제의 진행이 잘못되고 있다는 것을 인정하는 것이 싫어서 소홀했었는데 Pixar의 디자인 프로세스 이야기는 이를 반성하는 계기가 되었습니다.