태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.


'mental model'에 해당되는 글 3건

  1. 2012.09.06 아이폰 스크롤 UI의 고유한 멘탈 모델 (5) by 無異
  2. 2011.08.25 왜 어떤 가이드라인은 실패하는가? - 말보다 행동이 중요하다 by 이 재용
  3. 2010.08.17 Interaction Models (1) by 전성진
2012.09.06 08:21

아이폰 스크롤 UI의 고유한 멘탈 모델

작년에 발표된 MacOS X의 메이저 업데이트인 lion (10.7) 을 설치하고 체감한 가장 큰 변화는 스크롤바가 사라진 것 입니다. 알록달록 스크롤바가 너무 싫었거든요. 오에스텐의 GUI 요소들은 맥하드웨어의 소재에 맞춰 조금씩 변화하고 있습니다. 맥북이나 아이맥에 아노다이징 처리한 알루미늄이 사용되면서 창의 타이틀이나 툴바는 매트한 금속 질감으로 바뀌었는데, 스크롤바 만은 유독 초기 iMac을 닮은 반짝이는 캔디 느낌의 아쿠아테마를 10년째 유지하고 있습니다. 반짝거리는 썸이나 논두렁 처럼 깊게 패인 트랙은 창의 테두리도 없앤 미니멀한 다른 디자인 요소들과 조화를 이루지 못하고 부담스러워 보였습니다.



OSX snow leopard (10.6) vs. lion (10.7)


인디케이터와 컨트롤러로써의 스크롤바
스크롤바는 현재 보고 있는 부분이 전체 페이지의 어느 위치인지, 썸의 길이를 통해 전체의 분량이 얼마나 되는지 가늠할 수있는 정보 표시와 스크롤바를 움직여서 원하는 위치로 바로 이동하는 컨트롤러의 두가지 역할을 합니다. 그러나 마우스 휠이 개발되고 터치패드에도 휠 스크롤 기능이 제공되면서 스크롤바를 잡아서 위치를 이동하는 일은 거의 없어졌습니다. 원래는 조작이 쉽도록 충분한 크기를 가지고 있었던 것인데, 컨트롤러의 역할이 줄어들고 인디케이터 역할만 하다보니 과분한 공간을 차지한다는 생각이 듭니다. 부차적인 정보가 컨텐트 자체 보다 더 사용자의 시각적 주의를 빼았는다는 점이 더 큰 문제이기도 하고요.
피처폰들은 그래서 가느다란 스크롤바를 사용했습니다. 상하 키패드로 스크롤을 하니까 인지가능한 최소한의 픽셀로 스크롤바를 표시 한 것이지요. 하지만 터치 스크린을 사용한 프라다 폰이나 윈도우즈 모바일에서는 스크롤 조작이 요구되어 보다 두꺼운 스크롤 바를 채용하게됩니다. 휴대전화나 PDA처럼 작은 화면에서는 스크롤바가 차지하는 영역이 더욱 부담스럽지만요. 공간을 희생하며 크게 만들었음에도 작은 화면에서 스크롤바을 잡고 스크롤 하는 건 영 불편하기 짝이 없었습니다.


LG 샤인폰(2007.11), LG 프라다폰(2007.5), 삼성 T옴니아 - 윈도우모바일 6.1 (2008.11 )이미지 출처 세티즌

