태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.


'guideline'에 해당되는 글 10건

  1. 2015.01.15 [HCI KOREA 2015 후기 1/2] 성공적인 스마트TV 표준 가이드라인 만들기 발표 후기 by 김 동후
  2. 2012.12.26 UX 신입 디자이너가 알아야 할 UI디테일 용어 1탄 (14) by yesong
  3. 2012.02.17 안드로이드 디자인 : Android 4.0 ICS 디자인 가이드 (1) by kyuheeee
  4. 2011.08.25 왜 어떤 가이드라인은 실패하는가? - 말보다 행동이 중요하다 by 이 재용
  5. 2011.07.31 그들만의 리그, 우울한 ISO UI 표준 – ISO 13407 & ISO 9241의 역사 by 이 재용
  6. 2011.07.27 마침내 혼란을 극복한 Windows 7 - Windows User Experience Interaction Guidelines의 역사 (2) by 이 재용
  7. 2011.07.15 사용자의 80%만을 위해 디자인하라 - Apple Human Interface Guidelines의 역사 (3) by 이 재용
  8. 2011.02.27 사용자의 목소리로부터 보다 효과적으로 정보를 얻는 방법 (2) by 전성진
  9. 2010.11.17 안드로이드 체크박스 디자인 fail (8) by 無異
  10. 2010.01.29 Windows 7 Design Principles by 이 재용
2015.01.15 01:00

[HCI KOREA 2015 후기 1/2] 성공적인 스마트TV 표준 가이드라인 만들기 발표 후기


2014년 12월11일, HCI KOREA 2015에서 '스마트TV 표준 가이드라인에 대한 사례 발표'를 진행하였습니다. 현장의 분위기와 발표 내용을 간략하게 요약하여 공유합니다.

성공적인 스마트TV 표준 가이드라인 만들기

UX디자이너에게 표준을 지키는 일은 중요합니다. 더불어 표준을 만드는 일도 중요합니다. 이번 학회에서 나눌 주제는 'IT 솔루션의 표준을 만드는 일' 즉 표준 가이드라인(General Guideline)작성에 관한 내용이었습니다. IT 솔루션을 개발하고 디자인하는 곳이라면 어디서든 표준 가이드라인을 만듭니다. 스마트TV도 예외는 아닙니다. 특히 스마트TV OS개발의 경우 기획, 개발, 디자인 등 다양한 부서 간 협업을 통해 서비스가 만들어집니다. 때문에 서비스의 일관성을 유지시켜 주는 표준 가이드라인의 역할이 중요합니다. 이번 발표에서는 '성공적인 스마트TV 표준 가이드라인을 제작하려면 어떻게 해야 할까?' 라는 주제를 가지고 pxd에서 고민했던 내용들을 공유하였습니다. pxd가 생각하는 표준 가이드라인은 무엇인지, 어떤 유형의 가이드라인이 있는지, 어떤 방식으로 작성이 되는지, 어떻게 하면 성공적인 스마트TV 가이드라인을 만들 수 있는지 등 스마트TV 표준 가이드라인 작성 전반에 관한 이야기를 공유하였습니다. 발표는 크게 4가지 내용으로 구성하였습니다. 표준 가이드라인의 정의 및 유형 / 가이드라인 제작 현황과 문제 / 스마트TV에서의 가이드라인 / 성공적인 가이드라인 작성 노하우로 구성되어 있으며, 발표 진행은 정유리 주임과 김동후 선임 연구원이 전반부와 후반부로 나누어 진행하였습니다.


1. 표준 가이드라인의 정의 및 유형

표준 가이드라인은 '서비스 개발의 표준을 정의하여 개발자들에게 일련의 권장사항 규칙을 제공하는 소프트웨어 가이드 문서(wikipedia)'입니다. 가이드라인에는 Design principle, look&Feel, Interaction, Navigation, Component 등에 대한 내용들이 들어 있습니다. 좋은 가이드라인은 응용 프로그램의 직관성, 학습성, 일관성을 구축하여 사용자의 경험을 향상시킵니다. 구체적으로 설명하면, 서비스 일관성을 위한 공통의 원칙 제시, 브랜드 철학 공표 및 계승, 커뮤니케이션에 필요한 판단 기준 제시, 결과물 검증에 기준이 되는 도구로의 활용 등의 역할을 합니다. 결과적으로는 최종 서비스 사용자의 경험에 중요한 영향을 끼치게 됩니다.


2. 가이드라인 제작 현황과 문제

그동안 pxd에서는 여러 분야에서 표준 가이드라인 작업을 경험해 보았습니다. 그 경험을 토대로 현재의 제작 현황에 대해서 분석해 보았습니다. 크게, 제작 시스템과 환경적인 문제로 나눌 수 있습니다. 시스템적인 측면에서 가이드라인 제작의 이상적인 구조는, 절대적인 권위를 가진 가이드라인 문서가 존재하고 그것이 각 개발 부서에 전달되어 공통된 룰을 따르도록 하는 형태라고 생각합니다. 하지만 (필자가 경험한) 대부분의 가이드라인 제작 시스템은 개발에 관여하는 유관 부서마다 독립적으로 원칙을 규정하고 그 규정들을 짜집기 하는 형태로 이루어집니다. 환경적인 측면을 보면, 개발 실무진에서 가이드라인에 대한 중요성을 간과하고 실무 경험이 없는 사람들이 가이드라인을 제작하여 완성도가 떨어지는 경우가 있고 '가이드라인 사용자'를 배려하지 않고 내용에만 치중하여 사용성이 떨어지는 가이드라인이 제작되기도 합니다. 이러한 경우 가이드라인의 사용성이 떨어지고 권위와 신뢰도가 떨어지기 때문에 가이드라인이 무용지물이 되는 경우가 많습니다.

3. 스마트TV에서의 가이드라인

스마트TV는 UI설계 시 고려해야 할 점이 매우 많은 디바이스입니다. 하드웨어 특성상 불특정 다수를 만족시킬 수 있어야 하며 시청 거리가 고려 되어야 하고 간접 조작 방식(리모컨)에 대한 고려도 필요합니다. 즉, 사용자 경험에 대한 폭이 매우 넓은 디바이스라는 것입니다. 따라서 더 넓은 범위에서 표준을 정의해야 합니다. 첫 섹션에서는 인터랙티브TV의 초창기 모델인 Web TV의 가이드라인부터 현재 제공되고 있는 가이드라인의 사례를 살펴 보았습니다. 사례 분석을 통해 표준 가이드라인의 방향성을 생각해볼 수 있습니다. 첫째, 사용자의 행동 패턴을 중심으로 작성되어야 한다. 둘째, 브랜드의 철학을 담아야 한다. 셋째, 가이드 사용자를 위해 쉽게 탐색할 수 있는 구조로 제작해야 한다는 것입니다.


4. 성공적인 가이드라인 작성 노하우

참고로 말씀드리면, 이번 발표는 대단한 이론을 들고 나온 게 아닙니다. 그동안 실무에서 진행한 다양한 분야의 작업 경험을 바탕으로 '실무 관점의 제작 방향'을 정리한 것입니다.
이 사례 발표의 핵심 내용입니다. 발표자들이 생각하는 'TV 표준 가이드라인 작성 시 고려해야 할 점 3가지는 다음과 같습니다. 바로 Context, Reader, End User입니다. Context는 표준 가이드라인이 작성되는 맥락에 대한 이해가 필요하다는 것입니다. 프로젝트 배경에 대한 이해, 정책 결정 과정에 대한 히스토리 이해, 디바이스 이용 환경에 대한 이해를 말합니다. Reader는 가이드라인 사용자에 대한 배려를 말합니다. 누가 가이드라인을 보고 활용하는지 이해를 해야 하며, 적절한 레벨(너무 추상적이거나 너무 구체적이지 않은 중간 레벨)로 작성되어야 한다는 것입니다. End User는 최종 사용자인 서비스 사용자에 대한 이해입니다. 결국 표준 가이드라인은 서비스 사용자의 행복을 위한 '개발 매뉴얼'입니다. 때문에 End User에 대한 이해를 바탕으로 작성이 되어야 합니다. 사용자 중심의 정책, 인지 심리학적인 이해가 필수적입니다.
상세한 내용은 블로그 하단에 있는 슬라이드를 확인하시기 바랍니다.

