작업분석작업분석(Task Analysis)(Task Analysis)

작업분석 작업분석 (Task Analysis) (Task Analysis)

숙명여자대학교

임순범

교재



교재

 “ 더 나은 사용자 경험 (UX) 을 위한 인터랙션 디자인” , 댄 새퍼 , 에이콘 , 2008

 4 장 . 디자인 리서치 [p.122~126]

 5 장 . 인터랙션 디자인의 도구 [p.135~148]

 인터페이스 디자인을 위한 사용자와 태스크 분석 , J. Redish, 방수원 역 , 한 솜미디어 , 2003

 11 장 . 수집한 데이터 분석과 제시 [p.369~406]

 Univ.of Washington, James Landay 교수 강의노트

작업분석 (Task Analysis)



개요

 탐색 : 사용자가 누구인지 ? 수행하려는 작업이 무엇인지 ?

 작업의 실행현장을 관찰하고 ,

 실제 사용 시나리오를 작성한다 .



목적

 새로운 아이디어를 소프트웨어 / 콘텐츠 개발 전에 시험

 즉 , 디자인 과정의 초기단계 (early stage) 에서 문제점 파악



시스템 실패 원인

 사용자에게 필요한 작업을 하지않거나 사용자에게 적합하지 않다 .

=> “ 시스템은 반드시 사용자 작업에 맞아야 (match) 한다 .”

User Research 데이터 정리  작업분석



데이터의 정렬

 각종 문서 , 메모 , 사진 , 혹은 기억

 문서 , 스프레드시트 , 표 , 포스트잇 등의 형태

 데이터를 의미 있게 분류 : 개념적인 모델링

 디자인적인 함의를 추출



사용자 조사 데이터의 분석

 데이터 분석을 위한  작업분석 질문항목

 각종 문서 및 메모를 분류하여 정리  어피니티 다이어그램

 최대한 많은 아이디어 도출  브레인 스토밍



문서화 및 활용

 문서화 : 작업목록 , 워크플로우 , 유스케이스

 작업분석의 디자인 활용 : 페르소나 , 시나리오 , 스케치 , 스토리보드

분석 - 작업 분석 질문 (Questions)



James Landay 강의노트 , Univ.of Washington

1) 누가 (who) 시스템을 사용할 것인가 ? 2) 어떤 (what) 작업을 수행할 것인가 ? 3) 작업방법은 어떻게 배울것인가 (learn)?

4) 어디서 (where) 작업이 수행될 것인가 ?

5) 사용자와 데이터의 관계 (relationship) 는 무엇인가 ? 6) 사용자가 다른 도구 (tools) 를 사용하는가 ?

7) 사용자는 서로 어떻게 의사소통 (communicate) 하는가 ? 8) 얼마나 자주 (how often) 작업이 수행되는가 ?

9) 작업에 어떤 시간제약 (time constraints) 이 있는가 ? 10) 시스템이 오류 (error) 일 때 어떤 일이 일어나는가 ?

1) 누구 (Who)? :

 누구의 정의

 사용자 유형 구분 (identify), 배경 (Background), 보유기술 (Skills)

 작업습관 (Work habits) 및 선호도 (preferences)

 외형적 특징 (Physical characteristics) : 예 , 키 ?

 실제 사용자를 찾아가기

 그들에게 말한다 : 그들이 하는 일을 찾아내기

 바쁜 사람의 경우 : 대가 지불 , 대체 인력

 (BART 사례 )

 Identity? - BART 를 타는 사람 : 회사원 , 학생 , 장애인 , 노인 , 여행자

 Background? - ATM, 신용카드 또는 다른 지불 시스템을 사용해 본 자

 Skills? - ATM 기기에 카드 삽입할 줄 알거나 , BART 티켓을 살 줄 안다 .

 Work habits and preferences? - BART 를 일주일에 5 일 사용

 Physical characteristics? - 다양한 키 , 그러나 너무 크거나 작지 않다 .

2) 어떤 작업 (What Tasks)?

 새로운 기능 추가 및 자동화 기능에 중요

 작업의 상대적인 중요도 구분

 사용자를 관찰 , 그들의 관점에서 바라본다

 온라인 청구서 사례

 작은 치과 병원에서 청구서를 자동으로 발급한다 .

 회계 사무원은 새로운 시스템에 불만

 이익을 수기로 노트할 수 있는 예전 형식을 선호

