Transcript User-centered Design & Task Analysis

사용자 중심 디자인과
업무 분석
나쁜 인터페이스
• ?
• Requires recall
over recognition
– want recognition
over recall
목차
•
•
•
•
•
•
복습
사용성 (Usability)
사용자 중심 설계(User-centered design)
설계 방법론
고객과의 관계
업무 분석
복습
사회/구조적
문제
업무
설계 / 디자인
(Design)
기술
인간
복습
“스프레드시트가 수많은 업무를 쉽게 해준다.”
업무
설계 / 디자인
(Design)
기술
인간
사회/구조적
문제
사용성의 요건들
• 학습의 용이성
– 반복할수록 사용이 더 빨라야함, 등
• Recall
– remember how from one session to the next
• Productivity
– 업무를 빠르고 효율적으로 수행해야함.
• 에러율의 최소화
– 에러가 났을 경우, 사용자에게 편리한 피드백으로 사
용자가 수정하기 쉽도록 해야함.
• 높은 사용자 만족도
– 성공에의 확신
사용자 중심의 반복적 설계
개발자는 사용자와 함께 개발한다.
사용자의 용어로 사고한다.
업무 과정을 이해한다.
기술 중심이나 feature driven을 지양한
다.
설계
• 모든 단계를 반복한다.
•
•
•
•
프로토타입
평가
전통적인 소프트웨어 공학의 개발론:
폭포수 모델 (Waterfall Model)
시작
응용프로그램
명세
분석
요구사항 명세
설계
시스템 설계
구현
완성
폭포수 모델 vs.
반복적인 사용자 중심 설계
• 관점의 차이
– 폭포수 모델은 사용자의 시
각을 고려하지 않는다.
• 폭포수 모델은 피드백의
반영이 불가능하다.
• 사용자가 곧 고객이다.
– 이는 완성 후에 수정으로
이어지고 이는 막대한 자금
을 필요로 한다.
시작
• 각 단계마다 10배 정도의 비
용이 소요된다.
• 반복 설계 모델에서는 이러한
문제점이 일찍 도출된다.
프로토타입
설계
응용프로그램
명세
분석
요구사항 명세
평가
설계
시스템 설계
구현
완성
왜 반복적 모델을 사용해야 하나?
• 거의 25%에 달하는 소프트웨어 프로젝트가 다음과 같은 이유로 실
패한다.
– 예산 초과 & management pulls the plug
– 완성은 되었으나, 배우거나 쓰기에 너무 어려움
• 해답은: 사용자 중심 설계! 왜?
– 사용과 학습에 편리해질 수록 제품은 더 잘 팔린다.
– 제품을 스케쥴에 맞출 수 있다. 학습에 드는 비용이 감소한다.
설계 (Design)
• 설계(design)은 요구사항(requirements)에 의해
만들어짐.
– ‘어떻게 구현할까’가 아니라
– ‘무엇을 구현할까’에 중심
• 설계는 제품을 나타낸다.(A design represents
the artifact)
– UI는 다음과 같은 것들을 포함해야 한다.
• 화면 스케치나 스토리보드
• 각 업무와 그 관계, 구조 등에 대한 흐름도(flow diagrams)나
개괄 등
일기쓰기Write essay
워드 프로세서 시작
• 실행 가능한 프로토타입
개요 작성
– 표현은 간단하고 단순해야 한다.
각 개요 심화
워드프로세서 시작
워드프로세서 아이콘 찾기
아이콘 더블클릭
개요 작서
가장 먼저 드는 생각 정리s
.
.
웹 설계
• 설계자는 사이트의 여러 레벨에 대해서 상
세하게 표현을 해야 한다.
• Web sites are iteratively refined at all
levels of detail
사이트 맵
스토리보드
Schematics
선구현
Mock-up
설계 과정
문제점의 발견
디자인 실험
설계 개선
제품
설계 과정: 문제점의 발견
요구사항, 필요성 평가
문제점의 발견
– 고객의 기대 이해
– 프로젝트의 범위 한정
디자인 실험
설계 개선
제품
– 사용자 특성 이해해
– 현존하는 인터페이스
와 경쟁 응용 프로그
램 등 평가
사용자 이해
• 어떻게 사용자가 작업하나?
– 업무 분석, 인터뷰, 관찰 등
• 어떻게 사용자가 생각하나?
– 인간 지각에 대한 이해
– 사용자가 수행하는 업무를 관찰한다.
• 어떻게 사용자가 UI를 사용하고 상호작용
하나?
– 관찰하라!
실패한 설계의 예
• BART의 자동매표기
– 사용자가 BART 표를 사고, 요금을 낼 수 있도
록 한다.
– ATM 카드, 신용카드, 현금 등을 받는다.
실패한 설계의 예
• BART의 자동매표기
– 사용자가 BART 표를 사고, 요금을 낼 수 있도록 한다.
– ATM 카드, 신용카드, 현금 등을 받는다.
• 문제점
(?)
– 수행이 단지 한 방향으로만 이루어짐
• 표 종류 결정 -> 요금 방법 결정 -> 결제 -> 구매
– BART Plus표는 $28 이상인데, 사용자가 최소 $1이상
넣기 전에는 이를 알려주지 않는다.
• 일반 BART 표로 바꿀 수 없다.
– 결제 순서 / 카드 삽입은 표준이 아니다.
– large dismiss transaction button does nothing
他山之石
• 편리한 기계를 만드는데 실패함.
• Did the designers understand/care
– range of customers using the machine
– what tasks they would want to carry out
– some would find the behavior of the machine
disconcerting
• 어떻게 우리는 이러한 문제점을 피해야 할까?
– “사용자 요구 사항이 무엇인가?”에 관한 분석
업무 분석 (Task Analysis)
• 다음에 대한 정의
– 예상되는 사용자는 누구인가?
– 예상 사용자가 수행해야 하는 작업은 무엇인
가?
• 현재 실존하는 작업에 관한 관찰
• 실제 사용에 대한 시나리오를 작성한다.
• 소프트웨어를 작성하기 전에 새로운 아이
디어를 정리해본다.
왜 업무 분석을 해야하나?
• 다음과 같은 경우 시스템이 실패할 수 있다.
– 사용자가 필요로 하는 작업을 시스템이 지원하지 않
는 경우
– 사용자에게 적합하지 않은 시스템인 경우
• “시스템은 사용자의 업무에 정확하게 부합되어야만 한다.”
• 왜 “좋은” 인터페이스에 대해 정의하지 않는가?
– 사용자와 업무의 종류는 다양하다.(거의 무한대)
– 보통 가이드라인 자체가 막연해진다.
• 예. “적당한 피드백을 보낸다.”
질의 리스트
• 누가 시스템을 사용할 것인가?
• 현재 사용자가 수행하는 작업은 어떤 것인
가?
• 어떤 작업이 필요한가?
• 어떻게 작업에 대해 학습할 수 있는가?
• 어디에서 작업이 이루어지는가?
• 사용자와 데이터 사이의 관계는 어떠한가?
질의 리스트
• 고객이 갖고 있는 다른 도구들은 어떤 것
들이 있는가?
• 어떻게 사용자들은 다른 사람들과 의사소
통할까?
• 얼마나 자주 작업을 수행하나?
• 이 작업의 시간적인 제약이 있는가?
• 어떤 잘못 된 것이 있을 때 어떻게 되는가?
누구?
• Identity?
– in-house 또는 특정 집단의 사용자는 쉽다.
– 다양한 제품의 설계를 위하여 여러 특징을 가
지는 사용자에 대해 이해해야 한다.
•
•
•
•
배경
기술
작업 습관과 기호 (preferences)
신체적 특징
– 키, 몸무게 등
누구? (BART)
• Identity?
– BART를 타는 사람들
• 직장인, 학생, 장애인, 노약자 등
• 배경
– ATM이나 신용카드를 갖고 있음
– BART 자동 매표기를 사용한다.
• 기술
– 어떻게 ATM에 카드를 넣을지 알아야 함.
– 어떻게 BART 표를 살 지 알아야 함.
누구? (BART)
• 작업 습관이나 기호
– 중요하지 않음
• 신체적 특징
– 다양한 키  너무 높거나 낮으면 안됨!
사용자와 대화(對話)
• 실제 사용자들을 찾아라.
• 그들과 대화하라.
– 그들이 하는 일을 분석하라.
– 새로운 시스템이 이를 어떻게 지원할지 고민
하라.
• 그들이 너무 바쁘면?
– 그들의 시간을 사라!
• 예. 티셔츠, 머그잔 등
어떤 작업이 필요한가?
• 자동화와 새로운 기능 모두 중요하다.
• Relative importance of tasks?
• 사용자를 관찰하라.
– 예. 온라인 지불 시스템
• 작은 치과에서 자동 지불 시스템을 도입하였다.
• 하지만 사무원들은 이 시스템으로 힘들어졌다.
• 기존 노트에는 손으로 여백에 추가의 내용을 기입이 가
능했었지만, 새로운 자동 시스템에서는 이러한 기능이
없었다.
– 예. A라는 환자의 보험은 다른 환자보다 길게 적용해야 함.
어떤 작업이 필요한가? (BART)
• 기존 작업?
– 새 표를 사기 위해 현금을 냄 cash to buy new ticket
– 지금 갖고 있는 표에 추가 금액을 내고 새로운 표로 바꿈 cash
to add fare to existing ticket
– 현금이나 신용카드로 BART Plus 표를 삼 cash or credit to buy
a BART Plus at window
• 새로운 작업?
– 현금, 신용카드, ATM 카드 등을 지원하여
• 새로운 표를 사고 buy new ticket
• 기존 표에 추가 금액을 내며 add fare to existing ticket
• BART Plus 표를 산다. buy a BART Plus ticket
• 상세도가 매우 다양하다.
어떤게 작업을 학습할까?
• 사용자가 알아야만 하는 것은 무엇인가?
• 사용자는 연습을 해야만 하는가?
– 학교에서
– 일반적인 지식/기술
– 특별한 기술과 연습
어떤게 작업을 학습할까? (BART)
• 단순하게 사용할 수 있어야 한다.
Walk up & use system (?)
– 많은 배경 지식이나 연습을 가정할 수 없다.
can’t assume much background/training
• 연습?
– 시간 소모가 많으면 안됨.
too time consuming
• 기존 방법과 비슷하고 단순해야 한다.
– BART 기계
– ATM 기계
어디서 수행되나?
• 사무실, 연구실?
point of sale?
• 사용자에게 영향을 미
치는 환경인가?
• Customers under
stress?
• 신뢰성이 필요한가?
• 젖기 쉬운 환경이나
더러운 환경 등?
• 간단한 다과?
• 조명?
• 소음?
어디? (BART) 기차역
• 시끄러움
– 음성 I/O는 부적절
• 다른 사람이 훔쳐볼 수 있음
– 보안 적용 불가
– 개인 식별 번호는 은밀히 이루어져야 한다.
• 소리 등으로 확인하지 말 것
• 조명이 어두움.
– 사용자가 메시지를 읽기 쉽도록 한다.
사용자와 데이터 간의 관계?
• 개인적인 데이터
– 항상 같은 기계를 사용하는가?
– 아니면 여러 기계 중 하나를 사용하는가?
• 공통된 데이터
– 여러 명이 동시에 사용하는가?
– 여러 사용자들이 한번에 한 명씩 사용하는가
passed sequentially between customers?
• 원격 접속이 필요한가?
• 데이터 접속에 제한된 권한이 필요한가?
데이터 관계 (BART)
• 개인적 데이터
– 사용자는 여러 기계 중 임의의 한 기계를 이용한다.
– BART 카드에 정보를 기록한다.
• 공통된 데이터
(?)
– 요금 체계 (예. BART Plus에는 얼마?)
– 동시에 사용됨
• 데이터 접속에 제한된 권한이 필요한가?
– 사용자는 자신의 ATM 카드나 신용카드만 사용할 수
있음
• 원격 접속은 필요 없음
• More than just compatibility
• How customer works with collection of tools
– example: automating lab data collection
•
•
•
•
•
how is data collected now?
by what instruments and manual procedures?
how is the information analyzed?
are the results transcribed for records or publication?
what media/forms are used and how are they
handled?
다른 도구들 (BART)
• 없음
사용자끼리 어떻게 의사소통하나?
•
•
•
•
누가 누구와?
무엇에 대해?
조직 계층을 따라서? 아니면 반대로?
예: assistant to manager
– installation of computers changes
communication between them
– people would rather change their computer
usage than their relationship [Hersh82]
진보된 지하철 매표기: 홍콩
요약
• 사용자 중심 설계는 기존 방법론과 다르다.
– leads to solving problems up front (cheaper)
• 사용자를 파악하고 그들과 함께 설계하라
– 설계 전에 다음 질문들에 답하라
• 누가, 무엇을, 어디에서, 언제, 얼마나 자주 이
용하는가?
• 고객과 데이터 간의 관계는 무엇인가?
• 고객들이 갖고 있는 다른 도구들은 무엇인가?
• 오류 발생시 어떻게 되는가?