작업분석(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)? : 누구의 정의 실제 사용자를 찾아가기 (BART 사례) 사용자 유형 구분(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)? 새로운 기능 추가 및 자동화 기능에 중요 작업의 상대적인 중요도 구분 사용자를 관찰, 그들의 관점에서 바라본다 온라인 청구서 사례 작은 치과 병원에서 청구서를 자동으로 발급한다. 회계 사무원은 새로운 시스템에 불만 이익을 수기로 노트할 수 있는 예전 형식을 선호 3) 작업을 어떻게 배울까(learn)? 사용자가 무엇을 알아야 하는가? 교육/훈련이 필요한가? 학술적인 교육, 일반 상식 / 기술, 특수 훈련 / 트레이닝

5) 사용자와 데이터의 관계(relationship) 4) 어디서(where) 작업 수행? 사무실, 실험실, 영업현장? 사용자에 끼치는 환경의 영향은? 사용에 스트레스가 있는가? 비밀이 요구되는가? 젖거나, 더럽거나, 손이 미끄럽거나 등 외부 요인? 마실 것은 있는가? 조명은? 소음은? 5) 사용자와 데이터의 관계(relationship) 개인 데이터 항상 같은 기계에서 접근하는가? 다른 기계에서 사용하는가? 공용 데이터 동시에 사용되는가? 사용자간에 순차적으로 사용되는가? 원격 접속이 필요한가? 제약이 있는 데이터에 접근하는가?

7) 사용자간 의사소통(communicate)? 6) 다른 도구(tools)를 사용하는가? 단순한 호환성(compatibility) 이상의 문제 사용자가 여러 도구들을 가지고 어떻게 작업하는지 파악 사례. 자동 실험 데이터 수집기 현재 데이터가 어떻게 수집되는가? 어떤 도구를 사용하고, 수동 절차는? 정보는 어떻게 분석되는가 결과는 보고서나 논문을 위해 다시 기록되는가? 어떤 미디어/형식이 사용되고 어떻게 처리되는가? 7) 사용자간 의사소통(communicate)? 누구 사이에 의사소통하는가? 무엇에 대해? 조직의 명령체계에 따르는가? 혹은 그 반대인가?

8) 얼마나 자주(how often) 작업 수행? 자주 사용하는 사용자가 더 상세하게 기억 자주 사용하지 않는 사람은 도움이 필요 간단한 조작이라도 해당, 그래야 작업 수행이 가능 어떤 기능이 수행되는가? 가장 자주 수행되는 것? 어떤 사용자? 9) 어떤 시간제약(time constraints) ? 어떤 기능이 사용자를 서두르게 하는가? 어느 기능이 기다리게 하는가? 작업간에 시간관계가 있는가? 10) 시스템이 오류(error)일 때? 사람들이 다음 상황에 대해 어떻게 대응하는가? 작업 관련 오류?, 실행에 어려움?, 파국(대실패)? 백업 대응책은 있는가?

분석 - 데이터 정리 & 브레인 스토밍 사용자의 행위를 나열 어피니티 다이어그램 (Affinity diagram) 무엇이 중요한지 추정하기 위하여 분석 사용자들이 수행하는 시스템의 작업, 서비스 등 모든 절차 및 과정을 포함 사용자 행위는 인터뷰 결과에서 찾아서 정리 어피니티 다이어그램 (Affinity diagram) 공통된 이슈, 주제, 고객의 문제, 요구범위를 한자리에 보여주기 개별 행위/정보를 그룹핑, 그룹간에 관계를 설정, 계층적으로 구성 큰 벽면에 개별 행위를 기록한 포스트잇 사용 브레인 스토밍(Brain Storming) 최대한 많은 아이디어 도출

작업분석 결과의 문서화 주요 작업의 목록 작성 워크플로우 유스케이스 사업부서의 요구, 사용자 리서치, 기존제품, 브레인스토밍에서 도출 기능, 사용자 등급, 혹은 페르소나에 따라 카테고리화 필요 작업이나 요구사항이 빠짐없이 디자인되고 있는지 점검 워크플로우 작업목록의 업무들을 특정한 순서, 플로우, 중요도에 따라 배열 작업간의 논리적 흐름을 표현 유스케이스 제품/서비스의 기능을 간략하게 늘어 놓은 것 간단한 단어를 사용하여 해당 기능의 쓰임새와 이유를 설명 소프트웨어 설계에서 사용하는 기법

