HCI - Needfinding

? UI, UX, CX, SD 란?

=> "UI" : User Interface, "UX" : User Experience, "CX" : Customer Experience, "SD" : Service Design

 

* UI : 

제품의 시각적인 부분. user들에게 product를 더 매력적이게 어필할 수 있다.

UI는 제품의 첫 인상을 담당하는 부분이다. 만일 UI가 좋지 않다면, 진입장벽이 크게 형성될 수 있다.

ex) 김밥의 포장

 

* UX:

사용자가 제품이나 서비스를 실제로 사용할 때 어떻게 느끼고 무엇을 생각하는지를 의미한다.

ex) 김밥을 먹는 과정에서 느낀 맛, 크기 등

 

* CX:
제품 또는 서비스의 전반적인 인상. CX는 고객이 특정 서비스나 제품을 고르거나 고르지 않은 "이유"이다.

ex) 해당 김밥을 구매하게 된 이유.

 

* SD:
자원, 프로세스 등을 조직하는 과정.

제품이나 서비스를 중심으로 모든 것을 조정하여 최상의 기능을 제공하는 것.

ex) 김밥을 사러가는 과정과 구매하는 과정

 

* HCI (Human Computer Interaction):

사용자에게 최상의 경험을 제공하기 위해 다양한 구성 요소를 선택하고 만들고 결합하여 조화롭게 구성하는 것.

ex) 김밥 그 자체

---

* Software Requirement Specification (SRS)

- Software engineering에서, SRS는 User Requirements, Functional Requirements, Interface Requirements... 등과 같은 요구 사항들을 의미한다.

=> 우수한 SRS의 목표는 개발자가 세부 사항을 놓치지 않고 Requirements에 집중할 수 있도록 메뉴얼을 제공하는 것.

(개발이 요구사항을 충족시키는 것을 돕는다.)

 

# Needfinding : SRS를 문서화하기 이전에 user들을 이해하는 것이 필요하다. 그 과정에 수행하게 되는 것이다.

=> 현재 유저들이 경험하고 있는 문제가 뭘까?

=> 왜 문제가 일어날까?

=> 문제를 느끼고 있는 대상은 누굴까? 개별 사람에 대한 문제일까? 아니면 다른 사람들도 있을까?

 

#Ideation 

=>"지금 문제를 해결하려면 어떤 개선점이 필요할까?"

---

#Needfinding의 과정

* 유저의 특성에는 무엇이 있을까? => 나이, 지식 수준, Computer experience, Motivation 등 다양한 기준이 있을 수 있다.

 

! 사용자에게 Needfinding을 할 때 "정말"로 객관적인 데이터를 수집하는 것이 중요하다.

만약, 사용자에게 자신의 아이디어나 자신이 원하는 결론에 조금이라도 다다를 수 있는 내용을 알려주고 수집을 할 경우, 이는 깨끗한 데이터가 아닐 수가 있다.

따라서 너무 빨리 System design을 하는 것 보단 충분한 Needfinding 이후에 하는 것이 좋다.

 

* 자주 저지르는 오류

- User가 아닌 System의 관점으로 봐버린다. (ex: user의 약속에 관해 공지한다 x -> 약속에 관한 알림을 받는다. o)

- UI 디자인을 너무 일찍 고정하는 것. => 초기 디자인부터 고정된 UI에 너무 연연하게 된다.

- 사용자의 구체적인 의도에만 집중.=> "의도"에 초점을 맞춰라.

(ex: 디스크에 파일을 저장 x -> 저장된 것을 확인.)

 

1. User들을 분류하기.

 

* Multiple Classes of Users

- User들을 여러 Class로 분류하는 것이 필요하다.(직업, 나이 등)

 

- Beyond users : stakeholders

1. First degree : 제품이나 서비스를 이용하고 싶어하는 사람들

2. Second degree : 제품을 사용하는 사람들의 결과물을 가지고 일하는 사람들.(ex: 동료)

3. Third degree : 시스템을 설치, 배포, 지원하는 사람들.

 

- 또 다른 관점

1. Owners and shareholders : 제품이나 서비스를 통해 이익을 늘리거나 효율을 늘리고 싶어하는 목표를 지닌 사람.

2. Customers : design process에서 구체적으로 원하는 사항이나 선호도가 있는 사람들

