이직 준비하면서 포폴 정리 중인데 제가 맡았던 것들이 대부분 출시 전에 엎어지거나 회사에서 지표를 안 풀어줘서 쓸 숫자가 하나도 없어요ㅋㅋ 전환율 몇 % 올랐다 이런 거 한 줄도 못 씀... 그렇다고 없는 숫자 지어낼 순 없잖아요. 이럴 땐 그냥 과정이랑 의사결정 위주로 풀어내는 게 맞을까요? 아니면 사용자 인터뷰 반응 같은 정성적인 거라도 억지로 끼워넣는 게 나을까요? 다들 어떻게 처리하시는지 궁금해요.
포폴에 넣을 성과 지표가 없는 프로젝트, 어떻게 푸세요?
9.10 04:45조회수 0댓글 9
저는 재작년에 6개월 붙잡고 있던 B2B 어드민 개편이 런칭 2주 전에 통째로 홀딩된 적 있어요. 지표는커녕 실사용자 한 명도 못 붙였죠ㅋㅋ 그때 포폴에선 결과 대신 문제 정의랑 트레이드오프를 메인으로 뺐습니다. "권한 구조가 4단계라 기존 IA로는 케이스가 12개까지 늘어남 → 3개 패턴으로 압축, 대신 예외 케이스는 별도 플로우로 분리" 이런 식으로요. 숫자가 없어도 판단 근거가 촘촘하면 설계 능력은 충분히 읽힙니다. 정성 데이터는 억지로 끼워넣는 순간 티가 나요. 인터뷰가 3명이면 3명이라고 쓰고 그 안에서 나온 구체적 발언을 인용하는 게 낫습니다. 표본 작은 걸 일반화하려고 포장하면 면접에서 바로 파고들어요.
전 좀 다르게 봐요. 숫자 없는 게 오히려 티나는 건 억지로 끼워넣을 때더라구요. 저는 그래픽 쪽이라 애초에 전환율 같은 지표랑은 거리가 먼 작업이 대부분인데, 예전에 포폴 정리하면서 "브랜드 인지도 향상에 기여" 같은 문장 넣었다가 면접에서 그거 어떻게 측정하셨냐고 물어보시길래 식은땀 흘린 적 있어요ㅋㅋㅋ 결국 제가 왜 이 색을 골랐고 클라 피드백을 어떻게 반영했는지 얘기하니까 그쪽이 훨씬 반응이 좋았고요. 사용자 인터뷰 반응은 억지가 아니라 그것도 엄연한 근거 아닌가요? 다만 출시 전에 엎어진 프로젝트는 저도 어떻게 써야 할지 모르겠어요... 엎어진 이유까지 솔직하게 쓰시는 분들도 있던데 그건 좀 위험한가 싶기도 하고.
저도 브랜드 쪽 카피 넣었다가 비슷하게 당한 적 있어요ㅋㅋ 인터뷰 반응은 저도 근거 맞다고 생각해요. 다만 "긍정적이었다" 말고 "5명 중 3명이 이 단계에서 막혔다" 식으로 구체적으로 쓰니까 훨씬 덜 억지스럽더라고요. 엎어진 건 저는 이유를 회사 탓처럼 안 쓰고 "우선순위가 바뀌어 중단됐고, 대신 이 리서치는 이후 다른 화면에 반영됐다"까지 붙여요. 결과가 아니라 판단을 보여주는 거니까요.
저는 그 뒤로 아예 "엎어진 이유"를 한 줄로 못 박고 시작해요. 브랜드 리뉴얼 하나가 대표 교체되면서 중단됐는데, 처음엔 창피해서 얼버무렸거든요ㅋㅋ 근데 "예산 재배정으로 홀딩됐고, 이때 만든 그리드 시스템은 이후 상세페이지 템플릿으로 그대로 넘어갔다"고 쓰니까 면접에서 오히려 그 얘기만 물어보시더라고요. 결과 없는 게 문제가 아니라 왜 그렇게 했는지가 안 보이는 게 문제였던 것 같아요.
혹시 지원하는 회사가 어떤 곳인지에 따라 답이 달라지진 않을까요? 저는 아직 신입이라 감히 조언드릴 입장은 아니고, 사실 저야말로 숫자가 하나도 없는 포폴로 취준했던 사람이라서요ㅠㅠ 그때 제가 할 수 있는 거라곤 왜 이 방향을 골랐는지 최대한 솔직하게 적는 것뿐이었어요. 근데 3년차 실무 프로젝트는 또 다른 기준으로 보실 것 같아서, 저도 다른 분들 답변이 너무 궁금해요. 출시 전에 엎어진 것도 결국 회사 사정인데 그게 왜 디자이너 손해로 돌아오는지 좀 억울하네요 😢
회사마다 보는 기준이 다른 건 맞는데, 저는 오히려 그래서 지표 없는 게 덜 치명적이더라구요. 면접에서 숫자 물어본 곳은 있었지만 못 냈다고 떨어진 적은 없었고, 대신 "왜 그렇게 결정했냐"는 계속 파고들었어요. 하은님이 하신 것처럼 솔직하게 이유 쓰는 게 결국 3년차한테도 똑같이 통하는 것 같아요. 엎어진 프로젝트도 그 안에서 제가 판단한 건 남으니까요!
면접에서 숫자보다 왜 그렇게 했냐를 파고든다는 말 들으니까 좀 안심되네요. 저는 아직 면접 경험이 없어서 신입이라 봐주는 건가 싶었거든요. 3년차한테도 똑같이 통한다면 그냥 제가 판단한 근거를 더 촘촘하게 적어두는 쪽으로 가야겠어요. 엎어진 프로젝트에도 남는 게 있다는 말이 위로가 돼요.
저도 마지막 회사에서 리서치 다 돌리고 스펙까지 나왔던 온보딩 개편이 조직개편으로 접힌 적이 있어서 그 막막함 알 것 같아요. 그때 제가 정리했던 방식은 결과 대신 '가설과 검증 설계'를 앞에 두는 거였어요. 어떤 문제를 어떤 근거로 정의했고, 성공을 무엇으로 측정하려고 했는지, 측정 지표를 어떻게 설계했는지까지 쓰면 숫자가 없어도 이 사람이 지표를 다룰 줄 안다는 건 충분히 보이더라고요. 실제로 면접에서 "런칭됐다면 어떤 수치를 봤을 것 같냐"는 질문을 받았는데, 그 부분을 미리 정리해둔 게 도움이 됐어요. 정성 데이터는 억지로 끼워넣는다기보다 인용의 밀도 문제인 것 같아요. 인터뷰 반응 여러 개를 나열하면 장식처럼 보이는데, 디자인을 바꾸게 한 결정적인 한마디만 남기고 그 앞뒤로 무엇을 바꿨는지 붙이면 근거로 읽히더라고요.
숫자가 없으면 판단 기준을 대신 보여주는 쪽으로 가는 게 낫더라고요. 저도 7년 하면서 엎어진 프로젝트가 절반은 되는데, 지표 대신 "왜 이 안을 택했는가"를 검증 가능한 형태로 적어요. 예를 들면 초기 안 3개 중에 어떤 걸 왜 버렸는지, 그때 근거가 된 CS 문의 유형이나 기존 화면의 이탈 구간 같은 거요. 회사가 지표를 안 풀어줘도 본인이 문제를 정의할 때 봤던 자료는 쓸 수 있잖아요. 정성 데이터는 억지로 끼워넣지만 않으면 충분히 무기가 돼요. 인터뷰 반응을 "사용자들이 좋아했다"로 쓰면 공허한데, 8명 중 6명이 같은 지점에서 막혔고 그래서 구조를 이렇게 바꿨다까지 이어지면 그건 그냥 근거예요. 출시 전에 엎어진 건 면접에서 물어보면 담백하게 말하면 되고요. 제 경험상 면접관은 성과보다 사고 과정을 더 캐묻습니다.