1. 신규 프로젝트의 경우
   • 이 경우 분석할 task 가 없다. 따라서 새롭게 정의해야 하는데 그냥 기획자들이 맘대로 이런게 필요할거야 하고 정의하면 안된다. 따라서,
   • <1> 러프스케치
     • 환경분석에서 도출한 시사점을 보고서 러프 스케치를 그려 본다.
     • 상상력을 발휘해서 그리는 단계이다.
     • Q. 여기서 새로운 아이디어가 나와야 하는 단계인가? 아니면 벤치마킹 해서 그리면 안되는가?
     • Q. 이 과정에서 의문점을 도출해야 하는데, 어느 정도까지 자세하게 그려야 하는가?
     • Q. 시사점만을 보고서 러프스케치를 그리는 과정이 너무 인사이트가 부족한 것이 아닐까? 러프스케치를 그리는 근거가 단지 시사점 그 문장 뿐인가?
     • Q. 러프스케치의 목적이 새로운 아이디어를 도출하기 위함인가, 혹은 화면 구성을 하기 위함인가? 화면을 그리는 것이기 때문에, 새로운 아이디어도 포함될 수 있고, 화면 배치에 대한 생각도 들어가 있을 수 있고 자질 구레한 기능 등이 들어갈 수 있는데, 이런 것들이 다 러프스케치에서 짬뽕 되면 새로운 아이디어가 너무 정리가 안되는 것이 아닌가?
     • Q. 차라리 그림으로가 아니라 시사점을 통해서 이런 기능들이 있으면 좋겠다, 식으로 구어체로 정리하는 방법은 별로일까?
     • Q. 왜 의문점을 도출 할 때 러프 스케치를 통해 도출해야 하는가?
   • <2> 의문점 도출
     • 각 화면에서 유저가 가질 수 있는 의문점과 고려해야 할 사항들을 의문점의 형식으로 적어서 포스트잇에 하나씩 적는다.
     • 조원들과 같이 해야 다양한 아이디어를 얻을 수 있다.
   • <3> 스토리 라인 도출
     • 의문점을 바탕으로 카테고리를 한다.
     • 속성 분석 작업이라고 한다.
     • 의문점들을 그대로 키워드 별로 정리하는 것이 아니라, 각 의문점에서 연상할 수 있는 문맥적인 큰 의미들을 크게크게 정리한다.
     • 상상력이 필요하고, 포괄적이고 전체적인 설계 정리가 필요하다.
     • 상상력을 발휘해서 그린 스케치에는 새로운 아이디어가 포함되어 있다. 하지만 그러한 새로운 아이디어를 바탕으로 항목화 하는 것이 아니라, 그 아이디어를 바탕으로 도출해 낼 수 있는 일반적이고 포괄적인 방향으로 스토리 라인을 정리해야 한다. 그래야 ux 방향을 기획자의 의도대로가 아니라, 사용자 중심으로 설계할 수 있다.
     • 이때 도출된 스토리 라인은 계속 수정이 될 수 있다. 하지만 포괄적인 의미에서 작성을 했을 때 그 수정 폭이 좀 더 포괄적이고 전체적으로 할 수 있다.
     • Q. 의문점을 바탕으로 속성 분석하여 카테고링 하는 것이 누가 하느냐에 따라 달라질 수 있는 것 같은데, 잘한 카테고링에 대한 판단 기준이 있는가?
     • Q. 어떤 의문점이 나왔는지도 이런 속성 분석의 성패를 가르는 것 아닌가?
     • Q. 어느정도까지 포괄적으로 잡아야 하는가?

리뉴얼 프로젝트의 경우

<Task analysis>
1. what it is
- simple and effective process for laying out tasks from a user's perspective.
- it gets you to the bottom of what the user will want to do and the simplest, most effective way of doing that by breaking down tasks into smaller steps
- define user's problems
1.1 how does it work
- laid all the steps out
- see where additional user support is required
- eliminate unnecessary steps

