토스 Product Designer (Tools) 서류 합격 후기 (2)

이전 글에서는 내가 토스에 지원하게 된 계기는 무엇이었고, 토스 Product Designer (Tools) 포지션에 지원하기 위해 프로젝트를 선정한 방식에 대해 작성했다.

 

이전 글 보러가기: https://sejeongdesign.tistory.com/5

토스 Product Designer (Tools) 서류 합격 후기 (1)

 

이번 글에서는 “포트폴리오 없이 지원하기” 전형의 답변을 작성한 과정을 이야기해보고자 한다.

각 질문에 대한 답변을 작성하면서 무엇을 중요하게 고려했는지를 중심으로 풀어보았다.

 

답변 작성하기: 모든 질문의 하나의 스토리가 되도록

 

각 답변을 작성하면서 모든 답변의 내용을 읽었을 때, 문제 정의와 이를 해결하기 위한 과정이 하나의 논리로 자연스럽게 연결되는가에 신경을 많이 썼다. 개인적으로 특히 작성하기 어려웠던 질문 세 개를 중심으로 설명하고자 한다.

 

 

디자인한 제품의 사용자는 누구였고, 어떤 문제를 발견했나요?

 

내가 진행한 프로젝트의 사용자는 세 명이었다. 제품의 타겟 유저와 내부 유저인 팀원들이다. 나는 세 명의 사용자가 가진 세 가지의 문제가 사실은 하나로 연결되어 있다는 점을 의도하고자 했다. 예를 들어 사용자 1의 문제는 사용자 2의 문제 때문에 발생했고, 사용자 2의 문제는 사용자 3의 문제 때문에 발생했다… 라는 식이다. 문제의 본질을 찾기 위해 마치 꼬리에 꼬리를 물고 “왜?” 라는 질문을 던지는 것과 같다. (*문제해결 기법 중 하나로, 5 Why로 많이 알려져 있다.)

 

내가 신입 시절에 네카라쿠배 현직자에게 받았던 포트폴리오 피드백에 의하면, 정의한 사용자(페르소나)가 가진 여러 개의 문제가 따로 노는 건 좋지 않다. 읽는 사람의 입장에서는 “그래서 뭐가 진짜 문제란 거야” 라는 의구심을 불러일으키기 때문이다. (진짜 이렇게 피드백을 주셨다.) 누가 어떤 문제를 겪고 있는지 구체적으로 쓰는 것도 중요하다. 그 전에 “각 사용자들의 문제를 하나로 연결하는 본질이 무엇인지"를 명확히 정의해야 한다.

 

 

그것이 왜 문제라고 생각했나요?

토스 "Product Designer (Tools)" JD 중 일부 (출처: https://toss.im/career/job-detail?job_id=5470955003)

 

 

문제의 중요도를 판단할 때, 팀원 모두가 공감할 수 있는 “회사의 목표”를 근거로 삼았다는 점을 드러내고자 했다. 팀에서 디자이너가 유저 경험에 대해 가장 많이 안다고 해서, 디자이너 혼자만의 생각으로 문제의 중요도를 판단하지 않았다. 그래서 문제의 중요도를 판단하는 기준에 “비즈니스 관점”을 담을 수 있도록 노력했다. 내가 재직하고 있는 곳에서도 비즈니스 임팩트가 문제의 중요도를 파악하는 기준으로 많이 쓰이곤 했기 때문이다.

 

예를 들어, 문제 해결 대상이었던 유저는 비즈니스적으로 더 높은 가치가 있다는 것을 다른 유형의 유저와 비교하는 방식으로 설명했다. 내부 팀원에 대해서는, 문제를 해결한다면 비즈니스적으로 더 임팩트 있는 업무를 할 시간이 늘어난다는 주장을 구체적인 문제 상황과 함께 설명했다.

 

 

문제가 해결되었다고 생각하시나요?왜 그렇게 생각하시나요?

 

사실, 내가 소재로 쓴 프로젝트는 실패한 프로젝트다. 부분적으로 개선 성과가 있었지만, 처음에 정의한 사용자들의 문제를 모두 해결하지 못했기 때문이다. 그럼에도 내가 (목표 달성 측면에서) 실패한 프로젝트를 소재로 썼던 이유가 있다. 부분적으로 개선 성과가 있었고, 유저와 가장 가까이에서 소통할 기회가 있었던 몇 안 되는 프로젝트라는 점에서다. 프로젝트에 결점(?)이 있기 때문에, 이 질문의 답변을 작성하면서 가장 신경쓴 점은 프로덕트 개선에 대한 “진심” 이었다. 성과는 과장하지 않고, 실패한 부분에 대해서는 솔직하게 인정한다. 특히 실패한 부분에 대해서는 회사의 사업 방향성이 변경되어서 성과를 검증하기 어려웠다는 이유를 제시하되, 만약 프로젝트가 계속 진행되었다면 유저의 문제를 해결하기 위해서 어떤 방식을 시도해봤을까? 에 대한 고민을 드러냈다. 초안은 성과에 대한 서술에 비해 실패한 부분에 대한 서술이 빈약했는데, 이 내용을 교정하는 데는 챗GPT의 첨삭이 도움이 많이 되었다. 답변 중에서 가장 작성하기도 어려웠고 지원서를 제출한 뒤에도 아쉬움이 많았던 내용이기도 하다.

 

답변 첨삭할 때 정말 잘 써먹은 챗GPT. 티키타카하면서 여러 번 퇴고했다.

 

요약

1. 정의한 문제가 한 개든 여러 개든, 문제의 “본질”이 드러나야 한다. 문제의 본질을 찾는 데는 “5 Why” 같은 기법이 도움이 된다.
2. 문제의 중요도를 판단할 때, 팀원 모두가 공감할 수 있는 “회사의 목표”를 근거로 삼았다는 점을 강조한다.
3. 문제를 해결한 결과를 설명할 때는 진정성을 보여준다. 성과는 구체적인 수치와 함께 제시하되 과장하지 않는다. 실패한 부분이 있다면 솔직하게 인정한다. 단 실패한 부분에 대해서는 프로덕트 개선에 대한 깊은 고민을 보여줄 필요가 있다.

 

다음 아티클에선 개선 전후를 명확하게 보여주는 “대표 이미지”를 어떻게 만들었는지 설명하고자 한다.