"인스타에서 본 그 옷을 사고 싶은데, 사이트 들어오면 옷 종류가 너무 많아서 다시 찾아야 해요. 그러다 그냥 포기."
다경에스앤디
사업 영역과 레퍼런스가 한눈에 스캔되도록
네이비 베이스의 그리드와 여백으로 정보 위계를 고정했습니다.
"화보로 들어와서
화보로 나가지 않게."
인스타그램 화보로 트래픽은 충분. 다만 그 트래픽이 사이트에 닿으면 다시 "쇼핑몰 메뉴"에서 상품을 검색해야 하는 단절. 화보의 무드가 구매 동선과 분리된 채 끊겼습니다.
화보는 잘 찍었는데, 사이트는 화보랑 다른 사이트 같아요. 사람들이 화보 보다가 사진 속 옷을 못 찾고 그냥 닫아요.Brand director, kick-off (2026.05)
나의 해석
화보의 톤과 쇼핑몰의 톤은 본래 다릅니다. 다른 톤을 합치는 대신, 화보 위에 "보이지 않는 결제 동선"을 얹습니다. 사용자는 화보를 떠나지 않은 채 구매할 수 있어야 합니다.
결제 도달까지 7번의 클릭.
3번이면 충분했어야 합니다.
인스타에서 사이트로 진입한 사용자가 "사진 속 옷"을 찾아 결제까지 도달하는
평균 경로 = 7 클릭. 모바일 95% 트래픽 환경에서 이건
실질적 차단막입니다.
FIG. 02-A · Purchase depth audit · 7 → 3 clicks
"화보 위" 가 카탈로그가
되어야 합니다.
Problems · 진단
- P-01인스타 진입자의 1차 화면이 화보가 아니라 평범한 메뉴 그리드.
- P-02화보 속 옷을 찾기 위한 탐색 비용이 4클릭 이상.
- P-03모바일 결제까지 풀 페이지 전환 5회. 화보 무드 완전 소실.
- P-04한복 카테고리의 전통적 분류(저고리·치마·당의…)가 비전공자에게 진입 장벽.
Goals · 디자인 목표
- G-01홈 1차 화면을 풀-블리드 화보 hero로. 인스타 톤과의 동일성 확보.
- G-02Lookbook을 shoppable 카드 그리드로 재구성. "코디 전체 구매" 진입점 제공.
※ 화보 위 hot-spot dot 인터랙션은 컨셉 단계로 다음 빌드 예정 - G-03스타일 진단 (style-test 3-question quiz)으로 스타일 → 룩 → 제품 흐름 분리.
※ Half-modal Buy는 컨셉 단계 라이브는 detail.html 풀 페이지 결제 - G-04스타일 진단 결과 페이지(style.html)에서 Look 기반 보조 필터 운영 메인 카테고리 IA(상의·스커트·원피스 등)는 유지.
"어플도 아니고 사이트도 아닌"
그 중간 이 정답이었습니다.
10명 모두 모바일 진입자. 인스타 화보를 보다가 사이트로 넘어와본 경험이 있는 사용자. 공통 발화는 "사이트로 넘어오면 다른 데 온 느낌"이었습니다.
"화보랑 쇼핑이 따로 있어서 너무 번거로워요.
그냥 사진 보다가 바로 사고 싶은데, 그게 안 돼요."
"한복 카테고리가 이름을 다 어려워요.
저고리, 당의… 저는 그냥 '명절에 입을 옷'을 찾는 건데."
"결제할 때 페이지가 자꾸 바뀌면 멈칫하게 돼요.
한 화면에서 다 끝났으면 좋겠어요."
SNS → 룩북 → 결제 를
한 단면에 모았습니다.
현재 라이브 빌드: Lookbook은 카드 그리드 detail.html 풀페이지 결제.
아래 다이어그램은 컨셉 단계의 IA 제안 Lookbook을 중심 허브로 두고
SNS deep-link + half-modal 결제까지 잇는 가상 구조입니다.
FIG. 05-A · Lookbook as the omnichannel hub
전통의 어휘를 일상의 어휘 로
바꾸는 결정.
한복 브랜드의 가장 어려운 결정은 "어휘"였습니다. 전통을 지키고 싶지만,
비전공자에게는 진입 장벽. 둘 다 지키기 위한 트레이드오프를
기록합니다.
홈 = 메뉴 그리드 + 시즌 배너
홈 = 풀-블리드 룩북 hero (인스타 톤과 동일)
진입자의 90%가 SNS 화보에서 옴.
첫 화면이 그 톤과 다르면 즉시 이탈. 일관성이 곧 신뢰.
카테고리 = 저고리 · 치마 · 당의 · 두루마기
메인 카테고리 = 상의 · 스커트 · 원피스 · 아우터 (현대 어휘) + style-test 진단으로 Look 보조 필터 (출근/모임/행사/명절)
전통어 자체는 비전공자 진입 장벽. 1차는 익숙한 현대 카테고리,
2차로 style-test가 사용 맥락(Look) 기반 분기. Look 중심 IA는 보조에서 시작.
화보와 쇼핑몰 = 별도 페이지
Lookbook 카드 그리드 + "코디 전체 구매" 진입점
※ 화보 위 hot-spot dot은 컨셉 단계 다음 빌드 예정
감상의 흐름을 깨지 않으려면 화보가 자체 카탈로그여야 함.
1단계로 카드형 룩북에서 "코디 전체 구매"를 제공, dot 인터랙션은 좌표 운영 부담으로 다음 단계로.
결제 = 풀 페이지 (Cart → Checkout → Pay)
현재: detail.html 풀페이지 결제 (Cart → Checkout)
※ Half-modal 결제는 컨셉 단계 다음 빌드 예정
Half-modal은 모바일 인지 부하 면에서 정답이지만, 결제 보안·환불 흐름까지 모달 안에서 관리하려면 운영 비용이 크게 늘어남.
컨셉으로 남기고 라이브는 검증된 풀페이지 결제로 운영.
PDP = 거대 사진 + 사이즈 표
PDP = 룩북 사진(편집된) 우선 + 흰 배경 사진은
보조 갤러리로 강등
한복은 "어떻게 입었을 때"가 결정의 핵심.
흰 배경 사진은 사이즈/색 확인용으로만 충분.
데스크톱 디자인을 모바일로 축소
Mobile-optimized. 95% 모바일 트래픽 기준으로 카드 그리드·간격·터치 영역 우선 설계
트래픽 95%가 모바일이라 모바일 경험을 1차로 잡고, 데스크톱은 보조. 빌드는 max-width 브레이크포인트(desktop-first CSS) 기반이지만 의사결정의 우선순위는 모바일로 두었음.
Hot-spot의 4가지 상태 가
전체 동선을 결정합니다.
아래는 다음 빌드를 위한 컨셉 스펙 shoppable lookbook의 핵심 컴포넌트로
사진 위 "dot"을 설계했습니다.
현재 라이브 빌드는 카드 그리드 룩북으로 운영되며, dot 인터랙션은
좌표 운영과 사진 변경 시 유지보수 비용을 검토한 뒤 차기 단계로 미뤘습니다.
딥 네이비 신뢰층과
인포 블루 액션.
다경에스앤디의 베이스는 쿨 그레이 서피스와 딥 네이비 텍스트.
문의 · 다운로드 CTA만 인포 블루로 분리해 업무 맥락에 맞는 절제된 UI를 유지했습니다.
Color tokens · Core
Kitsch palette · 인터랙션 한정
Type stack
다경에스앤디
파트너와 함께 가는 물류 혁신
"복잡한 검색 대신, 오늘의 루트를 한 번에 받고 싶어요."
INSIGHT · 물류 · 파트너십
"화보 위 결제"가
작동한다는 가설.
컨셉 프로젝트 시뮬레이션 기반 예상치 (라이브 데이터 아님). 라이브 빌드는 Lookbook 카드 그리드 + detail.html 풀페이지 결제 아래 수치는 hot-spot · half-modal까지 구현됐을 때의 가설 결과입니다.
장바구니 도달율 상승 (예상)
인스타 진입 코호트에서 +34%, 직접 진입에서 +9% 가설. hot-spot이 구현됐을 때 "화보 컨텍스트"가 살아있는 진입에서 가장 강하게 작동할 것으로 예상.
평균 구매 동선 단축 (예상)
7 클릭 → 3.2 클릭 가설 (반올림). 컨셉 IA(hot-spot + half-modal 풀 구현 기준)에서 포기 시점이 결제 직전이 아닌 진입 직후로 이동할 것으로 예상.
모바일 직접 결제 증가 (예상)
Half-modal 결제 완료율 78% 가설. 페이지 전환 결제 대비 13%p 높음. "화면 잃지 않음"이 모바일에서 결정적 차이를 만든다는 가설 다음 빌드에서 검증 예정.
이번 빌드는 카드 그리드까지,
다음 빌드는 그 위에 점을 얹는다.
Hot-spot 좌표의 운영 비용.
컨셉 단계에서 hot-spot 좌표 운영을 시뮬레이션해보니, 룩북마다 디자이너가 수기로 좌표를 찍어야 하는 부담이 큼. 라이브 빌드에서 카드 그리드로 우선 출시한 이유. 다음 단계는 AI 보조 좌표 추천 → 디자이너 확인 흐름을 검토 중입니다.
Half-modal 결제의 운영 vs UX.
Half-modal은 모바일 인지 부하 측면에서 답이지만, 결제 보안·환불 흐름까지 모달 안에서 다루려면 운영·CS 비용이 큼. 라이브는 검증된 detail.html 풀페이지 결제로 두고, half-modal은 다음 빌드에서 실험 단계로 접근할 예정.
Mobile-first 의사결정 vs CSS 빌드 패턴.
의사결정의 우선순위는 모바일이었지만, 빌드 단계에서 max-width 브레이크포인트(desktop-first 패턴)를 사용했습니다. 다음 빌드에서는 처음부터 min-width 기반 mobile-first CSS로 통일해 태블릿(768–1024px) 사각지대를 줄이는 것이 과제.