4회차 — 서비스 개선 제안
직접 겪은 서비스 불편을 설명하고, 개선안과 설득 근거를 문서로 만들어 발표해요
이번 회차 한 줄 목표 내가 실제로 불편했던 경험을 상대가 검토하고 판단할 수 있는 개선 제안으로 바꾼다.
| 구분 | 내용 |
|---|---|
| 단계 | ✋ 2단 — 손 (기법) |
| 미리 해올 것 | 실제 사용하는 서비스 1개 선정 + 개선 제안 문서 |
| 이번 회차 산출물 | 동료 피드백을 반영한 제안서 + 기업에 보낼 메시지 초안 |
| 다음 회차까지 | 해당 기업에 제안을 전달하고 발송·답변·미응답 상태 기록 |
2·3회차에서는 다른 기업의 선택과 결과를 했다. 이번에는 내가 겪은 불편을 출발점으로, 문제를 설명하고 개선을 제안하는 연습을 한다. 발표를 듣는 팀원은 서비스 담당자 역할로 질문한다.
어떤 서비스를 고를까?
최근 직접 사용했고, 불편했던 상황을 구체적으로 설명할 수 있는 서비스 하나를 고른다. 서비스 전체보다 특정 상황이나 흐름 한 가지로 범위를 좁힌다.
예를 들어 주문 취소 상태를 확인하기 어려웠던 쇼핑 서비스, 검색 조건을 다시 입력해야 했던 예약 서비스, 알림을 받고도 필요한 정보를 찾기 어려웠던 앱을 선택할 수 있다. 실제 경험과 설명용 예시는 구분한다.
선정 기준
- 불편을 겪은 날짜·상황·사용 목적을 설명할 수 있다.
- 화면이나 사용 과정을 근거로 제시할 수 있다.
- 불편 때문에 생긴 추가 행동·시간·실수·포기를 설명할 수 있다.
- 다음 회차까지 기업의 공식 문의나 제안 채널로 전달할 수 있다.
미리 작성할 문서
형식은 Markdown, 문서, 슬라이드, HTML 중 자유다. 처음 보는 사람이 이해할 수 있는 2~4쪽 분량 또는 그에 준하는 자료를 권장한다. 완성된 화면 디자인보다 문제와 제안의 연결이 중요하다.
1. 서비스와 사용 상황
- 어떤 서비스를, 어떤 목적으로 사용했나?
- 언제 어떤 순서로 사용했나?
- 어떤 사용자가 같은 상황을 겪을 수 있나?
2. 실제 불편과 근거
- 어느 단계에서 무엇이 막혔나?
- 기대했던 동작과 실제 동작은 어떻게 달랐나?
- 결국 어떻게 해결했으며, 어떤 손해나 추가 행동이 생겼나?
스크린샷·사용 과정·오류 메시지·직접 기록한 소요 시간 등을 붙인다. 개인정보는 가리고, 한 번의 경험을 모든 사용자의 문제로 일반화하지 않는다.
3. 왜 불편한가
사용자 입장에서 원인을 설명한다. 예를 들어 상태 안내가 부족한지, 필요한 정보가 흩어져 있는지, 같은 작업을 반복해야 하는지 구분한다. 관찰한 현상과 추정한 원인은 따로 적는다. 내부 기술이나 운영 사정은 알 수 없으면 추정이라고 표시한다.
4. 어떻게 개선할까
현재 흐름과 개선 후 흐름을 비교한다. 텍스트·간단한 화면 스케치·순서도 모두 가능하다.
- 핵심 개선안 1개와 선택 이유
- 사용자가 덜 하게 되는 행동 또는 새로 얻는 정보
- 비용·운영 부담·다른 사용자에게 생길 수 있는 부작용
- 이번 제안에서 제외할 내용
5. 기업 담당자를 어떻게 설득할까
기업이 판단해야 할 이유를 적는다. 사용자에게 좋은 점과 기업이 검토할 이유를 함께 설명한다.
| 설명할 것 | 스스로 던질 질문 |
|---|---|
| 사용자 가치 | 사용자의 어떤 작업이 더 쉬워지나? |
| 기업 관점의 가치 | 반복 문의, 이용 포기, 실수 등을 줄일 가능성이 있나? |
| 우려와 대응 | 구현·운영 비용이나 기존 정책과의 충돌은 무엇인가? |
| 구체적인 요청 | 어떤 부분을 검토하거나 어떤 설명을 답해주면 좋겠나? |
기업 효과를 숫자로 제시한다면 근거를 붙인다. 내부 자료가 없으면 “감소할 것으로 예상한다”처럼 가설로 적고, 임의의 매출이나 을 만들지 않는다.
2시간 진행 순서 · 6명 기준
| 시간 | 활동 |
|---|---|
| 20:00~20:10 | 체크인: 내가 고른 서비스와 불편 한 줄 |
| 20:10~21:22 | 6명 발표·리뷰: 1인 발표 7분 + 질문 5분 |
| 21:22~21:42 | 기업 담당자 역할로 설득 연습 |
| 21:42~21:55 | 피드백을 반영해 제안서·발송 메시지 수정 |
| 21:55~22:00 | 발송할 채널과 다음 회차 기록 방식 확인 |
발표 순서
- 서비스와 실제 사용 상황
- 불편했던 장면과 그 영향
- 원인에 대한 내 해석
- 개선 전·후 비교
- 기업이 검토할 이유와 내가 요청할 내용
동료 리뷰 질문
- 이 불편은 실제로 겪은 것인가? 근거만 봐도 상황이 이해되는가?
- 제안한 변경이 그 불편을 직접 줄이는가?
- 기존 방식에는 어떤 운영상 이유가 있을 수 있는가?
- 더 작은 변경으로도 해결할 수 있는가?
- 담당자가 “우선순위가 낮다”고 하면 어떤 근거로 다시 설명할 것인가?
- 메시지를 받은 사람이 무엇을 검토하고 답하면 되는지 명확한가?
설득 연습
2명씩 짝을 지어 한 명은 제안자, 다른 한 명은 담당자가 된다. 담당자는 “이미 다른 방법이 있다”, “일부 사용자만 겪는다”, “개발·운영 부담이 크다” 중 하나를 질문한다. 제안자는 근거와 요청 범위를 조정해 설명하고 역할을 바꾼다.
기업에 보낼 메시지 초안
제목: [서비스명]의 [사용 상황]에 대한 개선 제안
안녕하세요. [서비스명]을 사용하는 이용자입니다.
최근 [상황]에서 [구체적인 불편]을 겪었습니다.
현재는 [현재 해결 방법]으로 처리하고 있으며, [추가 행동/영향]이 발생했습니다.
[핵심 개선안]을 제안드립니다.
사용자에게는 [효과]가 있고, 운영 측면에서는 [검토할 이유]가 있을 것으로 생각합니다.
[고려한 제약/더 작은 대안]도 문서에 정리했습니다.
첨부 또는 링크: [제안서]
[검토 요청 사항 또는 현재 방식에 대한 질문]을 확인해주시면 감사하겠습니다.5회차까지 과제
4회차 리뷰를 반영한 제안을 각자 해당 기업에 직접 전달한다. 공식 고객센터·제품 피드백·제안 접수 채널 중 적절한 곳을 고르고, 전달한 문서와 메시지를 보관한다.
| 기록 항목 | 적을 내용 |
|---|---|
| 발송 | 기업·서비스, 발송 날짜, 채널, 전달 문서·메시지 |
| 현재 상태 | 답변 대기 / 접수 안내 / 담당자 의견 / 검토 의사 / 기타 |
| 답변 | 수신 날짜와 실제 답변 내용. 자동 접수 안내와 담당자 답변 구분 |
| 내 해석 | 이해된 점, 거절·보류 이유, 추가로 필요한 설명 |
| 다음 행동 | 제안 보완, 다른 대안 검토, 적절한 채널 확인, 기다리기 등 |
답변이 없으면 기록 기준일 현재 미응답으로 적는다. 미응답을 거절이나 제안의 실패로 단정하지 않는다. 자동 접수 안내를 검토·채택으로 기록하지 않는다.
완료 기준
- 실제 경험과 개선안·설득 근거를 문서로 작성했다.
- 동료 피드백을 반영하거나 반영하지 않은 이유를 적었다.
- 해당 기업에 제안을 전달하고 발송 기록을 남겼다.
- 답변 또는 기준일 현재 미응답 상태를 기록했다.
- 5회차에서 토론할 질문을 하나 준비했다.