페이퍼요약 - 온라인 헬프의 사용성 테스트 by GRAYLING

제목: 온라인 헬프의 사용성 테스트(Fear and Loathing of the Help Menu: A Usability Test of Online Help)

저자: TREVOR GRAYLING

문서유형: 저널 페이퍼(총 12페이지), 1998년

 

데이터베이스 검색 애플리케이션의 HELP 메뉴에 대한 사용성 테스트 수행 사례를 기술한 자료

---

배경 설명

• 논문 저자의 회사 MDL Information Systems, Inc.은 제약 및 바이오테크 업체를 위한 데이터베이스 검색 소프트웨어를 개발하고 다양한 화학 데이터베이스를 공급함
• 시스템 최종사용자는 대개 박사 학위를 보유한 화학자들이며 유용한 화합물(chemical compounds)을 찾기 위해 검색 소프트웨어로 데이터베이스를 검색함
• 데이터베이스가 크기 때문에(대략 600,000 화합물) 유용하고 다루기 쉬운 숫자의 데이터베이스 레코드를 얻기 위해서는 화학자들이 복잡하고 강력한 검색 쿼리를 개발할 필요가 있음
• MDL 소프트웨어는 사용자가 실제 분자(a molecule)나 반응(a reaction)을 그릴 수 있는 그림 컴포넌트를 제공. 즉, 원자(atoms), 결합(bonds) 등에 대한 일반 화학 표기를 사용하여 그린 그래픽이 검색 쿼리가 되며 이 쿼리는 애플리케이션의 데이터베이스 검색 컴포넌트로 전해짐
• MDL 소프트웨어 버전 2.0은 전형적인 윈도우 스타일 GUI 인터페이스를 가짐(즉, 기능 위주의 툴과 메뉴 명령어 집합으로 구성됨)
• 여러 이유로 소프트웨어 버전 2.0의 모든 최종사용자 문서를 온라인 헬프 형식으로만(즉, 인쇄된 종이 매뉴얼 없이) 제공하기로 회사가 결정함

예비 사용성 테스트 수행

• 유일한 사용자 지원 정보 소스인 온라인 헬프의 정확한 구축이 중요해짐에 따라 꼼꼼한 사용자 분석(user analysis)과 태스크 분석(task analysis)을 수행함. 또한 온라인 헬프에 대한 전형적인 불만사항(아래 목록 참조)을 피하기 위해 HELP 설계에도 시간을 투자함
• 이후 HELP 시스템의 대표적인 부분을 페이퍼 프로토타입으로 구축하고 두 번의 예비 사용성 테스트를 수행함. 먼저 6명의 피실험자로 테스트를 하고, 변경 및 수정을 거친 후 다시 5명의 피실험자로 테스트를 수행함
• 이 예비 사용성 테스트 결과가 긍정적이여서 사용자 지원 정보를 온라인 헬프로만 제공하기로 한 전략에 자신감을 갖게 됨. 또한 이 테스트가 사용자들이 헬프 정보 접근 툴로 목차 보다는 인덱스 사용을 선호함을 보여줌. 따라서 여러 주의 작업 일정을 잡아 인덱스(약 2,000 엔트리를 포함)를 세심하게 편집함
• 버전 2.0 출시일이 다가옴에 따라 완전한 온라인 헬프(즉, 완성된 애플리케이션의 HELP)의 사용성 테스트가 필수적이게 됨. 특히, 빠진 정보나 빠진 인덱스 엔트리가 있는지, 설계 노력을 통해 제거하고자 했던 전형적인 온라인 헬프 불만사항들이 진짜로 제거(또는 감소)되었는지를 사용성 테스트에서 확인하고자 함

문헌 조사, 제품 검토, 최종사용자로서의 주관적 경험에 따르면 온라인 헬프에 대한 전형적인 불만 사항이 아래와 같다.

• 정보가 빠져 있음(HELP가 포괄적이지 않음)
• 정보를 찾을 수가 없음(인덱싱이 좋지 않음)
• 하이퍼스페이스에서 항상 길을 잃게 됨(하이퍼링크가 좋지 않거나 모호함)
• 헬프 윈도우와 애플리케이션 윈도우를 동시에 조작하는데 어려움을 겪음
• 주의해서 읽을 필요가 있는 길고 복잡한 내용의 경우 종이 문서를 더 선호함
• 길고 스크롤링 되는 HELP 화면이 싫음

사용성 테스트의 패러미터

