페이퍼요약 - 소프트웨어 개발자를 위한 사용성 기초 by Ferré

제목: 소프트웨어 개발자를 위한 사용성 기초(Usability Basics for Software Developers)

저자: Xavier Ferré 외 3인

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

 

의도한 사용성 수준을 가진 시스템을 구축하기 위한 일반적 사용성 프로세스를 기술한 자료

---

사용성(Usability) 개념

• 사용성(usability)은 사용자 인터페이스(UI)의 외양에 대한 것만이 아니라 어떻게 시스템이 사용자와 상호작용 하는 지와 관련 있음
• 사용성을 시스템의 특정한 하나의 측면으로 정의하기 어렵고 개발 대상 시스템의 사용 의도에 따라 달라진다. 예를 들어, 대다수 사용자가 어쩌다 한번 사용하는 박물관 키오스크의 소프트웨어 시스템은 최소한의 노력으로 습득이 가능하도록 ‘습득용이성(ease of learning)이 중요시 되지만 효율성 같은 사용성의 또 다른 측면은 큰 비중을 차지하지 않음. 반면 은행 캐셔 시스템은 고객 대기 시간을 줄일 수 있도록 높은 효율성이 요구됨
• 사용성은 소프트웨어 상호작용(software interaction)뿐만 아니라 도움 기능(help features), 사용자 문서(user documentation), 설치 지침(installation instructions) 과도 관계한다.

사용성 속성(Usability attributes)

사용성은 대개 아래 5가지 기본 속성들로 나뉨. 이 속성들이 때때로 서로 충돌함(예, 습득성 vs. 효율성). 시스템의 사용성은 단순히 아래 속성들 값의 합계가 아니라 각 속성마다 특정 수준에 도달해야 함을 의미한다.

 

• 습득성(Learnability): “시스템 주요 기능을 배우고 업무를 완수하는데 익숙해지기가 얼마나 쉬운가”를 나타냄. 대개 사용자가 시스템으로 특정 태스크를 완성하기까지 걸리는 시간을 측정하여 전문가가 동일한 태스크를 완수하는데 걸리는 시간과 비교하여 평가
• 효율성(Efficiency): 사용자가 시스템을 사용하여 수행할 수 있는 시간 단위 당 태스크 수. 시스템 사용성이 높을수록 사용자가 더 빠르게 태스크를 수행하고 업무를 완수 가능함
• 시간 경과에 따른 사용자 기억(User retention over time): 간헐적 사용자에게는 다시 학습을 하지 않고도 시스템을 사용할 수 있는 것이 중요. 일정 시간 시스템을 사용하지 않은 후에 시스템이 어떻게 작동하는지를 사용자가 얼마나 잘 기억하는지 나타냄
• 에러율(Error rate): 사용성에 부정적 영향을 줌. 이 속성은 시스템 에러가 아닌 사용자가 태스크를 수행하는 중에 범하는 에러 수를 가리킴. 사용성이 좋으면 에러율이 낮음
• 만족도(Satisfaction): 시스템에 대한 사용자의 주관적인 인상

사용성 프로세스

• 시스템의 사용성이 상호작용 설계에 달려있으므로 개발 프로세스 전반에 거쳐 시스템 사용성을 다루어야만 하며, 사용성 테스팅(Usability testing) 만으로는 높은 사용성을 가진 제품을 생성하기에 충분하지 않음
• 사용성이 높은 소프트웨어 시스템을 구축하기 전에(또는 그 UI를 설계하기 전에) 해당 시스템을 사용할 사람들에 대한 정보가 필요함 (아래 예)
  - 시스템 사용자가 누구인가?
  - 시스템 사용자가 무엇을 달성할 필요가 있는가?
  - 이를 달성하기 위해 시스템 사용자가 시스템으로부터 필요로 하는 것이 무엇인가?
  - 시스템 사용자가 필요로 하는 것을 시스템이 어떻게 제공해야 하는가?
