1. 경영진의 UI/UX 관련 개발 요구사항 조사 및 정의

목표

경영진을 대상으로 p.83심층 인터뷰를 통해 의견을 반영하여 비즈니스 요구사항을 정의함

경영진 인터뷰를 통해 제품의 사업적, 기술적 측면의 요소를 깊이 이해하는 것을 목표로 함

경영진이 생각하는 사업적 목표를 바탕으로 UI/UX 디자인 프로세스를 정의함

경영진 인터뷰는 반드시 사용자 리서치를 시작하기 전에 진행되어야 함
(여기서 얻은 결과를 토대로 앞으로의 효과적인 리서치를 계획할 수 있는 것)

활동

1. 초기 비전과 기대 : 사용자와 고객, 회사의 비전을 일치시키는 일을 진행함
2. 비용과 일정 : UX리서치, UI/GUI 디자인에 투자될 예산과 일정을 결정함
   (리서치 규모, 디자인의 목표 등이 결정됨)
3. 기술적 제약과 가능성 : 현 기술의 발전 가능성 파악, UI/UX 디자인의 미래와 방향을 제시
4. 사업전략, 사업목표, 각 프로세스 책임자 선정, 회의 계획 세우기, 우선순위 선정, 개별적인 업무단위를 구분함
5. 경영진의 프로젝트에 대한 이해 : 인터뷰 내용을 바탕으로 경영진마다 상이한 UI/UX 개발 프로젝트에 대한 이해를 돕고 협의되도록 함

TIP

경영진 인터뷰는 여러 명을 한꺼번에 하는 것보다 개별로 진행하는 것이 좋음

다수의 목소리에 묻혀 개인의 중요한 의견을 놓칠 위험이 없어야 함

각 인터뷰는 한 시간을 넘어서는 안 됨

2. 자사-타사-사용자분석(3C분석), 트렌드 분석

목표

기존의 자사 제품과 주요 경쟁사 제품을 분석하는 마케팅적 관점으로 시장을 이해함

경쟁 상황을 파악하여 차후 인터뷰에 필요한 질문을 준비하는데 필요한 자료를 구체화함

활동

1. 현 상황 이해 (자사, 타사 제품 상태 분석)
   • 사용자(고객의 욕구, 시장동향, 표적시장), 경쟁사(상대적 경쟁력, 경쟁사, 강점과 약점), 자사(자사현황, 자사의 강약점, 자사목표) 분석
   • AW(Forces at work)분석은 3C 분석을 사용하는 경우에 빠지기 쉬운, 사업에 영향을 미치는 거시적 환경을 주로 분석하는 기법
2. 사용성 평가 기준을 활용, 전문가 사용성 평가를 진행함
   • 휴리스틱 분석 (Heuristic analysis) + 제이콥 닐슨(Jacob Nielson)의 '10대 사용성 리스트'(가장 널리 사용되는 사용성 평가 기준임)
   • 가장 빠르고 저렴하게 사용성 디자인을 평가할 수 있다는 장점을 가지고 있음
   • 이 기법을 통해 전반적인 UX 품질을 측정하고, UX 이슈가 될 만한 내용을 도출해 낼 수 있음
   • 제품과 프로젝트의 배경 지식 파악 ▶ 어떤 사용성 기준을 사용할지 결정 ▶ 조사 및 분석의 과정으로 결과보고서를 작성, 프로젝트 팀과 주요 경영진들에게 제출함
3. 핵심 이슈(Key Finding)를 도출함

TIP

제품의 강점과 약점을 상세히 확인해야 함

사용자에게 제공되고 있는 기능과 기존 제품으로 가능한 기술 영역을 이해하는 것이 중요함

지금까지 제작된 시안과 프로토타입이 있다면 함께 분석함

경쟁사 제품을 분석시 도출되는 공통적 핵심 이슈를 중심으로 경쟁사 요소의 문제점, 사용자 핵심 니즈, 미충족 니즈(Unmet Needs)를 준비함

3. 관계자 개발 목표 협의 및 공유 워크샵

목표

앞의 단계에서 조사, 분석된 결과를 토대로 부서간, 내부 관계자간(마케팅, 디자인, 개발, 영업 등의 관계부서) 개발 목표를 협의하여 향후 개발을 원활히 하기 위해 진행함

UX적 차별성이 있는 컨셉 또는 UI의 대폭 개선 등 디자인 및 개발 이슈가 많은 상황에서 필요함

활동

1. 워크샵 범위와 목적을 정의함
2. 아이디어 워크샵을 통해 아이디어를 발산, 수렴 및 평가하며,
   육색사고모자(6 Thinking Hats), 어피니티 다이어그램(Affinity Diagram) 등을 사용할 수 있음
3. 아이디어를 정리, 분석 후 전문가적 통찰을 통해 아이디어를 선정, 개발목표를 도출함

TIP

벤치마킹을 통한 성공, 개선사례 위주의 개발 필요성을 경영진 및 의사 결정자에게 제시, 회사 차원의 지원이 가능하도록 함

내부 관계자간 워크샵에서 중요 이슈들에 대한 협의가 최대한 이루어지도록 하는 것이 중요함

1. 리서치 대상 선정 및 내용 설계

목표

