포폴 프로젝트, 도메인이 달라도 합격할 수 있다?
회사가 보는 건 업종이 아니라 문제 해결 방식
우디 님… 제가 지원하는 회사랑 포폴 프로젝트 도메인이 달라요. 가능성이 없을까요?
포트폴리오 코칭을 하다 보면 매번 나오는 질문입니다. 여기서 많은 디자이너 분들이 도메인 불일치 = 탈락 같은 공식을 먼저 떠올리는데요 실제로 합격 데이터를 보면 꼭 그렇지 않습니다.
도메인이 딱 맞아도 떨어지고 도메인이 달라도 붙습니다. 왜냐면 회사가 보는 건 이 사람이 우리 업종을 해봤나? 보다 이 사람이 우리 팀이 매일 싸우는 문제를 같은 방식으로 풀 수 있나? 쪽에 더 가까워서 그렇습니다. 조금 더 쉽게 말하면 이렇습니다.
도메인은 '배경'이고
문제 해결 방식은 '전개'이며
합격은 결국 전개가 '설득'되느냐에서 갈립니다.
저는 포트폴리오를 구성할 때 초반(첫 프로젝트)에 지원 회사가 중요하게 여기는 문제 해결 구조와 최대한 맞는 프로젝트를 먼저 배치하라고 말합니다. 내가 가장 자랑스러워할 프로젝트가 아닙니다. 그 회사의 문제 해결 방식과 핏이 맞는 프로젝트를 제일 앞에 두는 것입니다.
도메인이 달라도
UX 문제는 닮아 있습니다
회사마다 업종은 달라도 사용자들이 겪는 문제는 비슷합니다. 그 지점이 어디냐면 보통 이런 곳이에요.
처음 들어왔는데 믿음이 안 간다
뭘 해야 할지 모르겠다
너무 어렵고 복잡하다
실패했을 때 다시 돌아갈 길이 없다
가격/옵션/규칙이 애매해서 결정을 못 하겠다
이게 도메인마다 표현만 다를 뿐, 구조는 꽤 동일합니다. 그래서 도메인이 다르더라도 문제-원인-해결 패턴의 유사성을 맞춰 보여주면 합격 핏이 만들어집니다. 아래는 제가 코칭에서 자주 쓰는 도메인별 문제 패턴을 풀어쓴 버전입니다.
도메인이 달라도 UX 문제는 닮아있다1) 핀테크
신뢰가 없으면 온보딩에서 나갑니다
핀테크에서 가장 흔한 장면은 이거예요. 온보딩 중에 본인인증, 계좌 연결, 카메라 권한 같은 걸 갑자기 요청하면 사용자는 멈추고 고민합니다. 문제는 권한 자체가 아니라 맥락입니다. 왜 지금 이걸 달라고 하지? 가 해소되지 않으면 유저는 그냥 나갑니다. 그래서 해결은 대체로 이런 방향으로 가죠.
권한 요청 전에 짧게 이유를 설명해 주고
보안/신뢰 요소를 말이 아니라 시각으로 보여주고
인증에 실패했을 때 다시 설 수 있는 복구 플로우를 만들고
어려운 금융 용어를 쉬운 말로 바꾸는 것
핀테크 경험이 없어도 신뢰 기반 온보딩 이탈을 다룬 프로젝트가 있으면 충분히 연결됩니다.
핀테크와 신뢰 문제2) 커머스
결제 직전이 가장 무섭다
커머스는 장바구니까지는 잘 갑니다. 그런데 결제 단계에서 갑자기 이탈률이 튀어요. 이유는 뻔합니다. 쿠폰 조건이 헷갈리고, 배송비가 마지막에 튀어나오고, 총액이 계속 바뀌고, 입력이 길어요. 그래서 커머스 해결 패턴은 거의 비슷합니다.
쿠폰은 자동 적용되거나 최적 혜택을 계산해 주고
배송비/총액은 결제 직전이 아니라 미리 고정 노출하고
원터치 결제 간편 결제를 강화하고
탐색에서 구매까지 흐름이 끊기지 않게 정보 구조를 정리하는 것
이건 여행이든 교육이든, 심지어 SaaS 결제든 그대로 이어집니다. 결정 직전의 불안을 줄이는 설계, 이게 핵심이에요.
3) 라이프스타일/소셜
첫날 락인이 안 되면 다음은 없다
SNS나 커뮤니티는 D1 잔존이 정말 중요하죠. 첫날에 볼 게 없다, 재미가 없다, 내가 할 게 없다고 유저가 느끼면 그냥 끝입니다. 문제는 대체로 세 가지예요.
개인화가 부족해서 피드가 빈 느낌
글쓰기/참여 허들이 높아서 첫 액션이 안 나옴
규칙 안내가 늦어서 신고/갈등이 생김
그래서 해결도 이렇게 모입니다.
관심사 기반으로 초기에 개인화를 잡아주고
왜 이 추천이 떴는지 이유를 보여주고
글쓰기 UI를 최소 단계로 만들고
규칙은 필요한 순간에 딱 안내하는 Just-in-time 방식으로 바꾸는 것
이 패턴을 포트폴리오에서 잘 보여주면 도메인이 달라도 성장/리텐션 문제를 다룰 수 있는 사람으로 읽힙니다.
SNS와 첫날 락인 문제4) 여행/로컬
정보가 많을수록 유저는 결정을 못 합니다
여행 서비스는 정보가 많아요. 후기, 가격, 옵션, 일정… 근데 이상하게 전환이 낮습니다. 해결은 이런 형태가 많습니다.
시나리오 기반 추천으로 상황을 먼저 잡아주고
지도 기반으로 일정이 자동으로 이어지게 하고
리뷰는 인증 구조를 넣어서 신뢰도를 세우고
가격/옵션은 비교 테이블로 판단을 쉽게 만드는 것
이것도 결국 인지부하를 줄이고 결정 도와주기예요. 핀테크 신뢰 문제랑 결이 다르지 않습니다.
5) B2B SaaS
기능이 아닌 일의 흐름 보여주기
업무툴은 처음 켰을 때 머리가 아파요. 역할/권한이 복잡하고, 세팅이 어렵고, 화면은 기능이 너무 많죠.
원인은 보통 이렇습니다.
온보딩이 목적 없이 기능 나열이고
역할별로 필요한 게 다른데 UI가 한 덩어리로 보이고
실제 업무 흐름과 동선이 맞지 않는 것
그래서 해결은 샘플 데이터 + 단계별 온보딩 같은 게 정말 많이 보입니다.
샘플 데이터로 온보딩 성공 경험을 먼저 만들고
역할 기반 인터페이스로 분기해 주고
핵심 기능을 먼저 보여주고
데이터 흐름을 스토리처럼 안내하는 것
B2B를 안 해봤어도 복잡한 구조를 학습 가능한 경험으로 바꾼 프로젝트가 있다면 연결됩니다.
6) 헬스케어
꾸준함을 설계하지 않으면 앱은 그냥 기록장
헬스케어는 시작도 어렵고 유지가 더 어렵습니다. 입력 허들이 높고, 목표 설정이 부담스럽고, 보상이 늦어요. 그래서 해결은 대체로 이렇게 갑니다.
자동 연동으로 입력 부담을 줄이고
작은 목표로 시작해서 점진 확장하고
루틴 유지에 보상 구조를 넣고
개인화 추천의 기준을 분명히 하는 것
이건 교육 도메인과도 굉장히 비슷해요. 결국 리텐션 싸움이니까요.
7) 에듀테크
끝까지 완주할 수 있을까?
에듀테크는 초반에 코스 선택에서 이탈하고 중반에 완강률이 떨어집니다. 이유는 진도 관리가 어렵고 보상이 약해서가 많습니다. 그래서 해결은 이런 방향으로 가죠.
목표 기반 추천 코스로 시작을 쉽게 만들고
콘텐츠를 잘게 쪼개서 진입 허들을 낮추고
대시보드로 성과를 보이게 하고
즉각적 보상(배지, 피드백)을 넣는 것
에듀테크와 완강률 문제나가며
도메인은 명함이 아니라 대화 주제입니다
포트폴리오는 결국 채용담당자와의 대화입니다.
저 이 업종 해봤어요는 그렇게 매력적인 답변이 아닙니다. 대신 저는 이런 방식으로 문제를 정의하고 원인을 쪼개 검증하고, 개선합니다가 더 낫습니다. 그래서 포트폴리오 프로젝트의 도메인이 다를 때는 이렇게 접근하는 걸 추천합니다.
지원 회사(도메인)가 중요하게 여기는 대표 문제를 먼저 뽑고
내 프로젝트에서 비슷한 구조의 문제를 찾고
문제-원인-해결-검증의 흐름을 앞쪽에 배치하고
첫 프로젝트에서 팀에서 바로 일할 수 있는 사람처럼 읽히게 만드는 것(팀핏 맞추기)
물론 예외는 있어요. 블록체인/메타버스/게임처럼 산업 이해 자체가 강하게 요구되는 특수 도메인은 조금 다른 합격 경향성이 나옵니다. 하지만 대부분의 일반 서비스에서는 도메인보다 문제 패턴이 더 중요합니다.
내가 가진 프로젝트들이 지원 회사 도메인이랑 다르면 급하게 사이드 프로젝트부터 추가하지 마세요. 우선 문제 해결 방식이 닮은 프로젝트가 있는지 체크하고 강조해 보세요. 그 순간부터 포트폴리오의 배치가 달라지고 설득력도 같이 올라갈 거예요.
더 구체적인 포트폴리오
전략에 도움이 필요하다면?
지금 만들고 있는 포트폴리오 전략이 맞는지 검토가 필요하다면 아래 링크를 클릭해 보세요. 흩어진 생각들을 합격 가능한 스토리로 엮으실 수 있게 응원하겠습니다.
'포폴 프로젝트, 도메인이 달라도 합격할 수 있다?'(끝)