학회 발표를 마치며

(발표자 정유리 주임과 김동후 선임의 소감)
프로젝트를 통해 얻은 노하우를 나만의 언어로 가공하여 사람들에게 발표할 수 있었다는 것, 연구 기간 동안 스마트TV에 대해 진지한 고민을 해볼 수 있었다는 것, 많은 관계자들 앞에서 발표를 해보았다는 것 등 많은 것들을 경험할 수 있는 시간이었습니다. 발표 준비 및 발표를 통해 스스로의 역량을 점검해 볼 수 있었고, 성장을 위한 청사진을 그려 볼 수 있는 기회가 되었습니다.


발표 슬라이드


[참고##HCI학회##]

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


Trackback 0 Comment 0
Ad Test...
2012.12.26 07:30

UX 신입 디자이너가 알아야 할 UI디테일 용어 1탄

그리 오래 전은 아니지만 UX라는 분야에 처음 입성했을 때, 머리 속에 가득 찬 아이디어를 우리가 흔히 부르는 Wireframe에 옮기는 데 애를 먹었던 기억이 있습니다. 그림은 대충 그려지는 데 정작 내가 그리고 있는 것이 무엇인지 '정의'를 내릴 수가 없었던 탓이지요. 이처럼 기획자라면 누구나 UI규격서를 설계해 본 적이 있을 것입니다. 이것은 UI기획자와 디자이너 간, 혹은 UI기획자와 개발자 간의 일종의 약속이자 물리적인 결과물입니다. 그렇기 때문에 모든 약속은 명확한 정의가 바탕이 되어야 합니다. 그래야 작업자 간의 원활한 커뮤니케이션을 이끌 수 있으니까요.

이번 포스팅에서는 원활한 커뮤니케이션을 위한 기본적인 조건인 UI컴포넌트 용어를 정리해보려고 합니다. 시리즈의 첫 번째로 가장 기본적인 전통 용어를 정리해보았습니다. (사전에 기재되었거나 각 제조사에서 공식적으로 쓰이고 있는 고유 단어를 기준으로 용어를 선별하였으며, 앨런 쿠퍼의 About Face 서적을 참고로 작성하였습니다.)





드롭다운 리스트 (Drop-down List)
객관식 문제에서 볼 수 있는 선택지와 유사한 개념입니다. 맨 처음 진입 시에는 프로그램에서 지정한 기본값이 보여지다가 화살표 버튼을 누르면 숨어 있던 다른 항목들이 나타납니다. 이 중 특정 항목을 선택하게 되면 기본값이 사용자가 선택한 항목으로 바뀌는데, 이로써 사용자는 자신이 원하는 항목이 선택된 것임을 인지할 수 있습니다. 반면 처음부터 펼쳐진 형태는(즉 드롭다운 하지 않는 형태는) 그냥 리스트 박스라고 부릅니다.



콤보 박스 (Combo Box)
드롭다운 리스트와 입력 필드 기능을 결합(그래서 콤보!)한 형태입니다. 사용자가 직접 정보를 입력하거나 나열된 항목들 중에서 하나의 항목을 선택하여 정보를 입력할 수 있습니다. 흔히 Office Tool에서 개체 혹은 텍스트 속성을 입력할 때 사용됩니다.



라디오 버튼 (Radio Button)
윈도우나 팝업의 선택 영역에서 어느 하나를 선택 또는 취소하기 위해 사용하는 버튼입니다. 일련의 선택 항목 중 단 하나의 항목만 선택할 수 있습니다.



체크 박스 (Check Box)
반면, 또 다른 선택 수단인 체크 박스는 동시에 여러 개를 선택할 때 사용됩니다. 틱 박스(Tick Box)라고도 불립니다. 또한 다중 선택 뿐만 아니라 On/Off 개념으로 사용되기도 하는데요. 라디오 버튼과 체크 박스 이 두 컴포넌트는 모바일 환경에서도 널리 사용되어 사용자에게 매우 친숙한 컨트롤입니다.



토글 (Toggle Button/Switch)
On/Off를 설정할 때 쓰이는 위와 같은 컨트롤을 토글 버튼(위) 혹은 토글 스위치(아래)라고 부릅니다. 토글 버튼의 경우 언뜻 보기에는 버트콘 같지만 선택 시에 음각(눌린) 상태로 변하는데 해당 항목이 실행되고 있음(On)을 의미하며, 다시 누를 시에는 볼록한 원래 상태(Off)로 되돌아옵니다. 토글 스위치는 모바일에서 주로 사용되며 손가락으로 직접 스위치를 좌우로 움직이거나 영역을 선택하여 On/Off 상태를 조절합니다. 이 때, 사용자가 현재 상태를 인지할 수 있는 시각적인 피드백이 반드시 필요합니다.



버트콘 (Butcon) / 툴바 (Tool Bar)
버트콘이란 버튼과 아이콘의 조합으로서 앨런 쿠퍼가 그의 저서 About Face에서 이 용어를 정의하였습니다. 쉽게 말해 버튼 기능이 있는 아이콘입니다. 리본 메뉴, 툴바에 적용되면서 기존 문자 중심의 드롭다운 메뉴를 대체할 강력한 컴포넌트로 자리잡았습니다. 그리고 이러한 버트콘을 사용자의 기호 및 필요에 따라 바(Bar)형태로 모아놓은 것이 툴바입니다. MS에 의해 처음으로 소개된 개념으로 '도구 모음'이라고도 불립니다.



툴팁 (Tooltip)
사용자가 특정한 메뉴에 마우스 롤오버 시 약 1~2초 뒤에 해당 메뉴에 대한 설명이 말풍선 형태로 제공됩니다. 위에 정의한 버트콘은 사용자가 학습하기 전에는 식별이 어려울 수 있다는 치명적인 단점이 있는데, 툴팁은 이 점을 잘 보완할 수 있는 도구입니다.



스피너 (Spinner)
대표적인 숫자 입력 컨트롤입니다. 편집 필드와 우측 옆의 작고 납작한 두 개의 화살표으로 구성되어 있습니다. 현재 필드에 입력된 숫자값을 기준으로 위아래 화살표 버튼을 눌러 조절하거나 혹은 편집 필드에 직접 원하는 숫자값을 입력할 수 있습니다.



다이얼 (Dial)
일전에 pxd에서 주제로 다룬 '스큐어모피즘'의 예라고 볼 수 있는데요. 놉(Knob)이라고도 불리며, 실제 기계의 메타포를 적용시킨 사례입니다. 현실에서는 사용자가 손으로 직접 다이얼을 잡고 좌우측으로 돌려 값을 조절하는데, 컴퓨터에서는 마우스 드래그(Drag) 혹은 클릭(Click)동작으로 대신합니다. 주로 음향을 조절할 때 쓰이기 때문에  Garage band 같은 작곡 응용프로그램에서 많이 쓰입니다.



슬라이더 (Slider)
리얼메타포를 사용하고 있는 또 다른 경우입니다. 콤보 상자의 경우 사용자가 입력 가능한 범위를 모르는 상태에서 입력하는 상황에 처할 수 있는데 반해, 슬라이더는 입력값이 제한되어 있음을 시각적으로 인지할 수 있습니다. 다시 말해 사용자가 부적절한 값을 입력할 가능성이 없기 때문에 상당히 직관적인 컨트롤이라고 할 수 있습니다.



입력 필드 (Text Input Field)
사용자가 키보드로 직접 텍스트를 입력하는 곳으로서 편집 필드 또는 텍스트 상자 등으로도 불립니다. 특정 항목의 속성을 입력할 때 외에도 검색, 정보 입력 등 상황에 따라 각기 다른 목적으로 사용됩니다. 여러 줄을 입력할 수 있을 때는 입력 영역(Text Area)이라고도 부릅니다.



드롭다운 메뉴 (Drop-down Menu)
풀다운 메뉴(Pull-down Menu)라고도 하며, 가장 전형적이고 어디에서나 볼 수 있는 메뉴 스타일입니다. 메뉴의 제목이 표시되어 있는 곳을 선택하면 메뉴가 아래로 펼쳐집니다. 메뉴 내의 항목으로 마우스의 포인터를 옮기면 그에 따라 각 항목이 반전되고, 클릭하면 그 항목이 선택 및 실행됩니다. 약 3년 전부터는 드롭다운 메뉴의 변형인 메가 메뉴(2편에서 소개할 예정)가 널리 활용되고 있습니다.



리본 메뉴 (Ribbon Menu)
기존에 있는 텍스트 기반의 드롭다운 메뉴를 보완하기 위해 MS에서 툴바에 탭을 결합한 형태를 선보입니다. MS Office 2007부터 도입되었는데요. 위 화면에서 알 수 있듯이 눈에 익숙한 버트콘의 조합으로만 이루어져 있거나, 버트콘으로만 식별하기 어려운 메뉴의 경우 버튼에 icon과 메뉴명을 함께 표기하고 있습니다. 드롭다운 메뉴에만 익숙했던 사용자는 이러한 리본 메뉴를 처음 접할 시에 매우 당황하지만 지속적인 사용 과정을 거침으로써 반복적이고 자주 접근하는 메뉴를 자연스럽게 사용할 수 있게 됩니다. 이처럼 시각적인 요소를 보완하여 드롭다운 메뉴보다 직접적인 장점이 있지만 모든 메뉴를 풀어놓기 때문에 복잡해보이는 단점도 있습니다. 결국 한글 오피스에서는 드롭다운 메뉴와 리본 메뉴를 모두 제공하는 다소 부자연스러운 해결책을 내놓고 있는데, 이처럼 리본 메뉴는 앞으로도 개선될 여지가 있다고 봅니다.



트리 메뉴 (Tree Menu)
목록의 보기 방식 중 하나로서 계층 구조를 표시하는 데 유용합니다. 윈도우 탐색기에서 대표적으로 쓰이고 있습니다.



GNB (Global Navigation Bar)
웹페이지에 표시되는 하이퍼링크들의 집합 영역을 말합니다. 쉽게 말해 웹사이트에서 항상 표시되는 메뉴로서 탑 메뉴, 메인 메뉴라고도 불립니다. 주로 웹사이트의 상단 혹은 좌측에 고정으로 위치하며 바(Bar), 탭(Tab), 드롭다운 메뉴 등의 메뉴 형태로 제공됩니다.

LNB (Local Navigation Bar)
서브 메뉴라고 불리며 웹사이트의 좌측에 주로 위치합니다. 위치는 고정되어 제공되나 항목은 진입하는 메뉴에 따라 다르게 제공됩니다.




대화 상자 (Dialog Box)
사용자의 지시 사항이나 어떤 사항에 대한 결정을 묻기 위해 사용자가 하던 일을 잠시 멈추게 하는 창을 말합니다. 우리에게는 팝업(Pop-up)이라는 용어가 보다 익숙한데요, 대화 상자라고 부르는 이유는 말 그대로 컴퓨터와 사용자 사이에 대화를 제공하기 때문입니다. 대화 상자는 목적에 따라 다양한 형태로 호출됩니다. 크게 오류 등 공지가 필요한 경우, 사용자가 선택한 대상의 속성을 지정하는 경우, 작업의 진행 상황을 알리는 경우, 사용자가 선택한 사항을 재 확인하는 경우 등으로 나뉠 수 있습니다.



여기까지 기본적으로 알아야 할 컨트롤을 정리해보았습니다. 다음 포스팅에서는 앞서 정의한 컨트롤을 바탕으로 응용된 개념 및 새롭게 추가된 컨트롤에 대해 알아보도록 하겠습니다.

[참고: 안드로이드 디자인 가이드 http://klutzy.github.com/android-design-ko/]

[참고##가이드라인##]
[참고##UI 용어##]

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


Trackback 1 Comment 14
Ad Test...
2012.02.17 13:36

안드로이드 디자인 : Android 4.0 ICS 디자인 가이드

구글이 안드로이드 아이스크림 샌드위치(Ice Cream Sandwich) 스타일 가이드인 <Android Design(안드로이드 디자인)>을 공개했습니다. 안드로이드 운영체제를 탑재한 스마트폰/태블릿 모두에 최적화된 애플리케이션과 사용자 인터페이스를 만드는 데 도움을 주는 가이드라고 소개하고 있습니다. 

안드로이드 디자인 가이드(영문) : http://developer.android.com/design/index.html  
안드로이드 디자인 가이드(한글 번역) :  http://klutzy.github.com/android-design-ko/

디자인 가이드는 다음과 같은 세 가지에 초점을 맞추고 있습니다.

- Style (devices and displays, themes, typography, color, writing style etc.)


- Patterns (navigation, selection, notifications, swipe views, compatibility etc.)


- Building Blocks (text fields, scrolling, buttons, dialogues, tabs, lists etc.)


디자인 가이드에서 제공하는 것들은 권장사항 입니다. 그러나 다양해지는 디스플레이 크기나 하드웨어 성능의 차이, 그리고 안드로이드의 일관된 사용자 경험을 고려할 때 기획자, 디자이너, 개발자가 한번 쯤은 꼼꼼히 읽고 숙지해야 할 것 같습니다. 
(또한, 안드로이드 디자인 가이드는 정기적으로 업데이트 될 것이라고 합니다.)


참고
2011/09/06 [Mobile] 안드로이드 위젯 기획시 고려사항
2011/07/15 사용자의 80%만을 위해 디자인하라 - Apple Human Interface Guidelines의 역사
2010/11/17 안드로이드 체크박스 디자인 fail
2010/10/29 미투데이의 Family UI 비교 – 웹, iOS 앱, 안드로이드 앱을 중심으로
2010/08/26 Android의 BACK 버튼과 HOME버튼을 이용한 내비게이션 룰
2010/06/28 안드로이드 UI/GUI 가이드라인
2010/03/27 안드로이드 시대에서 폰 제조사들의 차별화 전략?

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


Trackback 1 Comment 1
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...
2011.07.31 22:40

그들만의 리그, 우울한 ISO UI 표준 – ISO 13407 & ISO 9241의 역사

그리 쉽지는 않지만, 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. 왜 어떤 가이드라인은 실패하는가? - 말보다 행동이 중요하다


3. 그들만의 리그, 우울한 ISO UI 표준 – ISO 13407 & ISO 9241의 역사
많은 종류의 표준을 만들어내고 있는 국제 표준화 기구(ISO)는 스위스에 본부를 둔 국제 기구로 많은 UI 국제 표준도 만들어 낸다. UI 관련 표준은 여러개가 있는데, 가장 대표적인 것이 1997년에 발표된 ISO 9241이다.

ISO 9241 (1997)

ISO 9241은 전산 장비 등의 소프트웨어/하드웨어에서 Ergonomics 측면으로 필요한 부분을 정의하고 있다.
이들 중에서 특히 소프트웨어 파트는 ISO-9241-10 에서부터 ISO-9241-17까지인데,

* Principles for human-computer dialogues (ISO 9241-10)
* The relevance of the context of use (users, tasks, environment) and the definition of usability in terms of effectiveness, efficiency and satisfaction (ISO 9241-11)
* Characteristics of presented information and recommendations for the presentation of information (ISO 9241-12)
* Recommendations for user guidance; these apply to all dialogue techniques (ISO 9241-13)
* Recommendations for the usage of dialogue techniques (Menu, Command, Direct Manipulation, Form-Filling) (ISO 9241-14 to ISO 9241-17)

이렇게 요약해 볼 수 있다. (출처 ISO9241 2001년판)

예를 들어, ISO 9241-11 (1998년판,사진)에서는 ‘사용성’을 다음과 같이 정의하고 있다.

Usability: Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

만약 누군가 ‘사용성’에 대해 국제적으로, 학술적으로 매우 정확하게 언급하고 싶다면 위의 정의를 반드시 기억하고 인용해야할 것이다. 특히 초보 UI 디자이너라면, 위 정의 문장의 한 단어 한 단어를 곱씹어 생각해 볼 필요가 있다. 이미 수십년 전의 정의에서조차도 ‘Usability’를 정의할 때, 반드시 ‘specified context’와 ‘specified users’에 따른 ‘specified goals’를 지정한다. (문서는 계속하여 저 정의에 사용된 모든 단어를 다시 하나씩 정의해 나간다)

ISO 9241 초기 시리즈를 다 읽을 수 없다면 10-17까지 모두를 총괄하는 ISO 9241-11을 꼭 읽어봐야 한다. (이 시리즈에 대한 요약과 각 파트의 역할에 관하여는 2001년 개정판에 매우 상세하게 나와있다)

이 시리즈 전체를 살펴보는 문서로는 User Focus의 David Travis가 2003년에 처음 쓴 Bluffers’ Guide to ISO 9241 (http://www.userfocus.co.uk/articles/ISO9241.html)가 있다.


ISO 13407 (1999)

ISO 13407은 1999년 6월 1일 발표(사진)되었다.
ISO 13407에서는 usability라든지 하는 주요 용어의 정의를 모두 ISO 9241-11로부터 가져오고 있다. 이 문서에서는 크게 4가지를 제시한다.

4. Human-Centered Design Process를 적용해야 하는 이유
5. Human-Centered Design의 원칙
6. Human-Centered Design 계획법
7. Human-Centered Design 활동들(activities)

Human-centered process를 적용해야하는 이유는 그것이 쉽고, 비용이 덜 들고, 사용자에게 만족감과 생산성을 높여준다는 것이다. 그리고, 일반적인 Human-centered design 원칙을 제시하고 있는데, 가장 핵심적인 것으로, a) 사용자의 참여 혹은 사용자와 작업에 대한 명확한 이해 b) 사용자와 기술에 대한 균형 c)디자인 해법의 반복적용 d)여러 분야의 참여 이렇게 4가지를 들고 있다.

아울러, 프로젝트 계획법에 대해 설명하고, 각 단계에서 어떤 일을 해야하는가(Human-centered design activities)에 대하여 자세히 설명한다.
a) 먼저 사용 환경에 대하여 구체적으로 한정하고 이를 잘 이해하는 활동
b) 사용자와 문제를 해결하려는 주체를 특정하는 일
c) 디자인 해법은 어떻게 만들어야 하는가,
그리고 d) 어떻게 평가해야 하는가 등에 대해 설명하고 있다.


