문제 해결형 포트폴리오의 맹점
프로덕트 디자이너 포트폴리오 이야기
* 개인적인 견해입니다
프로덕트 디자이너, UX디자이너의 포트폴리오는 대부분이 ‘문제 → 해결 → 결과’의 구조입니다. 이 구조는 굉장히 중요합니다. 어떤 문제를 발견했고, 그것을 어떻게 풀었으며, 결과적으로 어떤 성과를 냈는지를 설명해야 합니다. 문제 해결 과정을 하나의 이야기처럼 풀어낸 포트폴리오를 보면 평가자들도 이해하기 쉽습니다.
그런데 안타깝게도, 많은 포트폴리오가 "이것만 넣으면 된다!"라고 생각합니다. 문제를 적어놓고, 해결책을 제시하고, 마지막엔 어떻게든 수치화를 해서 성과를 보여줘야지!
예를 들어 이런 식입니다.
"검색 화면에 필터가 없어서 유저들이 불편해했습니다.
필터를 원하는 사람이 80%로 나왔습니다.
그래서 필터를 넣었습니다.
(스터디인 경우) UT를 했더니 5명 중에 5명이나 좋다고 했습니다!
(실제 런칭한 경우) 결과적으로 구매 전환율이 200%나 올랐습니다!"
문제도 있고, 해결도 있고, 결과도 있습니다. 겉으로 보면 완결된 스토리처럼 보입니다. 하지만 면접관 입장에서는 이 사람을 뽑을 수 없습니다. 문제를 해결한 건 맞지만, 이 지원자가 아니면 안 되는 이유, 이 지원자만의 역량이 보이지 않거든요.
이런 포폴을 보면서 드는 생각은
“아, 필터 넣었구나.”
여기서 끝입니다.
왜냐면 이건 누구라도 할 수 있는, 업계 표준화된 해결책이기 때문입니다. 왜 이 문제가 중요한지, 근본적인 원인이 무엇이었는지, 어떤 사용자가 어떤 상황에서 불편해했는지에 대한 설명이 없었고, 성과는 단순히 숫자로만 나와 있었습니다.
결국 200%이던, 300%이던, 면접관은 이 지원자에게 크게 관심을 갖지 않습니다.
비슷한 포폴들을 보는 심정문제 해결형 포트폴리오에서
빠지기 쉬운 함정
여러 포트폴리오를 보면서 발견한 탈락 케이스들을 적어보았습니다.
1. 문제 정의가 얕다.
문제는 세상에 널려 있습니다. VOC만 봐도 엄청 많습니다. 그런데 왜 지금 이 문제를 풀어야 했는지, 이게 비즈니스와 사용자 경험에서 얼마나 중요한 문제였는지에 대한 설명이 빠져 있습니다.
문제는 어디에나 있다2. 근본 원인 분석이 없다.
유저가 기능을 쓰지 않는 이유는 다양합니다. 몰라서 못 쓰는 것인지, 필요성을 못 느끼는 것인지, 실제로는 써도 효과가 없어서 포기하는 것인지. 그런데 많은 경우 이런 원인 분석 없이 바로 “없으니 넣었다” 혹은 "복잡해서 단순화했다"식으로 점프합니다.
생각보다 간단한 문제가 아닐수도 있다3. 사용자 맥락이 없다.
우리의 유저는 이런 성향이라 이런 상황에서 이런 이유 때문에 불편했다-등의 유저의 사용성에 대한 설명이 있어야 디자인이 설득력을 얻습니다. 하지만 이런 서술이 생략되는 경우가 많습니다. 사용자 맥락이 없다면 단순한 문제 해결이 될 가능성이 높아집니다.
4. 해결 방안에 깊이가 없다.
왜 이 방식을 선택했는지, 다른 화면이나 흐름으로는 풀 수 없었는지에 대한 고민이 드러나지 않습니다. 단순히 하나의 솔루션을 제시하고 끝나버립니다.
가장 많이 물어보는 면접 질문에는 "이 방식 말고 다른 해결 방법을 고민하신 것이 있나요? 그것은 왜 선택되지 못했나요?" "이런 방식이 유저에게 더 쉬울 것 같은데, 이런 방식은 생각해 보셨나요?"입니다. 이 지원자가 얼마나 고민을 해서 나온 해결 방안인지 확인하고 싶어 합니다.
1400만개까지는 생각하지 않아도 됩니다5. 성과를 억지로 수치화한다.
실무에서는 하지 않을 것 같은 수치를 억지로 만들어서 성과로 가져옵니다.
예를 들어 이커머스에서 장바구니에 담는 시간이 줄었다는 걸 성과로 제시하는 경우가 대표적입니다. 하지만 실제로 중요한 건 구매 전환율이나 매출이지, 장바구니에 담는 ‘속도’는 아닙니다. 보통 이커머스 유저의 경우 상품 페이지를 넘나들며 충분히 고민하다가 담기 때문에 해당 수치는 중요하지 않습니다. 게다가 UT용 프로토타입과 실제 앱의 시간 측정 데이터는 비교 자체가 어렵기 때문에 이런 숫자는 오히려 신뢰를 떨어뜨릴 수 있습니다.
비슷하게 "10명에서 물어봤는데 10명이 쓴다고 했습니다"라는 성과가 있습니다. 하지만 실무에서는 "쓸 것 같나요?"라고 미래의 상황을 가정해서 물어보지 않는 경우가 대부분입니다. 해당 내용은 토스 블로그 글을 참고해 주세요. (https://toss.tech/article/26109)
억지로 만든 성과중요한 건 깊이입니다.
결국 포트폴리오에서 중요한 건 내가 어떤 깊이로 문제를 바라봤는가입니다. 단순히 문제를 발견하고, 기능 하나 추가해서, 숫자 몇 퍼센트 올린 게 포트폴리오의 전부가 되어서는 안 됩니다.
왜 이 문제를 풀어야 했는지, 이 문제가 왜 생겼는지, 유저는 왜 이런 어려움을 겪는지, 여러 해결책 중 왜 이걸 선택했고 특히 어떤 걸 고려했는지, 결과는 어떤 의미를 갖는지 등 나의 역량이 충분히 드러나게 포트폴리오를 구성해 주세요.
성과 숫자 하나보다 중요한 건, 그 숫자가 나오기까지의 과정입니다. 오히려 정성적인 결과라도 맥락과 이유가 탄탄하다면 훨씬 더 설득력이 있습니다.
마치며
요즘 “문제 해결형 포트폴리오로 썼는데 왜 떨어지나요?”라는 질문을 자주 받습니다. 문제를 예상 가능하게 푼 것은 아닌지, 나의 고민이 정말 잘 드러나는지 점검해 주세요. 문제를 해결하는 건 디자이너라면 누구나 합니다. 중요한 건, 그 문제를 왜 선택했고, 어떻게 접근했으며, 무엇을 배웠는지, 디자이너로서의 사고 과정을 보여주어야 합니다.
평범한 문제해결 포폴은 관심을 받지 못한다네카라쿠배 디자이너
피그마스터 서비스들이 궁금하시다면?
