사용자 중심 디자인을 구성하는 요소에 대한 명확한 합의는 없습니다. 그러나 1980년대에 IBM의 John Gould와 그의 동료들은 가장 공통적으로 사용되는 정의를 포함하는 사용성을 위한 디자인[GOU88]이라는 접근 방식을 개발했습니다. 이 접근 방식은 수많은 대화식 시스템, 특히 IBM의 1984 올림픽 메시지 전달 시스템[GOU87]의 실제 경험으로부터 개발되었습니다. 이 접근 방식에는 다음과 같은 네 가지 기본 컴포넌트가 있습니다.
Gould는 개발자가 사용자를 결정하고 사용자를 가능한 제일 초기부터 관련시켜야 함을 제안합니다. Gould는 사용자, 사용자의 타스크 및 요구사항의 숙지를 위한 다양한 방법을 제안합니다.
· 사용자와 대화
|
· 고객 위치 방문
|
· 사용자 작업 관찰
|
· 사용자 작업 녹화
|
· 작업 조직 학습
|
· 직접 체험
|
· 작업 과정에서 사용자가 생각을 말하도록
유도
|
· 참여 디자인
|
· 디자인 팀에 전문가 사용자 포함
|
· 타스크 분석 수행
|
· 설문조사 및 질문지 사용
|
· 테스트 가능 목적 개발
|
Rational Unified Process(RUP)에서 워크샵은 여러 핵심 단계에서 사용되지만 정확한 그림을 형성하려면 Gould가 설명한 활동 유형으로 이를 보충해야 합니다.
(이와 관련 논의의 일부로, 사람들은 종종 수행하는 대상을 수행하는 방법과 상당히 다르게 설명합니다. 작업 배치 또는 "분명하지 않은" 신문 스크랩의 존재와 같이 일반적으로 수행되는 타스크 및 중요하지 않은
세부사항은 "공식적으로" 현재 프로세스의 일부가 아니므로 잊혀지거나 생략됩니다.)
개발 초기부터 사용성 타스크를 병행하여 수행해야 합니다. 사용성 타스크에는 사용자 인터페이스 스케치 및 사용자 안내서나 온라인 도움말 초안 작성이 포함됩니다. 또한 Gould는 사용성이 한 그룹의
책임이어야 한다고 지적합니다.
통합 디자인의 중요 특성은 프레임워크에서 자세한 사용자 인터페이스 디자인까지 전체 접근 방식을 초기 단계에 개발하고 테스트하는 것입니다. 이 특성은 사용자 중심 디자인과 다른 순수 점진적 기법
사이의 중요한 차이점입니다. 이 특성을 통해 나중 단계에서 수행되는 점진적 디자인이 프레임워크와 매끄럽게 통합되고 사용자 인터페이스의 모양, 용어 및 개념이 일관성 있게 됩니다.
RUP 내에서 도메인 모델을 사용하여 이 프레임워크를 설정하면 사용자 인터페이스에 나타나는 모든 용어 및 개념이 일반 비즈니스와 특정 사용자에게 알려지고 이해됩니다. (특정 사용자 그룹에만 관련된 도메인
모델의 서브세트도 있을 것입니다. 해당 서브세트를 쉽게 식별할 수 있게 도메인 모델을 구성하도록 주의해야 합니다.) 사용자 인터페이스 디자인이 진행됨에 따라 여러 도메인 클래스가 사용자 인터페이스 요소로
표시됩니다. 사용자 인터페이스 요소 및 해당 요소 간 관계는 도메인 모델과 일관성이 있어야 하고, 디자인 중인 시스템의 모든 파트에 걸쳐 일관되게 표시되어야 합니다. (이를 통해 사용자를 지원하고 사용자 인터페이스
컴포넌트의 재사용을 개선합니다.)
초기 사용자 테스트는 초기 스토리보딩 및 충실도가 낮은 프로토타입의 초기 개발을 의미합니다. 충실도가 높은 프로토타입은 프로세스의 나중에 나옵니다.
스토리보드와 유스 케이스를 함께 사용하여 디자인 중인 시스템의 구체적 사용 시나리오를 작성할 수 있습니다. 해당 시나리오에는 양식 설명, 예시 설명(예시를 위한 사용자 인터페이스 모형 사용)을 사용할 수 있고,
스토리보드, 둘러보기(사용자와 함께) 및 사용자 초점 그룹은 대부분의 소프트웨어 개발자에게 익숙하지 않은 접근 방식입니다. 그러나 이 접근 방식은 구현이 진행된 이후 부적절한 디자인 또는 잘못된 요구사항을 발견하는
것보다 훨씬 비용 효과적입니다.
객체 지향 개발은 반복 프로세스와 동의어가 되고 있습니다. 반복 디자인은 이해의 정제가 필요하고 요구사항이 변화하는 문제에 잘 맞습니다. 예상대로 반복 디자인은 사용자 중심 디자인의 핵심 컴포넌트입니다.
시간에 따라 변화하는 사용자의 요구 뿐만 아니라 다양한 요구사항을 처리할 수 있는 디자인 솔루션 생성의 복잡한 특성으로 인해 핵심 컴포넌트가 됩니다.
사용자 중심 방법에서 반복 디자인은 통합 프레임워크 내에 수행됨에 주의하십시오. 합의된 프레임워크 외부의 점진적 개발은 "땜질식" 솔루션이 될 수 있으므로 일부러 사용하지 않습니다.
대화식 시스템의 성공은 사용자 요구를 수용하는 능력에 의존합니다. 이는 다양한 사용자 커뮤니티의 식별 뿐 아니라, 개별 사용자의 스킬, 경험 및 환경 설정 범위의 인식을 의미합니다.
개발자와 관리자는 사용자의 요구를 이해한다고 느끼지만 실제로는 거의 그렇지 않습니다. 이들은 사용자가 타스크 수행에서 원하는 방식이 아니라 타스크 수행에서 해야 하는 방식에 초점을
맞춥니다. 대부분의 경우 선호도의 문제는 자체로도 중요하지만, 통제 가능하다고 느끼는 그 이상입니다. 선호도는 또한 경험, 능력 및 사용 방식에 따라 결정됩니다. 이러한 문제는 디자인 프로세스에서 대화식
시스템의 인간 중심 디자인 프로세스라는 제목의 국제 표준 [ISO 13407]을 보증하는 데 매우
중요하게 고려됩니다. 표준 및 관련 문제는 이 페이지의 나머지 부분에서 개괄적으로 논의됩니다.
사용자는 사용자 인터페이스를 통해 시스템을 이해하고 상호작용합니다. 인터페이스에 제공된 개념, 이미지 및 용어는 사용자의 요구에 적합해야 합니다. 예를 들어 고객이 티켓을 구매하는 데 사용하는 시스템은 티켓 판매
직원이 전문적으로 사용하는 시스템과 매우 다릅니다. 기본 차이점은 요구사항이나 자세한 유스 케이스에 있는 것이 아니라 사용자의 특성 및 시스템이 작동하는 환경에 있습니다.
아래 그림 1처럼 사용자 인터페이스는 최소 2차원인 컴퓨터 및 도메인 경험에 따라 잠재적으로 광범위한 경험도 제공해야 합니다. 컴퓨터 경험에는 컴퓨터에 대한 일반적인 숙지 정도 뿐 아니라 개발 중인 시스템 경험도
포함됩니다. 컴퓨터 또는 문제점 도메인에 대한 경험이 부족한 사용자(그림의 왼쪽에 표시)는 전문가 사용자(그림의 오른쪽에 표시)에 대한 사용자 인터페이스와 크게 다른 접근 방식을 필요로 합니다.
그림 1: 학습 용이성 대 사용 용이성에 대한 컴퓨터 및 도메인 경험의 영향
서투른 사용자가 시간이 지나면 전문가가 될 것이라고 가정할 수는 없음을 명심하십시오. 낮은 사용 빈도, 동기 부족 또는 지나친 복잡도와 같은 여러 요소로 인해 전문가가 되지 못할 수 있습니다. 반대로 일부
시스템에는 너무 많은 전문가 사용자가 있을 수 있습니다. 이렇게 되는 요소는 훈련, 높은 사용 빈도 또는 높은 동기 부여(작업 종속성)가 있을 수 있습니다. 사용자 인터페이스 디자인에 대한 이러한 일부 문제 및
영향이 표 1에 표시되어 있습니다.
|
낮음
|
높음
|
컴퓨터 경험
|
단순 질문 및 응답, 간단한 양식 입력, 웹(하이퍼링크됨) 또는 메뉴 인터페이스 스타일
|
복잡한 양식 입력, 웹(하이퍼링크됨) 또는 메뉴 인터페이스 스타일(질문과 응답 또는 간단한 양식 입력은 숙련된 사용자에게 매우 실망스러울 것임)
|
도메인 경험
|
공통 용어 및 개념
|
도메인 관련 용어 및 개념
|
훈련
|
학습 용이성에 초점을 맞춤(일관됨, 예측 가능함, 외우기 쉬움)
|
사용 용이성에 초점을 맞춤(직접적, 사용자 정의 가능, 비침입식)
|
사용 빈도
|
배우고 기억하기 쉬움, 단순 인터페이스 스타일
|
사용하기 쉬움, 사용자 제어를 허용하는 여러 단축키 및 기법
|
동기 부여
|
사용에 대한 보상, 복잡하지 않고 강력함.
|
여러 고급 및 사용자 정의할 수 있는 기능이 있어 복잡함.
|
표1, 사용자 인터페이스 디자인에 영향을 주는 특정 요소
대화식 시스템은 적절한 범위의 사용자 경험 및 환경을 제공하도록 디자인되거나, 디자인 범용을 제한하는 단계를 수행해야 합니다. 예를 들어 훈련을 사용하여 복잡한 시스템의 학습 용이성 요구사항을 줄일 수 있습니다.
또는 시스템에서 시스템 영역을 줄이면 사용자의 핵심 요구사항을 보다 잘 만족시킬 수 있습니다(Alan Cooper 저, The Inmates Are Running the Asylum [COO99]의 제안).
사용자 중심 디자인의 일부로 사용자의 스킬 및 실제 속성을 고려해야 합니다. 이러한 문제는 점차 법률로 제정되고 있습니다. 대부분 장애가 있는 사용자를 수용하는 방향으로 진행되고 있습니다. 그러나
일반적으로 광범위한 사용자가 액세스할 수 있는 시스템을 만드는 것이 전체 사용자 커뮤니티에게 이득이 됩니다.
아래 표에는 세계 여러 곳의 관련 법률 및 자원이 표시되어 있습니다.
표 2a, 국가, 지역 또는 기관별 장애 관련 법률
법률 외에도 사용자 중심 디자인 및 사용자 인터페이스 디자인은 점차 아래 표시된 표준화의 대상이 되고 있습니다.
설명
|
웹 사이트/표준
|
ANSI
|
www.ansi.org
|
ANSI
ANSI-HFES
ANSI-NSC
|
ANSI 및 HFES(Human Factors and Ergonomics Society)는 다양한 결합 표준을 발표했습니다. ANSI에도 누적 스트레스 증후군(반복 운동 손상,
RSI라고도 함)의 제어 및 방지와 관련된 ANSI-NSC Z365가 있습니다.
ANSI는 IISP(Information Infrastructure Standards Panel)의 일원으로 사용자-컴퓨터 상호작용에 대한 표준을 기초 작업하고 있습니다.
|
ISO
|
www.iso.ch
|
ISO 9241
|
다양한 일련의 표준이 주로 워크스테이션의 인간 공학을 고려함은 물론 사용성에 대한 안내를 포함하고 있습니다(11부). 또한 개발 중인 ANSI-HFES 200의 기본이 됩니다.
|
ISO 10075: 1991
|
정신적 워크로드와 관련된 인간 환경 공학 규칙
|
ISO 17041-1: 1995
|
텍스트 편집을 위한 커서 제어
|
ISO 11581
|
아이콘 및 포인터를 처리하는 개발 시리즈
|
ISO 13407: 1999
|
대화식 시스템의 인간 중심 디자인 프로세스 표준
|
표 2b, ANSI 및 ISO 사용자 인터페이스 및 사용자 중심 디자인
표준
사용자 요구에 맞는 시스템을 개발하려면 요구사항 분석에 많은 노력이 필요합니다. 사용자 중심 디자인에서 이 노력은 일반 사용자에게 초점을 맞춤니다.
비즈니스 모델링 규칙은 비즈니스 작업자(비즈니스 내부 인원) 및 비즈니스 액터(비즈니스 외부 인원)의 모델링을 포함합니다.
사용자 중심 디자인의 실제 강조해야 할 부분은 위에서 언급된 중간 산출물에 설명된 역할을 수행할 실제 인원의 요구사항을 이해하는 것입니다. 특히 소프트웨어 시스템을 디자인하기 편리하도록 가상의 사람을
디자인하지 않아야 합니다. 사용자를 설명하는 중간 산출물은 사용자와 실질적으로 직접 접촉한 후에만 작성해야 합니다. 사용자 중심 디자인에서 이 직접 접촉은 정황적 질문이라고도 하는 프로세스의
파트입니다. Hugh Beyer 및 Karen Holtzblatt(저서 Contextual Design, [BEY98]에서)는 정황적 질문의
전제를 다음과 같이 설명합니다.
"...고객이 작업하는 장소로 가서 고객이 일하는 것을 관찰하고 작업에 대해 고객과 대화합니다."
(일부 구체적 예제는 이미 사용자에게 초점을 맞춤에 나열되어 있습니다.) 이 접근 방식은 시스템 요구사항 뿐만 아니라 사용자 자체, 사용자의 타스크 및
환경을 보다 잘 이해하는 데도 사용됩니다. 각각에는 고유의 속성이 있으며 함께 사용되는 경우 사용 컨텍스트라고 합니다. 이 내용은 아래 설명된 사용자 중심 디자인의 ISO 표준에 자세히 설명되어 있습니다.
ISO의 대화식 시스템의 인간 중심 디자인 프로세스(Human-centered design processes for interactive systems) [ISO13407]는 디자인의 첫 단계를 사용 컨텍스트의 이해 및 지정으로 식별합니다. 속성은 다음과 같이 제안됩니다.
컨텍스트
|
속성
|
타스크
|
시스템의 사용 목적, 성능 빈도 및 지속 기간, 상태 및 안전 고려사항, 활동 할당, 사람과 기술 자원 간의 조작 단계. 타스크는 제품이나 시스템에서 제공되는 함수 및 기능
측면에서만 설명되면 안됩니다.
|
사용자(각각 유형 및 역할이 서로 다름)
|
지식, 스킬, 경험, 교육, 훈련, 실제 속성, 습관, 선호, 기능.
|
환경
|
하드웨어, 소프트웨어, 자료, 실제 및 사회 환경, 관련 표준, 기술적 환경, 주위 환경, 법률적 환경, 사회 및 문화 환경.
|
표 3: 사용자 중심 디자인에 대한 ISO 표준의 사용 컨텍스트
사용자 컨텍스트를 두 개의 구성 파트(사용자 유형 및 역할)로 분할한 다음 모든 네 개의 컨텍스트 간의 관계를 고려하는 것이 유용합니다.
그림 2: 컨텍스트 간 관계
그림 2는 모든 타스크가 환경 내에서 사용자가 가지는 역할 안에서 수행되고 있음을 표시합니다. 이러한 컨텍스트는 표 4에서와 같이 RUP 중간 산출물에 해당합니다.
ISO 13407 컨텍스트
|
RUP 중간 산출물
|
환경
|
|
사용자
|
|
역할
|
-
상위 레벨:
-
비즈니스 액터 (외부 사용자),
-
비즈니스 작업자 또는 비즈니스 시스템 (내부 사용자)
-
세부사항:
|
타스크
|
|
표 4, ISO 사용자 중심 디자인 표준 컨텍스트 및 해당 RUP
중간 산출물
이러한 컨텍스트 각각은 적절한 사용자 인터페이스의 디자인에 큰 영향을 줄 수 있습니다. 따라서 잠재적으로 상당히 많은 변환에 직면하고 있습니다. 소규모 시스템의 경우에도 두 개의 환경(예: 사무실 및 고객
사이트), 세 개의 사용자 유형(판매 초보자, 판매 전문가 및 관리) 및 여섯 개의 역할(전화 판매 지원자, 외부 영업 담당자 등)이 있을 수 있습니다. 즉, 실제 조합 설정은 대개 훨씬 작겠지만 타스크마다 최대
36개의 변경이 발생할 수 있습니다.
타스크는 개별적으로 명확하게 설명되어야 하지만 하나의 설명이 모든 변환에 적용될 수는 없습니다. 한 접근 방식은 역할 설명에 사용자 및 환경 컨텍스트를 포함하는 것입니다. 이 접근 방식은 Constantine
and Lockwood [CON99]에 의해 채택된 솔루션입니다. 이 접근 방식은 역할, 사용자 및 환경의 각 중요 변환에 대해 별도의 "사용자 역할"을 제공한 후 단순한 명사가
아니라 설명 구문으로 결과 사용자 역할의 이름을 지정하는 것입니다. 예를 들어 "고객" 역할을 "일반 고객", "웹 고객", "단골 고객" 및 "고급 고객"과 비교합니다.
각 사용자 역할 설명에는 역할 자체 및 역할의 사용자(역할 담당자(incumbent)라고 함)와 환경의 세부사항이 포함됩니다. 사용자 역할에 해당하는 액터를 선택하여 이 접근 방식을 RUP에 채택할 수 있습니다.
시나리오, 유스 케이스 및 기본 유스 케이스라는 용어는 어느 정도 중첩되며 서로 다른 디자인 접근 방식에 사용되어 약간 다른 의미를 가집니다. 예를 들어 RUP에서 "시나리오"는 유스 케이스 인스턴스, 즉 가능한
기본 및 대체 플로우를 통한 특정 "경로"만을 의미합니다. 그러나 일반적으로 사용자 중심 및 사용자 인터페이스 디자인 방법에서는 시나리오를 단순 이벤트 플로우보다 훨씬 많은 세부사항이 포함된 사용 계층으로
설명합니다. 이 추가 정보는 나중 디자인 단계에 관련되지 않을 수 있지만 사용자, 타스크 및 환경을 이해하는 파트를 형성합니다. 따라서 시나리오는 비즈니스 모델링 규칙에서 광범위하게 사용될 수 있지만(스토리보드 및 역할 연기법) 초점은
요구사항 규칙의 유스 케이스로 이동합니다.
그림 3은 이 중첩의 특징을 표시합니다. 맨 위 스케일은 함께 변화하기 쉬운 여러 서로 다른 요소를 통합합니다. 예를 들어 목적이 요구사항으로 이동할수록 구조는 대개 보다 정규화됩니다. 사용자 역할이
기본 유스 케이스를 약간 더 특정하게 만들고(이전 섹션 참조) 보다 공식적인 구조를 가지므로 기본 유스 케이스는 일반 유스 케이스의 오른쪽에 나타납니다.
그림 3: 시나리오와 사용자 중심 디자인 유스 케이스 간 개념 중첩
시스템 유스 케이스와 기본 유스 케이스의 차이점은 예제를 통해 가장 잘 설명됩니다. 표 5는 Constantine and Lockwood의 사용 소프트웨어[CON99]의 유스 케이스를 표시합니다.
사용자 조치
|
시스템 응답
|
카드 삽입
|
자기선 읽기
파인트(pint) 요청
|
PIN 입력
|
PIN 확인
트랜잭션 옵션 메뉴 표시
|
키 누르기
|
계정 메뉴 표시
|
키 누르기
|
금액 입력 메시지 표시
|
금액 입력
|
금액 표시
|
키 누르기
|
카드 반환
|
카드 받기
|
현금 지급
|
현금 받기
|
|
표 5: ATM에서 현금을 인출하는 일반 유스 케이스
이 예제는 액터와 시스템 간의 이벤트 시퀀스를 자세히 설명합니다. 두 열 사이에 사용자 인터페이스를 나타내는 세로 선을 사용합니다. Constantine과 Lockwood는 이 기본 유스 케이스 스타일을 권장했지만
이 특정 유스 케이스는 기본 유스 케이스가 아님에 유의하십시오. 이 유스 케이스는 상호작용의 구문 세부사항, 즉 상호작용의 발생 방식을 기반으로 하기 때문입니다. 기본 유스 케이스는
시맨틱이라고 하는 상호작용 자체에 초점을 맞춥니다. 표 6은 상호작용의 기본 버전입니다.
사용자 의도
|
시스템 책임
|
자체 식별
|
ID 확인
선택사항 제공
|
선택
|
현금 지급
|
현금 받기
|
|
표 6: ATM에서 현금을 인출하는 기본 유스 케이스
이 유스 케이스는 현금 인출 상호작업의 핵심을 캡처합니다. 사용자 조치 및 시스템 응답 표제는 사용자 의도 및 시스템 책임으로 교체되어 강조되는 변경을 반영합니다. 우수한 인터페이스 디자인은 사용자
목적 및 의도에 중점을 두며, 기존 유스 케이스에서는 이 부분이 숨겨지는 경우가 많습니다. 기본 유스 케이스는 특히 다음 경우에 유용합니다.
-
디자인 제한조건이 거의 없음(예: 은행 카드 사용의 내포된 디자인 제한조건이 false임)
-
다른 식별 방법(예: 보안 인터넷 액세스)을 사용하도록 시스템을 확장할 수 있음
-
해당 제한조건이 없는 프로젝트에서 나중에 재사용하기 위해 디자인 제한조건 없이 유스 케이스를 작성하려고 함.
그러나 기본 유스 케이스에는 결함이 있습니다. 표 5에서와 같이 완벽하게 직접적인 유스 케이스는 본질적으로 상당한 논쟁의 대상이 될 수 있습니다. 예를 들어 카드를 삽입하면 고객이나 계정이 식별됩니까?
Constantine and Lockwood는 이 작업을 고객 식별로 해석했지만 대부분의 기존 ATM에서는 이 작업은 나중 단계입니다. 망막 스캔 및 지문 식별 등의 최신 기술의 관점에서 이 결정은 신중한 결정이
될 수도 있고 부주의한 결정이 될 수도 있습니다. 이 경우에는 결과적으로 둘 이상의 계정을 보유한 고객이 수행해야 할 추가 선택이 필요합니다.
기본 유스 케이스의 다른 결함은 추상적 특징 때문에 사용자와 기타 이해 당사자(stakeholder)가 검토하기에 적합하지 않다는 것입니다. 이 문제 파트는 기본 유스 케이스를 다시 사용자 조치를 나타내는 구체적
양식으로 변환해야 하기 때문에 발생합니다. 구체적 용어로 상호작용을 설명하는 시나리오를 작성하여 디자인 모델이 사용 가능하면 이 작업을 수행할 수 있습니다(내부 오브젝트 협업이 아니라 사용자 시스템 상호작용을
고려하지만 유스 케이스 실현(realization)과 비슷한 개념).
요약하면 다음 경우에는 기본 유스 케이스를 빌드하지 않는 것이 좋습니다.
-
사용자 인터페이스 기술이 의도적으로 크게 제한됨(예: 시스템에 은행 카드만 사용해야 함)
-
사용자가 보다 요약된 유스 케이스를 이해하는 데 필요한 시간에 비해 예상 이점이 과대 평가됨.
RUP는 기본 유스 케이스를 명시적으로 참조하지 않지만 타스크: 사용자
인터페이스 디자인에서 기본 유스 케이스가 시작점으로 사용된 후 사용성 요구사항을 고려하여 개발되고 논의되어 스토리보드(가이드라인: 스토리보드 참조)를
작성합니다.
즉, 상호작용을 의미하는 시맨틱만 남도록 모든 디자인 또는 현재 구현 세부사항이 제거됩니다. 그런 다음 다양한 디자인 대체가 검토될 때 구문상의 세부사항(상호작용 발생 방식)이 기본 유스 케이스에
실현(realization) 유형으로 추가됩니다. (각 대체 디자인은 실제로 동일한 기본 유스 케이스의 실현(realization)입니다.)
그런 다음 스토리보드를 타스크: 사용자 인터페이스 프로토타입 생성의 입력으로 사용하여 사용자 인터페이스 프로토타입을 개발할 수 있습니다.
|