태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.


'Apple'에 해당되는 글 6건

  1. 2011.08.25 왜 어떤 가이드라인은 실패하는가? - 말보다 행동이 중요하다 by 이 재용
  2. 2011.07.15 사용자의 80%만을 위해 디자인하라 - Apple Human Interface Guidelines의 역사 (3) by 이 재용
  3. 2011.04.28 Apple 디자인 성공의 비밀과 UCD (9) by 이 재용
  4. 2010.07.19 스티브 잡스의 위기 관리: 통계 숫자와 고객 경험 by 無異
  5. 2010.04.14 “Apple처럼 oooo하게 해 주세요” (4) by Limho
  6. 2010.03.29 Apple, Blackberry, Orange 이름의 유래 by 이 재용
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...
2011.07.15 18:29

사용자의 80%만을 위해 디자인하라 - Apple Human Interface Guidelines의 역사

UI 디자이너에게 표준을 지키는 일은 중요하다.
그러나 지난 번 글(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. 왜 어떤 가이드라인은 실패하는가? - 말보다 행동이 중요하다

참고 UI 디자이너는 표준을 지켜야 하는가? (http://story.pxd.co.kr/317)
안드로이드 UI/GUI 가이드라인 (http://story.pxd.co.kr/162)
Windows 7 Design Principles (http://story.pxd.co.kr/13)



1. 사용자의 80%만을 위해 디자인하라 - Apple Human Interface Guidelines의 역사

UI 개발자에게 표준을 따르는 일은 매우 중요하다. 특히 운영체계(Operating System)의 표준을 따르지 않으면 사용자에게 많은 혼란을 일으키기 때문에 치명적인 불편을 안겨줄 수 있다. 그렇기에 각 OS에서 제공하는 가이드라인을 숙지하는 것이 꼭 필요한 일이다.

하지만 이 Apple의 가이드라인은 여느 OS의 가이드라인과는 다른 위치를 차지하고 있다. UI에 관해 변변한 서적이 없던 시절, 유일하게 교과서적으로 이론을 배울 수 있을 뿐만 아니라 실무적으로 필요한 지식과 팁을 한 번에 배울 수 있는 서적이었기 때문이다. 하지만, 이제 볼 수 있는 책이 많아진 오늘날에도, Apple이 차지하고 있는 UI의 독보적 탁월함에 동의하는 사람이라면, 설령 자신이 Mac OS에서 UI를 개발하지 않더라도, UI 디자이너라면 언젠가는 한 번 꼭 보아야할 책이라고 생각하여 소개한다. (Apple의 기업 문화나 UCD와의 관계에 관해서는 Apple 디자인 성공의 비밀과 UCD)참고.

Apple은 자신의 OS에 대한 가이드라인을 Addison-Wesley와 함께 1985년부터 출판하고 있다. 맥 OS의 역사와 함께 Apple 가이드라인의 역사를 살펴보고자 한다.


1985년 Human Interface Guidelines: The Apple Desktop Interface

Human Interface Guidelines: The Apple Desktop Interface

1984년 1월 24일 애플의 OS인 System 1.0 이 출시되고, 1985년 4월에 System 2.0 이 출시된다. 처음 1985년에 출판된 가이드라인은 찾을 수가 없고 pxd 도서관에 소장하고 있는 것은1987년 11월 판이다. 1987년 11월이면 System Version 3.3 이고, 책에 언급하고 있는대로 Finder Version 5.5를 기준으로 설명하고 있는 책이 되겠다. 다행히 책 뒷면에 보면 원래 책 디자인을 커버만 다르게 한 것이고, 내용은 동일하다고 설명하고 있다.

책의 서문을 보면 매우 감동적이다.

서문에서 데스크탑 소프트웨어의 장점이 '일관성'을 유지해서 사용자가 쉽게 학습할 수 있게 하는 것이 최대 장점이므로 이 가이드라인을 통해서 일관성을 유지하도록하고, 예외적으로 이 가이드라인을 따르지 않으면서도 좋은 소프트웨어들이 있긴 하지만, 충분한 이유가 있을 때만 그러한 예외를 추종하도록 강조하고 있다.

제1장 '철학' 부분에서 애플은 사용자를 어떻게 보는가에 대해 설명한다
People aren't trying to use computers - they're trying to get their jobs done.
그러나 사람들의 일이란 얼마나 창조적이고 예술적인가에 대해 충분히 설명하고 있다.

1장에서 애플이 제시하는 10가지 디자인 원칙을 옮겨보면,
Mataphors from the real world
Direct manipulation
See-and-point (instead of remember-and-type)
Consistency
WYSIWYG (What you see is what you get)
User Control (not computer)
Feedback and dialog
Forgiveness
Perceived stability
Aesthetic integrity

Principles of graphic communication 부분에서는, Visual Consistency, Simplicity, Clarity 등을 별도로 제시하고 있다. 흥미로운 것은 '프로그래머'를위한 철학도 있는데, Modelessness, Event loop(언제나 사용자 이벤트를 받아들여라), Reversible actions, Screen(화면을 중시해라), Plain language가 들어있다. 아마도 당시에는 이런 부분들에 대한 정책은 프로그래머들이 정한 듯 하다. (물론 plain language를 위하여 전문 writer를 고용하라는 말도 들어있다)

또 1장에서는 User testing과 장애인에 대한 고려 사항에 대해서도 설명하고 있다.

2장부터는 각 화면 요소와 구성을 하나씩 설명한다. 특히 흥미로운 부분은 다이알로그 박스에 들어있는 Cancel-Ok 버튼 순서에 관한 설명인데, 이 부분은 설명이 기니까 별도의 기사로 쓸 계획이다.


1992년 Macintosh Human Interface Guidelines

Macintosh Human Interface Guidelines

1987년과 1992년 사이에 애플에서는 'Inside Macintosh' 시리즈를 통하여 각 부분 부분별로 Guideline에 대하여 설명하여 왔던 것 같다. 그리고 Human Interface Notes라는 것도 출판했다고 하는데 전혀 찾을 수가 없다. 사람들에게 가장 대중적으로 읽히고, 또 오늘날 Guideline계의 교과서라고 할 수 있는 Macintosh Human Interface Guidelines는 1992년에 처음 출판되었다. (아마존에서는 2판 판매)

이 책은 맥의 중흥기랄수 있는 System 7 (1991년 5월 출시)을 대상으로 하고 있다. System 7은 그 중간에 PowerPC 칩 적용으로 맥이 본격적으로 많은 사람들의 사랑을 받게된 시기이기도 하다.

 

서문에서 디자인 원칙으로
Mataphors
Direct manipulation
See-and-point
Consistency
WYSIWYG (What you see is what you get)
User Control
Feedback and dialog
Forgiveness
Perceived stability
Aesthetic integrity
Modelessness

이렇게 11가지를 설명하고 있다. 이전의 10개에 프로그래머용 철학 중 Modelessness를 추가하여 11가지가 된 셈이다.

글 서두에 거의 유일한 '실무 교과서'였다고 했듯이, 책의 전반부(Part One)는 다양한 원칙, 팁, 프로세스 등으로 가득차있다. 사용자 관찰 10단계, 복잡성 대처법, 인터페이스 확장법, 시장 요구 대응법 등을 포괄하고 있다. 특히 80% 솔루션에 대한 이야기가 처음 등장한다. 사용자의 80%만 만족시키려고 하면, 매우 단순한 제품이 나온다는 뜻이다. 나머지 20%까지 만족시키려는 순간 망한다는 말이다. 1992년에도 그들은 이걸 알고 있었다.

Part Two에서는 인터페이스의 다양한 요소들에 대해 설명한다. 앞의 책에 비해 언어 부분이 추가되었으며, 여러 리소스들을 부록에 포함시키고 있다. (당시로서는 매우 소중한 리스트였다)


2000년 Apple Human Interface Guidelines

Apple Human Interface Guidelines

2001년 3월 24일 정식 출시된 Mac OS X는 오랜 동안 클래식 맥 OS의 불안정함을 깬 역작이라고 할 수 있다. 초기 골수 사용자들로부터 반대도 많았다고 들었지만 한단계 도약이었음에 틀림이 없다. 디자인면에서는 이전부터 하드웨어에서 사용하던 반투명 디자인을 화면에 옮겨 'Aqua'를 시도하였던 것으로 유명하다. 알파와 베타 버전이 나오던 기간에 이를 위한 가이드라인은 여러 가지 이름으로 불렸다. 2000년 1월 20일에 나온 'Aqua Layout Guidelines'는 'Adopting the Aqua Interface', 'Inside Mac OS X: Aqua Human Interface Guidelines', 등을 거쳐 결국 지금의 이름인 'Apple Human Interface Guidelines'가 되었다.

이 때부터 책으로 나오지 않았기 때문에 온라인에서 언제나 접할 수 있는 장점이 있는 반면 예전 버전은 쉽게 찾을 수 없는 아쉬움이 있다. Pxd 도서관에는 2003년에 만들어진 (OS X 10.3 정식 발표 이전에 배포한)가이드라인 출력물을 보관하고 있다(사진).

 

이 책에서는 11개의 디자인 원칙으로
Mataphors
See-and-point
Direct manipulation
User Control
Feedback and Communication
Consistency
WYSIWYG (What you see is what you get)
Forgiveness
Perceived stability
Aesthetic integrity
Modelessness

등 같은 항목을 약간의 용어를 달리하고, 순서를 달리하고, 설명 분량을 줄여서 기술하고 있다. 또한 더 간략해지긴 했지만, 각종 방법들에 관해 설명한다.

이 시기 책에서 처음 'Experience' 라는 말을 사용한다. 'The Macintosh Experience' 에 대해 설명하면서, 포장, 설치 등에서 일관된 경험을 요구하고 있다. 이 버전부터 (이전 버전에서 열을 내어 설명하던) OK-Cancel 로직 부분이 대거 빠지게 된다. (그림 속에 아주 간단히 나타내는 정도) 그리고 재미있던 어펜딕스들이 대거 빠져 나갔다.


2006년 Apple Human Interface Guidelines

Pxd에서 보유중인 2006년 10월 3일자 가이드라인에는,'좋은 소프트웨어의 특징(Characteristics of Great Software)'라는 부분이 추가되었는데, High Performance, Ease of Use, Attractive Appearance, Reliability, Adaptability, Interoperability, Mobility가 그것이다.

 

또한 이 책에서는 12개의 디자인 원칙으로
Mataphors
Reflect the User's Mental Model
Explicit and Implied Actions
Direct manipulation
User Control
Feedback and Communication
Consistency
WYSIWYG (What you see is what you get)
Forgiveness
Perceived stability
Aesthetic integrity
Modelessness
를 제시하고 있다.

Macintosh Experience 파트에서 '포장'이나 '인스톨'부분은 다 뒤로 돌려 버리고, 그냥 소프트웨어적인 부분 설명하는 것을 맨 앞에 두었다.

Pxd에서 보유중인 2008년 1월 15일자 가이드라인에는, 2007년 10월 26일에 출시된 레오파드 Mac OS X v10.5 업데이트 내용을 반영하였으며, 이 즈음부터 책(PDF) 표지에 파란색 글씨로 'User Experience'라는 말이 들어갔다.


2011년 Apple Human Interface Guidelines

Apple Human Interface Guidelines

마지막으로 현재(2011년 7월) 인터넷 (애플 개발자 라이브러리)에서 다운로드 받을 수 있는 버전은 2011년 5월 31일 판이다. 트랙패드에서의 동작 인식에 관한 것이 추가되었다. 이전 책에서 사용자 입력에서 마우스, 트랙볼, 스타일러스 펜만 언급하였다면 트랙패드가 하나의 부분으로 추가되어, 핀치나 three finger swipe, four finger swipe 등에 대해 설명하고 있다.

Metaphors, Mental Model(Familiarity, Simplicity, Availability, Discoverability), Explicit and Implied Actions, Direct Manipulation, See and Point, User Control, Feedback and Communication, Consistency, WYSIWYG (What You See Is What You Get), Forgiveness, Perceived Stability, Aesthetic Integrity

이상으로 간단(?)하게 Apple Human Interface Guideline의 역사를 살펴보았는데, 예전 책을 들쳐보며 차이점을 찾은 것은... 사실 당장은 최영완님의 OK-Cancel에 관한 글을 읽다가 시작한 일인데, 개인적으로 재미있어서라기 보다는 누군가 한 번쯤 해 두면 다른 사람들이 편리하게 사용할 수 있을 것 같아서이다.

다음 글에서는 '2. 마침내 혼란을 극복한 Windows 7 – Windows User Experience Interaction Guidelines의 역사'에 대해서 살펴볼 것이다.

 

참고

iOS(iPhone,iPad,iPod)에 관심이 없더라도 꼭 보길 권한다.
iOS Human Interface Guidelines (Web) - 2014.01.11 수정함
iOS Human Interface Guidelines (PDF)


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



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


Trackback 0 Comment 3
Ad Test...
2011.04.28 01:45

Apple 디자인 성공의 비밀과 UCD

누구도 부정할 수 없는 사실은, 디자인 혁신에서 가장 앞서있는 기업이 Apple (애플)이라는 사실이다. 그러나 애플은 제품에 대해 철저히 숨기는 것 만큼이나 제품 개발 과정에 대해 직원들의 대외 노출을 막는 것 아닐까 생각이 들 정도로 많이 알려지지 않았다. 일반적인 사용자 중심 디자인(UCD, User Centered Design) 방법을 사용하지 않는다. 특히 Focus Group을 무시한다 정도?(Innovation:Lessons from Apple, Economist)

그런데 지난 CACM(Communications of ACM)誌에 이 주제에 관한 기사가 실렸다. 이를 계기로 기사에서 언급한 내용을 살펴보려고 한다.(기사는 CACM 2011년 4월호인데 ACM회원이 아니면 볼 수 없다. 따라서 출처는 모두 원문 블로그로 밝힌다.)


CMU(Carnegie Mellon University) 컴퓨터과 교수인 Jason Hong은 2010년 7월 21일자 ACM Blog에 Why is Great Design so Hard라는 글을 싣고, Microsoft는 개발자:UI 디자이너 비율이 50:1 정도로 그 어떤 기업보다 높은 편인데 왜 디자인이 구리냐라고 질문하면서 혹시 '디자인'에 대한 이해가 전혀 없는 개발자들이 이상한 자기들만의 문화를 만들어가면서 실질적인 힘도 없는 디자이너를 프로세스 후반에 넣어 개발하다가 결국은 아무도 책임지지 않는 구도로 가니까 그런 거 아닐까라고 추측을 해 본다. (우리나라 대부분의 회사들도 피해가기 어려울 것이다. 간혹 '개발자'대신에 '상품기획'이나 '마케팅'으로 바꾸어 읽어야 하는 회사가 있긴 하다.) 그는 다시 Part 2에서 애플이 다른 것은, 조직 전체에, 일상 과정 전체에 '디자인'이 퍼져있다는 점을 지적한다. 그것도 위에서 아래로. 그러면서 소개하길, 제품 디자이너가 이렇게 만들자라고 제안했을 때, 개발팀에서 '안된다'라고 말하니, 제품 디자이너가 '안된다는 걸 증명해봐라'라고 해서 개발팀이 그걸 증명하기 위해 노력하다보니 원 디자인의 90% 정도는 구현할 수 있었다는 일화를 들었다.

(우리 나라 대부분의 '개발자'와 '개발자 중심 회사'와 일하면 정반대의 상황이 펼쳐진다. 개발팀에서 '안된다'고 하면 그걸로 끝이다. pxd에서는 반대로 '그것이 된다'라는 걸 증명하기 위해 소스 코드를 검색하고, 다른 개발자의 자문을 얻어서 방법을 알아내 개발자에게 알려주는 경우가 잦다. 그러다 보니 지친다. 정말 UI에 관심을 갖고 구현하려고 노력해 주는 개발자는 네오위즈-첫눈 시절 몇 명, 개발회사로는 유비벨록스가 유일했던 것 같다.)

특히 애플은 표준적인 HCI(Human Computer Interaction) 즉 UCD 기법을 사용하지 않는다. 대신, 1. Subject Matter Expert를 활용한다. lead user 혹은 IDEO의 unfocus group이라고 볼 수 있는, 전문 사용자(극단적 사용자)를 살펴본다. 생활동영상 편집 프로그램인 iMovie를 만들기 위해, 동영상편집전문가를 만나보는 것이다. 2. 근본적인 해결이 나올 때까지 치열하게, 오랫동안 고민한다. 3. 자료에 근거하지 않고, 철학에 근거해 디자인한다. 저자는 애플 제품이 많은 경우 '세계 최초'가 아니었다면서 디자인 역량이 있는 경영자들을 중심으로 '문제 해결'을 위해 오랫동안 끈질기게 고민하는 디자인 문화가 애플을 만든 것이라고 주장한다.

(결국 1번은 요즘 많은 agency들이 하고 있는 흔한 방법이라 쉬운데. 2번은 우리 나라 기업들이 도전해 볼 만하다고 믿고 싶다. 3번-디자인 철학을 가진 리더-을 할 수 있는 건 운이니까.)

Tog도 비슷한 이야길 한다. 2010년 4월 그의 블로그에 Mac & the iPad라는 제목으로 역사는 반복된다고 주장하면서, 애플은 맥 시절부터 제품 최초 출시에는 아주 작은 팀이 엄청난 집중력으로 (일주일에 90시간씩) 일하면서 핵심 개념에 유기적으로 연결된 제품을 만들어 내고, 확장할 때는 대규모 팀이 붙는 형식을 취한다면서, 작은 팀이 끈질기게 문제 해결을 한다고 강조한다. 그러다보니 초기 맥, 초기 아이폰에 실리는 기본 프로그램들은 매력적이고 유기적이고 일관되지만, 개수는 매우 적을 수 밖에 없다. 물론 여기에 두려움 없는 리더, 잡스의 역할도 크다. 제품의 핵심을 해치는 것은 초기에 일부러 배제한다. 폐쇄적인 시스템과 비밀스런 조직을 운영한다.

Pragmatic Marketing에 실린 You Can't Innovate Like Apple이라는 기사에서는 디테일에 엄청난 신경을 쓰면서 대단한 아이디어를 대단하게 포장하는 등, 애플은 디자인을 '선물'로 생각한다고. 크리스마스 선물을 트리 밑에 두고 참고 참다가 크리스마스날 열어보면서 기뻐할 수 있도록. 그리고 픽셀단위로 정확한 목업을 10개 이상 만든다. 다른 기업에선 완성품이라고 할 완전히 서로 다른 디자인의 목업을 10개 만들고, 그 중에 3개 골라 또 만들고, 다시 1개 골라 만드는 동안(10 to 3 to 1) 엄청난 돈과 노력이 투자된다. 디자인 작업의 90%를 버린다-라고 한다.

이 글 역시, 시장 조사를 하지 않지만 소비자에 대해 잘 아는 것이 중요하다는 점, 좋은 리더, 집중, 작은 팀, 세계 최고 수준의 훌륭한 사람들(+엄청난 보상)이 아주 작은 디테일까지 끈질기게 노력하는 것을 지적한다. (brainstorming-production pair meeting과 pony meeting같은 기술적인 언급도 들어있다)

결국!

애플 혁신의 힘은,
1. 소비자를 잘 아는 훌륭한 리더와 경영층, 그리고 조직 전체에, 일상에 퍼진 디자인 중심의 문화
2. 천재들로 구성된 작은 팀이 핵심을 오랜동안 끈질기게 해결하고, 아주 작은 디테일까지 최선을 다하는 장인 정신(일주일에 90시간 일하고, 작업의 90%를 버린다) + 이에 따른 유무형의 보상

으로 요약해 볼 수 있다. 그러면 표준적인 UCD가 필요없는 건 당연하다. 

[참고-영문]
Innovation:Lessons from Apple (Economist, 2007)
You Can't Innovate Like Apple (Pragmatic Marketing, 2008, Alain Breillatt)
Apple's design process (BusinessWeek, 2008, Helen Walters)
Mac & the iPad (AskTog, 2010, Bruce Tognazzini)
Why is Great Design so Hard, Part 2 (ACM Blog, 2010, Jason Hong)
8 Things to Know About the Company Culture at Apple (ux movement, 2011, anthony)
How Apple works: Inside the world's biggest startup (Fortune Tech,2011, 번역있음)
기타
90 Hours a week and loving it (Folklore, 1983, Andy Hertzfeld)
The Secret of Apple Design (Technology Review, 2007, Daniel Turner)
Apple: America's best retailer (Fortune, 2007, Jerry Useem)

[참고-한글]
애플은 어떻게 돌아가고 있는가? (Fortune Tech, 2011)
"애플, 발명한 건 없다… 단지 찾고 조합했을뿐" (머니투데이,2011)

[참고##UCD##]

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


Trackback 1 Comment 9
Ad Test...
2010.07.19 12:36

스티브 잡스의 위기 관리: 통계 숫자와 고객 경험

아이폰4 안테나 이슈에 대해 기자 회견을 통해 전달하려고 한 메시지가 저한테는 회견 전에 틀어준 유튜브 동영상 처럼 "사기 싫음 말등가"와 "범퍼 먹고 떨어져" 로 들렸습니다. 애플빠에 가까운 저에게 왜 이런 부정적인 이미지로 비쳤을까요?


고객 경험

애플은 고객 경험을 파는 회사입니다. 이번 신형 아이폰 광고도 기능이나 스펙을 나열하는게 아니라 애플을 사용하는 고객 한 사람 한 사람과 그들의 삶 속에서 가치를 주는 스토리를 전달하도록 치밀하게 만들어져 있습니다.

하지만 문제가 생기자 얼굴을 바꾸고 개개인의 고객 경험이 아닌 산술평균화된 숫자를 내보였습니다.


출처: 애플 via engadget


잡스가 말하는 안테나 문제의 본질은
1.다른 스마트폰들도 다 똑같다. 라는 물타기와
2.사실 별 문제도 아닌데 언론의 과장이 너무 심하다.라는 통계 숫자 나열입니다.

물타기도 문제이지만 고객의 경험에서 나오는 문제를 통계 숫자로 덮으려는 모습이 눈에 걸립니다.


문제의 모델링 

우리나라 평균 자녀수가 1.15명이라고 하는데, 애 하나를 키우다가 0.15명의 아이를 또 낳은 아빠의 삶은 어떻게 달라질까요? 평균화된 숫자는 고객의 경험을 전혀 나타내지 못합니다. 통계 숫자들은 사실이 아니라 의도를 보여주는데, 이번에는 사용자의 문제를 희석하는데 사용되었습니다. 그래서 사용자의 문제를 알고 싶을 때는 정량적인 조사가 아니라 정성적인 조사를 위주로 합니다. 숫자는 거들뿐이죠.


통화 단절의 사용경험

숫자만 보면 형체가 없는것 같지만 실제 안테나 수신 불량을 겪은 고객은 분명하게 존재하고,  그 경험은 전화를 사용하면서 겪는 가장 최악의 경험일 것입니다. 우리나라는 통신 사정이 좋아서 엘리베이터나 지하 주차장에서 아주 예외적으로 통화 단절을 경험할 때가 있는데요. 그것이 일상이 될 때의 스트레스는 더 크겠지요. 통화 단절은 사용자만이 아니라 통화 상대에게도 전해져서 불만은 배가 됩니다. 동일한 통화 단절을 계속 경험하면 "너 전화 바꿔라" 같은 짜증섞인 말도 들어야 하고요.


통계 숫자놀이

다시 숫자를 가지고 얘기하면, 고객 센터에 안테나에 대한 불만이 0.55%밖에 되지 않는다고 하고 통화 단절이 이전 세대폰에 비해 1%포인트 미만으로 늘었다고 합니다. (문제를 가진 고객이 적게 보이도록 하고 있지만) 암튼 그럼 대다수의 사용자는 아무 문제가 없고 그 작은 소수의 고객이 전체의 1%포인트의 차이를 만드려면 그들은 얼마나 통화 단절이 늘었다는 걸까요?

0.55%라는 숫자가 안테나에 문제가 없다라고 하기는 어렵습니다. htc는 자기네 고객센터의 안테나 문제는 0.016%라고 밝혔습니다. 모든 폰이 불완전하다고 하는데 다른 스마트폰에 비해 34배정도 더 불완전하면 좀 문제가 있는 거잖아요.

drop call rate도 실제보다 훨씬 작은 크기로 인식하도록 실제 단절율 보여주는 대신 이전 세대폰과의 차이를 표시합니다. 고객 불만 센터 자료는 퍼센트를 사용하다가 이번에는 100건당으로 표시합니다. 1%는 통화량에 따라 어떤 큰 수 있수도 있지만 우리는 보통 자연수에 익숙하다보니 1보다 작으면 그냥 없다고 느끼게 되니까요. 참고로 아이폰의 통화 단절율은 뉴욕에서는 30% 라고 하기도 합니다.



We want to make all our users happy

암튼 그럼에도 불구하고 모든 고객을 행복하게 만들겠다는 기업 이념은 절대 모든 사용자를 만족시키는 디자인을 하겠다는것이 아닙니다. 모든 사용자를 만족시키는 디자인 같은건 없으니까요. 모든 사용자를 만족시키기 위해서 빛나는 엣지를 무디게 한다면 사람들이 애플을 좋아할 이유가 없지요. 물론 저는 아이폰을 또 살거에요. 사기 싫음 말등가.
[참고##스티브 잡스##]


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


Trackback 0 Comment 0
Ad Test...
2010.04.14 18:19

“Apple처럼 oooo하게 해 주세요”

어플리케이션 GUI 디자인을 의뢰하는 클라이언트들로부터 한동안 들어야 했던 말은 “iTunes 처럼 oooo하게 해 주세요” 였습니다..  oooo은 다양한 표현들이었지만 어쨌든 ‘iTunes처럼’ 으로 시작하는 요구 사항들이었죠. 이후 모바일 프로젝트에서는 “iPhone처럼(보다) oooo하게 해 주세요” 라는 말을 가장 많이 들은 것 같습니다.
이렇게 관용구처럼 쓰이게 된 데에는 애플의 뭔가가 많은 사람들을 감동시켰기 때문일 겁니다. 자타공인 최고라 할 수 있는 Apple사의 제품 디자인, GUI 디자인에 대해 짚어 보고 싶었습니다.

삼성, LG 같은 가전 제품 회사가 100가지 메뉴를 골고루 갖춘 식당이라면 Apple은 전문 메뉴를 가진 식당에 비유할 수 있겠습니다.  이 점이 제품의 일관된 이미지를 관리하는 데에 유리했고, 이런 강점이 GUI디자인 컨셉과 스타일 결정에도 유리하게 작용했던 것 같습니다. 그러나 그런 환경이 똑같이 주어진들 아무나 할 수 있는 것도 아닐 겁니다. 몇 년간 트랜드를 이끌어 갈만한 미래의 디자인 아이덴티티를 끌어 내기 위해 피나는 시도와 도전, 고뇌의 과정이 있어야겠죠.

오랜동안 MAC OS GUI테마였던 Apple platinum은 GUI 역사에서도 한 획을 그은 그래픽이었지만 Apple의 제품 디자인과는 별개로 진화했던 것 같습니다.

iMAC과 Apple yosemite 기종부터 Apple은 보다 선도적인 제품 소재(Material, Color, Finishing)를 선택하여 제품에 적용해 왔고 소재 컨셉을 그대로 GUI 디자인에 표현하기 시작했죠.

Aqua style은 제품 디자인뿐만 아니라 그래픽 분야에서도 선풍적이었습니다.

다시, Apple 제품의 이미지를 만들 제품 소재(aluminium)를 신중하게 선택하고 GUI에 적용했습니다.

하드웨어와 소프트웨어(OS)를 같이 만들어 제품 라인 전반에 반영한다는 것이 얼마나 위대한 지를 보여 줍니다. Apple에게는 컴퓨터를 하드웨어와 소프트웨어로 나눈다는 것이 의미가 없는 것 같습니다. 그 둘은 몸과 마음 같아서 제품을 만들 때 떨어뜨려 생각할 수 없다는 철학을 느끼게 합니다.

iPod / iPhone의 GUI도 같은 맥락에서 살펴 보면, 전면의 강화 유리 재질감이 적용되었다고 볼 수 있습니다. 기능에 따라 터치 외관 부분이 매번 실재 유리 재질의 콤포넌트들로 (물리적)재구성된다고 상상했을 때 도출될 수 있는 표현이라고 저는 생각합니다.

어떤 것을 상상해서 표현하느냐는 GUI 스타일과 컨셉을 결정하는 데 중요한 고민거리입니다. 그런데 많은 GUI 디자이너들이 이러한 고민 없이 애플 스타일의 완성도만을 따라 그리는 일이 많은 것 같습니다. 어쨌든 지금까지 언급한 것처럼 하드웨어 이미지와 소프트웨어 이미지가 자체의 퀄러티뿐 아니라 서로 조화를 잘 이루어 사람들의 마음을 움직이게 했던 것은 아닐까요.

음... 애플 모니터를 보다가 언뜻 스친 생각인데요... LCD/LED패널이 꺼졌을 때 Black이 아니라 aluminium 컬러와 질감으로 보여질수만 있다면 모니터를 이렇게 만들지는 않았을까요? ^^; (좀 오버인가? 어디까지나 제 상상입니다.)

이쯤되면 애플의 그 다음이 궁금해집니다.
알 수 없지만^^, 새로운 기술의 가치를 가장 이상적으로 구현하는 애플이라면, 요즘 주목을 끌고 있는 투명 패널에 관심이 있을 수도 있겠다는 생각이 듭니다. 물론 예전에 다소 허접하게 투명 body를 선보인 적이 있긴 하죠.

삼성이 투명 amoled를 개발했습니다.
그런데 투명 패널과 가장 잘 어울리는 OS GUI 디자인과 기막히게 정리된 내장이 다 들여다 보이는 투명 컴퓨터 본체를 만들어낼 만한 곳은 애플 밖에 없어 보이네요...:)

투명이든 뭐든 애플이 또 어떤 상상력으로 사람들을 즐겁게 해 줄 것인 지, 동종 업계 사람들을 또 얼마나 난감하게 만들 지 궁금합니다.

[참고##UI 역사##]


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


Trackback 0 Comment 4
Ad Test...
2010.03.29 19:42

Apple, Blackberry, Orange 이름의 유래

Apple Inc. (Apple Computer)
애플 컴퓨터 이름의 유래에는 여러 가지 이야기가 있는데, 대체로 종합하면, 스티브잡스가 사과 농장에서 일했는데 그래서 사과를 좋아하게 되었거나, 아니면 비틀즈를 좋아했는데 그 음반 회사 이름인 애플 레코드에서 영감을 얻었다고 한다. 회사 이름을 지어야만하는 정해진 시일까지 더 나은 이름을 생각하지 못 하면 그 이름으로 하기로 했고 결국 애플 컴퓨터라고 이름짓게 되었다. 처음 로고 아이디어는 뉴튼과 사과나무였는데 너무 복잡해서 그 다음은 그냥 사과로 했다가 오렌지랑 너무 비슷해 보여서 결국은 한 입 베어 물은 것으로 하기로 했다. (HubPages, MacRumors, Wikipedia)

또 다른 이야기로는, 창립자인 스티브잡스가 가장 좋아하는 과일이 사과였다. 회사 설립 후 3개월이 지나도 이름을 짓지 못 하자 마지막 날 오후 5시까지 더 나은 이름을 제시하지 못 하면 '사과'라고 부르겠다고 동료들을 위협했다고 한다. It was the favourite fruit of founder Steve Jobs. He was three months late in filing a name for the business, and he threatened to call his company Apple Computers if the other colleagues didn't suggest a better name by 5 O'clock. (WTN News:왜 회사 이름을 과일 이름으로 지으면 안 되는가)

이 뉴스 소스에 의하면 (정확한지는 모르겠으나) 결국 이 이름 때문에 비틀즈 음악을 내는 Apple Records와의 기나긴 상표 분쟁에 시달리게 되었고, 비틀즈는 스티브잡스에게 '바나나 컴퓨터'라고 이름을 바꾸라고 했다고 한다. It is also said that The Beatles have suggested that Apple Computers should call itself a “Banana” or anything other than apple. Now, now where are their British manners? Are consumers really ready to carry “Mr. iBanana”?

iTunes에 비틀즈의 음악이 들어오게 된 것은 매우 최근의 일인데, 그 이유도 Apple 브랜드를 둘러싼 양사의 오랜 소송과 그로 인한 감정적 앙금 때문이라는 이야기가 있다.

Banana Republic
1978년에 설립되고 1983년에 Gap에 인수된 의류 회사로 전세계 500 개 가게를 가지고 있다. 원래 '바나나 리퍼블릭'은 중남미에 농업 중심이면서 정치적으로 불안정한 나라들을 가리키는 말이다.

Blackberry
원래는 E-mail 관련한 이름을 지으려고 했는데, E-mail은 업무와 관련있고, 그러면 혈압을 높일 수 있다는 조언에 따라, 이를 포기하고, 마음에 평화를 주는 과일 이름으로 가기로 했는데 여러 가지를 검토 끝에, 검은색 키보드가 옹기종기 있는 모양을 따서, 블랙베리라고 지었다고 한다.
http://advice.cio.com/al_sacco/rim_blackberry_history_origin_of_the_name_blackberry 
http://www.cio.com/special/slideshows/famous_tech_names/slide02#slideshow 

Orange (mobile network operator)
프랑스에 본부를 둔 세계에서 5번째로 큰 이동통신회사. 브랜드는 내부 마케팅 디렉터가 만들었고 브랜드화 하는 작업은 외부 컨설팅회사인 Wolff Olins에서 맡았다.
The Orange brand was created by an internal team at Microtel headed by Chris Moss (Marketing Director) and supported by Martin Keogh, Rob Furness and Ian Pond. The brand consultancy Wolff Olins was charged with designing the brand values and logo and advertising agency WCRS created the Orange slogan "The Future's bright, the Future's Orange" along with the now famous advertising. The logo is square because it was felt that the word orange could be seen as a fruit and it needed to be strong in the business world rather like American Express and Hertz. It was also important to establish it as the colour Orange, which is seen as a strong Feng Shui colour. The Orange network was launched on 28 April 1994 (from wikipedia)

피엑스디도 처음 이름을 지을 때, 귤 미디어라고 짓고 싶었는데 다른 동료들의 반대가 심해서 실패했다. 여러 과일들 가운데서 귤이 가장 좋은 user interface를 갖고 있다고 생각했기 때문인데, 같은 이름의 디자인 회사가 있었기 때문에 더 주장하기 어려웠다.

[참고##UI 역사##]

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


Trackback 0 Comment 0
Ad Test...