고품질의 리서치 결과를 얻기 위해 적절한 리서치 대상자 선정과 리서치 설계(적절한 인터뷰 기법, 관찰조사 기법, 리서치 포인트 정의 및 내용설계)가 필요함

리서치 대상그룹(표본)이 사용자 행동 유형들을 충분히 포함하면서, 그 범위가 필요 이상으로 넓지 않게 조정하기 위해 대상 선정 및 계획 단계를 거침

활동

1. 사용자 분류기준 정의 및 분류
2. 세그먼트(분류된 사용자 그룹)별 매력도 평가
3. 리서치 대상 프로파일 선정 및 대상 선정
4. 리서치 포인트 정의
5. 이슈별 내용 상세 설계
6. 전체 내용 점검
7. 리서치 방식 정의, 리서치팀 구성, 스케줄링

TIP

리서치 기법은 리서치 규모와 목적에 따라 정량적, 정성적 리서치를 적절히 사용함

리서치는 불특정 다수의 사람들을 대상으로 수행할 수도 있으나, 리서치 결과의 신뢰성을 위해서는 대상자 선정이 까다롭게 되어야 함

리서치는 벤치마킹이나 통계분석, 전문가 평가 등을 통해서 도출한 이슈들을 실제 사용자들에게 확인하는 절차임

신생기업, 제품의 경우 포커스그룹인터뷰로 시작하여 대상자를 확대해 나가는 것이 좋음

2. 리서치 진행

목표

사용자의 불편사항과 니즈를 파악하기 위한 단계로써, 해당 제품/서비스에 대한 다양한 의견을 수집함

활동

1. 설문조사(서베이)/개인(심층인터뷰)/그룹(포커스 그룹인터뷰) 리서치 진행
2. 리서치 내용 점검 및 보완

인터뷰 기술

[Do]

심문하지 말고 대화를 나눠라.

이야기에 공감하고, 일방적인 판단은 하지 말라.

전문가가 아니라 배우는 사람이 돼라.

기본적인 질문을 하라.

참가자들에게 보여달라고 요청하라.

볼 수 없는 부분에 대해서는 더더욱 구체적인 이야기를 요청하라.

제안된 기회를 받아들여라.

모순을 경계하라.

디자인 문제를 넘어서지 말고 제품을 넘어서라.

비언어적 신호에 주의를 기울여라.

너무 많이 말고 약간 앞서 생각해라.

팀원들을 믿어라.

[Do not]

유도질문을 하지 말아라.

인터뷰 참가자에게 해결책에 대해 묻지 마라.

인터뷰 도중 문제를 해결하려 하지 말라.

3. 리서치 결과 정리

목표

필드리서치(데스크리서치와 달리 사용자 사용행태를 실제로 조사, 에스노그라피, 옵저베이션 등이 있음) 결과분석을 토대로 핵심이슈 도출을 통해 시사점을 찾고 사용자 경험 가치 발굴을 목표로 하며 이것은 전략과 디자인 개발의 토대가 됨

이슈별, 사용자별, 사용자의 컨텍스트별, 사용자의 경험별 분류기준을 적용하여 필드리서치 결과를 정리함

리서치 분석 결과 그대로 핵심이슈가 될 수도 있지만, 유추나 재해석, 결과들의 복합적 해석, 페르소나(Persona), 사용자 멘탈모델(Mental Model)등과 복합적 해석을 통해 핵심이슈가 도출될 수 있음

어피니티 다이어그램(Affinity Diagram), 인지도 맵(Cognitive Maps)기법 등을 활용하여 정리함

[리서치 결과분류]

** 참조서식, 인터뷰 리포트

1. UX차별화(혁신,경쟁)전략 수립

목표

경쟁환경, 기술적 발전, 사용자의 니즈를 반영하여 시장에서 차별화될 수 있는 혁신, 경쟁 전략을 수립함

"사용자는 뭘 원한다. 그래서 우리 제품/서비스는 이런 가치를 담아야 한다."라는 거시적 시각에서 접근하는 UX Value를 작성함

활동

1. 3C분석, FAW분석, 비즈니스 모델 캔버스, SWOT 분석 등을 활용하여 시장 경쟁 요소 및 차별화 이슈를 정리함
2. 사용자 조사를 통한 주요 사용자 니즈를 정리함
3. 핵심 이슈를 도출함
4. UX 차별화 전략을 수립함

출처 : UX1, UX Consultant 과정

1. 페르소나(Persona) 분류 및 정의

목표

사용자들이 제품/서비스에 대해서 중요시 여기는 가치(니즈의 중요도에 따라 어떤 영역에 가치를 두는지 분석)에 따라서 사용자를 구분하여 정의함

활동

1. 맥락적 인터뷰 등 다양한 조사기법을 통해 수집한 제품/서비스를 찾는 이용동기에 따라서 사용자를 구분함
2. 동일한 가치, 동기를 가진 사용자들을 행태(빈도, 탐색방법, 이용시간/장소, 이용경로, 기타 특징)별로 구분함
3. 동일한 가치, 동기, 행태를 가진 사용자들을 태도(인지도, 충성도, 경험/지식, 동기강도, 만족도)별로 구분함
4. 모형크기, 중요도, 발전가능성을 토대로 1순위 사용자(Primary User Group)/ 2순위 사용자(Secondary User Group)/ 기타(Ignorable)로 분류함
5. 사용자들의 가치(니즈), 이용동기, 행태, 태도에 따라 분류하고, 분류한 결과를 토대로 페르소나(Persona)를 정의함
6. 각 페르소나별 특징들을 토대로 별명을 붙임