• 사용성 프로세스는 사용자 상호작용 설계자(user interaction designers)가 분석 단계 동안 위 질문들에 답할 수 있도록 돕고 또한 설계 단계에서는 설계를 지원한다.

[사용성 프로세스]

I. 사용성 분석 단계(Usability analysis phase)

A. 사용자 분석(User analysis)

개발 대상 시스템과 주어진 시간 제약에 따라 사용자에 대한 정보를 수집하는 여러 방법이 존재하며, 대표적으로 아래와 같은 방법들이 있다.

• 사이트 방문(site visits): 개발자가 사용자 작업 환경에서의 사용자를 관찰함(교체될 시스템을 이용해서 관찰 또는 기존 시스템이 없는 경우라면 수작업으로 사용자가 태스크를 수행하는 모습을 관찰). 또한 사용자들의 행동에 숨은 동기나 전략을 이해하기 위해서 개발자가 사용자들을 인터뷰 하기도 함
• 포커스 그룹(focus groups): 선정된 사용자 그룹과의 잘 준비된 토론. 특정 주제에 관한 사용자의 관점과 경험에 대한 정보를 수집하는 것이 목표이며, 동일 주제에 대한 여러 관점을 얻기에 적절한 방법
• 서베이(surveys): 정보의 품질이 질문의 품질에 달려 있음. 사용자에게 일일이 내용을 확인하는 것이 어렵거나 불가능하기 때문에 서베이는 일방적인 정보 소스
• 파생 데이터(Derived data): 핫라인 보고서, 고객 불만 편지 등을 포함. 사용성에 대한 좋은 소스가 될 수도 있지만 종종 해석하기 어려움. 오로지 문제점만이 보고되고 좋은 점은 언급되지 않음

B. 태스크 분석(Task analysis)

• 태스크의 개념이 객체 지향 소프트웨어 개발에서의 유스케이스 개념과 유사함. 즉, 태스크는 사용자에게 의미 있는 하나의 활동(activity)이다. 사용자 분석의 결과가 태스크 분석의 입력이 되거나 또는 이 두 분석이 때때로 공동으로 수행됨
• 분석을 통해 식별된 태스크는 제품 개발 주기 전반에 거쳐 UI 설계를 주도하고 테스트 하는데 사용될 수 있음. 태스크들을 중요도와 빈도에 따라 우선순위를 주고 우선순위가 높은 소규모 태스크 집합에 중점을 두는 것이 권고됨(즉, 가장 중요한 기능에 집중)
• 태스크 분석은 식별된 태스크 집합을 평가하는 것으로 마무리됨(평가에 사용자도 참여하면 더 바람직함)
• 일차적인 태스크 분석 후 사용자가 달성하고자 하는 목표에 기반하여 시스템이 지원할 태스크를 식별. 이것이 서브태스크와 사용자가 수행할 특정 액션으로 분해되며, 식별된 태스크들은 사용성 명세(usability specifications) 구축을 위한 기초로 활용됨. 또한 식별된 태스크들을 현실세계 예로 실증하고 이를 사용성 테스트에서 테스트 참가자에게 제공함

C. 사용성 벤치마크(Usability benchmarks)

• 사용성 벤치마크는 시스템 설계가 시작하기 전에 정의되는 정량적인 사용성 목표이며 5개의 기본 사용성 속성(또는 이들의 부속성)에 기반한다.
• 개발 대상 시스템을 위한 사용성 속성 값을 평가하기 위해 사용성 벤치마크가 필요함. 즉, 평가하고자 하는 각 사용성 속성을 위한 벤치마크 집합을 사용성 테스트에서(또는 사용자 만족도 질문지를 통해) 계산가능한 형식으로 정의해야 함. 아래 표의 예 참조
• 대부분의 사용성 벤치마크가 태스크 분석에서 명세된 태스크와 연결되므로 태스크 분석의 결과를 이 활동의 입력으로 함

 