3) 작업을 어떻게 배울까 (learn)?

 사용자가 무엇을 알아야 하는가 ?

 교육 / 훈련이 필요한가 ?

 학술적인 교육 , 일반 상식 / 기술 , 특수 훈련 / 트레이닝

4) 어디서 (where) 작업 수행 ?

 사무실 , 실험실 , 영업현장 ?

 사용자에 끼치는 환경의 영향은 ? 사용에 스트레스가 있는가 ?

 비밀이 요구되는가 ?

 젖거나 , 더럽거나 , 손이 미끄럽거나 등 외부 요인 ?

 마실 것은 있는가 ? 조명은 ? 소음은 ?

5) 사용자와 데이터의 관계 (relationship)

 개인 데이터

 항상 같은 기계에서 접근하는가 ? 다른 기계에서 사용하는가 ?

 공용 데이터

 동시에 사용되는가 ? 사용자간에 순차적으로 사용되는가 ?

 원격 접속이 필요한가 ?

 제약이 있는 데이터에 접근하는가 ?

6) 다른 도구 (tools) 를 사용하는가 ?

 단순한 호환성 (compatibility) 이상의 문제

 사용자가 여러 도구들을 가지고 어떻게 작업하는지 파악

 사례 . 자동 실험 데이터 수집기

 현재 데이터가 어떻게 수집되는가 ?

 어떤 도구를 사용하고 , 수동 절차는 ?

 정보는 어떻게 분석되는가

 결과는 보고서나 논문을 위해 다시 기록되는가 ?

 어떤 미디어 / 형식이 사용되고 어떻게 처리되는가 ?

7) 사용자간 의사소통 (communicate)?

 누구 사이에 의사소통하는가 ?

 무엇에 대해 ?

 조직의 명령체계에 따르는가 ? 혹은 그 반대인가 ?

8) 얼마나 자주 (how often) 작업 수행 ?

 자주 사용하는 사용자가 더 상세하게 기억

 자주 사용하지 않는 사람은 도움이 필요

 간단한 조작이라도 해당 , 그래야 작업 수행이 가능

 어떤 기능이 수행되는가 ?

 가장 자주 수행되는 것 ? 어떤 사용자 ?

9) 어떤 시간제약 (time constraints) ?

 어떤 기능이 사용자를 서두르게 하는가 ? 어느 기능이 기다리게 하는가 ?

 작업간에 시간관계가 있는가 ?

10) 시스템이 오류 (error) 일 때 ?

 사람들이 다음 상황에 대해 어떻게 대응하는가 ?

 작업 관련 오류 ?, 실행에 어려움 ?, 파국 ( 대실패 )?

 백업 대응책은 있는가 ?

분석 - 데이터 정리 & 브레인 스토밍



사용자의 행위를 나열

 무엇이 중요한지 추정하기 위하여 분석

 사용자들이 수행하는 시스템의 작업 , 서비스 등 모든 절차 및 과정을 포함

 사용자 행위는 인터뷰 결과에서 찾아서 정리



어피니티 다이어그램 (Affinity diagram)

 공통된 이슈 , 주제 , 고객의 문제 , 요구범위를 한자리에 보여주기

 개별 행위 / 정보를 그룹핑 , 그룹간에 관계를 설정 , 계층적으로 구성

 큰 벽면에 개별 행위를 기록한 포스트잇 사용



브레인 스토밍 (Brain Storming)

 최대한 많은 아이디어 도출

작업분석 결과의 문서화



주요 작업의 목록 작성

 사업부서의 요구 , 사용자 리서치 , 기존제품 , 브레인스토밍에서 도출

 기능 , 사용자 등급 , 혹은 페르소나에 따라 카테고리화

 필요 작업이나 요구사항이 빠짐없이 디자인되고 있는지 점검



워크플로우

 작업목록의 업무들을 특정한 순서 , 플로우 , 중요도에 따라 배열

 작업간의 논리적 흐름을 표현



유스케이스

 제품 / 서비스의 기능을 간략하게 늘어 놓은 것

 간단한 단어를 사용하여 해당 기능의 쓰임새와 이유를 설명

 소프트웨어 설계에서 사용하는 기법

결과 - 계층적 작업목록