TIP

잘 만들어진 페르소나(Persona)는 누가 우리 제품/서비스를 이용하는지, 이용 특성에 따른 사용자 유형을 쉽고 명쾌하게 이해할 수 있도록 도움

잘못 만들어진 페르소나(Persona)는 있으나 마나 한 군더더기에 불과하며 통계분석을 통해 나온 결과를 그대로 반영할 뿐임

2. 페르소나(Persona) 작성

목표

정의된 페르소나(Persona)들을 서술하는 문서를 작성함

페르소나(Persona)에 대한 최종적인 산출물 형태가 됨

작성내용

(밑줄은 필수항목)

1. 사용자 별명
2. 사용자 정보 및 간단한 프로파일
3. 사용자가 제품/서비스에 대해 갖는 태도
4. 사용자에 대한 구체적인 정보
   (인구 통계학적인 정보, 제품에 대한 이용정보)
5. 사용자의 니즈
6. 공급자 기대(Business Objectives)
7. 동기
8. 동기별 이용 시나리오
9. 시나리오별 이용 기능/콘텐츠
10. 시나리오별 구체적인 이용행태

** 참조서식, 페르소나

출처 : UX1, UX Consultant 과정 中 발췌

TIP

사용자들의 특징과 차이가 분명해야 하며, 실제 사용자처럼 느껴져야 하며 모든 사용자를 포괄해야 하며, 의사결정에 영향을 미치는 시사점이 있어야 함

잘 만들어진 페르소나(Persona)에는 각 페르소나(Persona)별 특징과 이용동기, 이용 시나리오, 니즈와 고민점(Pain Points)등이 자연스럽게 녹아들어 있음

잘못 만들어진 페르소나(Persona)에 대한 묘사는 억지스러우며, 구체적이지 못하고 이미 알고 있는 사실을 정리했을 뿐임

3. 페르소나(Persona) 활용

목표

정의된 페르소나(Persona)를 이후 이루어지는 UX 디자인 작업에 활용하여 주요 의사결정과 상세 디자인 수행에 활용함

활용분야

1. 사용자 시나리오 작성 : 페르소나(Persona)별로 사용자 시나리오를 작성함
2. 기능 정의 : 페르소나(Persona)별로 주요 기능, 세부 기능의 필요여부를 작성하여 체크리스트로 활용함
3. 레이블 정의 : 주요 페르소나(Persona)들에게 익숙한 용어 및 표현을 통해 레이블을 정의함

TIP

잘 만들어진 페르소나(Persona)는 '시장 매력도 분석(마케팅)'보다 더 큰 통찰을 제시하며, 어떤 페르소나(Persona)가 가장 매력적이며 성장 가능성이 높은지 판단할 수 있음

잘못 만들어진 페르소나(Persona)는 통찰도 얻을 수 없고 의사결정도 내리기 어려움, 어떤 경우에는 '시장 매력도 분석'과 거의 비슷해서 '이 작업을 왜 해야하는지 조차 헷갈리는' 경우도 있음

1. 컨셉 모델 정의

목표

컨셉모델은 여러가지 추상적인 컨셉들 사이의 관계를 보여주는 다이어그램으로, 서비스/제품을 기획할 때, To-Be모델을 가시화해서 검토하기 위해 정의함

활동

1. 구성 요소 중 '명사'에 해당하는 Entity를 친화도에 따라 Grouping함. Key Entity는 별도로 배치함(그룹 안으로 포함시키면 핵심가치가 사라질 수 있음)
2. 각 Entity들을 '동사'에 해당하는 Relation들로 연결시킴
3. Entity의 중요도로 크기, 색상 등을 결정하여 조절하고, Relation의 흐름안에 거쳐 지나가는 Entity들을 Relation 자체를 넓은 화살표로 표현하여 그 과정에 포함시킴

Flickr의 컨셉모델

참조 : http://www.flickr.com/photos/bryce/55749985/sizes/o/

상단의 사용목적이 표현되어 있으며, 각 객체(Flickr User, photos, Subject)가 다른 사용자 그룹이나 컨텐츠에 어떻게 녹여지고 사용될 수 있는지 그 아래에 텍스트 /이미지/도형 /선을 이용하여 잘 표현되어 있고, 그 흐름들이 유기적으로 얽혀있음

각 흐름에서 사용자 위치와 사용가능한 행동이 자세하게 묘사되어 있음 자세한 묘사는 프로젝트 관련자들의 커뮤니케이션을 원활하게 함

1. 요구사항 매트릭스 작성

목표

다양한 경로를 통해 수집된 직접적인 요구사항을 검토하여, 페르소나(Persona)의 목적을 기준으로 데이터 니즈, 기능 니즈, 제품 품질, 제약 요인으로 요구사항 매트릭스를 작성함

요구사항 요소

