WEGO
##KR위고 — 그룹 여행 플랫폼
##EN
##END#UIUX #GUI #Service_Design #Personal_Project
그룹 여행에서 계획·공유·정산이 여러 앱으로 흩어지는 문제를 다뤘습니다.
설문과 심층 인터뷰로 문제를 정의하고, IA·유저 플로우 탐색부터 로고·아이콘·컬러 시스템까지 전 과정을 설계했습니다.
##EN
I tackled a problem in group travel — planning, sharing, and settling up scatter across several apps.
I defined the problem through a survey and in-depth interviews, then designed the whole path, from IA and user-flow exploration to the logo, icons, and color system.
##END
역할
##EN
ROLE
##END
##KR
UX 리서치 · UI · GUI
##EN
UX research · UI · GUI
##END
유형
##EN
TYPE
##END
##KR
개인 프로젝트
##EN
Personal project
##END
사용 툴
##EN
TOOLS
##END
Figma · Illustrator
기여도
##EN
CONTRIBUTION
##END
100%
##KR
▍ 기능을 더 붙이는 대신, 여행 전·중·후 세 구간을 축으로 서비스를 짰습니다.
##EN
▍ Instead of adding more features, I built the service around three phases — before, during, and after the trip.
##END
문제 · 맥락
##EN
Problem · Context
##END
일정은 메모 앱에, 사진은 메신저에, 정산은 각자의 계산기에.
하나의 여행이 앱 네다섯 개로 쪼개지고, 여행이 끝나면 어디에도 정리되어 남지 않습니다.
개인적인 불편으로 단정하지 않기 위해 설문과 인터뷰를 진행했습니다.
(설문 n=22 · 2024.07)
##EN
The itinerary lives in a notes app, the photos in a messenger, the settlement in everyone's own calculator.
One trip splits across four or five apps, and when it ends nothing is left organized anywhere.
To make sure this wasn’t just my own annoyance, I ran a survey and interviews.
(survey n=22 · July 2024)
##END
##KR
100%응답자 전원이 2인 이상 그룹 여행 경험 — 표본 적합성 확인
50%한 번의 여행에 앱 4개 이상 병행
55%여행이 끝나면 앱을 방치하거나 이탈
##EN
100%of respondents had traveled in a group of two or more — sample validity confirmed
50%used four or more apps on a single trip
55%abandoned or left the app once the trip ended##END
##KR
“사진 공유를 그때그때 매번 하기도, 여행 후 한번에 하기도 번거로워요.”
설문 주관식 응답
“공금을 쓰더라도 급할 땐 개인카드를 쓰는데, 그 부분을 나중에 정산하기 애매해요.”
설문 주관식 응답
##EN
“Sharing photos as you go is a hassle, and so is doing it all at once after the trip.”
Open-ended survey response
“Even with a shared fund we use personal cards when it’s urgent, and settling that up afterward is awkward.”
Open-ended survey response
##END
과정 · 리서치
##EN
Process · Research
##END
응답을 구조로 옮겼습니다.
설문으로 규모를 재고, 페르소나·저니맵으로 맥락을 세우고, 어피니티 다이어그램으로 흩어진 말을 묶은 뒤, 유저 플로우와 IA로 화면의 뼈대를 만들었습니다.
##EN
I turned the responses into structure.
The survey measured scale, personas and journey maps built context, an affinity diagram grouped the scattered comments, and user flows and IA gave the screens their skeleton.
##END
설문조사 n=22
##EN
Survey, n=22
##END
페르소나 · 저니맵
##EN
Persona · journey map
##END
어피니티 다이어그램
##EN
Affinity diagram
##END
유저 플로우 · IA
##EN
User flow · IA
##END
데스크리서치
##EN
Desk research
##END
린캔버스
##EN
Lean canvas
##END
과정 · 판단
##EN
Process · Judgment
##END
기능을 더 붙일 것인가, 여정을 나눌 것인가.
##EN
Add more features, or split the journey?
##END
##KR
불편의 목록을 그대로 기능으로 옮기면 앱은 도구 창고가 됩니다.
대신 응답을 여행 전·중·후로 갈라 놓고 보니 각 구간이 요구하는 것이 서로 달랐습니다.
여행 전에는 접근성이, 중에는 연결성이, 후에는 투명성이 문제였습니다.
그래서 기능이 아니라 세 구간을 축으로 서비스를 짰습니다.
##EN
Move a list of annoyances straight into features and the app becomes a tool shed.
Instead, once I split the responses into before, during, and after the trip, each phase turned out to demand something different.
Before the trip the issue was access; during it, connection; after it, transparency.
So I built the service around those three phases rather than around features.
##END
여정별 설계 방향 — AS-IS → TO-BE
##EN
Design direction by phase — AS-IS → TO-BE
##END
범위 결정
##EN
Scope decisions
##END
필요해 보이는 기능이라도 전부 받지는 않았습니다.
의도적으로 범위 밖에 둔 것이 있습니다.
##EN
Not every feature that looked necessary made it in.
Some things I deliberately left out of scope.
##END
##KR
- 항공·숙소 예약과 결제. 기존 예약 서비스와 겹치는 순간 ‘그룹 여행의 협업’이라는 초점이 흐려진다고 봤습니다.
- 메인에 SNS형 피드를 두는 안.
여행 중인 사용자에게 필요한 건 남의 여행이 아니라 우리 일정이라 판단해, 커뮤니티는 별도 탭으로 분리했습니다.
##EN
- Flight and accommodation booking and payment.
The moment it overlaps with existing booking services, the focus on collaboration for group travel blurs.
- An SNS-style feed on the main screen.
What a traveler needs mid-trip is our itinerary, not someone else’s trip, so the community sits in a separate tab.
##END
설계 규칙
##EN
Design rules
##END
화면이 수십 개로 늘어나도 흔들리지 않도록, 네 가지 규칙을 먼저 정하고 전부에 적용했습니다.
##EN
So that nothing would drift as the screens grew into dozens, I set four rules first and applied them to all of them.
##END
##KR
하나의 화면, 하나의 결정 — 목적지·날짜·메이트를 분리해 한 단계에서 판단할 대상을 하나로 제한했습니다.
같은 구조를 모든 화면에 반복 — 타이틀·탭·카드의 위치와 간격을 고정해, 화면이 늘어나도 같은 규칙 위에서 확장되게 했습니다.
상태를 색으로 먼저 알린다 — 민트는 진행·활성, 회색은 비활성. 가계부는 낼 돈과 받을 돈을 색으로 나눠 표시했습니다.
복잡한 정보는 분해해 비교한다 — 환율·시차·번역·날씨를 카드 단위로 쪼개 한 화면에서 비교할 수 있게 배치했습니다.
##EN
One screen, one decision — destination, dates, and mates are separated so each step asks for a single judgment.
The same structure on every screen — titles, tabs, and cards keep fixed positions and spacing, so new screens extend the same rule.
State announced by color first — mint for active and in progress, gray for inactive. In the ledger, money owed and money owing are split by color.
Complex information broken apart to compare — exchange rate, time difference, translation, and weather are split into cards so they can be read side by side on one screen.
##END
주요 화면
##EN
Key screens
##END
연결 · 공유 · 마무리 · 지속. 서비스의 핵심을 담당하는 네 화면은, 각각 설문에서 나온 응답들에 대한 답으로 설계했습니다.
##EN
Connect · share · close out · keep. The four screens that carry the service were each designed as an answer to a specific survey response.
##END
진행중인 여행 · 메인
그룹챗·메이트·도구를 한 화면에 모아 이동 없이 파악.
근거 — 설문 50% · 앱 4개 이상 병행
##EN
Trip in progress · Main
Group chat, mates, and tools gathered on one screen — nothing to navigate to.
Basis — 50% of respondents · four or more apps in parallel
##END
공유 카메라 · 앨범
공유 카메라로 찍은 사진이 자동으로 공유 앨범에 저장. 따로 보내는 과정이 없습니다.
근거 — “사진 공유가 번거로워요”
##EN
Shared camera · Album
Photos taken with the shared camera save straight to the shared album. No sending step.
Basis — “Sharing photos is a hassle”
##END
자동 정산
공동 지출을 1/N로 계산해 결과만 제시. 받을 돈과 낼 돈을 색으로 구분.
근거 — “정산하기 애매해요”
##EN
Automatic settlement
Shared spending is split 1/N and only the result is shown. Money to receive and money to pay are separated by color.
Basis — “Settling up is awkward”
##END
여행기록 · 통계
여행 중 쌓인 데이터를 카드형 통계로 시각화.
근거 — 설문 55% 이탈
##EN
Trip log · Statistics
Data gathered during the trip, visualized as stat cards.
Basis — 55% of respondents left the app
##END
추가 화면
##EN
More screens
##END
여행 전 준비부터 여행 중·후의 공유와 기록까지, 사용 순서대로 배치해 화면 간 일관성을 확인할 수 있게 정리했습니다.
##EN
From pre-trip preparation to sharing and recording during and after, laid out in order of use so the consistency across screens can be read at a glance.
##END
##KR
여행 전 — 로그인 → 내여행 → 목적지·메이트 설정 → 입력 확인 → 여행 목록 → 알림
##EN
Before the trip — Log in → My trip → Destination · mates → Confirm → Trip list → Notifications
##END
##KR
여행 중·후 — 일정·지도 → 그룹챗 → 실시간 위치공유 → 가계부 → 여행서랍 → 날씨 → 커뮤니티
##EN
During · after — Itinerary · map → Group chat → Live location → Ledger → Trip drawer → Weather → Community
##END
그래픽 시스템
##EN
Graphic system
##END
전체 화면은 모두 같은 그래픽 시스템 위에 서 있습니다.
브랜드 마크부터 UI 아이콘·컬러·타이포까지 설계했습니다.
##EN
Every screen stands on the same graphic system.
I designed all of it — from the brand mark to the UI icons, color, and type.
##END
로고 개인이 아닌 ‘우리(We)’의 이동 — W·E를 하나로 이어 함께 움직이는 형태
##EN
Logo The movement of “we”, not of one person — W and E joined into a single form that moves together
##END
아이콘 커스텀 UI 아이콘 24종
##EN
Icons 24 custom UI icons
##END
컬러 여행지의 풍경에서 출발한 팔레트
##EN
Color A palette drawn from the landscape of a destination
##END
타이포 Pretendard 5웨이트로 잡은 위계
##EN
Type Hierarchy set with five weights of Pretendard
##END
결과
##EN
Result
##END
흩어져 있던 여정을 하나의 앱 안으로 모으고, 전 구간의 화면을 같은 규칙 위에서 설계했습니다.
##EN
The scattered journey is gathered into a single app, and every screen across all three phases is designed on the same rules.
##END
##KR
앱 4개 이상 → 1개여행 전·중·후를 한 서비스 안에서
각자 → 함께같은 정보를 여행 멤버 전원이 동시에
24종 직접 설계한 커스텀 UI 아이콘
##EN
4+ apps → 1before, during, and after the trip in one service
Apart → togetherthe same information for every member at the same time
24
custom UI icons designed from scratch##END
회고
##EN
Reflection
##END
근거를 세워 설계하는 방식은 끝까지 지켰습니다.
다음에는 그 근거가 실제 사용자에게 닿는지까지 확인하고 싶습니다.
##EN
I held to designing from evidence all the way through.
Next time I want to confirm that the evidence actually reaches real users.
##END
##KR
사용자 검증 — 아이콘과 타이포 위계, 컬러가 의도대로 읽히는지 인지 테스트를 설계 과정 안에 넣고 싶습니다.
색에만 기대지 않기 — 정산의 빨강·파랑은 색각 이상 사용자에게 다르게 보일 수 있어, 부호와 아이콘을 함께 쓰는 방식으로 다듬고 싶습니다.
##EN
User validation — I’d like to build cognition testing into the process, to check whether the icon and type hierarchy and the color read as intended.
Not relying on color alone — the red and blue in the settlement screen can read differently for users with color vision deficiency, so I’d refine it to use signs and icons alongside color.
##END