ISO 9241-210 (2010)

작년에 ISO에서는 ISO 13407을 폐기하고 그 대신 ISO 9241-210(사진)을 발표하였다.

이 문서에서 정의하는 'user experience' 란 이렇다.
"person's perceptions and responses resulting from the use and/or anticipated use of a product, system or service"

물론 여기에 추가하여, 사용자의 감정,신념등과 연결되어 있으며, 브랜드에서부터 성능까지 많은 부분이 관여된다는 노트를 1,2,3으로 나누어 붙여 설명하고 있다.

13407을 계승하여 Human-centered design의 원칙을 6개로 확장하였는데,
a) The design is based upon an explicit understanding of users, tasks and environments.
b) Users are involved throughout design and development.
c) The design is driven and refined by user-centered evaluation.
d) The process is iterative.
e) The design addresses the whole user experience.
f) The design team includes multidisciplinary skills and perspectives.
이렇게 좀 더 나누어 설명하고 있다.

먼저 가장 기초적으로 이해해야하는 것이, 사용자, 그리고 목표나 할 일(task) 마지막으로 환경 혹은 context라고 이야기할 수 있는 것들이 이 세 가지는 사람에 따라 여러가지 다른 말로 표현될 수 있겠으나 누구라도 중요하게 꼽는 세 가지라고 볼 수 있다.
두 번째에서는 사용자의 ‘참여’를 전제로 하는데 반드시 진짜 사용자가 매 디자인 과정마다 참여해야한다는 뜻이라기 보단, 모든 과정에서 사용자를 고민해야한다는 뜻으로 보면 좋을 것 같다. (실제 참여는 프로젝트마다 다르다고 써있다) 이런 식으로 6개의 원칙을 설명하고 있다. 특히 e)에서 전체 experience를 강조한다.
그 후에 문서에서는 전형적인 Human-Centered Design Process에 대해서 설명한 뒤, 지속 가능성에 대하여 짧게 언급한 뒤 결론을 맺는다.