1. 데이터 니즈 : 각 페르소나(Persona)의 멘탈모델과 객체들의 주요 특성과 관련된 데이터 객체들을 모아 정리되며(데이터 객체 리스트), 인터페이스에 영향을 주므로 초기에 확인해야 함
   ex) 이메일 메시지의 속성은 제목, 발신인, 발신일, 참조인, 답변 등
2. 기능 니즈 : 사용자가 목적을 이루기 위해 무엇을 해야하는지 동사형으로 설명함. 기능 니즈 리스트로 정리되며, 할 수 있는 최대한 철저하게 해야함
   ex) 페르소나(Persona)는 이메일 메시지를 읽고, 삭제하며, 특정 양식으로 다른 메시지들과 함께 보관할 수 있음
3. 제품/서비스의 품질 : 데이터 및 기능 니즈 외에 중요하게 고려해야 할 여러가지 속성으로 제품 품질이라 부를 수 있으며 감성적 품질도 고려해야 함
   ex) 얼마나 빨리 시스템이 파일을 처리하는 지와 같이 실용적이고 정량화 할 수 있는 요구사항들을 포함함
4. 제약 요인 : 제품 출시 데드라인, 개발 및 제작 비용, 시스템이 준수해야 하는 규제 등이 포함되며, 제약 사항의 강도(변경가능, 변경불가 등)가 논의되어야 함

[요구사항 매트릭스]

2. 정황시나리오 제작

목표

정황 시나리오(Contextual Scenario)는 요구사항 정의에 사용되는 초기 시나리오를 말하며, 높은 수준, 낙관적이면서도 발생 상황에서의 이상적인 시스템 동작에 초점을 맞춤

제품/서비스가 어떤 모습을 가져야 하는지 상상하는 첫번째 활동으로, 페르소나(Persona) 관점에서 시나리오를 작성함

활동

1. 필요한 정황 시나리오를 확인함
   • 페르소나(Persona)가 관여하고 싶어하는 주요 활동들의 전형적인 예를 포함하고 있어야 하며, 함께 발생되는 활동들은 하나의 시나리오에 통합되어야 함
   • 1순위 페르소나(Persona)의 주요 활동에 기반을 두고 리스트 작성 후, 2순위 페르소나(Persona)의 활동 포함여부를 검토함
2. 개별스토리를 개발함
   • 리스트로 정리된 각각의 상황에 대해 페르소나(Persona)의 스토리(서술적으로 해당 상황을 표현)로 서술함
   • 육하원칙으로 서술하며, 세부사항을 적절히 조절하여 간결하면서 전달력있게 작성함
3. 다른 사람에게 정황 시나리오를 검토해달라고 부탁함
   • 정황 시나리오 작성에 대한 지식이 많고 그동안 리서치에 참가했던 팀 리더 혹은 영역전문가가 가장 적합함

유즈케이스, 유저스토리, 정황 시나리오

유즈케이스는 행위자와 시스템 사이의 인터랙션을 묘사하며, 일반적으로 다이어그램형식으로 묘사됨
사용자들이 인터랙션에 대해 어떻게 느끼는지 또는 왜 특정 동작이 바람직한지 다루지 않으며, 또한 페르소나(Persona)를 이용하지 않음

유저스토리는 스크럼(Scrum) 등에서 사용되며, 시나리오와 비슷하게 보이지만 요구사항에 가까움. 사용자의 작업 흐름을 처음부터 끝까지 묘사하지 않음

시나리오는 사용자가 최종 목표를 달성하기 위한 방법을 순차적으로 묘사함

3. 정황 시나리오로부터 요구사항 도출

목표

정황 시나리오 리스트를 토대로 상세히 작성된 개별 시나리오로부터 관련 요구사항을 작성함

시나리오 외의 다른 자료(멘탈모델, 목적, 환경, 기술과 능력, 비즈니스 및 다른 니즈, 이해관계자, 규제, 경쟁자, 접근성, 지속가능성 등)으로 부터 요구사항을 도출함

[ 정황 시나리오 리스트 도출 예시 ]

** 출처 : 인간중심 UX디자인, 킴굿윈, 에이콘출판사

[ 시나리오에서 요구사항 도출하는 과정 예시 ]

** 출처 : 인간중심 UX디자인, 킴굿윈, 에이콘출판사

1. 정보구조(Information Architecture) 설계

목표

정보 구조화와 분류 체계를 수립, 사용자 요구사항을 토대로 기능 구조를 도출, 메뉴 구조를 작성하고 네비게이션과 레이블링을 정의함

활동

1. 기능 그룹핑
   • 시나리오로부터 도출된 요구사항, 기능들을 포스트잇에 나누어 쓰고 카드소팅 기법을 활용, 그룹핑하여 그룹의 이름을 정하는 과정을 거침
   • 기능을 어떻게 묶느냐에 따라 정보/기능 구조가 달라지므로 인터페이스의 구조(ex : 메뉴구조, 화면 구성 등)를 고려해야 함
   • 카드소팅(Card Sorting)을 사용하여 다양하게 그룹핑을 시도하면서 정확한 기능구조를 정하는 것이 중요함
