서비스경험디자인기사 실기 사용자 요구 파악

1. 정의

```

사용자 요구 파악은 사용자가 서비스에서 무엇을 필요로 하는지 찾아내는 과정이다.

사용자는 서비스를 실제로 이용하는 사람이다. 요구는 사용자가 바라는 것, 필요로 하는 것, 불편해서 개선되기를 원하는 것을 뜻한다.

쉽게 말하면 사용자 요구 파악은 “사용자가 무엇 때문에 불편한가”, “사용자는 무엇을 원하고 있는가”, “서비스는 무엇을 해결해야 하는가”를 정리하는 일이다.

서비스경험디자인에서는 사용자 요구를 단순히 사용자가 말한 내용으로만 보지 않는다. 사용자가 직접 말한 내용도 중요하다. 하지만 사용자의 행동과 상황에서 드러나는 숨은 요구도 중요하다.

예를 들어 사용자가 “글씨를 크게 해주세요”라고 말했다고 가정하자. 겉으로 보이는 요구는 글씨 크기 확대다. 하지만 실제 요구는 “정보를 쉽게 읽고 싶다”일 수 있다. 또는 “중요한 내용을 빠르게 찾고 싶다”일 수 있다.

따라서 사용자 요구 파악은 사용자의 말을 그대로 받아 적는 일이 아니다. 사용자의 말, 행동, 상황, 감정, 불편을 함께 보고 실제 니즈를 찾아내는 과정이다.

니즈는 사용자가 실제로 필요로 하는 것이다. 사용자가 직접 말하지 않아도 행동이나 문제 상황에서 드러날 수 있다.

```

2. 필요한 이유

```

사용자 요구 파악이 필요한 이유는 서비스 개선의 기준이 사용자에게 있기 때문이다.

서비스디자인은 제공자 중심이 아니라 사용자 중심으로 문제를 해결한다. 제공자가 좋다고 생각하는 기능이 실제 사용자에게는 필요 없을 수 있다. 반대로 사용자가 정말 필요한 기능은 제공자가 놓치고 있을 수 있다.

사용자 요구를 제대로 파악하지 못하면 다음 문제가 생긴다.

• 사용자에게 필요 없는 기능을 만들 수 있다.

• 실제 불편을 해결하지 못할 수 있다.

• 서비스 이용 과정이 계속 복잡하게 남을 수 있다.

• 프로토타입 검증에서 문제가 반복될 수 있다.

• 운영 후 사용자 불만이 계속 발생할 수 있다.

실제 개발에서도 사용자 요구 파악은 중요하다. 앱, 웹사이트, 관리자 페이지, 예약 시스템, 민원 시스템, 쇼핑몰 모두 사용자 요구를 기준으로 설계해야 한다.

예를 들어 회원가입 기능을 만든다고 가정하자. 개발자는 이메일, 비밀번호, 이름, 전화번호, 주소를 입력받는 화면을 만들 수 있다. 하지만 사용자는 “가입을 빠르게 끝내고 싶다”고 생각할 수 있다.

이때 사용자 요구를 파악하면 불필요한 입력 항목을 줄일 수 있다. 소셜 로그인 기능을 고려할 수 있다. 오류 메시지를 더 쉽게 만들 수 있다. 현재 가입 단계가 어디인지 보여줄 수 있다.

즉, 사용자 요구 파악은 서비스의 방향을 정하는 기준이다. 이후 조사, 분석, 디자인 원칙, 아이디어 도출, 프로토타입 개발까지 모두 사용자 요구와 연결된다.

```

3. 핵심 개념