왜 널리 활용되고 있지 않을까?
사용자 인터페이스 디자인에 있어서 표준이 중요한데 왜 ISO 규정들은 널리 활용되지 않을까? 그건 아마 문서가 너무 많고 비싸기 때문일 것이다.

여기 소개한 것 말고도 UI 관련 백여개의 ISO가 있다.
예를 들어 ISO 9241이 다른 파트도 많은데, part 151에서는 사용하기 쉬운 웹사이트란 어떤 것이가에 대해 정의하고 있고, ISO 15938 Information technology -- Multimedia content description interface, ISO/TR 16982:2002, Ergonomics of human-system interaction,  Usability methods supporting human-centered design 등 다른 시리즈의 문서들도 많다.
자세한 것은 David Travis의 Guide 참고바란다. (http://www.userfocus.co.uk/articles/ISO9241.html 9파운드에 판매하는데, 내용을 미리 좀 보고 싶으면 샘플페이지와 2005년도 판을 참고하면 된다.) 이렇게 많은 걸 언제 다 본단 말인가?

ISO가 보급이 더딘 또 다른 이유는 너무 비싸기 때문인 것 같다. 예를 들어 ISO 9241-210 (즉 하나의 파트) 가격이 16만원이 넘는다. 몇 개만 둘러보려해도 수백만원이 금방 넘는다. 이러한 국제 기구 운영 예산의 상당 부분이 표준 문서 판매에 의존하고 있기 때문인 것 같은데, 널리 퍼트려야할 표준 문서를 이렇게 비싸게 판매한다는 것은 명백한 자기 모순이기 때문이다. ISO에 참여하는 회원 협회들의 자국 정부 지원을 통해 해결하는 것이 바람직하지 않을까 생각한다.

ISO구입은 ISO(http://www.iso.org/) 혹은 한국표준협회(http://www.kssn.net/)에서 할 수 있다.


결론
ISO의 여러 부당함에도 불구하고 어쨌든, ISO의 권위는 무시할 수 없는 것이고, 누군가 표준적인 정의에서 출발하고 싶다면, ISO를 찾아보지 않을 수 없다. 또한 UI를 공부하는 사람들이라면 세계의 많은 사람들이 모여 짧은 문장으로 정의하고자 수많은 시간과 토론을 거듭한 이 문서에서 많은 것을 얻을 수 있을 것이다.

이 글에서 소개한 여러 문서 중에서 딱 하나만 읽을 시간이 있다면 당연히 ISO 9241-210을 읽어야 한다.

마지막으로 글을 쓰는데 도움을 주신 연세대 권오성 교수께 감사드린다.

다음 글에서는 "4. 왜 어떤 가이드라인은 실패하는가? – 말보다 행동이 중요하다"에 대해 살펴본다.

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

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


Trackback 1 Comment 0
Ad Test...
2011.07.27 14:28

마침내 혼란을 극복한 Windows 7 - Windows User Experience Interaction Guidelines의 역사

그리 쉽지는 않지만, 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. 왜 어떤 가이드라인은 실패하는가? – 말보다 행동이 중요하다



2. 마침내 혼란을 극복한 Windows 7 - Windows User Experience Interaction Guidelines의 역사
필자가 마이크로소프트에 근무한 것은 아니어서 정확하게 알 수는 없으나 여러 문헌과 검색의 힘을 빌어보면, 대략 다음과 같은 역사를 재구성해 볼 수 있다. (인터넷 자료를 참고하였다. 특히 Windows의 역사는 위키피디아에 전적으로 의존하였다.)

Windows 1.0은 1985년 11월 20일에 출시되었다고 한다. 그러나 1987년 12월 9일에 출시된 2.0과  함께 그리 많이 사용되지는 못 한 듯 하다. 첫 번째의 성공은 아무래도 1990년에 나온 3.0 그리고 1992년 3월에 출시된 Windows 3.1 이라고 할 수 있다.


1. Windows 3.1

검색으로 알려진 바에 의하면 1987년에 처음 출판되었다고 하는
The Windows Interface: An Application Design Guide (Microsoft programming series)
 
이 책은 아마존에서 1992년 4월 판을 찾을 수 있다. (피엑스디 도서관 보유) 이 책은 주로 Windows 3.1 을 대상으로 하고 있다. PDF 버전은 현재 찾을 수가 없다.
이 책에서 제시하는 UI 디자인의 원칙은, User Control, Directness, Consistency, Clarity, Aesthetics, Feedback, Forgiveness, Awareness of Human Strengths and Limitatioins 등 8가지이다.

역시 이 글을 쓰게된 시작이기도 한데, 이 책의 p136에 보면 왜 'OK'와 'Cancel'이 이렇게 배열되게 된 것인지에 대한 이유가 나온다. 그리고 다이알로그의 맨 마지막에 'Help'버튼을 위치시키라는 이유까지 한 페이지를 할애하여 설명하고 있다. 이 부분에 대하여는 따로 글을 쓰기로 한다.

2. Windows 95
그리고 그 다음 나온 것이
The Windows Interface Guidelines for Software Design

이 책은 1994년 1월 1일에 2판이 나온 것으로 아마존에서 찾을 수 있다. 정식 출시 1년 전에 2판이라니 잘 이해가 안 되지만 개발자용 프리릴리즈였을 수도 있고, 아마존의 오류일 수도 있겠다.(Windows 95는 1995년 8월 24일 정식 출시 되었다) 피엑스디 도서관은 1995년판을 보유하고 있다.
이 책은 주로 Windows 95에 대하여 설명하고 있다. 이전 버전과의 가장 큰 차이점으로 이 책에서는 OLE의 도입과 함께 ‘object oriented’ 즉 ‘application-centered’가 아니라 ‘data-centered interface’가 되었다는 것을 강조하고 있다. 어플리케이션을 만드는 프로그래머와 디자이너들에게 자신들이 만드는 프로그램을 다시 생각해보라고 강력하고 권고한다.
드래프트였던 것으로 보이긴 하지만 아쉬우나마 PDF를 찾을 수 있다.

'User Centered Design Principles'가 7가지 (User in Control, Directness, Consistency, Forgiveness, Feedback, Aesthetics, Simplicity)로 줄어들었다. Clarity가 Simplicity라는 말로 대체되었고, 인간의 장점과 한계에 대해 잘 알아야 한다는 (너무 포괄적이고 당연한) 원칙은 삭제되었다.

3. Windows 98 & 2000
Microsoft Windows User Experience (Microsoft Professional Editions)

이 책은 1999년 10월 8일에 출판된 것으로 아마존에서 찾을 수 있다. 이 책은 주로 Windows 2000과 Windows 98을 다루고 있다.(피엑스디 도서관 소유) Windows 98은 1998년 6월 25일에 정식 출시 되었고, Windows 2000은 2000년 2월에 출시하였다. Windows 2000 정식 출시 전에 책이 출판된 것은 개발자를 위한 사전 버전이 나왔기 때문일 것으로 짐작한다.
PDF 버전이 약간 이상하긴 하지만 있는 것 같다.

아마도 가장 많은 사람들이 기억하는 책일 것 같고, 피엑스디에서도 가장 열심히 스터디한 버전인 듯 하다. 'User Experience'라는 말을 처음 사용한 가이드라인이고, 책 곳곳에 'Experience'를 강조한 책이기도 하다. 디자인 원칙은 앞의 7개를 여전히 유지하고 있다.



4. Windows 2000 & Me & XP & Vista
Windows User Experience Guidelines for Windows XP and Windows 2000

이 시점부터는 더 이상 출판하지 않은 것으로 보인다. 위 문서는 2007년 판이다. 제목에는 2000과 XP라고 되어 있으나, 현 시점에서 다운로드 받을 수 있는 2007년판 최종본PDF은 2006년에 출시된 Vista에 맞추어져 있어서, 내부 차례를 보면 ‘Windows Vista User Experience Guidelines’라고 되어 있는 것을 확인할 수 있다. Windows Me는 2000년 9월에, Windows XP는 2001년에, Vista는 2006년 11월 30일에 각각 출시되었다.




5. Windows Vista
Windows Vista UX Guide

Vista가 정식 출시되기 전에 이와 같은 형식으로 UX Guide를 사전 배포하기도 하였다. 그림은 2006년 12월 4일에 최종 수정된 Vista UX Guide이다.
 







6. Windows 7 & Vista
Windows User Experience Interaction Guidelines (UX Guide) for Windows 7 and Windows Vista

이 문서는 지금도 계속 수정되고 있는데, 이 글을 쓰는 2011년 6월 현재, 2010년 10월에 마지막 수정을 한 것으로 나와 있다. Windows 7은 2009년 7월 22일에 출시되었다.

PDF를 다운로드 받을 수도 있고, 웹에서 직접 보려면 msdn에서 가능하다.

개인적으로 다른 건 못 보더라도 Windows 7의 가이드라인과 제작 과정에 대한 비디오는 꼭 보길 바란다. 만약 시간이 없다면, 왜 Design Principle이 중요하고, Windows 7은 어떤 Design Principle을 가지고 있는지 강조한 비디오만이라도 꼭 보길 권한다.

Windows 7 Design Principles (http://story.pxd.co.kr/13)

마이크로소프트가 그간 Windows UI/GUI에 대한 조소와 비아냥(특히 Vista)을 들으며 절치부심한 탓인지 엄청난 질적인 진보가 느껴지기 때문이기도 하지만, 이 시대에 UI를 하면서 사람들에게 가장 영향을 많이 미치는 Windows 와 iOS 의 UI Guideline을 안 읽어 봤다는 것이 모순이기 때문이기도 하다.

다음 글에서는 "3. 그들만의 리그, 우울한 ISO UI 표준 – ISO 13407 & ISO 9241의 역사"에 대해서 살펴본다.


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

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


Trackback 0 Comment 2
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.02.27 13:06

사용자의 목소리로부터 보다 효과적으로 정보를 얻는 방법

현재 진행중인 프로젝트의 간략한 사용성 테스트와 인터뷰를 하기전에 프로젝트 멤버들이 숙지하면 좋을 것 같아서 읽어보다가 공유합니다. 원문 링크를 걸고 간단히 요약을 올리려 했는데 결국 거의 번역이 되었네요. 기존의 사용자 인터뷰 경험이 있는 분들이라면 주옥과 같이 와닿을 수 있는 내용입니다.




원문:
When Observing Users is not Enough
: 10 Guidelines for Getting More Out of Users' Verbal Comments

by Isabelle Peyrichoux


사용자 관찰로는 부족하다고 느낄 때 
: 사용자의 목소리로부터 보다 많은 것을 얻어낼 수 있는 10가지 방법

사용성 테스트를 통하여 사용자들에게 단순하게 이 제품이 사용하기 편한지 질문하는 것보다 사용자들이 실제로 사용할 수 있는지를 관찰하는 것이 더 신뢰도 높은 정보를 얻을 수 있다고 한다. 그러나 관찰하는 것만으로는 어떻게 디자인해야 하는지에 대한 정보를 얻기에는 여전히 부족하다.
관찰에만 의존하는 방법은 다음과 같은 문제점이 있다.

-제한된 정보로 인해 잘못된 결과를 유도할 수 있다.
(왜냐면 관찰된 사용자의 행동은 해석이 다양할 수 있기 때문이다. 사용자가 링크를 클릭하지 못한 것이 못 본 것인지, 링크를 이해하지 못해서인지 정확한 이유는 사용자의 설명을  듣기 전에는 알 수 없기 때문이다)

반대로 사용자의 목소리에 의존하는 방법에 대하여 몇몇 전문가들은 우려를 나타내기도 하는데, 이를 극복하기 위해서는 객관적인 과학(objective science)의 영역에서 인간관계와 공감의 영역(human relationships and empathy)으로 초점을 옮겨야 한다.

사용자 인터뷰(테스트와 관찰의 과정에서 발생하는 부분을 포함하여)는 인터뷰어(조사자)와 인터뷰이(사용자)간의 relationship이며 여기에는 감정, 두려움, 판단 등이 작용한다. 심리치료에서 활용되는 방법과 훈련 등은 사용자의 목소리를 추출하고 해석하는 과정에서의 편견을 피하거나 최소화 하는데 도움이 되고 인터뷰 기법을 보다 풍부하게 해줄 수 있다.

이 글을 쓰는데 참고가 되는 이론들...(각 항목에 대한 링크는 원문참조)

-Carl Rogers's humanist approaches
: the person-centered approach of Carl Rogers
:Colette Portelance's creative non-directive approach to psychotherapy

-Carl Jung's theories
: psychological types and the Myers-Briggs Type Indicator(MBTI)
: shadow of the personality

사용자의 목소리로부터 보다 효과적인 정보를 얻기위해 다음 10개의 가이드라인을 소개한다. 
이러한 기법들은 인터뷰어가 사용자에 대해서 진실한 공감을 가지고 있을 때 가장 효과적이다. 사용자가 보기에 인터뷰어가 진실하지 않다고 느껴진다면 이러한 기법들은 별로 소용이 없을 것이다.   


1.관찰자의 사적인 판단(judgments)과 '투사'(projection)을 주의하라.
사용성 테스트 과정에서 사적인 판단을 피하라는 말은 쉽게 할 수 있지만 실제로 그렇게 하기는 어렵다. 인터뷰어가 효과적으로 과정에 '개입'하면서도, 사용자가 자유롭고 솔직하게 그리고 편안하게 이야기하기를 원한다면 인터뷰어의 사적인 판단이 들어가면 안된다.

다음과 같이 말하는 것을 주의하라.

-인터뷰어: "좋아요!" "훌륭합니다" 
(혹은 사용자의 대답에 따라 긍정적인 반응-답을 맞혔다는 듯한-을 해주는 것을 주의하라....이와 같은 인터뷰어의 판단하는 듯한 말은 사용자의 행동이 좋거나 혹은 나쁠 수 있다는 것을 암시하게 된다)

이럴땐, 상황에 따라 이렇게 대답해주자.
-인터뷰어: "그렇군요" "알겠습니다" 등등...

사용자 인터뷰를 하다보면 다양한 사람들을 만나게 되고, 그 중에는 인터뷰어의 개인적 특질과 잘 맞지 않는 사용자들도 있게 마련이다. 이러한 사용자들을 인터뷰어가 불편해 하는 것은 당연한 현상(이것을 '융의 그림자이론에서는 투사(projection)라고 한다)이긴 하지만 최선의 결과를 위해서는 이를 극복해야 한다.

각각의 사용자에 대하여 인터뷰어 자신의 느낌을 관찰해보고 걱정되는 점들, 느낌들을 적어보자. 그리고 이것들이 인터뷰어의 개인적 특질과 맞지 않아서 발생된 것인지 살펴보고 이를 극복하고 사용자에게 공감(empathy)을 가지려고 노력하면 보다 좋아질 것이다.

이것이 이 글에서 말하는 다른 모든 항목보다 적용하기가 어려우면서도 중요하다.


2.진정성과 투명성을 가져라
인터뷰어의 태도가 진실하고 오픈되어 있다면 사용자들도 편안함을 느끼게 되고 솔직해질 것이다. 진행상황에 있어서 문제가 있다면 이것을 솔직하게 이야기하자. 문제가 있음에도 불구하고 문제가 없는척 하지 말라.

-인터뷰 과정에서 어느순간 인터뷰어가 프로젝트의 다른 부분들, 혹은 챙겨야 할 것들 때문에 사용자에게 집중하지 못했다면....이를 솔직하게 시인하고 "제가 잠시 다른 생각을 하느라 못들었는데 다시 말씀해주시겠어요?"라고 요청한다.
-인터뷰 중간에 다른 과정으로 건너뛰고 싶거나 간략한 반응만 확인하고 빠르게 넘어가고 싶다면....사용자들에게도 이를 알려주도록 한다.


3.개개인의 사용자에게 맞춰라, 사용자를 인터뷰어에게 맞추도록 요구하지 마라.
인터뷰어는 자기도 모르게 사용자들이 자신의 방식에 맞추길 기대하게 된다. 인터뷰 후에 다음과 같이 말한 경험들이 있을 것이다.

"이번 사용자는 좀 별로였어" (사용자가 너무 소심한 타입이어서 잘 말해주지 않았다거나, 너무 수다스러워서 진실을 알기 어려웠다거나...)

인터뷰에서 좋은 데이터를 얻기까지의 노력은 사용자의 특성에 따라 다를 수 있겠지만, 좋은 결과를 위해서는 사용자의 개인적 특질과 리듬에 맞추도록 최선을 다해야 한다.
(예를 들어 인터뷰 도중 질문에 대해 사용자가 짧게 말한 후 침묵을 지키고 있을때, 인터뷰어는 사용자의 대답이 끝난줄 알고 다음 질문으로 넘어갔다가 뒤늦게 사용자가 이전 질문에 대한 추가적인 답변을 하는 경우가 있다. 이 사용자는 침묵하는 동안 더 자세한 대답을 고민하고 있었던 것이었지만, 인터뷰어는 그 '침묵'에 대해 사용자가 '더이상 대답할 것이 없음'으로 자기방식으로 판단해버린 것이다. 이러한 시행착오를 거쳤다면 이후의 인터뷰 과정에서는 그 사용자에 한하여 대답을 할 수 있는 시간을 더 할애하는 방식으로 보완하여 진행을 해야 한다)

'융'의 심리학적 성격이론과 MBTI 에서 말하는 내향적(introvert-말하고 싶은 것을 마음속으로 먼저 정리하는 경향이 있다)인 성격과 외향적(extrovert-생각과 동시에 말을 하는 경향이 있다)성격에 따라 인터뷰의 진행방식이 달라질 수 있다.

중요한 것은 사용자의 행동을 인터뷰어가 임의판단 하지 않아야 하고 객관적이어야 한다는 것이다. 인터뷰의 초반 몇 질문을 통해 사용자의 리듬과 특성을 파악하고 이에 따라 나머지 인터뷰를 진행하도록 하라.


4.사용자가 인터뷰어와 인터랙션 하는 방식을 주의깊게 살필 것
사용자들은 인터뷰어가 조심스럽게 설명하고 안심시켜도 자신이 '테스트 받고 있다'고 느끼기 때문에 '잘못된 대답'을 할까봐 두려워한다. 또 인터뷰어를 의식하여 자신의'좋은 인상'을 주려고 자꾸 신경을 쓰는 경우가 있다. (예를 들면 질문에 너무 강하게 과장된 대답을 한다거나 자신이 잘 하고 있는지 자꾸 확인하려 한다거나...하는 태도로 판단할 수 있다) 이러한 경우에는 사용자가 거짓을 말하는지 판단을 해야하고 사용자의 의견을 해석할 때 감안해야 한다.


5.사용자들이 자신들의 경험을 말하게 하라.
사용자들은  자기 자신의 느낌에 대해 솔직히 말하기 보다는 다른 사람들의 경험을 예측하여 이야기함으로써 '일반적인 대답'을 대신하려는 경향이 있다. (남에 대해 이야기함으로써 체면을 좀 덜 구길 것 같은 포지션을 취하려 하기 때문이다)
이럴땐 사용자가 일반적인 의견을 재구성하도록 하지 말고 자신의 의견을 이야기 한 부분으로 돌아가 이야기를 다시 풀어나가도록 한다.

-사용자 : "저는 괜찮은데 우리 엄마는 어려워할 것 같아요."
-인터뷰어: "당신에겐 이게 괜찮군요!"
-사용자 : "네 그래요, 왜냐하면...."
(성공!)


6.사용자들이 자신의 의견을 '자가검열'하는지 주의하라.
사용자를 주의깊게 관찰하여 사용자가 인터뷰어를 '기쁘게 해주기 위해'노력하는지 파악해야 한다. 이런 경우 사용자는 앞뒤가 안맞는 의견을 주게된다. 어떤 제품에 대해 좀 전에는 좋다고 했다가 또 불편하다고 했다가....즉 부정적인 의견을 말하고나면 인터뷰어가 맘 상할까봐 다시 괜찮다고 말하는 것이다.

이러한 경우 사용자의 진짜 의견이라고 생각되는 부분을 놓치지 말아야 하고 이곳에서 다시 질문을 시작해야 한다.

-인터뷰어: "이 웹사이트의 전체적인 인상이 어떻습니까?" 
-사용자: "매우 복잡한 것 같습니다. 그런데....아마도 이 분야에 익숙한 사람들이라면 괜찮을것도 같습니다. 네...괜찮을 거예요."
-인터뷰어: "아, 첫인상은 좀 복잡했었다구요?"
-사용자: "네 복잡했어요. 왜냐면..." 
(성공!)


7.사용자들이 해결책이 아닌 문제점을 이야기하도록 하라.
사용자들은 디자이너가 아니다. '문제의 해결'보다는 '문제의 규명'에 초점을 두어야 한다. 즉 문제가 발생했을때 이에 대한 해결책을 성급히 내려고 하지 말고 사용자와 함께 문제를 깊이 탐색해야 한다. 그러다보면 사용자 스스로 매우 좋은 솔루션을 발견할 수도 있다.

'문제발견' -> '문제 규명을 위한 적절한 추가질문'....이 구조를 기억하자. 예를 들면...

-사용자: "이 레이블은 잘못됐어요"
-인터뷰어: "왜 잘못됐다고 생각하죠?"
("그럼 어때야 한다고 생각하죠?" 라고 묻지 말자. 이러한 질문은 사용자로 하여금 솔루션을 고민하게 만든다)
(일단 문제를 이해했다면 상황에 따라 적절한 추가 질문을 하자, 다음과 같이...)
-인터뷰어: "어떤걸 기대했었나요? 혹시 맘속에 떠오른 레이블이 있었나요?"

예문 하나 더.
-사용자: "이 페이지는 좀 바보같아요, 별로네요."
-인터뷰어: "왜 별로라고 생각하세요?"
("어떻게 하면 좋아질까요?" 라고 묻지 말자)


8.'왜?'라고 물어보면서 더 깊이 파들어갈 것
사용자 인터뷰와 테스트를 통하여 다음과 같은 결론을 얻었다면, 문제해결을 통한 제대로된 디자인을 할 수 있을 만큼 충분한 정보를 얻지 못한 것이다.

-사용자들은 이전 버전의 제품을 더 선호한다
-사용자들은 레이블의 의미를 이해하지 못한다
-사용자들은 그 링크를 클릭하지 않는다
....

인터뷰를 통하여 사용자들이 왜 그렇게 하는지 이해하고 이유를 설명할 수 있을 때까지 파고들어야 한다!(어느정도 깊이로 파고들 것인지의 판단 기준). Indi Young도 "Why?"라고 물어보는 것의 중요성을 지적한 바 있다. 더이상 나올 것이 없을 때까지 파고들어야 한다, 부족한 것보다 남는 것이 낫다.

경험이 부족한 인터뷰어의 경우 필요한 정보를 충분히 얻기가 어렵겠지만 시행착오가 필요하다.


9.객관적이고 정확한 관찰을 할 것
사용자의 행동과 말을 잘못 해석하지 않을 수 있는 단순하면서도 강력한 툴이다. 

예를 들면...
(사용자가 아무것도 안하고 스크린의 한 부분을 바라보고 있었다면...'객관적이고 정확한 관찰'을 통하여 다음과 같이 말하자.)

-인터뷰어: "스크린의 이 부분을 한동안 쳐다보신 것 같습니다."
("망설이고 계시는군요"라는 식으로 말하지 말자. 그렇게 판단하는 것은 인터뷰어의 주관적인 판단이다.)
-사용자: "아, 네. 왜냐면...."
(성공!)

또 다른 예로는....
사용자가 웹페이지를 보면서 미소지었다면...다양한 의미가 있을 수 있고, 흥미로운 단서를 포함하고 있을 수도 있지만, 이에 대해 그냥 치나치면 아무것도 얻을 수 없을 것이다.

-인터뷰어: "미소짓고 계시네요...?" (객관적인 관찰)
-사용자: "네, 왜냐면 이 페이지의 이미지가 맘에 들어서요..." (관찰된 행동의 이유에 대한 사용자의 설명)

'객관적이고 정확한 관찰 기법'은 사용자가 침묵하거나, 비언어적인 표현을 하거나, 내비게이션 패턴 등 관찰된 것이 무엇이건 간에 보다 잘 이해할 수 있는 툴이다. 


10.사용자들이 자발적인 태도를 유지하도록 하고, 사용자의 행동의 흐름을 자연스럽게 따를 수 있게 하라.
사용자 테스트 과정에서 자발적인 반응일수록 그 신뢰도는 더 높다. 다음을 기억하자.
-사용자들이 테스트의 범위를 너무 벗어나지 않는다면 잠시동안 침묵을 하거나 생각할 시간을 갖더라도 방해하지 않도록 한다.
(때로는 인터뷰어 입장에서는 이것을 참아내기 어려울 수도 있다. 그러나 내향적인 사용자인 경우 마음속에 있는 말을 하기까지 준비시간이 필요할 수 있고 그것이 중요한 정보일 수도 있다!)

-미리 준비한 질문순서와 상관없이 항상 사용자의 자연스러운 흐름을 따르도록 한다.

-처음부터 바로 질문으로 바로 들어가기 보다는 사용자의 자발적인 반응에 따른 이야기를 하도록 한다.
(사용자가 테스트할 웹페이지를 보기 시작했다면 바로 질문에 들어가기 보다는 먼저 사용자의 자연스러운 반응이 나오도록 기다릴 필요가 있다)

-의도치 않게 사용자의 흐름이 방해받거나 끊겼다면, 사용자의 자발적인 언급의 시점으로 돌아오도록 하라.
("좀 전에 말씀하셨던 게...."라고 말하면서 흐름이 끊겼던 순간으로 되돌아 갈 수 있다)


결론
-사용성테스트(인터뷰와 테스트를 포함)는 인터뷰어와 사용자 두 사람 간의 relationship이 중요하다. 즉 인터뷰어가 사용자와 상호소통하는 방식이 테스트 결과에 지대한 영향을 미친다.
-신뢰(confidence)와 공감(empathy)을 형성해야 한다.
-사용자의 개성(personality)과 리듬에 맞추도록 하고, 사용자가 자기 자신의 경험과 그 뒤에 감추어진 이유를 이야기하도록 하여 깊이를 더해가도록 하고, 사용자의 흐름을 따르도록 해야 한다. 

-Eye tracking 연구를 할 때에도 사용자의 행동을 제대로 해석하기 위해서는 '항상' 사용자의 목소리를 들어야 한다. (스크린 상의 특정 단어에 핫스팟이 형성되더라도 이것이 흥미로와서인지, 혼란스러워서인지 혹은 놀라워서인지 해석이 다를 수 있기 때문이다)

-그렇다고 사용자의 목소리에 너무 의존하는 것은 위험이 따른다. 대부분의 태스크를 실패하고도 그 웹사이트가 좋다고 말할 수도 있다)

-성공적인 사용성테스트는 관찰된 결과와 사용자의 목소리가 올바르게 조합이 될 때 가능하다. 관찰데이터와 사용자 목소리 데이터는 따로따로 다루어지는 것보다 서로 조합이 될 때에 보다 신뢰도가 높다(최종 결론)

(감사합니다)
[참고##사용자 인터뷰##]

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


Trackback 0 Comment 2
Ad Test...
2010.11.17 12:39

안드로이드 체크박스 디자인 fail

퀴즈. 아래 그림의 두번째 사각형 버튼은 무슨 의미일까요?
제가 아는 한 (기존 pc 사용 경험으로는) 저건 dimmed 체크(체크되었으나 사용자가 수정하지 못하도록 비활성화)된 상태입니다. 그런데 사실 저건 안드로이드에서는 그냥 체크가 안된 상태입니다. 
체크 표시가 되어 있는데 왜 안되는거지? 이미 체크되어 있는데 뭘 더 어쩌란거지? 오랫동안 시행 착오를 거치고 나서 저게 언체크된 버튼이란걸 알았을때의 황당함과 그동안의 짜증을 기록에 남기기 위해서 블로깅합니다.




일관성(coherence)은 제품 내에서만 독자적으로 지켜지는것만으로는 부족하고 함께 사용되는 환경도 고려되어 져야 합니다. 안드로이드가 자폐증에 걸린것도 아니고 이미 통용되고 있는 디자인 언어를 자기만 다른 의미로 쓰고 있는건 문제가 있습니다.

맥오에스의 체크,언체크,비활성체크 참고.




그냥 박스만 그렸더니 뭔지 모르겠다고 뺀찌 먹고 살짝 흐리게 체크를 넣었을 것 같긴한데 잘못된 디자인 결정입니다. 더 심각한건 단말제조사마다 이 체크박스 이미지를 조금씩 변경하여 사용하고 있는데, 단말에 따라서는 완전 도를 지나치기도 합니다. 아래를 보세요. 이건 아니잖아요. 초록색쪽 색맹이나 색약인 경우에 구분이 가능할까요? 저도 잘 구분이 안돼요.
혹시 안드로이드쪽 디자인 작업 하시는 분은 좋은 해결책을 제시해 주시기 바랍니다.





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


Trackback 0 Comment 8
Ad Test...
2010.01.29 15:53

Windows 7 Design Principles

아마 보신 분들도 있겠지만, 안 보신 분들을 위해서 소개합니다. (시간이 나면 동영상 한 번 보면 좋습니다. 아래 사람 말대로 UI 공부보다는 '영어'공부에 더 도움이 될 듯) 50분 정도 길이인데, 작년 11월에 편지 받고 프로젝트 때문에 내내 못 보다가 이제야 봤습니다. 아래에 언급한 Windows 7의 디자인 원칙들을 보면,
 
1. 정말 중요한 원칙들을 잘 정리했다.
2. 그런데 이렇게 중요한 원칙을 이제서야 알았냐? 그동안의 윈도즈들은 다 뭐냐?
3. 이 중요한 원칙을 알고서도 이렇게 까지 밖에 못 만들었냐? 그러니까 윈도즈가 안 되는 거야
 
뭐 이런 생각들이 드는 군요
 
-------------------
 
Windows 7 Design Principles
 
A. 'Design Principle' 이란 무엇인가?
    1. 디자인 생각할 때 근거가 되는 틀이 된다 (A framework for design thinking)
    2. 뭔가 결정할 때 중요한 요소가 된다 (A key part of the decision making process)
    3. 생각한 목표를 이루었는지 검증할 수 있는 도구가 된다(A tool for evaluation of UX success against stated goals)
 
B. 'Design Principles'에서 중요한 것은 무엇인가?
    1. 사람들이 좋아하는 걸 만들어야 한다.
    2. 어플리케이션이 주인공이다 (OS가 아니라)
 
C. Windows 7 Design Principles (12:47)
   1. Reduce Concepts to Increase Confidence (12:55)
      할 수 있는 여러 가지 복잡하고 중복되는 방법을 제거하면 사람들은 더 자신감을 갖게 된다.
     (예를 들어 태스크바를 중심으로 프로그램을 시작할 수 있는 6가지 다른 방법을 1-2개로 단순화)
 
   2. Small Things Matter, Good and Bad (17:48)
      아주 작은 요소라도 큰 영향을 미칠 수 있다. (제가 보기엔 전혀 작은 요소들이 아닌 듯)
      (예를 들어 사진을 작게 보여주는 화면에서 컨텐트를 더 많이, 더 잘 보이게 하고, 쓸데없이 색이 들어간 UI 바를 제거)
 
   3. Delight (22:31)
      즐거움을 주어야한다.
      (예를 들어 어떤 프로그램을 선택하느냐에 따라 윈도즈 색이 약간씩 바뀌게 하는 재미)
 
   4. Solve Distractions, not Discoveratbility (25:50)
      사람들이 원하는 것에 더 집중할 수 있도록 해 주어라 (사람들이 이 기능을 발견할 수 있을까?하는 걱정을 하지 말고)
      애플이 정말 잘하는 부분이죠. 윈도즈는 아직도 멀었고. 5-6세 아이들처럼 모두들 주목받고 싶어해서 예의없이 설치게 하지 말고 조용히 선택을 기다리도록 해라.
      (예를 들어 어플리케이션 히스토리를 보기 위해 버튼을 넣는 대신 우클릭을 이용하게 하고, 바탕화면 돌아가기를 피츠법칙을 이용해서 우하단에 아무런 아이콘 없이 배치하기)
 
   5. Time Matters; Build for People on th Go (35:14)
       바쁜 사람들, 움직이는 사람들, 공유 프린터, 파일 공유, 여기 저기 옮겨 다니는 사람들을 고려
       (프린터를 공유하기 위해서 비스타에서 30-40 Steps가 필요했는데 7에서 3-5로 단순화함. 내 참... 자랑인지 누워서 침뱉기인지...)
 
   6. Value the Full Lifecycle of the Experience (38:30)
       설치하고, 적응하고, 매일 사용하고, 문제 해결하고, 제거하거나 업그레이드 할 때까지.
 
   7. Be Great at "Look" and "Do" (42:55)
       사람들의 기대를 만족시켜야 한다.
 
동의 안 하면 자기한테 이메일 보내라는 군요.
 
----------------------
 
 

 
 
----- Original Message -----
Sent: Tuesday, November 10, 2009 7:08 PM
Subject: UX 팩토리 / user experience blog

UX 팩토리 / user experience blog

Link to UX 팩토리 / user experience blog / 사용자 경험 블로그




윈도우7 디자인 원칙 : 출근 길에 볼만한 영어 동영상

Posted: 09 Nov 2009 05:30 AM PST

우리가 어렸을 때 말을 배우는 경험을 생각해 보면 모든 것이 "듣기"에서 시작된다는 점에서 영어공부에는 듣기가 참 중요하다는 생각이 들어요. 요즘 들어 동영상 포스팅이 부쩍 늘고 있는데, 이 동영상들을 영어 공부에 활용하면 어떨까요?

지난 주 부터 출근 길에 계속 반복해서 보고 있는 동영상이 하나 있어서 소개해 드려요.


재미있는 내용들이 많이 있지만, 그 중에서도 제가 인상깊었던 것은,


발견가능성(Discoverability)이 아니라, 주의가 흐트러짐(Distractions)의 문제를 해결하라는 것인데요. 주목을 끌려고 난리를 피우는 어린이들에게 매너를 갖추게 하는 일로 비유하는 군요.

전체 내용을 한 3~4번쯤 반복해서 본 것 같은데 참 재밌는 이야기에요. 여기에 가시면 동영상을 여러가지로 인코딩 된 버전으로 다운 받을 수 있는데, 이 중에 적절한 것을 다운 받으신 후에 PMP나 DVD 등으로 옮겨서 보시면 된답니다.

참고로, 얼마 전 소개해 드렸던 IASDR 2009의 발표 동영상이 몇 편 더 업데이트 되었네요.
저작자 표시 비영리 동일 조건 변경 허락


[참고##Windows##]



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


Trackback 0 Comment 0
Ad Test...