2. 각 그룹의 중요도/사용빈도를 바탕으로 연결/순서관계를 결정
   • 이 단계에서 인터랙션 디자인에 어떤 메타포를 도입할 것인지 결정하는 것이 좋음. 어떤 메타포를 도입하느냐에 따라 기능의 연결관계가 달라지기 때문임
   • 스케치를 통해 대략적으로 기능구조를 정의함

2. 대표화면 와이어 프레임 스케치

목표

인터페이스 디자인이 시각적으로 구체화하기 위해 와이어프레임(대표적인 화면들에 포함되는 정보, 인터페이스 요소, 그들의 레이아웃)을 대략적으로 스케치함

설계원칙

1. 메타포를 활용하라.
2. 기본 모드를 신중하게 결정하고 사용자 이력에 따라 똑똑하게 변하게 하라.
3. 사용자가 기억하게 하지 마라('회상' 보다 '인식';)
4. 사용자의 실수를 방지하거나 복구할 수 있는 방법을 제공하라.
5. 모든/특정 사용자의 모든 태스크 상황, 사용케이스, 시나리오를 고려하라.
6. 시스템의 현재 상태를 명확하게 가시화하라.
7. 인터페이스를 접어 복잡도를 낮춰라.
8. 사용자의 태스크 수행에 연속성을 부여하라. 팝업을 최소화 하라.
9. 모든 상황에서 반드시 의도된 행위를 유발하도록 설계하라.(행동 유도성)
10. 태스크 수행절차를 일관되게 하라.

** 참조서식, 와이어프레임 스케치

TIP

와이어 프레임 스케치 전, 공통적인 인터페이스 요소(예: 옵션버튼, 체크박스, 텍스트 입력필드 등)가 정의되어 있지 않다면 먼저 그것부터 설계해야 함

와이어 프레임 스케치를 토대로 주요 화면의 디자인이 결정되므로 하나의 디자인만 스케치하기보다는 여러 디자인 안을 스케치해서 비교하는 것이 좋음

사용자 요구사항과 UI설계 원칙을 함께 고려하여 설계해야 함(iOS나 Android OS 기반의 앱을 개발하는 경우, 애플과 구글의 사용자 인터페이스 가이드라인을 따르면 됨)

3. 페이퍼 프로토타입(Paper Prototype)을 통한 스토리보드 설계

목표

인터랙션을 고려하여 주요 흐름(Key Flow)을 스토리보드 형태로 그림

UI 컨셉션의 결과물을 사용자에게 평가받아 신속하게 문제점을 발견하고 개선하는 것이 중요함하지만 대표화면 와이어프레임만으로는 인터랙션 상의 문제점을 발견하기 어려워 페이퍼 프로토타입(Paper Prototype)평가를 활용함

제품/서비스 개발 초기에 별도의 하드웨어나 소프트웨어를 사용하지 않고도 제품의 디자인 컨셉, 사용성, 기능 동작 등을 빠르고 반복적으로 검증하는데 활용됨

활동

1. 대표화면, 인터페이스 위젯(아이콘, 팝업, 체크박스 등), 물리적 버튼을 사용하여 인터랙션의 흐름이 보이도록 스토리보드를 제작함
2. 사용자가 페이퍼프로토타입을 실제 상황인 것처럼 사용하면, 컴퓨터 역할을 맡은 사람이 인터랙션을 시뮬레이션함
   • 컴퓨터 역할을 맡아 종이를 조작하는 사람 1~2명 : 현재 인터페이스에 대한 이해도가 제일 높은 사람으로 가장 중요한 역할
   • 진행자(Facilitator, 평가진행자) 1명 : 사용자에게 수행할 태스크를 제시하고 질문에 대답하는 등 실험을 진행
   • 관찰자(Observer, 관찰/기록 하는 사람) 1명이상 : 사용자의 말과 행동을 관찰하여 사용자가 겪는 어려움이나 설계의 문제점을 기록하는 사람
3. 위의 사용자 평가결과를 토대로 와이어프레임, 인터랙션 설계를 개선, 상세설계(UI시나리오 문서 작성)로 진행함

TIP

페이퍼 프로토타입(Paper Prototype)을 활용할 수 있는 단계는 디자인 컨셉 결정 단계, 인터랙션 디자인 과정에서 사용성 문제를 파악하는 단계에 활용 가능함

UI컨셉, 기능/버튼 배치, 요구정보, 레이블, 피드백 적합성 등을 신속하게 평가하는 데 유용함

개발팀 간 혹은 개발팀과 고객 간 의사소통을 원활하게 해줌

1. GUI 이미지 무드보드 제작

목표

화면 디자인의 시각적 컨셉을 설명하기 위한 작업으로, 레이아웃, 타이포그래피, 참고 이미지 등을 활용하여 디자인 개발 컨셉을 표현, 개발방향성의 이해를 도움

활동

1. UX전략에 따른 화면 디자인 방향(시각디자인 언어)을 설정함
2. 이미지 수집 및 아이디어 발상을 진행함
3. 프리젠테이션을 위한 이미지보드(무드보드)작성 또는 러프한 디자인 시안을 제작함
   • 심미성, 간결성, 목적부합성, 장식성 등 시각적 언어를 기준으로 벤치마킹 GUI 이미지를 맵핑하고, 개발 방향에 적합한 포지셔닝을 설정함
   • GUI 벤치마킹 사례, 다른 시각 디자인, 사진 등의 이미지를 참고하여 디자인 컨셉을 참고할 수 있도록 함
   • 대표 메타포, 아이콘의 스타일, 폰트와 컬러 등의 예시를 제시함

