태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.


'google'에 해당되는 글 2건

  1. 2014.07.23 [pxd talks 49] How Google design global services by theminjung
  2. 2011.08.25 왜 어떤 가이드라인은 실패하는가? - 말보다 행동이 중요하다 by 이 재용
2014.07.23 01:00

[pxd talks 49] How Google design global services


49번째 pxd talk에서는 전 Google 인터렉션 디자이너이며 현재 FuturePlay에 새로운 둥지를 트신 김수 님을 연사로 모셨습니다. Google의 조직과 디자인 프로세스에 대해, 그리고 Global Service 디자인을 위한 팁에 대해 강연해 주신 내용을 정리하였습니다.

[이 글에 포함된 이미지는 김수 님의 발표자료에서 발췌하였으며 저작권자인 김수 님의 허락없이 무단사용하는 것을 금합니다.]

연사 : 김수, Tony kim (현 FuturePlay Inventor)
- 전 Google Interaction Designer
- 전 Naver China UX Manger
- KAIST Industrial Design



Google의 UX조직

Super Flat

많은 사람들이 알고 있듯이 Google의 기업문화는 수평적인 구조로 이루어져 있습니다. 동일한 발언권, 사소한 이슈로도 수많은 토론을 통해 '말하기를 좋아하는 문화'를 가지고 있습니다. 이러한 수평적인 구조를 가지게 되면 누가 어떤 일을 하는지 파악하기 쉽지 않습니다. 그래서 내부적으로 이를 극복하려는 툴이 있습니다. 같은 관심사를 가진 사람들이 모여 Mailing Lists를 만들기도 하고, 점심식사를 함께 할 사람을 무작위로 연결해주는 시스템, 자신들이 아는 지식을 가르쳐주고 배우는 UX University, 칭찬게시판 Kudos등이 있습니다.


UX Functions

UX조직을 들여다 보면, Design function에는 Interaction Designer, Visual Designer, 최근에 많아지기 시작한 Motion Designer 그리고 Prototyper가 있습니다. Research Function은 정량분석가와 정성분석가로 구성됩니다. 이렇게 각자의 역할을 가지지만 자신이 하고 싶은 일이 있으면 여러 가지 일을 해 볼 수 있습니다.


Google의 디자인 프로세스

Design Process

Google은 프로젝트 인원 할당에 보통 1 PM, 1 Designer, 1 Researcher, 1 Tech Lead, 6 Engineers 구조가 일반적입니다. (한국의 경우는 주로 1 PM, 1 Designer, 1 Tech Lead, 2 Engineers 인데 양산이 중요하다고 판단되면 엔지니어가 충원됩니다.)
PM이 프로젝트에 대해 러프하게 정의하면 Tech Lead가 실질적인 프로젝트 매니저가 되어 디자인과정이 진행됩니다.
Google에서 훌륭한 PM이란 서비스를 런칭했느냐 못했느냐로 판단하게 됩니다. 성공적인 런칭을 위해서 PM은 팀원들에게 많은 것을 믿고 위임하며 독려합니다. 그리고 팀원들은 자신이 맡고 있는 프로젝트에 대해 깊이 이해하고 프로젝트를 수행하려 노력합니다. 또한 향후에 더 가치있는 프로젝트에 참여하기 위해서도 자신에 대해 좋은 평판이 나도록 노력합니다.
PM이 성공적인 서비스런칭을 했느냐로 평가를 받는다면, UX디자이너는 사용자를 위한 훌륭한 제품을 만들었느냐로 평가를 받게 됩니다. 그래서 UX디자이너는 서비스 출시 이후의 사용자 로그데이터를 분석하며 다음 개편을 준비하고 끊임없는 팔로업을 하게 됩니다.

Google은 디자인 프로세스가 명확하지 않고 그때그때 상황에 따라 다릅니다. Deadline도 명확히 정해져 있지 않습니다. 불필요한 와이어프레임작업도 하지 않습니다. 명확한 이유가 있다면 이전 프로세스로 돌아가는 것도 가능합니다.

UX디자인(특히 비주얼 디자인)에 있어서는 모든 팀원들이 만족해야 진행이 되기 때문에 의사결정이 느린 편입니다. UX디자이너는 팀원들에게 충분히 디자인안에 대해 설득할 수 있어야 합니다. 그리고 UX디자이너들끼리 Design Sprint라는 것을 합니다. 한 명의 디자이너가 자신의 프로젝트에 다른 프로젝트 영역에 있는 디자이너들을 모아 이틀정도의 짧은 기간을 두고 집중해서 아이데이션을 합니다. 큰 프로젝트에만 진행되었지만 요즘은 전반적으로 많이 하는 추세입니다. 그리고 더 나아가 컨셉 영상도 많이 만들고 있습니다.

위 동영상은 google now의 시나리오 동영상입니다. 사용자의 정보를 모아 적절한 시점에 유용한 정보를 알려주겠다는 컨셉을 잘 보여준 동영상입니다. 실제로 내부의 커뮤니케이션을 위해서도 컨셉영상을 많이 만들고 있습니다.


Global service design을 위한 Tip

글로벌 서비스를 하기 위한 조건

1. Scalable Solution

글로벌 서비스를 하기 위해서는 하나의 포맷 안에 다양한 정보를 넣을 수 있어야 합니다. 나라마다 주로 하고 있는 스포츠는 다르기 때문에 '스포츠'라는 프레임에 다양한 종목의 정보가 들어갈 수 있어야 합니다. 나아가 디바이스에 따라서도 어떻게 보여줄지에 대한 고민이 필요합니다.