2. benefits
- get an overciew
- understand and predict what users may do in any given situation
- identify areas for improving / 
3. limitations
- overly linears and simplified
- too basic information
- there are many other ways to get to the same end goal
- anything is predictable. always unpredictable

4. questions we need for task analysis
- what personal or cultural experiences do users bring to the task?
- where and when do they begin a task?
- how long do they expect it to take?
etc. 
==> task analysis is not just defining what kind of task is needed. We should understand broader background information and context for better task analysis

5. how to do
1) data we can use
  - user interview
  - observational studies . etc
  - hierarchical task analysis (goal-> subtask)
* data should be collected until you can answer these questions.
- what makes users begin the task?
- how do users know when the task is complete?
- what do users have to know in order to complete the task?
- what tools do users need during the task?
2) how to deal with them
- draw a digram in an order
- write the story in narrative form
3) get feeedback
- whether it matches their understanding, clear, consistent
- same level of detail, vague?

포스트잇을 사용하는 이유

ux 프로젝트에서는 반복적으로 같은 일을 해야 하는 경우가 많기 때문에 형식보다 빠르게 결과를 낼 수 있는 방법 사용. 큰 벽이나 큰 종이를 사용해서 아이디어를 시각화 하는 방법. 무작위로 생성된 아이디어를 재배치 하기도 좋다.

ux 디자인 / ux 방법론은 다르다.

디자인 : 사용자의 경험을 디자인 하는것 
방법론 : 사용자를 이해하기 위한 방법을 프로세스로 정리해 놓은 이론. 따라서 프로젝트 마다 적합한 방법론이 있고 그렇지 않을 수 있다. 인사이트를 도출해내기 위한 '도구'일 뿐이지 필수적으로 거쳐야 하는 것은 아님.

ux는 사상이나 원칙이 아니라 방법론이다.(methodology). 사용자의 경험을 디자인 하는 학문이다. 사용자의 경험이 중심이 되어 디자인을 풀어나간다.

하지만 너무 방법론만을 중시하다 보면, ‘디자이너의 영감, 통찰력’을 평가절하하는 오류에 빠질 수 있다. “벌써부터 디자인을 구상해?” “ux 방법론에 맞지 않아” “이미 머릿속에 사용자의 경험이 예상이 되고 영감이 잡히는데, 방법론이 맞지 않는다고 해서 무시해야 하는가?” “왜 안돼?” 방법론을 따르지 않는다면 무시되어야 하는 걸까?

그래서 우선적으로 ux 각 단계에서 사용 되는 모든 방법론들을 정리해 보고, 내가 실제 프로젝트를 진행하는 데에 있어서 적합한 방법론을 선택하는 데 좀 더 합리적인 선택을 할 수 있도록 하고자 한다. 너무 많은 방법론들이 있고, 각각의 방법론들은 정답이 아니라 하나의 도구로서 사용되는 것인데, 정형화된 ux 순서를 따르고자 억지로 그 방법론에 끼워 맞춘다면 논리 구조를 학습하기 어려울 뿐만 아니라, 하나의 프로젝트 과정을 전체적으로 완전히 자신있게 이해했다고 말하기 어렵기 때문이다. 따라서 어떤 하나의 프로젝트를 하더라도 그에 맞는 방법론만을 사용하는 것이 아니라, 다양한 방법론 및 선택안을 검토 하고 그 중 최선의 방법을 선택하는 과정 또한 알고자 ux 관련 다양한 정보들을 한꺼번에 정리해서 아이디어 도출 과정에 좀 더 확신과 논리적 근거를 갖고자 한다.