[ UX전략에 따른 화면방향 설정 ]

출처 : http://cfile201.uf.daum.net/image/2029544950C9D97535BF0D

[ 이미지 무드보드 예시 ]

출처 : http://wireframes.linowski.ca/wp-content/themes/darwin/images/full70.jpg

** 참조서식, 무드보드

1. UI 시나리오 문서 작성

활동

1. 전체 기능을 한 눈에 이해할 수 있도록 기능 구조를 작성하며, 일반적으로 계층구조 또는 플로차트 표기법으로 작성함
2. 모든 기능에 대해 공통적으로 적용되는 UI요소와 인터랙션을 일반 규칙으로 정의함
3. 대표화면(시나리오에 포함되는 서로 다른 형태를 가진 독립적인 화면들)의 레이아웃과 그 화면들 속의 기능을 정의함
4. 인터랙션(페이퍼프로토타입에 의해 발견된 문제점들을 모두 개선한 최종 인터랙션) 흐름을 정의하며, 화면 내 그리고 화면 간 인터랙션의 순서(sequence), 분기(Branch), 조건(Condition), 그리고 루프(Loop)등을 명시함
5. 여러 예외 상황들에 대한 예외 케이스를 정의함
   (보통 소프트웨어 개발자나 품질 관리자들이 UI시나리오 문서에 대해 가장 불만을 많이 드러내는 부분이 예외 케이스 정리가 부족한 점임)
6. UI 일반 규칙을 지키면서 기능별 상세 기능 시나리오를 정의함

** 참조서식, UI 시나리오_스토리보드

[ UI 시나리오 문서를 위한 일반 규칙 정의 ]

2. UI 시나리오 문서 작성의 팁

Complete(완전성)

(누람 됨이 없이) 완전해야 함

최대한 빠진 것이 없도록 가능한 상세하기 기술함

시스템 기능보다 사용자의 태스크에 초첨을 맞춰 기술함

Consistent(일관성)

(서비스 목표/시스템/사용자요구사항과) 일관성이 있어야 함

문서마다의 UI스타일(Flow or Layout)을 일관되게 구성함

Understandable(이해성)

(처음 접하는 사람도) 이해하기 쉽도록 구성하고 설명함

애매모호하거나 추상적인 표현이나 이해하기 어려운 용어의 사용은 지양함

Readable(가독성)

문서를 쉽게 읽을 수 있어야 함(문서 템플릿과 타이포 그래피)

표준화된 템플릿을 제정하여 적용함(회사마다 고유 문서양식 정의)

일관성 있는 버전 넘버링(예 v1.0, v2.1.1등), 문서인덱스 규칙 적용, 목차 제공 중요함

충분한 줄간격 유지, 단락구분과 들여쓰기 기준을 적용하여 읽기 편하게 해야 함

적절한 여백/빈 페이지 활용 등으로 여백의 미를 살리면 좋음

시각적인 하이라이팅을 일관성 있게 활용해야 함

파워포인트의 상호참조(Cross-referencing) 기능 (예:하이퍼링크 등)을 활용함

Modifiable(수정 용이성)

변경이 용이해야 함

수정/개선 사항을 시나리오에 반영하는 것이 수월해야 함

하나의 동일한 사항 수정을 위해 문서 여기저기를 편집해야 하는 것은 좋지 않음

Traceable(추적용이성)

추적이 가능해야 함

어떤 변경사항들이 언제, 어떤 부분들에, 왜 발생했는지 추적이 용이해야 함

모범적인 UI시나리오 문서의 효과

요구사항 오류의 감소

의사소통 오류의 감소

개발과정에서의 재작업 감소, 혼선 최소화

불필요한 기능의 최소화

시나리오 작성과 소프트웨어 개발 비용 절감

개발속도 향상

유관부서 만족도 제고

3. UI검토(Iteration)

목표

UI 상세 설계 단계에서 사용성에 대한 반복적인 검토를 통해 완성도 높은 UI 상세 설계를 수행함

UI 스토리보드를 활용하여 페이퍼 프로토타입 평가를 통해 짧은 단위로 개발, 평가, 보완을 반복함

활동

1. 대표화면, 인터페이스 위젯(아이콘, 팝업, 체크박스 등), 물리적 버튼을 사용하여 인터랙션의 흐름이 보이도록 스토리보드를 제작함
2. 사용자가 페이퍼 프로토타입을 실제 상황인 것처럼 사용하면, 컴퓨터 역할을 맡은 사람이 인터랙션을 시뮬레이션해줌
   • 컴퓨터 역할을 맡아 종이를 조작하는 사람 1~2명 : 현재 인터페이스에 대한 이해도가 제일 높은 사람으로 가장 중요한 역할임
   • 평가진행자(Facilitator) 1명 : 사용자에게 수행할 태스크를 제시하고 질문에 대답하는 등 실험을 진행함
   • 관찰/기록자(Observer) 1명 이상 : 사용자의 말과 행동을 관찰하여 사용자가 겪는 어려움이나 설계의 문제점을 기록하는 사람임
