“예쁜 화면”보다 중요한 건 사용자 행동 설계

과제

1. 고객 인터뷰 준비하기

검증 포인트

• 유통기한 파악, 냉장고 재고 관리, 활용 방법 모름 → 실제로 불편한지?
• 사진 1장으로 끝낸다는 방식이 매력적인지?
• 평일 30분 이하 요리, 스마트폰 1탭 해결 → 실제 사용 가능성/의사

고객 정의 (Who)  Segment 특징 인터뷰 목표

얼리어답터	초등학생 이하 아이, 맞벌이 30대	빠른 adoption 가능성, UX/편리함 피드백
일반시장	평일 요리 시간 30분 이하 가정의 장보기 담당자	일반화 가능성, 실사용 의지 검증

 

 

만날 장소 & 방법 (Where)

초기에는 키즈카페, 온라인 맞벌이 오픈채팅 방, SNS, DM으로 얼리어답터 모집할 생각

방법	장점	주의점
온라인 인터뷰 (Zoom, 카톡 영상)	시간, 장소 구애 없음	소통 불편함
오프라인 인터뷰	키즈카페, 교회	사람 모집 필요
당근마켓, 커뮤니티	빠른 초기 인터뷰	표본 편향 가능

 

2.  배운점 블로그에 작성하기

서비스 기획을 공부하면서 가장 크게 느낀 점은,
기획은 단순히 화면을 만드는 일이 아니라 ‘움직이는 시스템’을 설계하는 일이라는 점이었다.

좋은 프로덕트는 단순히 UI가 예쁜 서비스가 아니다.
사용자의 문제를 해결하고, 자연스럽게 행동을 유도하며, 실제로 계속 사용하게 만드는 경험까지 설계해야 한다.

 

오늘은 클로드를 활용해 내가 상상하던 앱을 로우파이 디자인과 하이파이 디자인으로 구현해보는 시간을 가졌다.

선생님께서는 “만드는 건 어렵지 않다. 중요한 건 문제 정의”라고 강조하셨었는데

처음에는 개발자가 아닌 내가 과연 쉽게 만들 수 있을까 의문이 들었다. 속으로는 어느 정도 난이도가 있지 않을까 생각하기도 했다. 그런데 직접 프롬프트를 입력하며 구현해보니, 놀랄 만큼 빠르게 결과물이 만들어졌다. 기술의 발전 속도를 몸소 체감한 순간이었다.

하지만 동시에 한 가지 더 크게 느낀 점이 있었다.
아무리 프롬프트를 잘 쓰고 AI 활용 능력이 뛰어나더라도, 문제 정의가 명확하지 않으면 결국 시간과 비용만 낭비하게 된다는 것이다.

결국 앞으로 더 중요한 역량은 “무엇을 만들 수 있느냐”보다 “어떤 문제를 발견하고 정의할 수 있느냐”에 가까워지고 있다는 생각이 들었다.
오늘 수업은 단순히 AI 툴을 사용해본 경험이 아니라, 서비스 기획에서 가장 중요한 본질이 무엇인지 다시 생각해보게 만든 시간이었다.

---

1. UX는 “성공”보다 “실패 상황” 설계가 더 중요하다

서비스를 출시하면 모든 사용자가 행복하게 사용하는 것 같지만 실제로는 그렇지 않다.

출시 후 비율
해피 케이스 30%
언해피 케이스 70%

즉, 대부분은 오류·실패·예외 상황이 발생한다.

그래서 중요한 건:

• 오류가 났을 때
• 사용자가 길을 잃었을 때
• 시간이 부족할 때
• 입력을 잘못했을 때

어떤 메시지를 보여줄지까지 설계하는 것이다.

예를 들어 영화 추천 서비스라면:

❌ 단순 오류 메시지

시간이 없습니다.

✅ 사용자 행동을 이어주는 UX Writing

시간이 부족하시다면 짧은 러닝타임 영화로 다시 추천해드릴까요?

차이는 명확하다.

• 첫 번째는 문제만 말한다.
• 두 번째는 사용자의 다음 행동까지 도와준다.

---

2. UX는 “예쁨”이 아니라 “행동 기반 설계”

강의에서 인상 깊었던 예시는 신한은행 ATM 이야기였다.

시니어 사용자들도 쉽게 사용할 수 있도록:

• 버튼 수를 줄이고
• 흐름을 단순하게 만들고
• 현재 상태를 명확하게 보여준다

결국 UX의 핵심은:

“사용자가 헷갈리지 않고 원하는 행동을 끝낼 수 있는가?”

이다.

아무리 디자인이 예뻐도 문제 해결이 안 되면 좋은 UX가 아니다.

---

3. 유저스토리 = 사용자와의 “한 줄 약속”

기획에서 자주 등장하는 개념이 바로 유저스토리(User Story)다.

유저스토리는 단순 기능 설명이 아니다.

“사용자가 어떤 상황에서 무엇을 얻고 싶은가”