스크롤바를 키우자니 컨텐트 공간을 낭비하게 되고 스크롤바를 줄이면 조작이 어렵습니다. 모순되어 보이는 이 문제를 아이폰의 스크롤 UI는 스크롤바를 없애는 혁신적인 방법으로 해결했습니다. 스크롤바 같은 UI요소를 사용하지 않고 컨텐트 문서를 직접 밀어서 스크롤하게 하도록 했습니다. 문서를 잡고 스크롤하게 되면서 우선 조작 영역이 훨씬 넓어지니 사용이 편해졌고 (fitts's law) 터치의 움직임과 화면의 움직임이 일치하서 세밀한 조작을 할 수 있게 되었습니다.

지금은 너무나 당연하고 다른 방법을 생각할 수도 없지만 아이폰 이전에는 없던 방식이었습니다. 풀터치 스크린으로 보다 먼저 출시된 프라다폰이나 비슷한 시기에 출시된 삼성의 F700, 아이폰 출시 다음해에 나온 윈도우모바일 6.1 에서도 스크롤바를 사용했습니다. 아이폰 이후에 윈도우모바일을 탑재하고 나온 삼성의 옴니아나 HTC의 스마트폰 등은 이러한 제스쳐 스크롤을 제공하였지만 그건 윈도우모바일이 OS차원에서 제공하는게 아니라 제조사들이 만든 앱에만 구현해 넣은 것입니다. 앱 레벨의 구현 한계 때문에 비슷하게 동작할 뿐이지 반응이 매우 부자연스러웠습니다. 기본 탑재된 앱을 벗어나면 낮선 스크롤바를 만나게 됩니다.

안드로이드는 당시 스마트폰의 대세인 블랙베리 형태를 모델로 삼고 터치 인터페이스는 고려하지도 않았습니다. 스티스 잡스의 아이폰 발표 후 10개월이 지나서 세르게이 브린이 야심차게 오픈소스 모바일 OS 플랫폼으로 안드로이드를 발표할 때도 안드로이드는 쿼티 키패드를 사용하는 하드웨어 플랫폼 위주로 데모를 보여주었습니다. 터치스크린에서는 몇 개 앱에서의 일부 기능만을 보여주었는데 브라우저 패닝시에 화면이 느릿한 손가락도 따라오지 못하는 등 성능상으로 구현이 불완전했을 뿐 아니라 목록 선택이나 가상 키보드 같은 기본적인 터치 인터페이스도 준비되어 있지 않았던 것 같습니다. 데모에서는 북마크 목록을 선택하기 위해 터치스크린에서 터치가 아닌 하드웨어 키(트랙볼)를 조작하여 포커스를 이동합니다.


직접 조작으로의 전환
물론 아이폰 이전에도 포토샵과 같은 애플리케이션에서 hand tool 모드(손바닥 아이콘)에서 화면을 잡고 패닝을 하는 UI가 있었습니다. 하지만 그건 별도의 모드로써 동작하는 것이고 우리가 기본 모드로 사용하는 화살표 형태의 커서는 오브젝트(아이콘,텍스트) 선택이 우선입니다. 새로운 매체인 터치스크린을 처음 도입하면서 커서나 포커스를 통해 간접적으로 선택을 우선하는 기존의 GUI의 관습을 뒤엎기는 쉽지 않았을 것입니다. 모든 앱을 처음부터 다시 만들지 않는 이상 기존 앱과의 호환성을 고려하지 않을 수 없었을테고요.

애플은 스크롤을 위해서 선택 기능을 과감히 빼버렸습니다. 개선은 쉽지만 혁신이 어려운건 장점만이 아니라 기존의 것을 잃게되는 트레이드 오프가 따르기 때문입니다. 조직에서의 의사결정은 보수적인 경향이 있어서 기존의 것을 잃는다면 얻는 것이 더 크더라도 아이디어가 폐기되거나 보완하기 위한 장치가 덕지덕지 붙어서 원래의 명료함을 잃게되는 경우가 많거든요. 애플은 스크롤 특허의 개발 배경에서 밝히고 있듯이 폰이라는 작은 화면에서 정보를 표시하기 위해서는 패닝과 줌밍이 필수적이기 때문에 무엇보다 우선 해야 한다고 판단한 듯 합니다. iOS에서 텍스트 선택은 2년 뒤인 3.0에서나 구현됩니다.

스크롤바를 없애면서 잃게된 다른 여러 가지 중 하나는 조작을 하지 않을때는 위치 정보를 알 수 없다는 것입니다. 하지만 이는 처음 로딩시는 스크롤바를 보였다가 사라지게하여 전체 양을 가늠할 수 있도록 하고 조금 움직여보면 알 수 있기 때문에 심각한 문제는 아니었습니다. 책을 읽을 때도 얼마나 남았는지 남은 페이지 두께를 보거나 다음 챕터까지 페이지를 들춰보는건 자연스러운 동작이니까요.

화면을 잡고 움직이는 것이라 세밀한 조작이 가능하게 되었지만 그로인해 페이지가 길어지면 원하는 위치로 바로 이동하는 조작이 상당히 번거러워졌습니다. 스크롤바는 페이지 길이가 얼마나 되건 화면의 크기만큼만 움직이면 원하는 위치로 빠르게 이동할 수 있었던 반면에 한 페이지씩 계속 밀어 대야하니까요. 긴 페이지의 이동이 불편한 문제를 해결하기 위해 스크롤을 빨리 하면서 손을 떼면 관성에 의해 스크롤이 유지되는 flicking 제스쳐를 함께 제공하였습니다. 또 스크롤바는 가로와 세로만으로 반듯하게 움직이지만 화면을 손으로 잡아서 움직이다보면 삐툴삐툴 움직여서 글을 읽기 어려워집니다. 이 문제는 가로 세로로 약간 비스듬하게 움직이더라도 반듯하게 보정하는 것으로 해결 합니다.




tangible 스크롤 멘탈 모델
아이폰의 스크롤UI가 사실상 표준으로 다들 사용하고 있는 이유는 자연스럽고 직관적이기 때문일텐데요. 따로 학습할 필요없이 이미 경험적으로 알고 있는 지식에 기반한 사용자 멘탈 모델을 만들어내기 때문인 것 같습니다. 아이폰의 스크롤 UI는 화면에 보이는 페이지가 스크린 위의 픽셀 정보가 아니라 물리 법칙이 적용되는 가상의 평면적인 물리 공간에서 정말 만져지고 질량을 가지는 실체로써 존재한다는 환상을 만들어냅니다.

도널드 노먼은 두뇌의 작용에 따라 디자인을 3단계로 나누었는데, 이런 애플의 스크롤 멘탈 모델은 행동적인(behavioral) 단계가 아니라 보다 본능적인(visceral) 단계에서 형성되는 것 같습니다. 터치 스크롤은 구현 상으로는 단순히 손가락이 움직인 만큼 화면을 움직여 주어서 손 끝이 마찰에 의해 페이지에 딱 붙어서 밀고 있다고 느껴지도록 하는 것입니다. 요즘은 CPU가 빨라져서인지 개선이 되긴 했지만 안드로이드는 아키텍처의 문제인지 많이 더듬(stuttery)거려서 실제 물리 공간상의 물체라는 멘탈 모델을 형성하기 어렵습니다. 행동적으로 손가락을 따라 화면이 움직이는 건 같지만 미묘한 차이로 실제 물체를 잡고 움직인다는 느낌을 주지는 못합니다.

페이지의 끝까지 이동했을 때 효과인 bounce-back scroll 도 이런 멘탈모델과 관련이 있습니다. 페이지가 경계에 부딪혀 바로 멈추어 버리고 손가락만 미끄러지면 가상의 물리 공간이라는 모델을 형성하기 어렵습니다. 현실적인 물리 공간에서 이런 비탄성 충돌을 하면 더 격한 반응이 생기니까요. 안드로이드에서 사용하는 시각적인 충돌 피드백은 손 끝의 마찰을 이용해 민다는 촉각적인 모델에는 적합하지 않은 것 같습니다. 또한 꽝하고 부딪히는 충돌이라는 피드백 자체가 부정적이고요. 아이폰은 탄성 스크롤을 모델에 적용하여 부드럽게 충돌을 흡수합니다. 끝에 다다르더라도 탄성에 의한 저항은 있지만 여전히 미는 방향으로 움직입니다. 소송에 사용된 bounce-back이라는 용어는 손을 떼었을때 되돌아오는 시각적인 효과에 집중하지만 충격을 흡수하고 탄성의 저항에 의해서 조금씩 손끝이 미끄러지는 의사 촉각 경험이 저에겐 보다 매력적이었습니다.

페이지에 표시하는 내용이 복잡해서 렌더링이 오래걸리는 경우에 페이지가 무겁다라는 표현을 쓰는데, 플리킹을 해보면 스크롤이 빨리 안되는 것이 마치 정말 무거워서 잘 안 움직이는 것 같은 느낌이 들게 합니다. 무거우면 같은 힘(운동량)으로 플리킹을 하더라도 빨리 안 움직이게(v=F·t/m) 되고 마찰력(Ff = μ·Fn = μ·m·g)도 커져서 금방 스크롤이 멈출것 같고요. 애플 특허에는 마찰력을 시뮬레이션 한다는 내용만 언급되어 있고 자세한 구현 방법은 없지만 일관된 동작으로 사용자가 이런 모델을 형성하는데 도움을 주고 있습니다. 저는 최신 안드로이드 단말이 나오면 항상 이 플리킹 테스트를 해보는데 여전히 만족스러운 단말을 만나지 못했습니다. 버벅거린다는 불만을 해소하기 위해서인지 빠르게 튜닝을 하긴 했는데, 에너지 법칙을 무시한 채 더 빨라지기도 하고 마치 마찰이 없는 우주공간에서 휙휙 날아다니듯 움직여서 자연스러운 물리 현상이라고 느끼기보다는 인위적인 인터페이스를 의식하게 만듭니다. 경험적으로 알고 있는 물리 법칙을 위배하는 동작을 보이면 실제한다는 환상도 깨지고 메탈 모델도 만들어지기 어렵습니다.



아직 최종 판결이 난 것은 아니지만 애플과 삼성의 소송 결과를 해석하는 다양한 시선이 있는 것 같습니다. 저는 UI 디자인을 하는 입장에서 UI의 중요성이 부각되고 이슈화 되는 기회가 되어 우선은 의미가 있다고 생각하고 또 이제는 UI를 설계할 때 최선을 선택하는게 아니라 다른 것을 택하는 쪽으로만 위축이 되지 않을까 걱정이 되기도 합니다. 암튼 그래도 애플의 스크롤 UI 만큼은 보호받을 만큼 새롭고 진보적이라는 것은 인정합니다. 터치 인터페이스에서 가장 기본이 되는 스크롤만 봤을때, 다른 단말들도 기능적으로는 동작을 유사하게 흉내내고는 있지만 여전히 아이폰만큼 매끄럽게 분명한 멘탈 모델을 만들지 못하는 걸 보면 아이폰이 5년 이상 앞섰다는 스티브잡스의 호언장담이 허세만은 아니었구나 싶습니다.



*이 글은 Tech it! 에도 실린 글입니다.


팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 5
Ad Test...
2011.08.25 16:58

왜 어떤 가이드라인은 실패하는가? - 말보다 행동이 중요하다

그리 쉽지는 않지만, UI 디자이너에게 표준을 지키는 일은 중요하다. 특히 많은 사람들이 이미 따르는 표준이라면 그 중요성은 배가된다. 이해를 돕기 위하여 4회에 걸쳐서 Mac OS 표준, Windows OS 표준, 그리고 ISO(International Standard Organization) 표준의 역사에 대해서 알아보기로 한다.

1. 사용자의 80%만을 위해 디자인하라 - Apple Human Interface Guidelines의 역사
2. 마침내 혼란을 극복한 Windows7 - Windows User Experience Interaction Guidelines의 역사
3. 그들만의 리그, 우울한 ISO UI 표준 - ISO 13407 & ISO 9241의 역사
4. 왜 어떤 가이드라인은 실패하는가? – 말보다 행동이 중요하다


4. 왜 어떤 가이드라인은 실패하는가?

수많은 플랫폼, 회사, 어플리케이션들이 가이드라인을 만든다. 오늘도 누군가, 어디선가 가이드라인을 만들고 있을 것이다. 피엑스디도 가이드라인에 대해 업무 요청이 자주 들어온다. 그 때마다 피엑스디에서 늘 하는 말이 있다.

왜 어떤 가이드라인은 실패하는가?

가이드라인을 만드는 사람은 이 질문에 명확히 답을 가져야 한다. 그래야 성공적인 가이드라인을 만들 수 있다. 가이드라인의 중요성은 누구나 공감하지만, 성공하는 가이드라인은, 필자의 짐작에 1%도 안 될 것 같기 때문에, 그 1%안에 들려면 왜 수많은 가이드라인들이 모두 실패하는지를 알아야 한다.

우선 가이드라인에 어떤 말들이 들어가는지를 살펴보자 (가이드라인 전체를 비교할 수 없으므로 Design Principle에 해당하는 몇몇 키워드만으로 논의를 대체하고자 한다)


Jakob Nielsen 10 Huristics (1990-1994년)
Visibility of system status / Match between system and the real world / User control and freedom / Consistency and standards / Error prevention / Recognition rather than recall / Flexibility and efficiency of use / Aesthetic and minimalist design / Help users recognize, diagnose, and recover from errors / Help and documentation

Apple Mac OS (1987-2006년)
Metaphors, Mental Model(Familiarity, Simplicity, Availability, Discoverability), Explicit and Implied Actions, Direct Manipulation, See and Point, User Control, Feedback and Communication, Consistency, WYSIWYG, Forgiveness, Perceived Stability, Aesthetic Integrity

Windows 2000 (1992-2007년)
User in Control, Directness, Consistency, Forgiveness, Feedback, Aesthetics, Simplicity

SKT NATE UI Requirement Ver 1.0 (2003-2004)
철학(Clear, Speedy, Attractive), 원칙(Visibility, Simplicity, Consistency, Familiarity, Efficiency, Prioritization, User in Control, Feedback, Error, Affordance, Persnoalization, Fun)

KTF 표준 UI 규격 v2.0 (2005)
철학(Fun UI, Easy UI, Happy UI), 원칙(Intuitiveness, Consistency, Efficiency, Attractiveness)

Google (연도미상-)
useful, fast, simple, engaging, innovative, universal, profitable, beautiful, trustworthy, and personable.

Facebook (2009년-)
Universal, Human, Clean, Consistent, Useful, Fast, Transparent

네이버 UX의 9가지 원칙 (2013, UX World 발표, 출처: UX 디자인 팀블로그)
1. 사용자와 비즈니스를 이해한 UX디자인
2. 주요 기능과 정보의 우선순위가 정리된 UX디자인 (Prioritization)
3. 네러티브가 잘 구성된 UX디자인 (Storytelling)
4. 인터랙션이 잘 설계된 UX디자인 (Interaction)
5. 사용자 무의식 반응을 리드하는 UX디자인 (Intuitive)
6. 정보인지를 빠르게 도와주는 UX디자인 (Clear)
7. 디바이스의 특징과 테크놀러지가 잘 활용된 UX디자인
8. 그래픽 디테일이 아름다운 UX디자인 (Beautiful)
9. 브랜드에 좋은 영향을 주는 UX디자인 (Brand)
위의 과정에서 소소한 혁신의 지속성을 가지는 디자인.

현대카드 (2014, UX World 발표)
현대카드의 UX 철학 : Remarkable but Extremely Kind
Clear, Useful, Interaction, Storytelling, Simple, Consistent, Brand Expression + More Creatitvity




Shneiderman's "Golden Rules"
usability.gov's "Research-Based Web Design & Usability Guidelines"
UserFocus 247 web usability guidelines
기타 많은 가이드라인들(A huge list of Style Guides and UI Guidelines하나더,또하나더)


보면 아시다시피, 제이콥 닐슨의 기념비적인 휴리스틱 10가지 원칙 중심으로, 사실 모두 비슷비슷한 원칙들의 순서 바꾸기에 불과하다. 물론 직접 작성한 사람들은 하나 하나 공들여 골랐을 것이고, 오랜 시간 고민하여 순서를 정했을 것이다. 애플이나 몇몇 회사의 경우 오랜 시간 동안 자신들이 중요하다고 생각하는 것을 다듬어왔음도 알 수 있다. 그러나 나머지 모든 회사들의 원칙들과 비교해 볼 때, 애플이 무언가 잘 하고 있다면, 그것은 디자인 원칙(철학)을 잘 다듬어왔기 때문에 잘하고 있다고 보기는 어렵다는 것을 쉽게 알 수 있다.

그럼에도 애플에서 나온 제품들은, 그리고 그 플랫폼 위에서 개발되어 나오는 제품들은 모두 이 뛰어난 철학들을 공유한 것처럼 보이고, 대부분의 회사들이나 플랫폼은 그렇지 않은 것처럼 보이는 이유는 무엇일까? 왜, 어떤 가이드라인은 성공하는 것처럼 보이고, 어떤 가이드라인은 실패하는 것처럼 보일까?

UIE의 Jared M. Spool은 올해(2011) 5월에 자신의 글에서 필자가 지적했던 것처럼 대부분의 가이드라인이 비슷비슷하다는 것을 지적하면서, 이와는 차별된 가이드라인으로 Windows 7 가이드라인을 예로 들었다. Windows 7 가이드라인에 대해서는 필자도 몇 차례 글을 통하여 훌륭하다고 지적한 바 있는데,

Windows 7 (2010년, 원문)
1. Reduce Concepts to Increase Confidence
2. Small Thinks Matter, Good and Bad
3. Delight
4. Solve Distractions, not Discoveratbility
5. Time Matters; Build for People on the Go
6. Value the Full Lifecycle of the Experience
7. Be Great at "Look" and "Do"

그러면서 Spool은 위대한 가이드라인이 되기 위한 6개의 원칙을 제시한다.
1. 연구로부터 바로 추출된 것인가?
2. 대부분의 경우에 ‘아니다’라는 판단을 내릴 수 있는 근거를 제시하는가?
3. 경쟁자로부터 차별화 시킬 수 있는 원칙인가?
4. 나중에 반대로도 할 수 있는 것인가?
5. 이번 프로젝트에 근거해 평가할 수 있는 것인가?
6. 계속 의미를 검증하고 있는가?

Spool은 일반 사람들이 갖고 있는 ‘원칙(혹은 철학)’에 대해 갖고 있는 고정관념 – 영구 불변의 변치 않는 원칙 – 과 비교했을 때 이런 위의 원칙들이 언듯 보기에 직관에 반하는 것처럼 보이지만 실제로 이러한 것들이 위대한 디자인 가이드라인을 만든다고 주장한다.

Spool의 말에 전적으로 동의한다. 특히 2004년에서 2006년에 걸쳐 진행된 한국의 경쟁 두 이동통신사(SKT와 KTF)의 UI 가이드라인을 보면서, 어쩜 두 회사가 만드는 과정에서부터 결과까지 쌍둥이처럼 똑같을까?하는 생각을 하였던 필자로서는 더욱 크게 동감할 수 밖에 없다. 두 회사의 철학은 거의 비슷했다. 사실 두 회사만 비슷한 것이 아니라, 세상 모든 나머지 가이드라인들과 비슷했다. 어느 회사인들 Fun 하지 않은 걸 원할 것이며, 누군들 쓰기 어려운 걸 원할 것인가? 이런 식의 하나마나한 말 잔치 철학들은, 가이드라인을 읽는 독자들이 ‘무시’하기 쉬웠다. 경쟁사와 구별할 수 있는 철학도 없었지만, 그렇다고 틀린 말도 없었다.

구글이나 페이스북처럼 그리고 많은 회사들의 경우 이런 비슷비슷한 원칙이 나오기 때문에 결국 철학을 무시하게 되니, 남는 건 뒷 부분의 픽셀 단위 가이드라인과 지정된 칼라 밖에 없다. 이렇게 남은 가이드라인은 개별 어플리케이션을 디자인하는 사람들의 창의력을 막고 천편일률의 통일성만 강조된 결과를 남긴다. 그나마 잘 지켜진다면 말이다. 절대 변할 수 없고, 절대 틀릴 수 없는 철학들은 결국 절대 사용될 수 없는 철학인 것이다.

하지만, 이런 철학으로도 잘 하는 예외적인 회사가 있으니, 반드시 또 이 철학이 틀렸다고 말할 수는 없다. 그렇다면 Spool의 지적은 맞긴 하지만 부족한 지적이다.

왜, 어떤 가이드라인은 성공하고 어떤 가이드라인은 실패하는 걸까?

필자는 그것이 ‘가이드라인’이 갖는 권위 – 절차적 정당성에 근거한 영향력에 달려 있다고 생각한다.

대개의 가이드라인은 이렇게 만들어진다.
우선 자신의 제품이 중구난방임을 깨달은 UI 전담팀의 누군가가, 외부의 가이드라인을 수집한다. 모든 가이드라인을 수집한 다음에 자기 마음에 드는 것을 고르고 순서를 바꾼다. 그런 다음 힘이 있는 임원을 설득한다. 운 좋게 임원이 설득되면, 찍어 누른다. 지금까지 잘 하고 있던 현업 부서는 반발한다. 임원의 권력의 크기에 따라, 따라하는 시늉을 하든지, 아니면 진짜로 조금 따라하든지 한다. 가이드라인의 힘이 커지게되면 제품은 천편일률이 되고 문제를 깨닫는다. 조금씩 예외가 많아지다가, 해당 임원이 교체되면서 가이드라인도 사라진다.

더욱이 한국의 가이드라인은 대개 이렇게 만들어진다. 전담팀 누군가가 스스로 만들면 권위가 생기지 않을 것이므로 대학교 교수님께 맡긴다. 그러면 대학교 석사 1-2년차들 (즉 방금 학부 졸업한 학생들)이 자료를 수집하여 초안을 만들고, 박사 과정이 다듬고, 교수님이 검증한다 (사실 직접 실무를 안 해 보긴 모든 구성원이 비슷하다). 이렇게 실무 경력 합계 0년이 만들어낸 가이드라인을, 학위는 없지만 실무에서 잔뼈가 굵은 사람들이 따라야한다. 당연히 반발하지만, 역시 위에서(중앙부서에서, 그룹 본부에서) 찍어 누른다. 그 결과는 비슷하다.

이렇게 만들어진 가이드라인의 품질이 좋을 리도 없지만, 설령 품질이 좋다고 하더라도 구성원들이 그것을 충분히 이해하고 따라하려는 노력을 하기에는 권위가 없다. 권력에 의해 강요한다면 결국 그것은 시늉을 낳게 되고, 기계적인 적용 방법을 찾게 되고, 창의력은 점점 사라지게 되는 것이다.

그렇다면 성공하는, 즉 영향력있는 가이드라인은 어떻게 만들어야할까?

첫 번째는 구성원들의 합의에 의해 만들어야 한다는 점이다.
Nokia가 어떻게 가이드라인을 만들었는지 보자.

표준 문서를 만드는 순간 창의성은 사라진다. 그 사실을 알기 때문에 우리는 가능하면 최대한 표준 문서 만들기를 꺼렸다. 문서 대신, 단지 그런 방향은 아니라고 관리자들이 구두로 말하다 보니, 그것을 관리자 개인의 성향으로 모는 일도 생겼다. 마침내 같은 기본적인 질문을 반복해서 대답하고 있다고 느끼게 되자, 두 명의 시니어 디자이너가 원칙을 모아 명확하게 정리하기 시작했다. (Mobile Usability, 150p, 2003년 영문판 번역)

처음부터 문서를 만드는 것이 아니라, 디자인을 하는 사람들이 계속되는 협업과 토론을 통해 철학을 형성, 공유하고, 새로 들어온 신입들에게 같은 질문에 대한 같은 대답을 반복하다가 효율을 높이기 위해 표준 문서를 만들었다는 내용이다.

철학은 외부에서 가져올 수 없다.
위의 구글 디자인 원칙들은 허접하지만, 구글 철학을 한 번 보면, 몇 몇 개의 것들은 절대 다른 회사가 갖고 있지 못 하는 구글만의 문화와 철학이 느껴져서, 그것에 따르면 오히려 디자인 원칙들보다 더 제품의 전략과 인터페이스를 설계하는데 도움이 되지 않을까 생각한다. 창업자를 중심으로 창업 과정의 사람들이 함께 공유하고, 또 실천한 문화와 철학을 정리한 것이기에, 누구도 쉽게 적용할 수 있다. 또 어느 회사에게 맞는 것이 아니라, 구글만이 할 수 있는 것들이 듬뿍 담겨있다.

두 번째는 실패 사례로부터 출발하는 경우이다.
윈도즈 7의 원칙들을 살펴보면, 그간 무의미하고 추상적인 원칙들이 아무런 도움을 주지 않는다는 것과, 비스타의 처참한 실패로부터 배운 것들을 잘 정리하고 있다. 오랫동안 윈도우 사용자들을 리서치하고, 그에 따라 자신들에게 꼭 필요한 원칙들을 모으고, 첫 번째로 윈도우 7의 디자인을 하는데 적용을 한 것이다.
기존의 원칙들의 정신을 살린 것이라 하더라도, 자신들의 실패를 극복하기 위해 좀 더 정밀하게 좁혀졌고, 명확하게 설명이 되기 때문에 다른 사람들이 읽었을 때 무엇을 해야할지, 무엇을 하지 말아야할지가 분명하다. 따라서 이렇게 만들어진 원칙들은 윈도우 7만의 특징을 잘 설명하고 있다.

세 번째는 성공 사례로부터 출발하는 경우이다.
사람들은 리더의 말이 아니라 행동을 따라 배운다. 아이들은 부모의 말보다는 행동을 따라하고, 팀원은 팀장의 행동을 판단 기준으로 삼으며, 협력 파트너들은 그 회사의 가이드라인이 아니라 출시된 제품을 따라 만든다.

아무리 가이드라인에 ‘Simple’이라고 적어도, 나오는 제품들이 모두 복잡하다면 그건 아무런 의미없는 내용이 되고 마는 것이다. 경영자가 아무리 디자인이 중요하다, 소프트웨어가 중요하다고 떠들어도, 코스트(제조원가)에 밀려 디자인이 희생되고, 승진에서 재무 출신이 임원이 되면 그 회사는 디자인이나 소프트웨어를 중요하게 생각하지 않는 것이나 마찬가지다.

따라서 새로운 조직에서 가이드라인을 만들려고 한다면, 반드시 새로운 프로젝트(결과물)와 함께 만들어야 한다. 그 과정에서 서로 토론하고, 문화를 형성하고, 결과물에 적용하고 그 결과물을 성공시켜야 한다. 결과물이 성공하면, 사내외의 다른 사람들이 따라 하려할 것이고, 사람들이 따라하는 부분을 가이드라인으로 만들면 된다. 그것이 진정한 영향력이다.

정리하면,
1. 직접 쓸 것. 함께 쓸 것. 문화와 철학을 만들 것. (남의 도움은 받을 수 있으나, 남이 만들어 줄 수 없다)
2. 학부 막 졸업한 석사과정에게 맡기지 말 것. 출시된 상품의 화면 설계서를 백 번 이상 그려 본 사람에게 맡길 것.(자기 손으로 같은 버튼을 수백번 그렸다 지웠다 해 본 사람이 아니면 원칙을 만들 수 없다)
3. 성공 사례를 먼저 만들고 전파할 것. 성공으로부터 영향력을 만들 것. (권력에 의해 배포된 가이드라인은 권력과 함께 사라진다)

이것 저것 생각하기 싫다면? 피엑스디에 맡기면 된다. :)