3. 위의 사용자 평가결과를 토대로 설계를 보완함

1. GUI 스타일 가이드 제작

목표

스타일가이드는 일관성 있는 화면 디자인을 위해 레이아웃, 컬러패턴, 타이포그래피, 화면 디자인 요소들을 팔레트처럼 미리 정의하여 반복적으로 활용하기 위한 것임

활동

1. GUI 컨셉 수립 : GUI 컨셉션의 결과물을 토대로 상세한 GUI 디자인 컨셉을 수립함
2. 컬러 컨셉 수립 : 메인컬러, 서브컬러, 포인트컬러, 폰트컬러를 정의함
3. 폰트를 정의함

TIP

개발자에게 주요 컨셉과 디자인 원칙, 패턴을 효과적으로 전달하려면 디자인 문서가 필수적임

최종 결과물을 바탕으로 제품 구현 과정을 함께 지켜보고 지속적으로 의견을 주고 받아야 함

[GUI 스타일 가이드 예시 ]

참조 : http://baekhorang.tistory.com/entry/XFile

2. 세부화면디자인

목표

UI 시나리오 문서를 토대로 GUI 스타일가이드와 템플릿 디자인을 활용하여 전체 페이지에 대한 화면 디자인을 수행함

일관성 있게 스타일가이드를 적용하여, 팀 작업 및 추후 수정시 오류를 최소화함

GUI 디자인 원칙을 숙지하여, 사용성이 잘 적용된 화면디자인을 수행하도록 함

[ 애플이 제시하는 10가지 디자인 원칙 ]

3. GUI 검토 (Iteration)

목표

GUI 화면 디자인 단계에서 디자인 선호도 및 디자인 품질을 검증하여, GUI 가이드문서 작성 후 디자인 수정에 따른 반복적인 가이드문서 작성 작업을 최소화함

GUI 화면 시안 또는 시뮬레이션(플래시 등을 활용하여 화면의 동작을 구현한 버전)을 활용한 고수준 프로토타입 평가를 통해 짧은 단위로 개발, 평가, 보완을 반복함

활동

1. 사용자가 고수준 프로토타입을 실제 상황인 것처럼 사용해보는 평가를 진행함
2. 사용자 평가 결과를 토대로 디자인을 보완함

1. GUI 가이드문서 작성

목표

확정된 화면 설계 및 디자인을 적용하여 개발팀에 전달하게 되는 최종 데이터를 작업하는 단계임

개발이 진행되면서 개발부서의 설계변경에 따른 디자인 수정사항을 지속적으로 수정, 반영하여 개발팀에 전달할 때, 데이터의 정확도와 적절한 설명을 통한 원활한 커뮤니케이션을 위해 정확한 GUI 가이드 문서 작성이 필요함

활동

1. GUI 가이드문서 작성 및 문서를 관련부서에 배포함
2. 수정사항에 대해 확인 및 반영함
3. 변경이력을 관리함

** 참조서식, GUI 가이드문서

[ GUI 가이드문서 예시 ]

출처 : http://www.jjim.com/v7/files/201103/130132330007.jpg

1. 사용성검토, 결과 분석 및 수정사항 반영(Iteration)

목표

고수준(High-Fidelity)의 프로토타입을 활용 소프트웨어 개발과정 중 내부 개발자 및 전문가를 활용한 사용성 검토를 수행하면서 프로토타입에 대한 다양한 의견들을 수집, 분석하여 최종 개발에 반영함

활동

1. 검토계획을 수립함
2. 검토 대상자를 정의하고 모집함
3. 태스크와 질문사항을 준비함
4. 검토를 진행함
5. 검토 결과를 분석하고 반영함

TIP

설계가 변경될 수 있다는 점을 미리 고려, 가능한 경우 몇 가지 안을 미리 만들어 사용자 테스트 시에 제공하는 것이 좋음

성능(Performance) 평가, 선호도(Preference) 평가 등 평가항목에 적합한 평가방법을 수행함

http://uxmovement.com/wp-content/uploads/2012/11/image02.png

1. 사용성 테스트 계획 수립

목표

사용성 테스트의 목표,도구, 방법을 명시함

이 테스트에서 무엇을 얻어야 하는가? 테스트를 어떻게 진행할 것인가? 테스트 중에 무엇을 물을 것인가? 에 대해 계획함

소프트웨어 최종 배포전 시행하는 평가로, 프로젝트 초기에 사용성 평가를 수행했다면 비교평가를 통해 개발개선정도를 평가하는 계획을 수립할 수 있음

활동

1. 평가 목적을 정의하고 대상을 분석함
2. 사용자 집단과 테스트 환경을 정의함
3. 태스크 및 질문사항을 준비함

** 참조서식 : 사용성 테스트 계획서

사용성 평가 계획서 작성항목 예시

출처 : 댄브라운, UX DESIGN COMMUNICATION, 위키북스, 2009

2. 사용성 테스트 설계

목표

일반적이고 추상적인 테스트의 목적을 구체적인 상황과 테스트 케이스로 변환함

활동