결과 - 계층적 작업목록 HTA(Hierarchical Task Analysis) HTA 사례: 도서 대출 작업 시작점은 사용자의 작업 목표 추출된 행위 목록에서 행위간 순서가 도출될 경우 다시 배열 행위간 순서는 하나로 그룹핑 각 작업을 세부작업으로 구체화 최상위 계층은 작업목록 작업목록 사례: 도서관홈페이지 0. 도서 검색 0. 도서 대출 현황 조회 0. 도서 대출 예약 0. 자료 구입 신청 0. 신규 도서 등록 HTA 사례: 도서 대출 작업 0. 도서관에서 도서 대출 1. 도서관에 간다 2. 원하는 도서 검색 2.1 도서 목록을 검토 2.2 검색 화면에 접속 2.3 검색 조건을 입력 2.4 요구하는 도서인지 확인 2.5 위치 기록 3. 보관 서가로 가서 도서 확인 4. 도서를 가지고 대출 창구로

결과 - 유스케이스 소프트웨어 설계에 사용 111 제품/서비스의 기능을 간략하게 정리해 놓은 것 예: 유스케이스 유형의 사례 도출된 태스크 들을 ‘사용자’와 ‘시스템’ 관점에서 분류하여, 시스템에서 어떤 상호작용이 도출되는지 파악하려는 목적 유스케이스 유형의 사례 제목 작업자 목적 : 무슨 작업, 왜 필요? 기본 상태 : 유스케이스가 시작되는 상태 최종 상태 : 종료되면? 주요 단계 : 개별 기능의 단계를 나열 대안 : 유사 기능을 고려해야 할 다른 유스케이스 관련된 유스케이스 : 대부분 하나의 기능은 다른 기능과 연결 예: 제목 : 이메일 전송 작업자 : 사용자 및 시스템 목적 : 작업자가 메시지를 타인에게 자동으로 전송하고자 함 기본 상태 : 이메일 클라이언트 실행 최종 상태 : 이메일이 전송된다 주요 단계 : 1)… 2)… 3)… 4)… 대안 : ‘회신’ 및 ‘전달’ 기능 관련 : ‘새 메일창’, ‘주소 선택’, ‘주소 등록’, ‘수신인 주소 체크’

작업분석의 UI 설계에 적용 기법 페르소나(퍼소나) 시나리오: 글로 쓰인 프로토타입 스케치와 모델 스토리보드 제품/서비스에 관련될 사람들의 특정 유형 비슷한 목적, 의도, 행동방식을 공유하는 인물들의 가상적인 혼합 시나리오: 글로 쓰인 프로토타입 제품/서비스가 어떻게 쓰이게 될까? 등장인물이 페르소나: 설정한 인물에 컨텍스트를 부여 스케치와 모델 종이/화이트 보드에 스케치, 또는 모형제작 공간의 제약 없음, 쉽게 수정 스토리보드 사진이나 일러스트레이션을 이용하여 시나리오에 맞추어 배열 사용자의 동작 중 가장 중요한 부분을 설명

적용 - 페르소나(퍼소나) Persona 페르소나 설정 제품/서비스에 관련될 사람들의 특정 유형 ‘사용자들’이 아니라 특정 한 사람을 위해 디자인하는 느낌 비슷한 목적, 의도, 행동방식을 공유하는 인물들의 가상적인 혼합 개별 페르소나는 심층적인 성격차이(행동, 목적, 배경 등)가 필요함 페르소나 설정 리서치 대상자들의 특정 행동이나 의도에서 공통분모 추출 여기에 이름, 사진, 배경 데이터 추가하여 진짜 사람처럼 페르소나 정의 문서에 행동, 의도, 목적 등 기술 : 1명~7명 정도 페르소나별 해당 작업목록 표 작성 가능 사용자/태스크 행렬표 페르소나에 시나리오 필수 시나리오를 부여하여 목적에 맞는 기능을 테스트해야 쓸모

