사용자 중심 디자인과 업무 분석 나쁜 인터페이스

사용자 중심 디자인과 업무 분석

나쁜 인터페이스 • ? • 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 [Hersh 82]

진보된 지하철 매표기: 홍콩

요약 • 사용자 중심 설계는 기존 방법론과 다르다. – leads to solving problems up front (cheaper) • 사용자를 파악하고 그들과 함께 설계하라 – 설계 전에 다음 질문들에 답하라 • 누가, 무엇을, 어디에서, 언제, 얼마나 자주 이 용하는가? • 고객과 데이터 간의 관계는 무엇인가? • 고객들이 갖고 있는 다른 도구들은 무엇인가? • 오류 발생시 어떻게 되는가?