1. 테스트 설계 : 단일/비교 테스트를 설계하고, 질적/양적 결과 데이터를 정의함
2. 테스트 참가자 선정 : 참가자 수 결정, 참가자 무작위 추출, 참여 안내/동의서를 작성함
3. 과업 선정 : 과업분석, 순서/지침을 작성함
4. 질문지 인터뷰 작성 : 사전/사후 설문서, 사후 인터뷰 항목을 작성함

사용자 프로파일(예시)

** 출처 : UX1, UX Consultant 과정 중 발췌

1. 테스트수행

목표

아래의 항목들에 대해 분석 할 수 있도록 태스크 수행을 통한 사용성 테스트를 진행함

효율성 : 얼마나 시간이 걸리며, 몇 개의 단계를 거쳐서 태스크가 완료되는가?

정확성 : 사용자들이 얼마나 에러를 일으키는가? / 치명적인 에러와 복구가 가능한 에러 중 어떤 에러인가?

기억 : 사용 후 또는 한동안 사용하지 않은 다음에 얼마나 많은 것들을 회상해 낼 수 있는가?

감성적 반응 : 태스크 완료시 사용자들이 받는 감정은? / 긍정적인 경험이 다른 이들에게까지 전파되는가?

활동

1. 휴리스틱 평가(Heuristic Evaluation), 상태전이 다이어그램(STDS)등을 활용하여 전문가 사용성 테스트를 진행함
2. 정의된 환경, 태스크, 시나리오로 1:1 사용자 테스트를 진행함
3. 랩테스트(사용성평가룸에서 테스트), 리모트 테스트(인터넷을 활용한 원격테스트), 필드 테스트(현장테스트)등의 방법을 선택하여 진행함
4. 테스트 후 추가설문을 진행하여 사용자의 의도를 파악함

TIP

사전 인터뷰를 진행하여 사용자의 경험과 지식에 대해 파악함

테스트룸과 관찰룸을 구분함

사용성 테스트 진행시 사용자가 자신의 의사를 자유롭게 표현할 수 있도록 유도함

모든 테스트 시나리오 후 사용만족도 수준을 측정함

1. 사용성 테스트 결과분석

목표

테스트 결과 데이터들을 취합/분석하여 객관적이고 정량화된 값을 도출함

결과 및 진행 상황을 한 눈에 파악 할 수 있도록 하여 문서화를 통한 지속적인 자료로 활용이 가능하도록 정리함

활동

1. 테스크 결과를 분석함
   • 태스크 성공, 태스크 시간, 에러, 효율성, 학습성 등에 대해 데이터를 분석하고 수행 매트릭스를 작성
   • 비디오 분석 및 task analysis등을 활용하여 사용자의 테스트 수행과정을 관찰하거나 자가기록 데이터를 활용하여 데이터를 보강
2. 결과 보고서를 작성함
   • 사용성 문제점 종합
   • 심각성 분석
   • 개선안 도출 및 우선 순위 분석
3. 문서화함
   • 지속적인 자료로 활용

[ 수행 매트릭스 ]

1. 매뉴얼 작성 가이드 개발

목표

기능 설명 위주의 매뉴얼이 아닌 사용자 관점으로 작성된 태스크 위주의 매뉴얼로 재구성하여 활용도를 높이고, 소프트웨어의 이해도를 높이도록 함

사용자의 소프트웨어 이해도 향상으로 소프트웨어 사용 오류를 최소화하고 잦은 오류 발생에 따른 AS 비용을 최소화할 수 있도록 함

활동

1. 구버전 매뉴얼, 기능 사양서 등을 참고하여 매뉴얼 컨텐츠의 속성(정보의 종류, 비중, 이미지(그림,표)설명의 필요성 등)을 파악함
2. 태크스 위주로 매뉴얼 컨텐츠를 재구성함
3. 페이지타이틀, 주요 내용, 참고 내용, 안내문, 주석 등의 주요 컨텐츠의 레이아웃을 디자인함
4. 영역별 내용 작성에 필요한 설명문 및 주의사항을 작성하여 템플릿 페이지를 개발함
5. 매뉴얼 내용의 일부분을 적용한 샘플 매뉴얼을 작성하여 매뉴얼 작성가이드의 적정성을 검토함
6. 매뉴얼 작성 담당자에게 사용자 중심 매뉴얼 작성가이드 및 템플릿페이지(샘플매뉴얼 포함)를 배포함

출처 : Mobico, 'Technical Writing'

1. 사용자 피드백의 지속적인 수집

목표

고객 대응 부서, 영업팀 등으로 들어오는 다양한 사용자의 불만사항, 요구사항을 지속적으로 수집 및 유형화하여 체계적으로 정리함

개발자 또는 판매자, 구매자가 아닌 실사용자의 요구사항을 수집함

활동

1. 사용자 요구사항 정보를 수집함
2. 결과를 취합 및 정리함
3. 즉시반영, 차기 버전에 반영 등 반영의 시기와 정도를 판단하여 적용함

TIP

대규모의 사용자 리서치를 항상 수행하기 어려운 중소기업에서 활용할 수 있는 방법임

이 때 수집된 사용자 피드백의 유형을 토대로, 신규 개발 또는 리뉴얼 시 개선 필요 사항 도출에 활용할 수 있도록 함

출처 : http://www.slideshare.net/june820/4-voc