특히나 정확한 방법론을 선택하는 것이 매우 중요하다. 왜냐하면 사용하는 방법론의 종류에 따라 그 프로젝트의 방향성과 목적이 완전히 달라질 수 있기 때문이다. 가령, 클라이언트가 요구하는 프로젝트 방향과 목적이 있는데, 그에 부합하지 않는 방법론이 선택될 경우, 그 전체 프로젝트가 완전히 산으로 가는 경우가 발생할 수 있기 때문이다. 특히나 ux 방법론을 잘 습득하고 있는 사람이 많지 않아서, 얕은 지식으로 대충 적당한 방법론을 선택하는 경우가 많기 때문에, 정확한 지식을 습득하고 이에 대한 충분히 이해하는 것은 전문가가 되기 위해 반드시 필요한 단계이다.

ux 를 기획자, 혹은 디자이너가 많이 역할을 맡는다. 하지만 이에 대해 정확하게 배우고 일을 하는 과정이 필요하기 때문에, 지금 이 작업을 통해 인사이트를 정확히 도출하는 방법론을 완전히 습득하고자 한다. 시늉만 하는 기획자가 아닌 확실한 전문가가 되자.

우선 ux의 전체적인 과정에 대해 정리를 하자면,

ux는 크게 세가지 단계로 나눠 볼 수 있는데,

기획 –> 전략 –> 설계

1. RFP : client 가 의뢰를 하는 단계이다.
2. 환경분석, 시사점 도출 : 동향과 트렌드를 확인하여 ux 기획의 방향성을 잡는다.
3. task 분석 : 시사점과 관련하여 유저의 task를 도출해 낸다.
   • 신규 프로젝트 : 시사점 -> 러프스케치 -> 의문점 -> task리뉴얼 : 기존 서비스의 기능 나열 -> 사용자 종류(heavy, light)에 따라 분류
     • 이 과정에서 이해관계자와의 인터뷰를 통해 task를 좀 더 구체적으로 파악하고, 설계자의 의도를 들어 보면서 좀 더 자세히 이해할 수 있다. 유저와 이해관계자들의 task 별 context를 파악하는 과정이 필요하다.
     환경분석을 통한 task 분석을 통해 가설을 설정한다.
4. (착수보고회) : 실무의 경우 매크로 리서치 및 task 정리를 통해 앞으로 사용할 방법론과 일정에 대해 착수 보고회를 갖는다.
   • 착수 보고회를 갖기 전에 분석한 task에 대해 이해 관계자와 먼저 인터뷰를 갖고 이해한 task 가 맞는지, 실제 이해관계자들은 각각의 task에 대해 어떻게 느끼고 있는지 알아보는 과정을 거친다. 착수보고회에 참석하는 이해관계자들은 팀장급의 리더들이다.
5. ux 리서치 : 환경분석을 통한 시사점 + task 분석 결과를 바탕으로 구체적인 ux 전략을 얻기 위해 리서치를 진행한다.
   • 데스크 리서치(마이크로) : 벤치마킹
     • 환경 분석에서 도출된 시사점들을 바탕으로 벤치마킹을 한다.
     필드 리서치
     • 인뎁스 인터뷰이해관계자 인터뷰
     외부 고객(유저, 경쟁사)와 내부고객(이해관계자)들의 접점을 찾아야 하는 단계이다. 그와 더불어 기술 동향까지 포함해서 시사점을 기준으로 ux 방향성을 포괄적이고 전체적으로 탐색한다. rough sketch를 그리면서 큰 그림을 그린다.리서치의 결과로는 가설을 설정하여 ux 기획의 방향성을 설정한다. 사실 가설을 설정하기 보단, 환경분석 단계에서 설정했던 가설을 검증하고 새로운 방향성을 재정립 하는 단계라고 볼 수 있다.
6. 시사점 도출
   • 퍼소나, 여정지도 등의 방법을 사용한다.ux 리서치 결과를 통해 숨겨진 니즈를 파악하고, 그 숨겨진 니즈들을 패턴화 하여 아이디어를 도출한다.더블 다이어 그램에서 아이디어가 하나로 모아지는 시점으로, 이때를 기반으로 전체적인 방향성을 확립한다.
7. 프로토타입
8. 사용성 테스트
9. 와이어프레임