```

3-1. 사용자

사용자는 서비스를 실제로 이용하는 사람이다.

사용자는 고객과 다를 수 있다. 고객은 비용을 지불하는 사람을 뜻하는 경우가 많다. 사용자는 실제로 서비스를 쓰는 사람이다.

예를 들어 학원 수강 신청 서비스에서 비용을 내는 사람은 부모일 수 있다. 하지만 실제 수업을 듣는 사람은 학생이다. 이 경우 부모와 학생 모두 중요한 사용자 또는 이해관계자가 될 수 있다.

3-2. 사용자 요구

사용자 요구는 사용자가 서비스에서 바라는 것 또는 필요로 하는 것이다.

예를 들어 “예약 과정을 쉽게 이해하고 싶다”, “대기 시간을 알고 싶다”, “오류가 났을 때 해결 방법을 알고 싶다”가 사용자 요구가 될 수 있다.

3-3. 명시적 요구

명시적 요구는 사용자가 직접 말한 요구다.

예를 들어 사용자가 “버튼을 크게 해주세요”, “설명을 더 자세히 써주세요”, “예약 확인 문자를 보내주세요”라고 말하면 명시적 요구다.

명시적 요구는 확인하기 쉽다. 하지만 사용자가 말한 내용이 항상 정확한 해결책은 아닐 수 있다.

3-4. 잠재적 요구

잠재적 요구는 사용자가 직접 말하지 않았지만 행동이나 상황에서 드러나는 요구다.

예를 들어 사용자가 계속 뒤로 가기 버튼을 누른다면 현재 화면에서 필요한 정보를 찾지 못하고 있을 수 있다. 사용자가 입력 오류를 반복한다면 입력 방식이 어렵거나 안내가 부족할 수 있다.

잠재적 요구는 관찰조사와 인터뷰를 통해 파악할 수 있다.

3-5. 니즈

니즈는 사용자가 실제로 필요로 하는 것이다.

요구와 니즈는 비슷하지만 약간 다르다. 요구는 사용자가 표현한 바람에 가깝다. 니즈는 그 요구 뒤에 있는 실제 필요에 가깝다.

예를 들어 사용자가 “검색창을 크게 해주세요”라고 요구할 수 있다. 실제 니즈는 “원하는 정보를 빠르게 찾고 싶다”일 수 있다.

3-6. 페인포인트

페인포인트는 사용자가 서비스 이용 중 불편을 느끼는 지점이다.

예를 들어 긴 대기 시간, 어려운 용어, 복잡한 인증 절차, 찾기 어려운 버튼, 불친절한 오류 메시지가 페인포인트가 될 수 있다.

3-7. 사용자 맥락

사용자 맥락은 사용자가 서비스를 이용하는 상황이다.

같은 서비스라도 사용자가 어디에서, 언제, 어떤 기기로, 어떤 목적을 가지고 사용하는지에 따라 요구가 달라진다.

예를 들어 병원 예약 서비스를 집에서 천천히 사용하는 사람과 병원 앞에서 급하게 사용하는 사람은 요구가 다를 수 있다.

3-8. 요구사항

요구사항은 사용자 요구를 바탕으로 프로젝트에서 해결해야 할 조건으로 정리한 것이다.

예를 들어 사용자 요구가 “예약 상태를 알고 싶다”라면 요구사항은 “사용자는 예약 완료 여부와 예약 시간을 확인할 수 있어야 한다”로 정리할 수 있다.

```

4. 주변 기초 개념

```

4-1. 사용자 조사

사용자 조사는 사용자의 행동, 생각, 감정, 불편, 요구를 파악하는 과정이다.

대표적인 방법에는 인터뷰, 관찰조사, 설문조사, FGI가 있다.

• 인터뷰: 사용자를 직접 만나 질문하는 방법

• 관찰조사: 사용자가 실제로 행동하는 모습을 보는 방법

• 설문조사: 여러 사용자에게 같은 질문을 하여 답을 모으는 방법

• FGI: 여러 명을 모아 의견을 듣는 집단면접

4-2. 정성조사

정성조사는 숫자보다 이유와 맥락을 파악하는 조사다.

인터뷰와 관찰조사가 대표적이다. “왜 사용자가 이 단계에서 멈추는가”를 파악할 때 유용하다.

4-3. 정량조사

정량조사는 숫자와 통계로 문제를 파악하는 조사다.

설문조사, 클릭률, 이탈률, 완료율, 대기시간 분석이 정량조사에 해당한다.

예를 들어 “사용자 100명 중 40명이 예약 단계에서 이탈했다”는 정량 정보다.

4-4. VOC

VOC는 Voice of Customer의 줄임말이다. 고객의 소리라는 뜻이다.

문의, 불만, 리뷰, 상담 기록, 고객센터 접수 내용이 VOC에 해당한다.

VOC는 사용자 요구를 파악하는 중요한 자료다. 하지만 불만이 큰 사용자 의견만 많이 들어올 수 있으므로 다른 조사와 함께 보는 것이 좋다.

4-5. 사용자 여정

사용자 여정은 사용자가 서비스를 이용하는 전체 흐름이다.

보통 이용 전, 이용 중, 이용 후로 나눌 수 있다. 각 단계에서 사용자가 무엇을 하고, 무엇을 느끼고, 어디에서 불편을 겪는지 확인한다.

4-6. 터치포인트

터치포인트는 사용자와 서비스가 만나는 지점이다.

앱 화면, 문자 알림, 상담원, 안내문, 키오스크, 이메일, 전화, 매장 입구가 모두 터치포인트가 될 수 있다.

4-7. 인사이트

인사이트는 조사 결과에서 발견한 의미 있는 깨달음이다.

단순한 사실과 인사이트는 다르다.

“사용자가 예약 화면에서 3분 이상 머문다”는 사실이다. “사용자가 진료과 정보를 이해하지 못해 다음 단계로 이동하지 못한다”는 인사이트에 가깝다.

4-8. 요구사항 도출

요구사항 도출은 사용자 요구와 문제 상황을 바탕으로 서비스가 갖춰야 할 조건을 정리하는 과정이다.

사용자 요구 파악은 요구사항 도출의 기초가 된다.

```