페르소나의 작성 인터뷰 기록 분석 및 행동 변수 파악 페르소나의 목표 설정 도출된 태스크를 중심으로 사용자들의 행동과 관련된 모든 요소를 추출 3-4개 이상의 태스크 패턴에 항상 같은 그룹에 속한 사용자들을 찾는다. 이들의 행동을 중요 ‘행동 패턴’으로 간주 주요 행동 패턴의 논리와 근거를 파악하여 적절한 것인지 분석 페르소나의 목표 설정 사용자 행동 패턴(특성)을 간단한 목록 형태로 정리한다. 각 행동 패턴을 대표하는 페르소나 설정 페르소나별 목표를 정리하고, 개인적 사회적 관계를 설정 예) 목표 : 대출하기 위한 도서를 검색하고, 그 위치를 빨리 알 수 있었으면 좋겠다. 관계성 : 학생, 도서관 직원 등

상세 설명 작성 이름 동기와 요구사항 시나리오 사진 기타 페르소나를 명확하게 구분하기 위해 명명, 역할 명칭을 사용하기도 함 공통적인 동기를 가진 그룹은 하나의 페르소나로 묘사, 그룹의 사용자를 대표 사용자가 무엇을 얻고자 하는지, 무엇을 기대하는지를 표현 시나리오 시스템 자체가 어떻게 사용될지, 시스템과 사용자 간 상호작용을 묘사 시스템이 실제 사용 상황에 얼마나 적합한지 판단할 수 있게 한다 사용자가 사이트에 방문할 때 어떤 정보를 알고 있을지 정의하기도 한다 사진 페르소나를 대표하는 이미지 설정 기타 인구통계학적 정보, 기술 숙련도, 신상정보 등

페르소나의 작성 예 페르소나를 만드는 방법에는 표준화 된 형식이 없다. 페르소나는 프로젝트에서 차지하는 중요도와 비중에 따라 상세하게 묘사 단, 어떤 형태이더라도 공통적으로 사용자의 요구는 무엇이며, 사용자들이 무엇을 기대하는지는 표현되어야 한다. 김숙명 : 대출예약자 “목표 : 도서 대출 예약을 한다.” 기본 정보: 20살 여자 신상 정보: 대학교 신입생 요구사항: 도서 대출 예약 기술 친숙도: 인터넷 사용이 친숙하다. 동기 및 문제 시나리오 김숙명은 현재 20살의 대학교에 갓 입학한 여대생이다. 그녀는 신입생으로 첫 과제를 훌륭하게 수행하기 위해 도서관에서 과제와 관련된 도서를 대출을 하고자 한다. 그러나 현재 필요한 도서가 모두 대출이 된 상태이다. 그녀는 다음 순서로 대출을 받고자 대출 예약을 하려고 한다.

적용 - 시나리오 문제 시나리오 상세 시나리오 요구사항 분석, 페르소나 작성 다양한 요소들이 같이 작동되는 상황을 묘사 태스크 및 페르소나에서 정의된 문제시나리오를 기반으로, 목표로 하는 시스템이 ‘사용자’와 ‘시스템’ 관점에서 어떻게 수행될지 상세 시나리오로 표현 상세 시나리오는 구체적인 태스크 목록이 모두 포함되어 있어야 한다. 시나리오 단계에서는 태스크의 논리적인 흐름을 파악하는 목적 아직 화면 디자인은 포함하지 않는다. 프로토타입의 작성 및 평가에 활용 단순한 예제가 아니라, 디자인 변수를 설정하고 점검하는데 활용

적용 - 간략한 스케치 작성 기존의 스케칭과 유사 단순히 모습보다는 개념이 중요 낮은 정확도 요구 필요시 시간의 흐름이나 역학관계도 표현 낮은 정확도 요구 원하는 개념을 표현하는 정도의 정확도/정밀도로 충분 맥락(Context)을 대략적으로 파악할 수 있을 정도만을 필요로 하므로, 상세한 화면 디자인은 하지 않는다.

적용 - 스토리보드(Storyboards) 스토리보드의 유래 film & animation 주요 이벤트의 기록(“script”) 상세한 설명은 생략, 중요한 상호작용에만 집중 시나리오로부터 세부기능 도출 화면 레이아웃 및 상호작용에 따른 디자인 등을 포함 상세 입력도구, 시스템의 기능, 세부 인터랙션 등을 표현 주석 높은 수준의 스토리보드는 간략한 기능 정보를 포함 특히 그림으로 표현되기 어려운 것은 글로 표현하여 정확히 이해하도록

Ink Chat

Picturing Time