사용성 속성	측정 수단	측정할 값	현 수준	수용가능한 최저 수준	타겟 수준	가능한 최고 수준	관측결과
일상적 사용에서의 성능	“Answer request” 태스크	태스크를 성공적으로 수행하는데 걸린 시간	2분53초	2분53초	1분30초	50초
첫 인상	질문지	평균 점수(–2 ~ 2)	-	0	1	2

[사용성 명세 표 샘플]

II. 사용성 설계 단계(Usability design phase)

일단 개발 대상 시스템이 지원할 태스크를 분석했다면 UI의 개념적 설계에 대한 첫 시도를 할 수 있다(이는 다음 반복 단계에서 평가되고 개선됨).

 

D. 개념적 설계(Conceptual design)

• 이 단계 동안 기본적인 사용자-시스템 상호작용(user–system interaction)을 정의하고 또한 상호작용이 일어나는 UI 및 콘텍스트(contexts)에서의 오브젝트들을 정의한다. 사용자 분석과 태스크 분석에서의 발견사항(findings)들이 개념적 설계를 위한 기초가 됨
• 이 단계의 산출물은 통상적으로 종이 프로토타입(예, 연필 스케치, 스크린 모형)과 UI의 동작을 기술하는 명세서이다.
• 개념적 설계 단계는 그 결과를 평가하는 것으로 마무리됨. 이 단계의 마지막 테스트는 사용자와 함께 종이 프로토타입의 사용성 테스트나 사용성 인스펙션을 실행하는 것임

E. 시각적 설계(Visual design)

• 개념적 설계를 완료한 후에는 UI 외양(appearance)을 정의하는 시각적 설계가 수행됨. 스크린과 다이얼로그 박스의 레이아웃, 색과 위젯의 사용, 그래프와 아이콘의 설계 등을 포함한 모든 상세사항을 커버한다.
• 시각적 설계를 위한 규칙 및 원칙들이 존재하며, 전문적인 스크린 설계자가 요구된다.
• 이 단계의 산출물로는 프로토타입, UI 외양의 구체적 명세, 개발되어야 하는 신규 위젯에 대한 명세 등이 있다.

프로토타이핑(Prototyping)

프로토타입이 UI 설계에 독점적인 것은 아니지만 개발 단계 초기에 사용성 테스팅을 수행하는데 유용함. 설계 프로세스에서 사용자 관여가 필요한 경우 추상적인 기술 명세서 보다는 시스템 프로토타입이 훨씬 의사소통에(사용자가 이해하는데) 효과적임. 적은 구현 노력으로 사용성 테스팅 수행을 돕는 프로토타이핑 기법에 아래와 같은 것들이 있다.

• 종이 모형(Paper mock-ups): 설계 프로세스 초기에 설계자가 사용자를 위한 종이 프로토타입(대개 연필로 그린 그림 또는 스크린 설계 인쇄물)을 생성. 설계자가 컴퓨터 역할을 함(즉, 그래픽 요소들간의 변천이 있을 때 사용자에게 다음 요소를 보여줌)
• 오즈의 마법사 기법(“Wizard of Oz” technique): 사람 전문가가 시스템 역할을 하며 사용자가 눈치채지 못하게 사용자의 요청에 답함. 즉, 사용자가 스크린과 정상적으로 상호작용하지만 소프트웨어 대신 개발자가 네트워크로 연결된 타 컴퓨터에 앉아 질의에 답한다. 사용자는 실제 소프트웨어 시스템과 작업하는 듯한 인상을 받음. 이 방법이 실제 소프트웨어 프로토타입을 구현하는 것 보다 저렴함
• 시나리오/스토리보드/스냅샷(Scenarios, storyboards, and snapshots): 시나리오는 특정 상황에서 시스템과 상호작용하는 사용자의 가공적 이야기를 기술. 스냅샷은 특정 시나리오에서 발생하는 상호작용을 캡쳐한 시각적 이미지. 스토리보드는 어떤 가능한 상황에서의 메인 액션들에 초점을 맞춘 일련의 스냅샷 시퀀스. 이것들은 설계가 실제 사용 맥락(a real context of use)에서 적절한지에 대해 설계팀이 고민할 수 있게 해 줌

