사용자/비즈니스 문제 정의와 인용/인사이트를 명확히 작성합니다.
리서치 → 문제정의 → 아이디에이션 → 와이어/프로토 → 테스트 → 릴리즈 순으로 정리하고 의사결정 기준과 트레이드오프를 설명합니다.
정량/정성 지표(과업 성공률, 전환율, NPS, CS 감소 등)를 정리합니다.
플로우, 와이어, 컴포넌트, 접근성 체크 등 대표 산출물을 정리합니다.
Figma/프로토타입, 리서치 리포트, 사용성 테스트 결과 등 참고 자료를 연결합니다.
배운 점과 다음 실험 가설을 간결하게 작성합니다.
디자이너 포트폴리오에서 가장 흔한 실수는 완성된 화면만 나열하는 것입니다. 채용 담당자가 알고 싶은 것은 화면이 예쁜지가 아니라, 그 화면에 도달하기까지 어떤 문제를 보고, 무엇을 판단했는지입니다.
| 단계 | 담을 내용 | 분량 비중 |
|---|---|---|
| 개요 | 프로젝트, 기간, 역할, 팀 구성 | 짧게 |
| 문제 | 누가, 어떤 상황에서, 무엇이 불편했는지 | 중간 |
| 조사 | 사용자 인터뷰, 데이터, 경쟁 서비스 분석에서 알게 된 것 | 중간 |
| 탐색 | 시도한 시안들과 버린 이유 | 가장 많이 |
| 결정 | 최종안을 고른 근거 | 중간 |
| 결과 | 출시 후 반응, 테스트 결과, 배운 점 | 중간 |
최종안 하나만 보여 주면 면접관은 "다른 방법은 생각해 봤나요?"라고 묻습니다. 탐색 단계에서 시도한 시안 2~3개와 각각을 버린 이유를 보여 주면, 판단 과정이 자연스럽게 드러납니다.
가상 예시
- 시안 A: 필터를 상단에 고정 → 화면이 좁은 기기에서 목록이 가려져 제외
- 시안 B: 필터를 하단 시트로 → 사용성 테스트에서 참가자 5명 중 3명이 필터 위치를 찾지 못함
- 최종안: 목록 상단에 주요 필터 2개만 노출하고, 나머지는 하단 시트로 분리
근거가 부족한 개인 프로젝트라도 괜찮습니다. 주변 사람 3~5명에게 시안을 보여 주고 관찰한 내용만 정리해도, 아무 근거 없는 결과물보다 훨씬 설득력이 있습니다.
이렇게 만든 프로젝트는 "실제 서비스가 아닌 개인 개선 제안"이라고 분명히 밝히세요. 실제 회사의 의뢰를 받은 것처럼 보이게 하면 안 됩니다.
케이스 스터디를 위 흐름대로 정리했다면, 이 질문들의 답은 이미 포트폴리오 안에 있습니다. 전체 제출 형식은 포트폴리오 템플릿 가이드를 참고하세요.
실제 준비 과정에서 자주 쓰는 적용 시나리오
상황: B2C 앱 UX 개선 프로젝트
문제: 시안 결과물은 풍부했지만 문제 정의와 리서치 근거가 약해 의사결정 과정이 충분히 전달되지 않았습니다.
실행: 리서치 인사이트, 가설, 실험 결과를 단계별로 정리하고 접근성/사용성 개선 근거를 별도 섹션으로 추가했습니다.
결과: 포트폴리오 리뷰에서 사고 과정 설명력이 강화되어 면접에서 케이스 디스커션 비율이 높아졌습니다.
Q. 비주얼이 약하면 불리한가요?
A. 비주얼 자체보다 문제 해결 과정과 사용자 가치 증빙이 더 중요하며, 이는 충분히 보완 가능합니다.
Q. 리서치가 작은 규모여도 괜찮나요?
A. 표본 한계를 명시하고 의사결정에 어떻게 반영했는지 설명하면 신뢰를 확보할 수 있습니다.
Q. 케이스 스터디 길이는 어느 정도가 좋나요?
A. 한 프로젝트당 5~8분 내 검토 가능한 밀도를 권장하며 핵심 화면과 근거를 우선 배치하세요.