• 피실험자(test subjects): 문헌 조사 후 신뢰할 수 있는 결과를 얻기 위해 최소 8명의 최종사용자가 필요하다고 판단. 지역 회사에서 사용자 프로파일에 맞는 10명의 피실험자를 모집함. 10명 모두 박사 학위를 가진 화학자로 윈도우 애플리케이션 사용 경험이 있음. 이 중 5명은 해당 제품을 써 본적 없는 초보자 그룹으로 나머지 5명은 해당 소프트웨어의 이전 버전을 사용한 경험이 있는 전문가 그룹으로 나뉨
• 사용자 환경 에뮬레이팅: 테스트에서 실제 사용자 환경을 최대한 모방함. 피실험자는 혼자 작업하고, 온라인 헬프를 포함한 데이터베이스 애플리케이션과 프린터에 접근 가능하고, 힌트나 도움 없이 일련의 사용자 시나리오(데이터베이스 검색 문제)를 완수함. 피실험자가 검색을 완료하면 실험자는 조회했어야 하는 정확한 데이터베이스 레코드 수를 피실험자에게 알려주고 정확하지 않은 수를 조회한 경우 검색 쿼리를 개선하도록 피실험자에게 요청함. 한 가지 통상적인 사용자 환경과 다른 점은 피실험자가 작업을 하면서 자신의 생각을 소리 내어 말하도록 권장함(즉, “think aloud” 프로토콜 사용)
• 성공 기준 정의: 사용성 테스트가 성공적인지 어떻게 알 수 있나? 즉, 온라인 헬프의 성공을 어떻게 측정할 수 있나? 이에 답하는 테스트 기준을 결정할 필요가 있음. “주어진 시나리오를 위한 검색 쿼리(즉, 해당 시나리오와 화학적으로 관련 있는 모든 데이터베이스 레코드를 조회할 수 있는 쿼리)를 생성하는데 필요한 모든 헬프 정보를 사용자가 외부 지원 없이 찾을 수 있어야 한다”를 성공 기준으로 정함
• 사용자 시나리오 생성: 사용자 시나리오는 당연히 성공 기준에 기반해야 함. 또한 피실험자가 온라인 헬프에 의존할 필요성을 느낄 정도로 충분히 복잡한 시나리오를 필요로 함. 따라서 처음 보면 이해가 어려운 소프트웨어 부분, 온라인 헬프 작성시 설명하기 어려웠던 부분, 실제 고객들이 어려워하는 부분(고객 서비스 부서에 정보를 요청함)에서 시나리오를 취함
• 드레스 리허설 수행: 내부 직원 여러 명을 모집해 전체 테스트를 수행해 봄. 사용자 시나리오의 부정확성과 화학적 모호성을 체크하고, 피실험자가 실제로 온라인 헬프를 필요로 하는지 확인하고, 애플리케이션 프로토타입이 크래시 없이 시나리오가 요구하는 태스크를 수행할 수 있는지도 확인함. 또한 실험 장비를 테스트하고, 테스트에 걸리는 시간을 측정하고, 테스트 감독관과 관찰자-기록자 역할을 실험 주체 측이 예행 연습함

사용성 테스트 결과

• 검색 시나리오와 대면하면 피실험자가 여러 메뉴를 흩어보고 툴을 시도해보고 다이얼로그 박스를 응시함. 즉, 애플리케이션 사용법을 배우는데 있어서 HELP를 보지 않고 사용자 인터페이스 요소들을 직접 시도해보는 ‘시행착오(trial and error)’ 방식을 취함
• 실험자는 사용자가 어려움에 닥치면(즉, 일단 해 보는 방식의 첫 시도가 실패한 후) HELP 메뉴로 가서 헬프 인덱스를 브라우징 할 것이라고 예상했지만 실제 피실험자는 아주 마지막까지 HELP 메뉴 사용을 피함. 모든 툴, 메뉴, 다이얼로그를 꼼꼼히 본 후에도 피실험자가 여전히 시나리오 태스크를 위한 명령어나 기능을 못 찾으면 크게 한숨을 쉰 후 다시 처음부터 모든 메뉴, 툴, 다이얼로그를 찾기 시작함. 이 때도 HELP 메뉴로 가서 사용자를 돕기 위해 준비된 정보를 찾아보는 대신에 여전히 사용자 인터페이스 요소에서 직접 찾아보는 시행착오 전략을 고수함
• 피실험자가 온라인 헬프 사용을 꺼리기 때문에 어떻게 작업해야 할지를 종종 그냥 추측하였으며 간혹 첫 시도에서 성공적 검색을 해냄. 10명의 피실험자에게 3개 검색 시나리오를 주어 총 30개 검색이 수행되었는데, 무얼 해야 하는지 또는 특정 기능이 어디에 위치하는지 알아야 하는 어려움 때문에 23개 검색만 실제 완수됨. 이 23개 중 7개가 1차 시도에서 완수되었고, 2개는 2차 시도에서, 6개는 3차 시도에서, 8 개는 4차 시도에서 완수됨

