UX 매거진에 공개된 글 중에서 허락을 받고 번역해 올리는 글입니다.
http://uxmag.com/articles/improving-user-experience-in-manuals
일부 잘못된 번역이 있을 수 있습니다. 애매한 표현은 원문을 참고하세요.
번역/게시를 허락해준 Josh Tyson, Anastasios Karafillis에게 감사드립니다.
매뉴얼에서 사용자 경험 향상하기
아나스타시오스 카라필스 (Anastasios Karafillis)
매뉴얼은 아마도 제품의 사용자 경험에서 가장 다루기 어려운 부분입니다. 대부분 일부러 매뉴얼을 찾아 읽지는 않습니다. 디자이너 역시 매뉴얼을 보지 않아도 사용할 수 있는 사용자 인터페이스를 만들기 위해 노력합니다. 그렇다 하더라도 적절한 매뉴얼이 필요하다는 것에는 사용자나 디자이너 모두 분명히 동의할 겁니다.
매뉴얼은 사용자에게 도움이 될 만한 애플리케이션의 잠재적 기능을 끌어내는 강력한 도구가 될 수 있습니다. 하지만 많은 경우 매뉴얼이 사용자를 도와주기보다는 혼란스럽게 만들기도 합니다.
이 글에서는 테크니컬 라이터가 일반적으로 접할 수 있는 어려움이 어떤 것이 있는지 살펴보고 어떻게 매뉴얼의 사용자 경험을 향상할 수 있는지 이야기해보겠습니다.
스타일 : 책 vs 설명서
매뉴얼을 읽어보기 전에 겉으로 보이는 스타일은 사용자가 제품 자체의 인터페이스를 살펴보는(물론 서비스센터에 전화하는 것은 그렇게 할 수 없지만) 대신 매뉴얼을 집어서 읽어볼 마음을 들게 하는 중요한 계기가 됩니다.
매뉴얼이 전화번호부만 한 분량이라면 손사래를 치며 읽으려 하지 않을 겁니다. 그렇다고 콘텐츠를 너무 간단하게 만들라는 것은 아닙니다. 매뉴얼은 포괄적인 내용을 담고 있어야 합니다. 사용자가 잠재적인 위험이 있는 프로세스 실행 버튼을 실수로 클릭했을 때 매뉴얼에 관련된 내용을 담지 않았다면 이에 따른 책임을 질 수 있습니다.
설명할 제품의 기능이 너무 많다면 '빠른 시작 가이드'를 별도로 제공하는 것도 좋은 방법입니다. 빠른 시작 가이드는 제품의 인터페이스를 간략하게 소개하고 전체 시스템에 영향을 주지 않고 기본적인 기능을 살펴볼 수 있는 내용을 담아 제공합니다.
경우에 따라 매뉴얼에 빈 페이지를 삽입하는 것도 필요합니다. 문단 사이의 간격이나 페이지 여백도 중요한 가치를 가지고 있습니다. 적절하게 제공된 여백은 글을 쉽게 읽고 이해하는 것을 도와줍니다(http://psychology.wichita.edu/surl/usabilitynews/62/whitespace.htm). 물론 과도하게 사용하는 것은 주의해야 합니다.
글꼴의 선택 역시 신중해야 합니다. 일반적으로 인쇄물에는 바탕체(serif font)를 사용하고 화면으로 보는 것은 돋움체(sans-serif)를 사용하는데 사용자마다 선호하는 글꼴이나 크기는 그야말로 제각각입니다(http://www.awaionline.com/2011/10/the-best-fonts-to-use-in-print-online-and-email/). 다양한 방법을 시도해보고 어떤 것이 적절했는지 알아내는 것이 중요합니다. 여기서 중요한 것은 선택한 방법을 사용자와 함께 시도해봐야 한다는 겁니다.
목차 : 논리 vs 일관성
테크니컬 라이터들은 명확한 계층적 방식으로 목차를 구성하는 것을 권장합니다. 좋은 조언이지만 좀 더 고민할 것들이 있습니다.
매뉴얼이나 제품 인터페이스의 목차(또는 콘텐츠의 구조)는 상호 보완적인 정보 아키텍처를 유지해야 합니다. 인터페이스의 구조는 시각적이지만 매뉴얼은 주제에 따라 정리됩니다. 목차의 주제별 구조가 인터페이스의 시각적인 구조와 일치하지 않는다면 사용자는 혼란스러울 수 있습니다.
예를 들어 2007년도까지 마이크로소프트 워드에서 머리글이나 바닥글을 추가하려고 하면 보기(View) 메뉴에서 적절하게 페이지 설정을 하기 위해 머리글/바닥글을 선택해야 했습니다. 이 과정에서 머리글이나 바닥글은 페이지를 구성하는 인터페이스의 기본 형식 중 하나로 처리되었습니다. 하지만 이런 방식은 2007년 리본 인터페이스가 도입되면서 조금 바뀌었습니다. 워드 2007 이후 버전에서 머리글이나 바닥글을 추가하려면 리본 안에 있는 삽입(Insert) 탭을 선택하고 머리글과 바닥글 아이콘을 선택해야 합니다.
머리글과 바닥글은 외부 아이템처럼 취급되어 그림이나 차트, 표, 도형과 같은 다른 외부 아이템과 같은 탭 안에 모여져 있습니다. 이런 것들은 페이지에서 추가적인(기본 형식이 아닌) 요소입니다.
이러면 변경된 내용을 목차에 어떻게 반영해야 하는지 그리고 반영할 필요가 있는지 의문이 생깁니다. 논리적으로 생각해보면 "페이지 형식"이라는 장 아래에 머리글과 바닥글에 대한 세부 항목을 추가하고 "아이템 추가"라는 장 아래에 그림, 차트, 표를 설명하는 세부 항목을 추가하면 될 것 같습니다. 하지만 이렇게 설명하는 것은 눈에 보이는 인터페이스의 시각적인 구조와 일치하지 않습니다.
이런 때에는 정확하게 인터페이스에 일치하게 페이지, 표, 삽화, 링크, 머리글, 바닥글, 텍스트, 기호 등에 대한 설명은 "아이템 삽입"이라는 장 아래에 세부 항목으로 들어가는 것이 좋습니다. 이렇게 하면 사용자가 혼란스럽지 않으며 어떤 종류의 기능을 어디에서 찾아야 하는지 머릿속에서 쉽게 그려볼 수 있습니다.
설명 : 목표지향 vs. 서술
일반적으로 사용 매뉴얼은 단계에 따라 사용자가 특정한 목표를 달성할 수 있도록 안내하려는 의도를 가집니다. 이런 접근 방식은 일부 프로세스나 전체 애플리케이션에서 잘 동작하기도 하지만 목표가 명확하지 정의되지 않았을 때는 서술적인 접근이 적합할 수도 있습니다.
예를 들어 프로그램 설치는 목표지향적인 프로세스의 전형적인 사례입니다. 프로그램을 성공적으로 설치한다는 명확한 목표가 있으며 대부분 같은 과정으로 진행됩니다. 대부분의 설치 마법사 인터페이스는 사실 정해진 단계를 사용자가 따라오도록 설계되어 있습니다.
목표지향적인 프로세스는 작업을 마치면 "설치가 완료되었습니다." 또는 "전송 완료"와 같은 성공 메시지를 보여줍니다. 하지만 생산성 애플리케이션처럼 제품이나 서비스의 목표가 명확하게 정의되어 있지 않은 때도 있습니다.
생산성 애플리케이션을 사용하면 틀에 박히지 않은 멋진 문서나 매력적인 비디오, 프레젠테이션을 만드는 것을 목표로 가지기도 합니다. 목표가 세분되면 이를 적극 지원해주기 어려워집니다. 그래서 생산성 애플리케이션에 대한 매뉴얼은 제공하는 각 기능에 대해 설명해주어야 하고 이를 쉽게 다룰 수 있도록 배려해주어야 합니다.
예를 들어 포토샵에서 제공하는 컬러 피커(color picker)를 살펴보죠.
인터페이스 자체는 선택한 영역의 색상 속성을 어떤 식으로든 가져오는 것 외에 다른 목표가 있지는 않습니다. 이럴 때는 눈에 보이는 인터페이스 요소를 주요 기능과 하위 기능으로 분류해 구분하고 묶어주어야 합니다. 컬러 피커의 경우에는 왼쪽 영역의 색상 필드가 어떤 역할을 하며 가운데 있는 슬라이더바와 어떻게 연결되어 동작하는지를 설명해주어야 합니다. 색상 표기법 또는 색상 값(색조, 채도, RGB, CYMK 등)과 같이 오른쪽에 배치된 항목 역시 설명이 필요합니다.
이런 상황에서 목표는 사용자가 결정하게 되며 좀 더 상세하게 설명된 매뉴얼은 사용자가 만족스러운 결과에 도달하는 데 필요한 도구나 설정을 시도해보고 최고의 방법을 찾을 수 있게 도와줄 수 있습니다.
언어 : 기술적인 vs 일상적인
테크니컬 라이터는 사용자에게 익숙하지 않은 전문 용어를 피하고 쉬운 언어를 사용할 것을 권장합니다. 좋은 조언이지만 몇 가지 좀 더 고려할 사항이 있습니다.
상황에 따라 기술적인 용어를 사용해야 할 때도 있습니다. 이런 때 일관성을 유지하는 가장 좋은 방법은 용어집을 만들고 기술적인 용어를 설명해주는 것입니다. 상호 참조(cross-referencing)는 사용자에게 불편한 방식일 수 있지만, 일반적으로 가장 적절한 해결책입니다. 용어집을 찾아보는 것은 어려운 일이 아닙니다. 오히려 본문 중 기술적인 용어를 이해시키려는 부가설명을 추가하게 되면 전체적인 맥락을 복잡하게 하고 사용자가 용어에 익숙해지는 것을 방해하게 됩니다.
너무 일상적인 용어를 사용하면 의도한 내용을 설명하기가 어려워질 수 있습니다. 물론 데이비드 포그(David Pogue / http://www.davidpogue.com/)와 같은 테크니컬 라이터는 일상적인 용어를 즐겨 사용합니다. 즐거움과 정보를 동시에 주는 것이 불가능한 것은 아니지만 이에 따르는 위험이 무엇인지는 알고 있어야 합니다.
재미를 추구하는 것도 좋지만, 사용자가 매뉴얼을 읽는 목적은 가능한 한 빠르고 효율적으로 할 일을 끝내는 것입니다. 사용자는 어떤 식으로 설명하든지 상관없이 그 방법이 가장 옳다고 생각하며 이를 따라 하고 결과를 기대합니다.
쉽고 이해하기 쉬운 단계로 설명해주는 것은 사용자의 관심을 다른 곳으로 돌릴 수 있는 위험이 있습니다. 특히 내용이 너무 재미있다면 말이죠. 작성된 문서가 흥미롭건 그렇지 않건 간에 설명하고자 하는 과정이나 결과에 집중할 수 있도록 관계를 유지해야 합니다. 이렇게 하면 마음을 사로잡는 효율적인 글을 만들 수 있습니다.
구조 : 통일된 vs 나누어진
소설은 처음부터 마지막 장까지 읽는 것을 전제로 합니다. 하지만 매뉴얼은 사용자가 원하는 항목을 바로 찾아갈 수 있고 필요하지 않은 정보는 넘겨볼 수도 있습니다. 매뉴얼이 일관성 있게 의미 있는 정보로 나뉘어 있다면 필요없는 정보를 읽지 않더라도 사용자가 전체적인 내용을 충분히 이해할 수 있습니다.
제목은 짧게 쓰고 해당 장에 포함된 정보가 어떤 것인지 충분한 힌트를 주지 않아도 괜찮습니다. 오히려 각 장의 시작 부분에 "요약: " 이라고 굵은 글씨로 표시된 항목에 2줄 정도의 간단한 내용 요약을 포함하는 것이 좋습니다. 이렇게 하면 사용자가 전체 장을 읽지 않아도 됩니다. 또한, 요약된 내용은 사용자가 특정 기능에 포함된 잠재적인 위험이나 해당 기능이 다른 것과 어떤 관계를 맺고 있는지 알 수 있는 적절한 콘텐츠가 될 수 있습니다.
매뉴얼의 구조와 지시문을 사용할 때는 의미 있는 일관성을 유지해야 합니다. 예를 들면 다음과 같은 것들입니다. 모든 과정과 결과는 별도의 문단에 배치합니다. 주석을 사용할 때는 항상 굵은 글씨로 표기합니다. 지시문은 항상 들여쓰기를 사용합니다. 선택할 수 있는 항목을 설명할 때는 항상 비순서 목록(bullet list)를 사용하고 고정된 순서에 따라 진행되는 것은 순서 목록(number list)를 사용합니다. 그리고 사진 관련된 설명은 항상 아래쪽에 표기합니다. 절대로 위에 표기하지 않습니다.
마지막으로 부록을 추가하는 것을 고려해보세요. 인덱스나 FAQ, 문제 해결, 용어집과 같은 항목은 사용자들에게고 익숙한 개념입니다. 그리고 일관성 있는 구조(Q&A, 알파벳순, 오류 & 문제 해결)를 제공하는 것은 쉽게 내용을 검색하거나 찾을 수 있도록 도와줍니다. 매우 흥미롭게도 부록은 인터페이스의 일관성을 유지한다는 원칙에서 벗어나도 되는 영역입니다. 대신 사용자가 주제어나 동의어 그리고 궁금해할 만한 내용을 찾을 수 있도록 동작해야 합니다.
마무리
사용자 매뉴얼은 매뉴얼 자체뿐 아니라 제품과의 관계에서 사용자 경험의 중요한 역할을 담당합니다. 하지만 불행하게도 많은 경우 매뉴얼은 사용자를 도와주기보다는 혼란스럽게 만드는 원인이 되기도 합니다. 애플리케이션은 각각 다른 모습을 가지고 있고 다른 접근 방식이 필요합니다. 테크니컬 라이터를 대상으로 하는 조언은 많이 찾아볼 수 있지만 어떤 경우에 언제 적용해야 하는지를 이해하고 실천하기는 쉽지 않습니다.
테크니컬 라이터가 제품이 어떻게 동작하는지 명확하게 이해하기 위해서는 설계 단계부터 개발 과정에 같이 참여해야 합니다. 완성된 제품을 마감일이 임박해서 처음 접해보는 것보다 훨씬 좋은 결과를 만들어낼 수 있습니다. 그리고 나면 그들의 분석적이고 언어학적인 기술을 사용해 사용자가 쉽게 이해할 수 있도록 프로세스를 단순화하고 매뉴얼을 강력한 도구로 사용할 수 있을 겁니다.
아나스타시오스 카라필스 (Anastasios Karafillis)
그리스에서 프리랜서로 UI 디자인을 하고 있습니다. 사회과학과 철학을 전공했습니다. 사회 또는 디지털 정보 시스템을 잘 설계하기 위해서는 적절한 언어철학(philosophy of language)이 매우 중요하다고 믿고 있습니다. 주로 활동하는 분야는 인터랙션 디자인, 인포메이션 아키텍처, 공감, 사용성, 명명법(Nomenclature)입니다.