5. 실제 흐름

```

사용자 요구 파악은 다음 순서로 진행할 수 있다.

5-1. 사용자 대상을 정한다

먼저 어떤 사용자의 요구를 파악할 것인지 정한다.

모든 사용자를 한 번에 분석하려고 하면 범위가 너무 넓어진다. 핵심 사용자를 먼저 정해야 한다.

예를 들어 공공 민원 서비스라면 고령 사용자, 처음 이용하는 사용자, 모바일 이용자, 장애가 있는 사용자처럼 나눌 수 있다.

5-2. 사용자 상황을 확인한다

사용자가 어떤 상황에서 서비스를 이용하는지 확인한다.

• 언제 사용하는가

• 어디에서 사용하는가

• 어떤 기기로 사용하는가

• 무엇을 하려고 사용하는가

• 서비스 이용 중 어떤 어려움이 있는가

5-3. 사용자 발화를 수집한다

사용자 발화는 사용자가 실제로 말한 내용이다.

인터뷰, VOC, 리뷰, 상담 기록에서 사용자 발화를 수집할 수 있다.

이때 문장을 그대로 기록하는 것이 중요하다. 처음부터 해석을 섞으면 실제 의미가 흐려질 수 있다.

5-4. 사용자 행동을 관찰한다

사용자가 실제로 어떻게 행동하는지 본다.

사용자는 말로는 “괜찮다”고 해도 실제로는 같은 단계를 반복하거나, 버튼을 찾지 못하거나, 중간에 포기할 수 있다.

사용자 행동은 숨은 요구를 찾는 데 중요하다.

5-5. 불편 지점을 찾는다

사용자가 어디에서 막히는지 찾는다. 이 지점이 페인포인트다.

• 용어가 어렵다.

• 현재 단계가 보이지 않는다.

• 오류 메시지가 이해되지 않는다.

• 입력해야 할 정보가 너무 많다.

• 완료 여부를 확인하기 어렵다.

5-6. 요구와 니즈를 구분한다

사용자가 말한 요구를 그대로 해결책으로 정하지 않는다. 그 요구 뒤에 있는 실제 니즈를 찾아야 한다.

예를 들어 “버튼을 크게 해주세요”라는 요구가 있다고 하자. 실제 니즈는 “중요한 버튼을 쉽게 찾고 싶다”일 수 있다.

5-7. 요구사항으로 정리한다

마지막으로 사용자 요구를 프로젝트에서 해결해야 할 요구사항으로 정리한다.

요구사항은 구체적인 문장으로 작성하는 것이 좋다.

• 사용자는 현재 진행 단계를 확인할 수 있어야 한다.

• 사용자는 오류 발생 시 수정 방법을 알 수 있어야 한다.

• 사용자는 어려운 용어에 대한 쉬운 설명을 볼 수 있어야 한다.

```

6. 예시

```

아래는 사용자 요구 파악 예시다.

서비스 상황:
```

병원 모바일 예약 서비스에서 사용자가 진료과 선택 단계에서 자주 이탈한다.

사용자 발화:
“어느 진료과를 선택해야 하는지 모르겠어요.”
“증상은 아는데 진료과 이름이 어려워요.”
“예약을 잘못하면 다시 해야 할 것 같아서 불안해요.”

