UX UI 포트폴리오 많이 하는 실수들(2)
2026년 버전 업데이트
UX UI 포트폴리오 실수 두 번째 편을 가져왔습니다.
첫 번째 편에서는 디자인 감각, 메시지 전달, 문제 공감, 리서치 깊이와 관련된 실수들을 정리했습니다. 이번 글에서는 그다음 단계에서 자주 보이는 실수들, 디자이너의 사고와 역할이 잘 보이지 않는 경우를 중심으로 이야기해 보려고 합니다.
첫 번째 편을 아직 보지 않으셨다면, 아래 글을 먼저 참고해 주세요
5. 사소한 것을 과도하게 강조하는 경우
포트폴리오에서 자주 보이는 실수 중 하나는, 디자인 과정에서 기본적으로 수행해야 하는 선택을 마치 핵심 성과처럼 강조하는 경우입니다. “직관적으로 디자인했다”, “CTA를 눈에 띄게 배치했다”, “로딩에 스켈레톤 UI를 적용했다”와 같은 설명이 대표적입니다.
이런 설명은 UX를 고려하지 않았다는 의미는 아닙니다. 다만 이 정도 수준의 설명만으로는 디자이너의 문제 해결력이나 인사이트가 드러나지 않습니다. 실무에서는 이런 선택들이 ‘잘했다’의 기준이 아니라, 안 하면 안 되는 기본값에 가깝기 때문입니다.
면접관 입장에서는 자연스럽게 이런 생각이 듭니다. “이건 당연히 해야 하는 수준 아닌가? 이 디자이너는 이 정도를 잘했다고 생각하는 걸까?”
로그인 화면, 로딩 화면, 예약 화면 등을 보여주며 “유저를 생각한 설계”라고 설명하지만, 실제 내용을 보면 대부분 이미 업계 전반에서 널리 쓰이는 UI 원칙에 머무르고 있는 경우가 많습니다. 스켈레톤 UI나 CTA 강조는 특정 문제를 깊이 고민해서 나온 결과라기보다, 기본적인 UX 패턴에 가깝습니다.
무엇보다 이 설명들 안에 유저의 맥락이 거의 등장하지 않습니다.
유저가 어떤 상황에서 이 화면에 진입했고, 여기서의 핵심 과업은 무엇이고, 어떤 것을 기대하기 때문에 이 컴포넌트를 이렇게 배치했다 등의 설명이 빠져 있습니다. 결과 화면 개수는 많아도 해당 디자이너만의 인사이트가 느껴지지 않습니다.
해결 방법
UX UI를 설명할 때 단순한 것을 설명하는 것보다, 내가 특히 고민한 UX를 강조해야 합니다. “왜 그렇게 할 수밖에 없었는지”를 중심으로 풀어야 합니다. 유저는 이런 성향이고, 그 시점에 가장 중요한 행동은 무엇이었고, 그래서 화면을 이렇게 구성했다-고 설명할 수 있어야 합니다.
만약 그 설명이 어렵다면, 해당 화면은 포트폴리오에서 과감히 덜어내는 것도 좋은 선택입니다. 포트폴리오는 모든 작업을 보여주는 자료가 아니라, 잘 고민한 작업만 남기는 자료입니다.
김예지 선수 짤. 누구나 하는 걸 굳이 포폴에 쓸 이유가?6. 기능만 설명하고 UX 고민이 보이지 않는 경우
또 하나 자주 보이는 실수는 문제 해결을 기능 추가 수준으로만 설명하는 경우입니다. “유저들이 소통하고 싶어 해서 커뮤니티 기능을 넣었다”, “동기부여를 위해 랭킹과 뱃지를 추가했다”와 같은 설명이 여기에 해당합니다.
기능 자체는 나쁘지 않지만, 이 설명만으로는 디자이너의 역할이 잘 보이지 않습니다. 기능을 만들었다는 사실만 있고, 그 기능을 어떤 UX 관점에서 설계했는지는 빠져 있습니다.
커뮤니티, 랭킹, 레벨 시스템, 시즌 보상 같은 기능은 많은 서비스에서 이미 사용되고 있는 방식입니다. 하지만 사용 맥락에 대한 고민 없이 “커뮤니티를 넣었다”로 설명이 끝나면, 어떤 것을 고려해서 설계했는지 디자이너의 사고 과정은 보이지 않게 됩니다. 마치 서비스 설명서, 기능 정의서 같습니다.
그 결과 면접관은 자연스럽게 이렇게 생각합니다. “그래서 디자이너가 이 기능을 위해 어떤 고민을 했을까?"
해결 방안
기능뿐만 아니라 기능을 설계할 때 유저의 행동 흐름, 사용성과 함께 고민한 내용을 적어줍니다. 유저가 이런 성향이고 이런 것을 기대했기 때문에, 이 기능은 이렇게 표현되어야 한다- 즉 어떤 UX 판단으로 설계했는지가 드러날 때 포트폴리오는 설득력을 갖게 됩니다.
고민이 보이는 UX 예시 :
당근마켓 ‘매너 온도’ 글로벌 수출기 (2)- 프로덕트 디자이너의 Karrot score 신뢰 지표 만들기
7. 논리적 근거가 없는 솔루션
문제 정의와 해결책 사이의 연결 고리가 약한 경우도 매우 자주 보입니다. 문제는 그럴듯하게 설명되어 있지만, 솔루션이 갑자기 등장합니다. “동기부여가 부족하다"라는 문제 정의 이후, 동기 부여를 주기 위해 나만의 캐릭터를 도입하였다-는 식의 논리입니다. 동기부여를 줄 수 있는 방식은 캐릭터 외에도 수많은 방법이 있는데, 왜 캐릭터인지 근거가 들어가야 합니다.
솔루션 자체가 나쁘다고 말하기는 어렵지만, 왜 이 방식이어야 했는지에 대한 근거가 부족하면 설득력은 크게 떨어집니다.
캐릭터를 도입하면 정말 사용자가 더 자주 테니스를 치게 될지, 아니면 초반에만 관심을 끌고 금방 의미 없는 요소가 될지는 전혀 검증되지 않은 상태입니다. 특히 캐릭터나 성장 시스템은 디자인, 개발, 운영 측면에서 공수가 매우 큰 기능입니다. 그만큼 명확한 가설과 근거가 필요합니다.
그럼에도 불구하고 “다른 앱에 있으니까”, “요즘 많이 쓰이니까”, “한번 해볼까?”라는 접근으로 보인다면, 이 솔루션은 문제 해결이 아니라 리스크로 느껴질 수 있습니다.
해결 방안
이런 솔루션을 제시하려면 먼저, 유저가 동기부여를 가장 필요로 하는 순간이 언제인지부터 설명해야 합니다. 그리고 그 문제를 캐릭터라는 방식으로 해결하는 것이 왜 합리적인 선택이었는지에 대한 가설과 판단 과정이 있어야 합니다.
다른 대안들과 비교했을 때 왜 이 방식을 선택했는지까지 설명할 수 있어야, 솔루션은 비로소 설득력을 갖게 됩니다.
이게 최선인가요?8. 결과가 없거나, 올바르지 않은 성과를 결과로 제시하는 경우
마지막으로 많이 보이는 실수는, 결과가 없거나 UT로는 말할 수 없는 것을 성과처럼 포장하는 경우입니다. 숫자를 사용해 그럴듯해 보이지만, 오히려 포트폴리오의 신뢰를 떨어뜨리는 장표입니다.
UT는 소수 표본을 통해 문제를 발견하고, 행동을 관찰하며, 정성적인 인사이트를 얻기 위한 리서치입니다. 그럼에도 불구하고 UT 결과를 A/B 테스트나 실제 로그 데이터 분석 결과 같은 성과 지표처럼 제시하면, 면접관은 숫자를 보기보다 방법론을 먼저 의심하게 됩니다.
또한 지표 자체가 “좋아졌는지” 해석이 불가능한 것들이 섞여 있습니다. 체류시간은 프로덕트 유형/과업/시나리오에 따라 다르게 해석될 수 있고, 주요 지표가 아닐 수 있습니다. 또한 실제 서비스와 프로토타이핑으로만 신규 서비스 구현했을 경우 정확한 비교가 되기 어렵습니다.
만족도 점수, 긍정 비율 같은 지표도 UT로는 확인하기 어렵기도 하고 질문 설계가 잘 되었는지, 리크루팅이 편향되지는 않았는지, 질문이 유도형이지는 않았는지 의심이 갈 수 있습니다. 무엇보다 UT의 목적과 체크포인트, 인사이트 등 판단의 흔적 또한 없습니다.
해결 방법
UT 결과를 쓰고 싶다면, 성과를 주장하기보다 인사이트를 중심으로 정리하는 것이 좋습니다. 유저가 보인 행동, 그 행동을 통해 발견한 문제, 그리고 그에 따른 디자인 결정이 유의미합니다.
정량 성과를 말하고 싶다면, 그에 맞는 방법론과 데이터가 있는지부터 점검해야 합니다. 그렇지 않다면 숫자를 줄이고, 사고 과정을 더 많이 보여주는 편이 오히려 신뢰를 얻을 수 있습니다. 유저리서치에 대한 책을 읽고 올바른 리서치 방법론을 사용하는 것도 추천합니다.
이번 편에서 다룬 5~8번의 실수는 대부분 “무언가 있어 보이지만, 유저와 사고 과정이 보이지 않는 경우”라는 공통점을 가지고 있습니다. 사소한 것을 강조하거나, 기능을 나열하거나, 근거 없는 솔루션과 숫자를 제시할수록 포트폴리오는 점점 평범해집니다.
포트폴리오에서 보고 싶은 것은 서비스 설명이 아니라, 문제를 어떻게 바라보고 어떤 판단을 했는지입니다. 이 글이 포트폴리오를 다시 바라보는 기준을 정리하는 데 조금이나마 도움이 되었기를 바랍니다.
피그마스터 소개
10년 차 프로덕트 디자이너
네카라쿠배 3곳, 삼성, 스타트업 실제 재직
100회 이상 멘토링, 강의 (한성대학교, 패스트캠퍼스 등)
2025년 수강생들 서류 합격 : 삼성, 네이버, 라인, 카카오, 토스, 당근, CJ 등