HTA(Hierarchical Task Analysis)

 시작점은 사용자의 작업 목표

 추출된 행위 목록에서 행위간 순 서가 도출될 경우 다시 배열

 행위간 순서는 하나로 그룹핑

 각 작업을 세부작업으로 구체화

 최상위 계층은 작업목록

 작업목록 사례 : 도서관홈페이지

 0. 도서 검색

 0. 도서 대출 현황 조회

 0. 도서 대출 예약

 0. 자료 구입 신청

 0. 신규 도서 등록

 HTA 사례 : 도서 대출 작업

 0. 도서관에서 도서 대출

 1. 도서관에 간다

 2. 원하는 도서 검색

 2.1 도서 목록을 검토

 2.2 검색 화면에 접속

 2.3 검색 조건을 입력

 2.4 요구하는 도서인지 확인

 2.5 위치 기록

 3. 보관 서가로 가서 도서 확인

 4. 도서를 가지고 대출 창구로

결과 - 유스케이스



소프트웨어 설계에 사용

 제품 / 서비스의 기능을 간략하게 정 리해 놓은 것

 도출된 태스크 들을 ‘ 사용자’ 와 ‘ 시 스템’ 관점에서 분류하여 ,

 시스템에서 어떤 상호작용이 도출되 는지 파악하려는 목적

 유스케이스 유형의 사례

 제목

 작업자

 목적 : 무슨 작업 , 왜 필요 ?

 기본 상태 : 유스케이스가 시작되는 상태

 최종 상태 : 종료되면 ?

 주요 단계 : 개별 기능의 단계를 나 열

 대안 : 유사 기능을 고려해야 할 다 른 유스케이스

 관련된 유스케이스 : 대부분 하나 의 기능은 다른 기능과 연결

 예 :

 제목 : 이메일 전송

 작업자 : 사용자 및 시스템

 목적 : 작업자가 메시지를 타인에 게 자동으로 전송하고자 함

 기본 상태 : 이메일 클라이언트 실 행

 최종 상태 : 이메일이 전송된다

 주요 단계 : 1)… 2)… 3)… 4)…

 대안 : ‘ 회신’ 및 ‘ 전달’ 기능

 관련 : ‘ 새 메일창’ , ‘ 주소 선택’ , ‘ 주소 등록’ , ‘ 수신인 주소 체크’

111

작업분석의 UI 설계에 적용 기법



페르소나 ( 퍼소나 )

 제품 / 서비스에 관련될 사람들의 특정 유형

 비슷한 목적 , 의도 , 행동방식을 공유하는 인물들의 가상적인 혼합



시나리오 : 글로 쓰인 프로토타입

 제품 / 서비스가 어떻게 쓰이게 될까 ?

 등장인물이 페르소나 : 설정한 인물에 컨텍스트를 부여



스케치와 모델

 종이 / 화이트 보드에 스케치 , 또는 모형제작

 공간의 제약 없음 , 쉽게 수정



스토리보드

 사진이나 일러스트레이션을 이용하여 시나리오에 맞추어 배열

 사용자의 동작 중 가장 중요한 부분을 설명

적용 - 페르소나 ( 퍼소나 )



Persona

 제품 / 서비스에 관련될 사람들의 특정 유형

 ‘ 사용자들’ 이 아니라 특정 한 사람을 위해 디자인하는 느낌

 비슷한 목적 , 의도 , 행동방식을 공유하는 인물들의 가상적인 혼합

 개별 페르소나는 심층적인 성격차이 ( 행동 , 목적 , 배경 등 ) 가 필요함



페르소나 설정

 리서치 대상자들의 특정 행동이나 의도에서 공통분모 추출

 여기에 이름 , 사진 , 배경 데이터 추가하여 진짜 사람처럼

 페르소나 정의 문서에 행동 , 의도 , 목적 등 기술 : 1 명 ~7 명 정도

 페르소나별 해당 작업목록 표 작성 가능

 사용자 / 태스크 행렬표

 페르소나에 시나리오 필수

 시나리오를 부여하여 목적에 맞는 기능을 테스트해야 쓸모

페르소나의 작성



인터뷰 기록 분석 및 행동 변수 파악

 도출된 태스크를 중심으로 사용자들의 행동과 관련된 모든 요소를 추출

 3-4 개 이상의 태스크 패턴에 항상 같은 그룹에 속한 사용자들을 찾는다 .

 이들의 행동을 중요 ‘행동 패턴’ 으로 간주

 주요 행동 패턴의 논리와 근거를 파악하여 적절한 것인지 분석