2. You' re not users

스마트폰이 대중화되어 있지만, 미국에서 약39%는 아직 피쳐폰을 사용하고 있습니다. 글로벌 서비스를 하겠다고 시작하면 보통 스마트폰만을 고려하는 경우가 많습니다. 현재 인디아, 나이지리아, 스리랑카, 필리핀에서 서비스되고 있는 Google의 Freezone이라는 서비스는 text만으로 이루어져 있는 것을 볼 수 있습니다.
한 나라의 일반적인 사용행태가 다른 나라에서도 비슷하다고 생각하기 일쑤지만 각각의 나라마다 기기를 사용하는 행태는 직접 들여다보지 않으면 알 수 없습니다. 서비스에 맞는 충분한 글로벌 리서치가 필요합니다.

3. Culture Convention

나라마다 문화차이도 고려해야 합니다. 하나의 손짓에서도 나라마다 표현되는 의미가 제 각각입니다. 한국에서 ‘약속을 할 때’ 또는 ‘전화해’라는 손짓은 중국에서는 숫자 ‘6’을 뜻하고 하와이에서는 ‘안녕!’이라는 의미이고, 호주에서는 ‘담배 필까?’ 라는 뜻으로 쓰이기도 합니다.
‘1부터 10’까지 라고 쓰이는 표현도 다릅니다. 우리나라에서는 ‘1~10’으로 물결문자를 쓰지만 미국에서는 ‘1-10’를 사용합니다. 하나의 타협점으로 ‘1 to 10’이라고 쓰면 모두가 알아볼 수 있는 표현이 될 수 있습니다. 주가표시도 나라마다 다릅니다. 우리나라, 일본, 중국과 같은 동양권의 나라는 주가가 올라갈 때 빨간색을 사용하지만 미국이나 유럽권에서는 주가가 내려갈 때 빨간색을 씁니다.

4. Language

이스라엘의 히브리어는 오른쪽에서 왼쪽으로 씁니다. 하지만 문장 내의 영어(타국어)나 숫자는 왼쪽에서 오른쪽으로 씁니다. 상당히 독특한 표기방식입니다.
같은 뜻이라도 언어마다 단어의 길이차이가 많이 나는 경우를 고려해야 합니다. 예를 들어 영어로 ‘sync’를 러시아어로 하면 ‘синхронизировать’가 되어 길어지게 되는데 이때는 아이콘으로 대체될 수 있습니다. Google Gmail에서도 많이 사용되는 기능들은 텍스트에서 아이콘으로 대체되었습니다.

5.Time difference

글로벌한 행사의 경우, 두세시간의 짧은 시간이더라도 시차로 인해 다른 나라에서는 이틀에 걸친 행사로 표시 될 수 있음을 염두에 두어야 합니다.

6. Copyright & Local law

국가별로 국기의 비율이 다릅니다. 많은 디자인에서 같은 비율로 디자인되고 있는 경우가 많습니다. 그러나 엄밀히 따지면 국기의 비율도 지켜져야 합니다. 팁으로 가로사이즈를 고정하고 세로로 배열할 수도 있습니다.
전 세계 도시의 지하철 맵에도 저작권이 있습니다. 프로젝트를 시작하기 전 반드시 관련 저작권을 체크하여야 합니다.

7. Number

글로벌 서비스를 디자인할 때는 의사결정을 하기 어려운 경우가 많습니다. 이런 때 통계자료를 활용하면 유용합니다. 한정된 공간에 몇 개의 정보를 넣을 것인가를 판단할 때 검색 빈도 등의 통계자료를 잘 활용하면 사용자의 상당수를 만족시킬 수 있습니다.

8. Eat your dogfood

실제로 한국 디자이너들은 아이폰을 많이 사용하고 선호합니다. 하지만 안드로이드 프로젝트를 많이 경험하게 되는데 이때 디자이너 스스로 안드로이드 플랫폼에 대해 충분히 이해하고 있는가를 생각해 볼 필요가 있습니다.
모바일 디바이스일수록 Dogfooding(자사 제품 직접 써보기)을 많이 해봐야 합니다. OS는 매일매일 쓰지 않으면 적응하기도 이해하기도 쉽지 않습니다. 사용자와 가장 비슷한 환경일 때를 경험하며 디자인해야 합니다.


글을 마치며
지난 6월 안드로이드 OS ‘L’을 발표한지 얼마 안된 시점에서 구글의 이야기를 들을 수 있어 더욱 흥미로운 강연이었습니다. google의 기업문화에 대해 들으며 pxd 내에서도 시도해 볼만한 것들도 있겠다 싶어 재미있게 들었습니다. 특히 디자이너들끼리 아이데이션하는 Design Sprint가 인상적이었습니다. 디자이너들끼리 모여 아이데이션을 하며 도움을 주고 받는다면 담당디자이너는 자신만의 프레임에 갇히지 않고 다양한 시도를 할 수 있을 것 같습니다. 그리고 마지막으로 언급된 Dogfood는 글로벌한 서비스뿐만 아니라도 모든 프로젝트에 필수적이겠습니다. 그만큼 사용자환경에서 충분한 테스트를 거쳤는가를 되짚어볼 필요가 있겠습니다.
Google에서 글로벌 서비스 디자인을 직접 경험하고 좋은 강연을 해 주신 김 수님께 감사를 전하며 FuturePlay에서의 경험 또한 기회가 되면 나눠 주시길 바랐습니다.
[참고##pxd talks##]

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


Trackback 0 Comment 0
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...