온보딩 포트폴리오는 화면보다 이탈의 원인을 보여줘야 합니다

온보딩 리디자인 포트폴리오는 자주 비슷하게 시작합니다. 가입 흐름을 보여주고, 3단계에서 이탈률이 높았다는 문제를 제시하고, 여러 시안을 탐색한 뒤 더 간결한 최종 화면을 보여줍니다. 화면은 매끄럽지만 읽고 나면 한 가지 질문이 남습니다.

그래서 실제로 사용자의 이탈이 줄었나요?

좋은 케이스 스터디는 예쁜 결과물을 보여주는 문서가 아니라, 불확실한 문제를 어떻게 좁혀갔고 그 판단이 어떤 결과를 만들었는지 설명하는 문서입니다.

숫자는 출발점이지 문제 정의가 아닙니다

“3단계에서 42%가 이탈한다”는 유용한 신호입니다. 하지만 이 숫자만으로 3단계가 문제라고 단정할 수는 없습니다. 사용자가 앞 단계에서 이미 기대를 잃었을 수도 있고, 특정 기기나 유입 경로에서만 나타나는 현상일 수도 있습니다.

포트폴리오에서는 숫자 옆에 측정 범위와 질문을 적어야 합니다. 어떤 기간의 데이터인지, 신규 사용자만 포함했는지, 이탈을 어떤 이벤트로 정의했는지, 세그먼트별 차이가 있었는지를 밝혀야 합니다. 데이터가 말하는 것과 아직 모르는 것을 분리하면 문제 정의가 더 강해집니다.

버린 시안은 의사결정의 증거입니다

버린 시안 두 개를 보여주는 것은 좋은 출발입니다. 다만 “이 안은 복잡해서 버렸다”로 끝나면 취향의 기록에 머뭅니다. 어떤 사용자 문제를 해결하려 했고, 어떤 테스트나 제약 때문에 버렸는지 보여줘야 합니다.

예를 들어 한 시안은 정보를 한 화면에 모아 완료율을 높이려 했고, 다른 시안은 단계를 나눠 인지 부담을 낮추려 했을 수 있습니다. 이 둘을 비교하면 디자이너가 화면을 바꾼 것이 아니라 서로 다른 가설을 실험했다는 사실이 드러납니다.

최종안보다 출시 뒤의 장면이 중요합니다

출시 전이라면 사용성 테스트, 프로토타입 과업 성공률, 인터뷰의 구체적인 발화라도 보여주세요. 출시 후라면 전환율 하나만 자랑하지 말고, 어떤 사용자군에서 효과가 있었는지와 부작용이 없었는지를 함께 적어야 합니다.

결과가 아직 없다면 없다고 쓰는 편이 낫습니다. “검증 예정”을 “개선했다”처럼 표현하면 케이스의 신뢰가 오히려 떨어집니다. 문제 정의와 탐색이 훌륭해도 결과가 비어 있다면, 그 케이스는 완성된 성공담이 아니라 진행 중인 의사결정 기록입니다.

본인의 역할을 장면으로 보여줍니다

“팀과 협업했다”는 말은 거의 모든 프로젝트에 해당합니다. 본인이 직접 한 일과 팀이 함께한 일을 분리해야 합니다. 문제 정의에서 어떤 분석을 했는지, 사용자 테스트를 누가 설계했는지, 개발 제약과 어떤 방식으로 합의했는지, 최종 결정권은 누구에게 있었는지를 적습니다.

역할을 크게 보이게 만드는 것보다 판단의 경계를 정확히 그리는 편이 강합니다. 면접관은 모든 일을 혼자 했다는 사람보다, 자신이 책임진 결정과 다른 사람의 전문성을 구분할 수 있는 사람을 신뢰합니다.

좋은 점

데이터로 출발하고 버린 시안을 공개하면 결과만 보여주는 포트폴리오보다 문제 해결 과정을 이해하기 쉽습니다. 특히 온보딩처럼 단계별 흐름이 있는 문제는 가설과 검증을 연결하기 좋은 주제입니다.

한계

현재 케이스에 실제 출시 후 결과와 사용자 검증이 없다면 성공 사례로 단정할 수 없습니다. 이 한계를 숨기기보다 프로젝트의 현재 단계와 다음 검증 계획을 명확히 밝히는 편이 정직합니다.

남는 긴장

포트폴리오는 짧게 읽혀야 하지만, 판단의 근거를 모두 지우면 화면 쇼케이스가 됩니다. 반대로 데이터를 너무 많이 넣으면 핵심 이야기가 묻힙니다. 무엇을 버리고 어떤 숫자와 발화를 남길지가 포트폴리오 편집의 핵심입니다.

질문

• 이탈률이 높은 단계가 정말 원인인가요, 아니면 신호에 불과한가요?
• 각 시안은 어떤 가설을 검증하기 위해 만들어졌나요?
• 출시 후 결과가 없다면 그 사실과 다음 검증 계획을 밝혔나요?
• 내가 직접 한 판단과 팀의 기여가 구분되어 있나요?

온보딩 케이스의 마지막 장면은 최종 화면이어서는 안 됩니다. 사용자가 실제로 무엇을 했고, 팀이 무엇을 배웠으며, 그 배움이 다음 결정에 어떻게 반영됐는지가 보여야 합니다.