III. 사용성 평가(Usability evaluation)

사용성 평가는 사용성 프로세스에서 중심이 되는 활동이며, 현 버전의 사용성 수준과 현 설계가 적절한지 아닌지 여부를 결정할 수 있다.

 

사용성 테스팅(Usability testing)

• 사용자 그룹과 실험실에서 사용성 테스트를 수행하고 그 결과를 추가 분석을 위해 기록하는 활동. 소프트웨어 시스템의 사용성은 실제 사용자로 그것을 테스트 하지 않고는 예측할 수 없음
• 먼저 시스템을 테스트 하는데 어떤 사용자 그룹을 이용할지 그리고 각 그룹에서 몇 명씩을 테스트 참가자로 모집할지 결정함. 이어서 참가자에게 수행하도록 요청할 테스트 태스크를 설계함(대개 태스크 분석 결과로부터 골라내어 가상의 현실 상황에 대입시킴)
• 테스트를 준비하고 테스트 참가자를 모집한 후 테스트를 실행함(이를 비디오 카메라나 오디오 레코더로 녹음하기도 함). 추가 분석을 위해 시스템에서의 사용자 행동을 기록하기도 함. 모든 테스트를 수행한 후에는 데이터를 분석하고 다음 반복 주기에 적용하기 위해 결과를 수집한다.

생각을 소리 내어 말하기(Thinking aloud)

• ‘형성 과정 평가(Formative evaluation)’는 상호작용의 어떤 상세 측면이 좋은지 그리고 상호작용 설계를 어떻게 개선할 수 있는지 배우려는 노력이며(즉, 제품을 점차 만들어 가는 것을 도움), 시스템이 구축된 후 개발 프로세스 끝에서 수행되는 ‘부가적 평가(summative evaluation)’와 반대한다.
• ‘생각을 소리 내어 말하기’는 사용성 테스트에서 ‘형성 과정 평가’를 수행하는 것을 돕는다. 즉, 테스트 참가자에게 사용성 테스트에서 시스템을 사용하는 동안 생각하는 바를 소리 내어 달라고 요청함. 참가자의 행동도 말로 표현케 하여 사용자 발언을 수집
• 사용성 테스트에서 수집된 사용자 발언은 시스템 상호작용을 최적으로 설계하는데 중요한 통찰력을 제공한다. 테스트 참가자의 사고 프로세스를 상술함으로써 숨은 사용성 문제가 드러날 수도 있음

휴리스틱 평가(Heuristic evaluation)

• 사용성 전문가가 자신의 상호작용 설계 경험 및 일반적으로 수용되는 사용성 가이드라인에 기반하여 문제를 지적함. 전문가는 사용성 테스팅을 통한 최종 사용자와는 다른 종류의 피드백을 제공함
• 휴리스틱 평가가 사용성 테스팅을 보완하는 것 일뿐 대체하는 건 아님. 특정 사용성 문제를 식별하기 위해서는 실제 사용자에 의한 사용성 테스팅이 반드시 수행되어야 함

공동 사용성 인스펙션(Collaborative usability inspection)

• 완성된 시스템, 설계, 또는 프로토타입을 최종 사용자 관점에서 체계적으로 검토하는 것. 개발자, 최종 사용자, 애플리케이션 또는 도메인 전문가, 사용성 전문가가 함께 팀을 이루어 이 검토를 수행한다.
• 공동 사용성 인스펙션은 휴리스틱 평가, 다원론적 사용성 워크쓰루, 전문가 평가 등의 특징과 기법을 활용하며 사용성 테스팅보다 저렴하고 빠르다.
• 효율성 외에도 여러 관점과 전문성을 가진 사람들이 테스트 오브젝트를 검토한다는 장점이 있음. 또한 여기 참가하는 개발자는 어떻게 소프트웨어 사용성을 높일 수 있는지에 대한 스킬과 노하우를 얻게 됨