피실험자가 조회한 레코드 수가 틀렸음을(즉, 검색 쿼리가 잘못됨) 실험자가 알려주면 피실험자는 이를 다시 수정해야 함. 피실험자는 반복해서 실패를 한 후에야 비로소 도움을 얻기 위해 온라인 HELP로 갔으며, 온라인 헬프에서의 피실험자들의 태도가 아래와 같이 관측됨

• 헬프 정보를 성급히 읽음: 아주 간단한 지시도 잘못 읽는다. 예를 들면, “XXX 오브젝트를 더블 클릭해라”라는 지시에 싱글 클릭을 한 후 화면을 바라보며 왜 애플리케이션이 기대대로 동작 안 하는지 의아해함
• 하이퍼링크 선택을 부정확하게 함: 토픽 화면 상의 하이퍼링크들이 서로 분명히 구분되고 모호하지 않도록 설계에서 많이 애썼지만 피실험자는 링크를 아주 빠르게 흘긋 보고서는 종종 틀린 링크를 클릭함
• 빠르게 포기함: 첫 2~3개 화면 내에 원하는 정보를 못 찾거나 또는 올바른 경로에 있다는 느낌이 안 들면 필요한 정보를 못 얻었어도 그냥 헬프를 빠져 나와 다시 메뉴와 툴을 열심히 브라우징하기 시작함
• “일반 정보(general information)”를 보지 않음: 유익한 “Overview” 토픽과 포괄적인 “How to Use Help” 토픽을 일부러 준비했지만 이런 화면과 이와 유사한 화면들이 완전 무시됨
• 긍정적 측면은 피실험자가 다이얼로그박스 헬프(다이얼로그박스 상의 “Help” 버튼을 통해 가용한 컨텍스트에 한정된 헬프 화면)와 툴의 팝업 헬프(마이크로소프트 툴팁을 커스토마이징한 것으로 작은 팝업 공간에 툴/아이콘에 대한 간단한 설명을 제공)는 사용을 한다는 점이다.
• 피실험자가 성공 기준(“모든 관련 데이터베이스 레코드를 조회하는 검색 쿼리를 생성하는데 필요한 헬프 정보를 찾을 수 있어야 한다”)을 달성할 수 있었지만, 대개 일차 검색 쿼리가 부정확하다는 말을 들은 후에야 가능했음. 즉, 실험자가 알려주지 않았더라면 피실험자는 자신들의 일차 쿼리가 맞았다고 생각했을 것이며 이는 우려가 되는 결과임(왜냐면 실제 많은 사용자들이 애플리케이션을 비효과적이고 비효율적인 방식으로 사용할 수도 있음을 의미하기 때문)
• 두 번째 이슈인 온라인 헬프에 대한 전형적인 불만을 없애는 것(최소화 하는 것)은 전반적으로 성공적이었음. 피실험자가 내키지는 않지만 일단 HELP를 사용하기로 결심을 하면 자신들이 필요로 하는 정보를 찾을 수 있었음. 하지만 이런 성공도 피실험자들이 최대한 HELP를 외면하고자 한다는 점에서 빛이 바램

 

테스트 결과에 대한 실험자의 반응

• 사용자가 읽고 싶어하지 않는 무언가를 일년 이상을 신중히 설계하고 작성해 온 사실에 온라인 헬프를 담당하는 MDL의 Technical Communications 그룹은 전반적으로 의기소침해짐. 단순 사기 저하 뿐만 아니라 고객이 애써 피하는 자료를 작성하는 사람을 회사가 고용할 이유가 없으므로 기술 작가로서의 존재 자체에 위협을 느낌
• 출시 일이 임박함에 따라 애플리케이션 사용자 인터페이스를 다시 설계할 시간이 없었음. 따라서 테스트에서 발견된 오타, 에러, 누락된 인덱스 엔트리 등을 수정한 후에 사용자가 비교적 많이 사용하는 다이얼로그 박스 헬프를 개선하는데 노력을 집중함. 또한 컨텍스트에 한정되고 간편하게 가용한 여러 다른 HELP 정보 접근 방법(예, 툴/아이콘의 팝업 헬프, 주 메뉴 상에 직접 추가된 헬프 토픽, 위자드와 인터뷰어)을 활용함