[참고##가이드라인##]



팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 0
Ad Test...
2010.08.17 18:15

Interaction Models

pxd에는 오랫동안 축적되어온 사용자 관찰 기법들과 노하우가 있습니다.
"어떻게 하면 사용자로부터 디자인에 필요한 '좋은 정보'들을 얻어낼 수 있는가?"
이를 위해 열심히 스터디도 하고 프로젝트에서 얻어진 경험을 공유하기도 합니다.

그러면...

이렇게 해서 얻어진 '좋은 정보'를 가지고 어떻게 디자인을 해야 할까요?

pxd에는 '상세하게 분절된 좋은 방법들' (저는 이것을 '징검다리'라고 표현합니다)이 있습니다. 그러나 여전히 징검다리들의 간격은 넓어 보입니다. 징검다리는 디자이너가 딛고서 건너기 위한 목적도 있습니다만, '이렇게 건넜다'라고 증명하기 위한 용도로도 사용됩니다.

이번 글에서는 '좋은 정보'에서 '좋은 디자인'으로의 연결을 위한 징검다리 중 하나를 놓는 작업을 해 보려고 합니다.
사용자 조사를 통한 퍼소나(persona) 모델링, 그리고 퍼소나 시나리오로부터 functional needs와 functional elements를 추출하고 interaction framework를 스케치하는 과정을 좀 더 수월하게 하기 위한 징검다리입니다.


Models

Dubberly ("Models of Models" interactions May + June 2009)


Dubberly ("Models of Models" interactions May + June 2009) 에 의하면 model이란 이미 존재하는 세계에 대한 관찰의 결과로 얻어진(귀추법 ; abduction의 과정에 의한)  idea이며 이는 관찰에 의하여 현상의 패턴들로부터 얻어진다고 합니다. 
이렇게 얻어진 model은 현상을 바라보는 프레임웍으로 작용을 하여 향후 행동(action)을 가이드하거나 제한하게 되고, 가이드된 행동에 따른 결과를 발생시킵니다. 또 한편으로 model은 미래의 사건을 예측할 수 있게 해 주는데,  미래에 실제로 발생되는 사건과 예측된 결과가 동일한 것으로 판명되면  비로소 하나의 '검증된 model'이 됩니다. 실제 사건과 예측된 사건 간에 차이가 있는 것으로 판명되면  model을 다시 수정하는 과정을 거치고 이것이 반복되면서 model이 완성됩니다. 마치 천동설(Ptolemetic model ; "world system")이 지동설(Copernican model ; "solar system")로 바뀌고 이것이 증명되는 과정과도 같습니다.

(위와 동일 출처)



Interaction Models 
Dubberly는 디자이너들이 model을 활용하여 따로놀던 artifact들과 action들을 통합할 수 있다고 합니다. 즉 Interaction model을 통하여 interface widget을, service model은 고객 접점을, brand model은 메시지를, platform model은 각각의 제품을 통합합니다. 하지만 이정도 설명과 몇 가지 체크리스트로는 실질적 활용에는 다소 부족한 듯 합니다. 하지만 매우 중요한 방향성과 방법을 제시해주고 있다고 판단되며 기존에 해오던 프로세스와 방법론을 보완할 수 있는 가능성이 있는 것 같습니다.

관찰된 현상으로부터 패턴을 발견하고 이것을 귀추의 과정을 거쳐 모델링하는 것은 흡사 사용자 관찰을 통하여 발견된 행동패턴으로부터 목표 사용자의 '원형'을 모델링하는 퍼소나(persona)의 방법과 유사한 듯 합니다. 

여기에서 제가 관심이 있는 대목은 모델링의 대상이 '사용자'에 머무르지 않고 interaction framework으로 바로 연결될 '수는 없을까 하는 점입니다. 즉 사용자들을 관찰하여 이들이 사용하는 패턴을 추출하고 이로부터 사용자 멘탈모델들을 얻습니다. 이렇게 얻어진 멘탈모델들을 통하여 다시 모델을 만든다면 이것이 곧 interaciton framework의 초기형태가 될 수 있지 않을까 합니다.

최종적으로 얻어진 멘탈모델은 인지적 구조 위에 주요 task가 나열되고 이 속에 object와 action이 표시될 것입니다. 이를 화면 단위로 다시 그리면 이것이 interaction framework의 초기형태가 될 수 있습니다. 이는 어쩌면 퍼소나 모델링을 잘 해내고, 주 퍼소나의 멘탈모델에 따라 framework sketch를 하는 것과 같은 결과를 목표로 하는 것입니다만, 퍼소나를 만들기 까지의 힘든 여정과 이로부터 다시 출발하여 framework sketch를 그리는 과정을 단축할 수 있으리라 기대하는 것입니다.

간단하게 메모차원에서 프로세스를 나열해보겠습니다.

Observation
  -interview
  -CI (Contextual Inquiry)

Mental Modeling (Sketch)
  -User's
  -System's
  -Stakeholder's
  -Model of Models : 각각의 멘탈모델을 아우르는 모델, 인지적인 개념과 흐름을 나타내는 추상적 스케치

Interaction Modeling (Sketch) (=Interaction Framework Sketch)
  -추상적 스케치를 구체적인 스케치로 번역
  -validation : mental model 기준으로 검증, low-fi prototyping에 의한 검증, 체크리스트

Detailed Designing

이 과정에서 퍼소나 모델링은 생략되어 있습니다만 'mental model'을 기술할 때 메인 퍼소나의 행동패턴이 내재됩니다. 결국 디자인을 위한 퍼소나는 생략되었지만 내용 자체는 유지되고 있으며, 다만 커뮤니케이션 툴로서의 퍼소나는 생략되어 있습니다. 아마도 model을 매개로 커뮤니케이션 해야 할 것 같습니다.

이렇게 접근할 경우 사용자조사 직후부터 멘탈 모델링 과정을 통하여 비교적 빠른 시기에 interaction framwork 스케치 단계까지 진행해 나갈 수 있을 것입니다.

이후의 과제는 위의 모델링 과정을 상세하게 밝히는 것이네요. '좋은 모델'이 갖추어야 하는 요소에 대한 규명도 필요합니다. 이것은 프로젝트에 적용을 해보면서 정리해야 겠습니다.


팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 1
Ad Test...