유명한 행사라 기대를 많이 하고 갔는데 역시나 현장에서 발표를 듣고 사람들 분위기를 느끼다 보니 예상보다 훨씬 더 자극과 배움이 컸습니다. 특히 제품 개선 사례들을 보면서 '이렇게까지 구조적으로 일하는구나'라는 생과 동시에 여러 감정을 느꼈습니다. 그중 가장 인상 깊었던 세션을 기록해봅니다.
📌 UX 라이팅 핵심 정리 (우아한형제들 관점)
1.
라이팅의 본질: 말투가 아니라 '정보'
•
UX 라이팅은 말투의 감성적 평가보다 정보의 구조·우선순위가 더 중요함
•
기획/디자인의 목적에 따라 '정답에 가까운' 정보 위계가 존재할 수 있음
•
따라서 말투 논쟁보다 무엇을 먼저/어떻게 전달할지가 핵심
2.
정보 위계 기반으로 빠르게 합의
화면 공간은 제한되어 있고, 사용자는 많은 정보를 한 번에 인지하기 어려움
그래서 "가장 중요한 정보가 무엇인가?"로 출발해야 함
예) "3000원을 더 담으면 5000원 할인 가능"
→ 사용자가 원하는 '혜택'이 1순위 정보이며, 이를 중심으로 표현을 설계해야 함
3.
UX Writing = 상황·맥락 → 사용자 동기 → 기대결과로 연결
우아한형제들에서 강조하는 구조:
•
상황/맥락(Context)
사용자가 현재 어떤 상황인지
•
사용자 동기(Motivation)
지금 사용자가 무엇을 하고 싶어 하는지, 지금 사용자가 무엇을 하고 싶어 하는지
•
기대 결과(Expected Outcome)
사용자가 얻고 싶은 효과는 무엇인지, 사용자가 얻고 싶은 효과는 무엇인지
이 세 가지를 통해 우리가 사용자를 어떤 행동으로 이끌고 싶은지가 명확해짐
4.
동기와 결과가 UX 라이팅의 핵심
단순 말투 조정보다 중요한 것:
사용자가 왜 이 화면을 보고 있고, 정보를 통해 어떤 행동을 하고 싶어 하는지를 파악하는 것
라이팅 판단 기준이 "예쁘게 말하기"가 아니라 **동기·결과를 증폭시키는 문장인가?**가 되어야 함
✔ 전체 요약
UX 라이팅에서는 감성적 말투보다 정보 구조와 사용자 관점이 더 중요하다.
따라서 말투 논쟁보다 사용자가 원하는 정보가 무엇인지, 그중 가장 중요한 정보가 무엇인지 먼저 합의하는 것이 핵심이다.
또한 좋은 UX 라이팅은 상황/맥락 → 사용자 동기 → 기대 결과 의 흐름을 바탕으로 사용자가 원하는 행동을 자연스럽게 끌어내는 문장이어야 한다.
📌 여기어때 — 앱 구조 개선 사례 전체 정리
Step 1. 문제점/요구사항 수집
🔍 수집된 핵심 문제
1.
온보딩 → 홈 랜딩까지 속도 지연
- 초기 로딩이 너무 오래 걸려 사용자 이탈 가능성 증가
2.
백화현상(White Screen) 발생
- 화면이 하얗게 비는 구간이 생김
📑 관련 데이터 수집
•
UX팀 : 관련 AB 실험 데이터
•
UX팀 : UT/IDI 테스트 데이터
•
PO : 비즈니스 요구사항
•
Dev : 시스템 병목·로딩 구조 문제 파악
→ 즉, 문제 정의 단계에서 UX–PO–Dev가 필요한 정보를 모두 모아서 문제를 사실 기반으로 명확하게 정리한 단계
Step 2. Alignment
🎯 각 팀 간 관점 맞추기
문제 정의 이후, UX·PO·Dev가 무엇을 해결해야 하는지 한 줄 정의로 합의하는 단계
•
UX: 고객 문제 기반
•
PO: 비즈니스 인사이트 기반
•
Dev: 구현 타당성 기반
으로 정렬된 뒤 우선순위 선정의 필요성을 강조함
→ 이 단계의 핵심은 "모두 같은 문제를 보고 있는가?"를 맞추는 것
Step 3. 핵심 3 Phrases 정의
이 단계는 전체 개선 방향을 3가지 원칙(Phrase)으로 정리하는 부분이며, 실제 이미지에 다음 3가지 키워드가 등장함
1) Reduce
•
불필요한 단계를 줄여 로그인·랜딩까지의 시간을 단축
•
가입/로그인 같은 유지보수 비용도 최소화하는 방향
2) Flexibility
•
사용자가 원하는 플로우로 자연스럽게 이동하도록 유연성 확보
•
특정 단계 강제 → 자율적 진행 방식으로 변경
3) Focus
•
핵심 프로세스에 집중하여 사용자의 참여를 높이는 전략
•
한 번에 완주할 수 있는 경험 제공
→ 이 3가지가 이후 아이데이션과 솔루션의 기준이 됨
Step 4. Crazy 아이데이션
•
정해진 3가지 Phrase(Reduce/Flexibility/Focus)를 기준으로 극단적인 아이디어까지 포함해 다양한 해결안을 스케치
•
팀원들이 손으로 직접 화면 플로우·UI 구성·데이터 흐름을 그리며 "가능하면 다 그려보는" 단계
→ 구현 가능성보다 "문제 해결 아이디어 생성"에 집중하는 단계
Step 5. 솔루션 Finalize
👀 주요 변화 포인트
•
온보딩 플로우 단축
•
필요한 정보만 먼저 로딩
•
백화현상 최소화를 위한 화면 구성 변경
•
불필요한 재로딩 제거
•
유도 버튼·안내 문구 개선
•
홈 랜딩 속도 개선
→ Crazy 아이데이션 중 실제로 구현 가능한 솔루션을 정제한 단계
백화현상(White Screen) 해결 & 우선순위 선정 필요성
🔧 핵심 기술적 해결 방식
•
초기 데이터 Prefetching (미리 불러오기) 적용
•
우선 로딩 필요한 데이터와 나중에 로딩해도 되는 데이터 구분
•
우선순위 선정 기준 필요 → BRICE 도입
BRICE Framework 소개
BRICE =
Business Importance (비즈니스 임팩트)
Reach (도달 범위)
Impact (개선 시 고객 가치 변화량)
Confidence (근거의 신뢰도)
Effort (투입 노력)
→ (B × R × I × C) ÷ E
로 계산하여 정량적으로 우선순위를 산정
BRICE 적용 예시
Step 1
•
개선 대상 화면 선택
•
홈 화면 일부 기능의 개선 가능성 평가
Step 2
•
해당 기능의 B·R·I·C·E 점수를 입력
•
Business Importance: 3
•
Reach: 400,000
•
Impact: 1.5
•
Confidence: 1
•
Effort: 33
👉 총점 = 약 54,545 (정규화 시 우선순위 판단 기준으로 적용)
BRICE로 도출한 우선순위 vs 실제 솔루션이 다른 경우?
❓ 솔루션이 달라질 수 있는 이유
•
비즈니스 긴급성
•
법/정책 리스크
•
기술적 제약
•
사용자 정성 데이터(UT/IDI)에서 발견된 치명 결함
즉, BRICE는 정량적인 참고 지표일 뿐 최종 결정은 종합적 판단이 필요함
치명적인 문제가 발견되면?
•
BRICE 점수와 상관없이 즉시 우선순위 재조정
•
리스크 기반 의사결정이 원칙
•
UX·PO·Dev가 다시 Alignment 필요
📌그 외 내용 포함 전체 요약
여기어때 앱 구조 개선은 단순 화면 개편이 아니라 데이터 구조·로딩 우선순위·UX 플로우를 총체적으로 개선한 프로젝트였다.
전체 프로세스는 다음 순서로 진행됨:
1.
문제/요구사항 수집 (데이터 기반 문제 정의)
2.
Alignment (팀 간 관점 통합)
3.
핵심 3 Phrase 정의 (Reduce / Flexibility / Focus)
4.
Crazy 아이데이션 (창의적 해결안 발산)
5.
솔루션 Finalize (현실화된 최종 해결안 선정)
6.
우선순위 선정 — BRICE 활용 (정량적 판단 도입)
7.
협동 프로그램(워크숍)으로 공감대 확보
8.
10일 코드 스프린트로 AI 기반 기능 실험
이번 2024 인프콘 세션을 통해, 단순한 UI 손보기나 기능 하나 추가하는 수준이 아니라 앱 전체의 구조를 다시 설계하는 과정이 얼마나 정교한 프로세스 위에서 진행되는지를 생생하게 볼 수 있었습니다.
문제 정의 → Alignment → Phrase 설정 → 아이데이션 → 우선순위 정량화 → 코드 스프린트까지 이어지는 흐름은, '제품을 이렇게까지 깊게 다루는 조직은 무엇이 다른가'를 자연스럽게 보여주는 사례였습니다.
특히
•
데이터를 기반으로 문제를 규정하고
•
팀 전원이 같은 문장을 보며 합의하고
•
BRICE 같은 지표로 우선순위를 정하고
•
10일 만에 실제 코드 프로토타입까지 빌드하는 실행력
이 인상적이었습니다.
"좋은 UX는 협업에서 나온다"는 말이 단순한 슬로건이 아니라 실제 프로세스에 녹아 있다는 점이 크게 와닿았습니다.
그러다 보니 솔직히 우리 회사 업무 프로세스는 이런 구조나 흐름이 체계적으로 잡혀 있지 않아서 순간적으로 현타가 오기도 했습니다..ㅎㅎ🥲
다른 조직들은 문제 정의–데이터–협업–실행까지 연결되는 하나의 긴 줄을 당연하게 만들고 있는데, 우리는 아직 부족한 점 투성이 라는 것을.. 다시 실감했습니다.
하지만 반대로 말하면, 지금 배운 방식이 우리가 앞으로 개선할 수 있는 명확한 방향이기도 합니다.
오히려 이번 인프콘을 통해
•
어떻게 문제를 정의해야 하는지
•
어떻게 Alignment를 맞춰야 하는지
•
어떤 기준으로 우선순위를 정해야 하는지
•
어떤 방식으로 협업을 설계해야 하는지
등 실무에서 바로 가져올 수 있는 구체적인 힌트를 얻었다는 데 큰 의미가 있다고 생각합니다.