3. Employees : 특히 해당 서비스를 업무에 사용할 사람들이 있는 경우 design 단계에서 요구와 선호도 파악이 중요하다.

4. Suppliers

5. Regulators : 정부 등 서비스 개발에 다양한 가이드 라인 제한을 거는 요소들.

 

2. User들의 목표를 명세화하기

 

- 문제에 관련된 목표를 명확히 해야한다. (ex: KTX 여행의 티켓팅)

- 이 목표에 다다르는 과정을 subtask들로 분할한다. (ex: 로그인 -> 검색 -> 확인 -> 선택 -> 구매 ...)

- 이 개별 subtask들의 목표를 설정한다. (ex: 검색 : 가능한 일자의 KTX 티켓을 찾는다.)

 

3. Needfinding 시작

 

3-1. 컨텍스트 조회 

=> 현장 조회/인터뷰로 타켓 유저층을 이해하기.

 

컨텍스트 조회 4가지 원칙

a. Context : user의 workplace 주변 세부 사항 관찰. (추상화하지 말고 그대로 파악하기)

b. Partnership : Target user에게 공감하기, user의 action과 그 이유를 이해하기 위해 관찰, 질문한다.

c. Interpretation : 자신의 해석을 target user에게 공유하기, user들은 그 해석을 정정할 수 있다.

d. Focus : 주된 연구 목표에서 벗어나지 않게 집중.

 

- 쉬운 접근 방법 : The master-apprentice model :

Study target은 'Master'로써 context 내에서 크게 발언하고, 연구자는 '학생'으로써 묻고 배우는 방식.

? 크게 발언 : user가 작업 중에 자신이 무엇을 생각하고 무엇을 하고 있는지를 명시적으로 말함.

- (작업 중에) 동시에 진행하면? : 실시간으로 피드백을 받으나, 사용자의 작업에 영향을 미칠 수 있다.

-(완료 후) 회고 방식으로 진행하면? : 사용자 작업에 영향을 덜 주나, 참가자는 그때 당시 느꼈던 생각을 말하지 못할 수도 있음.

- 하이브리드 : 단점이 많이 중화되나, 참가자에게 부담이 된다.

-> 컨텍스트 조회가 좋지 않을 때 : Large target, 산발적 행동(드물게 일어남), 긴 시간동안 관찰해야할 때(장기 연구).

 

3-2. Diary Study

=> 참여자들은 자신의 행동/경험들을 스스로 기록한다. 기록은 주기적으로 이뤄지며, 쉬운 캡처나 녹화로 이뤄지는게 좋다.

=> 장기 연구에 적합하다.

 

3-3. ESM/EMA (Experience Sampling Method / Ecological Momentary Assessment)

=> "경험"이 발생한 즉시 기록. 참가자는 자신의 행동(사실)과 생각을 기록한다. (ex: 배달의 민족 주문 후 즉시 피드백)

=> 일반적으로 디지털로 수집된다.

 

3-4. Survey

=> 질문에 편향이 생기지 않도록 주의

 

3-5. Participatory Design (Co-Degisn)

=> user를 디자인 팀에 직접 포함.

=> 활동을 반복적으로 진행됨. 아이디어가 실제로 어떻게 진행되는지 확인, 테스트, 조정 반복.

 

 

4.Affinity Diagramming

=> 수집된 데이터를 정리하는 기법.

=> 목표는 공통된 문제, 요구를 찾는 것이다.

* 과정 :

1. 수집된 데이터를 노트에 단순화 하여 기록

2. 비슷한 주제 찾기

3. 아이디어 그룹화

4. 각 그룹에 label 지정.

(이 때, 내용이 동일한 데이터도 버리지 말고 확인하기. 반복된 데이터는 해당 문제가 더 중요하다는 것을 설명할 수 있음.)

 

5. Persona

=> 일반적인 user에 대한 한 페이지 설명. (수집된 user 데이터의 일반화. 데이터에 기반하여 일반적인 한명의 user를 가상으로 만든다.)

=> user를 정의하고 target에 명확한 초점을 유지하는데 도움을 준다.

 

6. Walk through data

=> needfinding의 최종 단계.

=> Data reviewing을 통해 이전 문제들을 "remind"할 수 있다.