페르소나의 목표 설정

 사용자 행동 패턴 ( 특성 ) 을 간단한 목록 형태로 정리한다 .

 각 행동 패턴을 대표하는 페르소나 설정

 페르소나별 목표를 정리하고 , 개인적 사회적 관계를 설정

 예 )

 목표 : 대출하기 위한 도서를 검색하고 ,

그 위치를 빨리 알 수 있었으면 좋겠다 .

 관계성 : 학생 , 도서관 직원 등



상세 설명 작성

 이름

 페르소나를 명확하게 구분하기 위해 명명 , 역할 명칭을 사용하기도 함

 동기와 요구사항

 공통적인 동기를 가진 그룹은 하나의 페르소나로 묘사 , 그룹의 사용자를 대표

 사용자가 무엇을 얻고자 하는지 , 무엇을 기대하는지를 표현

 시나리오

 시스템 자체가 어떻게 사용될지 , 시스템과 사용자 간 상호작용을 묘사

 시스템이 실제 사용 상황에 얼마나 적합한지 판단할 수 있게 한다

 사용자가 사이트에 방문할 때 어떤 정보를 알고 있을지 정의하기도 한다

 사진

 페르소나를 대표하는 이미지 설정

 기타

 인구통계학적 정보 , 기술 숙련도 , 신상정보 등



페르소나의 작성 예

 페르소나를 만드는 방법에는 표준화 된 형식이 없다 .

 페르소나는 프로젝트에서 차지하는 중요도와 비중에 따라 상세하게 묘사

 단 , 어떤 형태이더라도 공통적으로 사용자의 요구는 무엇이며 , 사용자들이 무엇을 기대하는지는 표현되어야 한다 .

김숙명 : 대출예약자 “ 목표 : 도서 대출 예약을 한다 .”

기본 정보 : 20 살 여자 신상 정보 : 대학교 신입생 요구사항 : 도서 대출 예약

기술 친숙도 : 인터넷 사용이 친숙하다 . 동기 및 문제 시나리오

김숙명은 현재 20 살의 대학교에 갓 입학한 여대생이다 . 그녀는 신입생으로 첫 과제를 훌륭하게 수 행하기 위해 도서관에서 과제와 관련된 도서를 대출을 하고자 한다 . 그러나 현재 필요한 도서가 모 두 대출이 된 상태이다 . 그녀는 다음 순서로 대출을 받고자 대출 예약을 하려고 한다 .

적용 - 시나리오



문제 시나리오

 요구사항 분석 , 페르소나 작성



상세 시나리오

 다양한 요소들이 같이 작동되는 상황을 묘사

 태스크 및 페르소나에서 정의된 문제시나리오를 기반으로 , 목표로 하는 시스템이 ‘ 사용자’와 ‘시스템’ 관점에서 어떻게 수행될지 상세 시나리오로 표현

 상세 시나리오는 구체적인 태스크 목록이 모두 포함되어 있어야 한다 .

 시나리오 단계에서는 태스크의 논리적인 흐름을 파악하는 목적

 아직 화면 디자인은 포함하지 않는다 .

 프로토타입의 작성 및 평가에 활용

 단순한 예제가 아니라 , 디자인 변수를 설정하고 점검하는데 활용

적용 - 간략한 스케치 작성



기존의 스케칭과 유사

 단순히 모습보다는 개념이 중요

 필요시 시간의 흐름이나 역학관계도 표현

 낮은 정확도 요구

 원하는 개념을 표현하는 정도의 정확도 / 정밀도로 충분

 맥락 (Context) 을 대략적으로 파악할 수 있을 정도만을 필요로 하므로 , 상세한 화면 디자인은 하지 않는다 .

적용 - 스토리보드 (Storyboards)



스토리보드의 유래

 film & animation

 주요 이벤트의 기록 (“script”)

 상세한 설명은 생략 , 중요한 상호작용에만 집중



시나리오로부터 세부기능 도출

 화면 레이아웃 및 상호작용에 따른 디자인 등을 포함

 상세 입력도구 , 시스템의 기능 , 세부 인터랙션 등을 표현

 주석

 높은 수준의 스토리보드는 간략한 기능 정보를 포함

 특히 그림으로 표현되기 어려운 것은 글로 표현하여 정확히 이해하도록

Ink Chat

Picturing Time