를 한 줄로 정리한 약속에 가깝다.

예시:

“사용자는 출퇴근 시간에 빠르게 오늘의 뉴스를 확인하고 싶다.”

이 한 줄이 기능 우선순위와 UX 방향을 결정한다.

---

4. 기획자는 복잡한 생각을 정리하는 사람

기획은 결국 복잡한 문제를 정리하는 일이다.

그래서 다양한 프레임워크를 알고 있으면 도움이 된다.

대표적으로:

• RICE
• ICE
• MOSCOW
• KANO MODEL

등이 있다.

---

5. 프로젝트가 잘 돌아가는 5가지 신호

좋은 팀은 아래 5가지가 명확하다.

1) 무엇을 할 것인가

예시:

• 이번 주 배포 기능
• 수정할 버그
• 사용자 테스트 범위

---

2) 언제까지 할 것인가

대부분 스프린트 단위(보통 2주)로 관리한다.

---

3) 누가 할 것인가

DRI(Directly Responsible Individual)

즉, “누가 책임지는가”가 명확해야 한다.

---

4) 어떻게 성공을 측정할 것인가

예시:

• 가입 전환율
• 클릭률
• 리텐션
• 오류 감소율

---

5) 리스크가 무엇인가

현재 막힌 것과 앞으로 막힐 가능성을 공유해야 한다.

---

6. 큰 일을 “작은 일”로 쪼개기

기획자는 일을 잘게 나눌 줄 알아야 한다.

큰 일은 미뤄지지만 작은 일은 시작할 수 있다.

예시:

❌ 로그인 기능 만들기

✅

• 로그인 API 연결
• 에러 메시지 작성
• 버튼 상태 처리
• 테스트 케이스 작성

이렇게 쪼개면 실행력이 높아진다.

---

7. RICE 모델 — 백로그 우선순위 정하기

기능 우선순위를 정할 때 사용하는 대표적인 방법.

RICE

R (Reach)

얼마나 많은 사용자가 영향을 받는가

---

I (Impact)

영향도

• 3 = 강함
• 2 = 중간
• 1 = 약함
• 0.5 = 미미

---

C (Confidence)

얼마나 확신하는가

• 100%
• 80%
• 50%

---

E (Effort)

얼마나 많은 리소스가 필요한가

예시:

• 0.5 = 2주

---

계산식

R×I×C÷ER \times I \times C \div ER×I×C÷E

중요한 건 공식 자체보다:

“왜 이 기능을 먼저 해야 하는가?”

를 팀 내부에서 합의하는 과정이다.

---

8. ICE / MOSCOW / KANO MODEL

특히 기억해두면 좋은 두 가지:

ICE

• Impact
• Confidence
• Ease

빠르게 우선순위를 정할 때 사용한다.

---

MOSCOW

기능을 아래처럼 나눈다.

• Must have
• Should have
• Could have
• Won’t have

핵심은:

“반드시 필요한 기능이 무엇인가?”

를 명확히 하는 것.

---

9. UCD — 사용자 중심 설계

UCD(User Centered Design)는 말 그대로:

“사용자 입장에서 설계하는 것”

이다.

기획자가 아니라 사용자 기준으로 생각해야 한다.

---

10. 로우파이 디자인의 중요성

처음부터 화려한 UI를 만들 필요는 없다.

오히려 빠르게 구조를 검증하는 것이 중요하다.

로우파이 단계에서는:

• 화면 흐름
• 버튼 위치
• 사용자 동선
• 정보 구조

를 중심으로 본다.

---

11. UI와 UX의 차이

많이 헷갈리는 개념.

UI

보이는 것

• 색상
• 버튼
• 레이아웃
• 타이포그래피

---

UX

사용자가 겪는 경험 전체

즉:

“사용자가 문제를 쉽게 해결했는가?”

가 핵심이다.

---

12. 닐슨의 UX 10원칙 — 특히 중요한 것

“시스템 상태를 보여줘라”

1. 사용자는 항상 현재 상태를 알고 싶어 한다.

예시:

배달 앱:

• 주문 완료
• 조리 중
• 배달 시작
• 도착 5분 전

이런 상태 표시가 사용자 불안을 줄인다.

반대로 송금 완료 후 갑자기 광고만 나오면 사용자는:

“진짜 송금된 거 맞아?”

라는 불안을 느낀다.

즉:

시스템은 항상 사용자에게 현재 상태를 설명해야 한다.

 

나머지는 다음시간에...

---

마무리

이번 내용을 공부하면서 가장 크게 느낀 건:

기획은 문서 작업이 아니라 사용자 행동을 설계하는 일이라는 점이다.

좋은 기획자는:

• 사용자의 불편을 발견하고
• 실패 상황까지 고려하고
• 복잡한 문제를 단순하게 만들고
• 팀이 움직일 수 있도록 구조화한다.

결국 중요한 건:

“예쁜 서비스”가 아니라
“사용자가 문제를 해결할 수 있는 서비스”를 만드는 것이다.