사용자 행동:
사용자가 진료과 선택 화면에서 오래 머문다.
사용자가 진료과 목록을 여러 번 열어본다.
사용자가 예약을 완료하지 않고 앱을 종료한다.

페인포인트:
진료과 용어가 어렵다.
증상과 진료과의 연결이 부족하다.
예약 실수에 대한 불안이 있다.

사용자 요구:
증상 기준으로 진료과를 찾고 싶다.
진료과 설명을 쉽게 보고 싶다.
예약 내용을 완료 전에 다시 확인하고 싶다.

요구사항:
사용자는 증상 기준으로 진료과를 추천받을 수 있어야 한다.
사용자는 각 진료과의 쉬운 설명을 볼 수 있어야 한다.
사용자는 예약 완료 전 선택 내용을 확인할 수 있어야 한다.

7. 코드 또는 설정 설명

```

이 주제는 개발 코드보다 사용자 요구를 분석하고 요구사항으로 바꾸는 과정이 중요하다. 따라서 위 예시를 항목별로 설명한다.

7-1. 서비스 상황

병원 모바일 예약 서비스에서 사용자가 진료과 선택 단계에서 자주 이탈한다.

서비스 상황은 현재 어떤 문제가 발생하고 있는지 설명한다.

여기에는 서비스, 사용자 행동, 문제가 포함되어야 한다. 이 예시에서는 병원 모바일 예약 서비스가 대상이고, 진료과 선택 단계에서 이탈이 발생한다.

7-2. 사용자 발화

“어느 진료과를 선택해야 하는지 모르겠어요.”
```

“증상은 아는데 진료과 이름이 어려워요.”
“예약을 잘못하면 다시 해야 할 것 같아서 불안해요.”

```

사용자 발화는 사용자가 실제로 말한 내용이다.

발화에는 사용자의 생각, 감정, 불편이 담겨 있다. 여기서는 진료과 선택의 어려움과 예약 실수에 대한 불안이 드러난다.

7-3. 사용자 행동

사용자가 진료과 선택 화면에서 오래 머문다.
```

사용자가 진료과 목록을 여러 번 열어본다.
사용자가 예약을 완료하지 않고 앱을 종료한다.

```

사용자 행동은 사용자가 실제로 한 행동이다.

말보다 행동이 더 정확한 단서가 될 때도 있다. 사용자가 오래 머물거나 여러 번 같은 화면을 확인한다면 정보 이해에 어려움이 있을 수 있다.

7-4. 페인포인트

진료과 용어가 어렵다.
```

증상과 진료과의 연결이 부족하다.
예약 실수에 대한 불안이 있다.

```

페인포인트는 사용자가 불편을 느끼는 지점이다.

이 예시에서는 어려운 용어, 부족한 설명, 실수에 대한 불안이 핵심 불편이다.

7-5. 사용자 요구

증상 기준으로 진료과를 찾고 싶다.
```

진료과 설명을 쉽게 보고 싶다.
예약 내용을 완료 전에 다시 확인하고 싶다.

```

사용자 요구는 사용자가 필요로 하는 것이다.

사용자 요구는 사용자의 관점으로 작성하는 것이 좋다. “사용자는 무엇을 하고 싶은가”를 중심으로 정리한다.

7-6. 요구사항

사용자는 증상 기준으로 진료과를 추천받을 수 있어야 한다.
```

사용자는 각 진료과의 쉬운 설명을 볼 수 있어야 한다.
사용자는 예약 완료 전 선택 내용을 확인할 수 있어야 한다.

```

요구사항은 사용자 요구를 서비스가 갖춰야 할 조건으로 바꾼 것이다.

“찾고 싶다”는 사용자 요구다. “추천받을 수 있어야 한다”는 요구사항이다.

```

8. 주의점

