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

이전 글에서는 내가 토스 프로덕트 디자이너 (Tools)의 포트폴리오 없는 전형에 지원하기 위해 질문 답변을 작성한 방식에 대해 이야기했다. 각 질문의 의도를 나는 어떻게 해석했으며, 내가 진행한 프로젝트 경험을 기준으로 어떤 메세지를 전달하고자 했는지에 중점을 두었다.

 

이전 글 보러가기:

https://sejeongdesign.tistory.com/6

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

 

이번 글은 서류 합격 후기의 마지막 파트다. “포트폴리오 없이 지원하기” 전형의 대표이미지를 작업한 방식에 대해 이야기해보고자 한다. 참고로 나는 데스크톱 기반의 프로덕트를 다루었다. 모바일과 데스크톱 프로덕트의 차이점을 인식하고 데스크톱 프로덕트의 대표이미지를 작업하기 위해 무엇을 신경쓰면 좋을지에 대해 이야기 할 예정이다. 나처럼 데스크톱 프로덕트를 개선한 프로젝트를 가지고 토스에 지원하려는 디자이너에게 도움이 되었으면 좋겠다.

 

---

 

프로젝트에서 어필할 게 얼마나 많은데… 한 장에 다 보여주라니요?

 

다음은 토스의 프로덕트 디자이너 (JD)에서 요구하는, 포트폴리오 없이 지원하기에 필요한 대표이미지의 조건 중 하나이다.

이 사례를 대표하는 이미지 1장을 업로드 해주세요.

 

여기서 주목해야 할 점은 내 의도대로 페이지를 구성할 수 있는 포트폴리오와 달리, 대표이미지는 1장을 첨부해야 한다는 사실이다.

 

혹시, 이 글을 읽는 여러분들은 단 한 장의 이미지로 디자인 프로젝트 성과를 어필하는 것이 어렵다는 것에 공감하는가?

 

구글에서 “포트폴리오 장수”로 검색하면 나오는 결과들

 

 

많은 디자이너들이 포트폴리오를 만들 때 적절한 “장수”에 대한 고민을 많이 한다. 그만큼 (장수 늘리기는 쉬울지 몰라도) 장수를 줄이는 건 매우 어려운 것 같다. 네이버도 각 프로젝트 당 한 장으로 정리된 포트폴리오를 요구할 정도다.(*23년 기준)

두세 장의 포트폴리오에 나의 모든 경험을 녹여야 할 때, 핵심을 요약하고 정리하는 스킬이 부족하다면 채용 담당자들한테 나의 논리가 탄탄하지 않다는 사실이 쉽게 드러날 수밖에 없다.

그런 점에서 많은 기업에서 포트폴리오의 페이지 수를 제한하거나, 아예 네이버처럼 극단적인 장수를 요구하는 곳이 있는 것도 이해가 된다. 현업에서 대부분의 사람들은 자신이 굳이 알 필요 없는 구구절절한 내용들, 이를테면 디자인 리서치, 채택되지 못한 시안 등… 자료가 많다고 해서 좋아하지 않는다.* (특히 디자인 직군이 아닌 PM, 기획자, 개발자라면 더더욱) 그들은 빠르고 효율적인 커뮤니케이션을 위해 핵심 위주의 커뮤니케이션을 선호한다. 채용담당자들도 포트폴리오를 통해서 지원자의 커뮤니케이션 역량을 보고자 한다. 기존 팀원들과 원활한 협업이 가능할지 확인하기 위해서다.

 

*물론 어디까지나 “회바회(회사 바이 회사)”다. 디자인 업무 자료의 많고 적음이 중요한 게 아니라 지원할 회사가 정의하는 효과적인 커뮤니케이션이란 무엇인가를 파악하는 게 중요하다.

 

데스크톱 프로덕트인데, 개선 전후를 한 페이지에서 보여줄 수 있을까?

 

토스 “포트폴리오 없는 전형” 의 대표이미지의 또 다른 조건은 아래와 같다.

제품 개선 프로젝트의 경우 as-is, to-be를 확인할 수 있는 이미지라면 좋습니다.

 

내 디자인을 보여주는 방식으로 여러 장의 포트폴리오를 활용하는 것에 익숙하던 나에게, 프로적트의 개선 전후를 한 페이지에 보여주는 것, 그것도 모바일보다 화면이 더 큰 데스크톱 프로덕트를 보여줘야 한다는 것은 막막하게 느껴졌다.

대표이미지의 레이아웃을 잡는 단계부터 여러 번 시안을 만들었지만, 실제로 레이아웃에 디자인을 얹어보니 문제가 보였다. 텍스트 크기가 작아서 가독성이 좋지 않다거나, 디자인을 확인하려면 화면을 확대해야 한다거나, 모니터를 기준으로 한 화면에 여러 개의 문제와 솔루션을 나열하는 방식이 최선일까… 이미지 하나 만드는 데에도 답변 작성하는 것 못지 않은 고민을 했었다. 그만큼 한 페이지에 디자인 문제 해결의 핵심을 일목요연하게 보여주는 작업은 나에게도 여전히 어려운 일이다.

여러 개의 시안을 만들면서 이럴 바인 포트폴리오를 만들어서 지원하는 게 낫지 않을까? 생각도 했다. 그 무렵, 단순히 기능의 개선 전후를 나열하는 방식은 대표이미지 1장의 의도가 아닐 것이라는 생각이 강하게 들었다.

 

 

이미지의 핵심은 기능 자체가 아닌, 기능이 소구하는 “목적”

 

나도 처음 대표이미지의 시안을 작업할 때는 스크린샷으로 UI의 개선 전후를 단순 나열하는 방식에서 벗어나지 못했었다. 그렇지만 데스크톱 프로덕트를 보여줄 때 이 방식은 적절하지 않다는 것을 깨달았다. 모바일은 화면의 크기가 작아서 하나의 화면 하나의 기능이라는 원칙이 비교적 잘 지켜진다. 그래서 지원자가 어떤 부분을 개선했는지를 비교적 쉽게 찾아낼 수 있다. 반면, 데스크톱은 화면이 넓다 보니 한 화면에 한 기능이라는 법칙이 꼭 지켜진다는 법은 없다. 기능이 많아지면 UI도 복잡해진다. 데스크톱 프로덕트의 UI를 단순히 스크린샷 캡쳐해서 보여주는 것은 지원자가 어떤 문제를 해결했는지를 알고 싶어하는 채용담당자를 배려하는 것은 아니다. (지친 업무에 활력(?)을 불어넣어주는 숨은그림 찾기도 아니고…)

 

채용담당자들이 내가 제출한 답변을 보고 진짜 궁금해하는 것은 뭘까? 디자인을 개선해서 유저의 문제가 해결되었는지가 아닐까? 내가 선택한 대안은, 개선한 기능의 “목적”에 집중하는 것이었다.

 

개선 대상이었던 기능은 유저의 어떤 목적을 달성하기 위한 것이며, 유저가 목적을 달성하는 방식은 개선 전후에 어떻게 변화했는지를 이미지에 녹이려고 했다. 예를 들어, 내 프로젝트의 개선 대상 중에는 신청서(폼)를 만드는 기능이 있다.* 유저가 랜딩페이지로 원하는 데이터를 수집하는 기능을 쉽게 구현할 수 있도록 만든 기능이다. 개선하기 전에는 이 신청서 하나 디자인하는 일이 참 번거로웠다. 이 상황을 as-is 이미지로 표현했다. 채용담당자들이 이미지를 봤을 때 “유저들이 이런 식으로 신청서를 만든다면 얼마나 불편했을까”를 느낄 수 있었으면 했다.

 

to-be 이미지에서는 버튼 하나만 클릭하면 신청서 디자인이 만들어지는 과정을 이미지로 표현했다. 유저 플로우를 활용해서 구체적인 기능을 함께 소개했다. as-is 이미지에서 느낀 불편한 점이 확실히 해소된다는 느낌을 받을 수 있게 의도했다.

 

*보안상 실제 프로젝트 내용을 쓴 것은 아니고, 최대한 비슷하게 각색했다.

 

요약

 

1. 포트폴리오든 대표이미지든, 핵심을 요약하고 일목요연하게 보여주는 스킬이 필요하다.
2. UI 디자인의 개선 전후를 소개할 때는, UI 디자인을 단순 나열하기보다 UI 및 기능이 소구하는 “목적”에 집중한다.

 

---

 

 

이 아티클을 끝으로 서류 전형 합격 후기를 마무리하고자 한다.

비록 네카라쿠배당”토”의 서류 전형 합격 후기일 뿐이지만, 짧게나마 내가 어떤 생각과 관점을 갖고 전형을 준비했는지 정리해볼 수 있었다. 말을 잘 못하는 나는 생각을 글로 풀어내는 것만으도 직무 인터뷰 준비에 적지 않은 도움이 되었을 것 같다.

 

마지막으로, 요즘 프로덕트 디자이너로 취업이나 이직하기가 너무 힘들다는 이야기를 많이 들었다. 사실 취업이나 이직이 쉽다는 이야기는 살면서 한 번도 못 들었지만… 부정적인 이야기에 취업 혹은 이직 욕구가 꺾이거나 위축되어 있는 사람들이 적지 않을 것 같다.

 

그럼에도 불구하고, 포트폴리오에 나만의 생각과 관점을 솔직하게 담는 데 집중한다면 충분히 서류 합격이 가능할 거라고 생각한다.

이 글이 나와 비슷한 상황에 있는 분들께 조금이나마 도움이 되었으면 좋겠다.