```

8-1. 사용자가 말한 요구를 그대로 해결책으로 정하면 안 된다

사용자가 “버튼을 크게 해주세요”라고 말해도 실제 문제는 버튼 크기가 아닐 수 있다.

중요한 것은 사용자가 왜 그렇게 말했는지 파악하는 것이다. 버튼을 못 찾는 것인지, 문구가 어려운 것인지, 화면 구조가 복잡한 것인지 확인해야 한다.

8-2. 요구와 니즈를 구분해야 한다

요구는 사용자가 표현한 바람이다. 니즈는 그 요구 뒤에 있는 실제 필요다.

8-3. 모든 사용자의 요구를 한 번에 해결하려고 하면 안 된다

사용자는 모두 다르다. 초보 사용자, 숙련 사용자, 고령 사용자, 모바일 사용자, 관리자 사용자의 요구가 다를 수 있다.

먼저 핵심 사용자를 정하고 그 사용자의 요구를 중심으로 분석해야 한다.

8-4. 사용자 요구와 제공자 요구를 구분해야 한다

사용자 요구는 서비스를 이용하는 사람의 필요다. 제공자 요구는 서비스를 운영하는 사람의 필요다.

예를 들어 사용자는 “신청 절차가 쉬웠으면 좋겠다”고 생각한다. 제공자는 “접수된 신청을 빠르게 분류하고 싶다”고 생각할 수 있다.

서비스디자인에서는 둘 다 중요하지만, 서로 구분해서 정리해야 한다.

8-5. 감정도 요구 파악의 단서가 된다

사용자가 불안하다, 답답하다, 헷갈린다, 기다리기 힘들다고 느끼는 것도 중요한 정보다.

감정은 서비스 문제를 찾는 단서가 될 수 있다. 예를 들어 사용자가 예약 실수를 불안해한다면 확인 화면이나 수정 기능이 필요할 수 있다.

8-6. 요구사항은 구체적인 문장으로 정리해야 한다

“사용자가 편해야 한다”는 요구사항으로 부족하다.

“사용자는 현재 진행 단계를 확인할 수 있어야 한다”처럼 실제 설계 기준이 될 수 있는 문장으로 작성해야 한다.

```

9. 요약

```

사용자 요구 파악은 사용자가 서비스에서 무엇을 필요로 하고, 어디에서 불편을 느끼는지 찾아내는 과정이다.

사용자가 직접 말한 요구도 중요하다. 하지만 행동과 상황에서 드러나는 잠재적 요구도 중요하다.

사용자 요구는 서비스디자인의 조사, 분석, 디자인 원칙, 아이디어 도출, 프로토타입 개발의 기준이 된다.

요구와 니즈는 구분해야 한다. 요구는 사용자가 표현한 바람이고, 니즈는 그 뒤에 있는 실제 필요다.

좋은 사용자 요구 파악은 사용자 발화, 사용자 행동, 페인포인트, 니즈, 요구사항을 연결해서 정리하는 것이다.

핵심 흐름은 다음과 같다.

1. 사용자 대상을 정한다.

2. 사용자 상황을 확인한다.

3. 사용자 발화를 수집한다.

4. 사용자 행동을 관찰한다.

5. 불편 지점을 찾는다.

6. 요구와 니즈를 구분한다.

7. 요구사항으로 정리한다.

```

10. 핵심 용어 정리

```

사용자 = 서비스를 실제로 이용하는 사람

사용자 요구 = 사용자가 서비스에서 바라는 것 또는 필요로 하는 것

명시적 요구 = 사용자가 직접 말한 요구

잠재적 요구 = 사용자가 직접 말하지 않았지만 행동과 상황에서 드러나는 요구

니즈 = 사용자가 실제로 필요로 하는 것

페인포인트 = 사용자가 서비스 이용 중 불편을 느끼는 지점

사용자 맥락 = 사용자가 서비스를 이용하는 상황과 조건

요구사항 = 사용자 요구를 바탕으로 프로젝트에서 해결해야 할 조건

사용자 조사 = 사용자의 행동, 생각, 감정, 불편, 요구를 파악하는 과정

인터뷰 = 사용자를 직접 만나 질문하는 조사 방법

관찰조사 = 사용자의 실제 행동을 관찰하는 조사 방법

설문조사 = 여러 사용자에게 같은 질문을 하여 답을 모으는 조사 방법

FGI = 여러 명을 모아 의견을 듣는 집단면접

정성조사 = 숫자보다 이유와 맥락을 파악하는 조사

정량조사 = 숫자와 통계로 문제를 파악하는 조사

VOC = 고객의 문의, 불만, 리뷰, 상담 기록 등 고객의 소리

사용자 여정 = 사용자가 서비스를 이용하는 전체 흐름

터치포인트 = 사용자와 서비스가 만나는 접점

인사이트 = 조사 결과에서 발견한 의미 있는 해석

요구사항 도출 = 사용자 요구와 문제 상황을 서비스 조건으로 정리하는 과정

```