What I learned — 프로덕트 디자이너의 1년 회고

Jiyu Han
7 min readAug 3, 2021

--

안녕하세요, 오늘은 제가 Dataframe에 입사한 지 꼭 1년이 되는 날이에요. 프로덕트 디자이너로 커리어를 시작한 지도 꼭 1년이 된 만큼, 2년 차를 맞이하기 전에 지난 1년을 되돌아보려고 합니다. 앞으로도 6개월 간격으로 회고 글을 꾸준히 적어보려 해요.

(6개월 전에 적었던 ‘What I learned — 미국 스타트업 주니어 디자이너의 6개월 회고’ 전문은 링크를 통해 보실 수 있습니다)

프로덕트 디자이너로 일한 지 1년 차, 그동안 무엇을 배웠을까?

PMF를 찾는다는 것, 그 과정에서 디자이너의 역할.

지난 6개월 동안 Dataframe에는 꽤 많은 변화가 있었습니다. 프로덕트 이름을 Dataframe에서 Prequel로, 다시 Hyperquery로 바꾸었고요. 프로덕트의 방향도 두어 번 *피벗하는 과정을 거쳤습니다. 지금은 “The collaborative workspace for analytics”라는 비전을 가지고 데이터 분석을 하기에 가장 좋은 툴이 되기 위해 나아가는 중입니다.

초창기 팀원으로서 프로덕트의 방향을 끊임없이 수정하고 올바른 방향과 타겟으로 점진적으로 다가가는 과정에 함께 할 수 있었고, 그 과정에서 각 팀원의 역할을 배웠습니다.

작년 12월 저희는 프라이빗 베타 런칭을 했고, 코파운더들은 끊임없이 유저와 미팅을 갖고 유저 데이터를 살펴보면서 프로덕트의 방향성을 점검하고 고민해왔습니다. 그리고 올해 초, 프로덕트 Pivot을 위한 비전과 방향을 새로이 제시했습니다.

그 후에 얼마만큼 바뀌었냐고 하면요. 지난 6개월간 그려왔던 레이아웃을 버리고 새로 레이아웃을 구성했고요. 어제까지 중요했던 기능은 오늘 더 이상 중요하지 않았습니다. 전달하고자 하는 룩앤필이 완전히 바뀌면서 프로덕트 이름, 로고, 웹 사이트, UI, 마케팅 문구, 일러스트 모든 것을 새롭게 리뉴얼했습니다. 개발팀은 빠르게 구현하기 위해서 기존까지 유지했던 데이터베이스, 운영환경, 인프라 모든 것을 마이그레이션하고 새롭게 만들어야했습니다. 그리고 이 모든 변화는 두세달 안에 이루어졌습니다.

여기서 저는 초창기 팀에서 프로덕트 디자이너가 해야 할 역할에 대해 조금이나마 배울 수 있었습니다. 바로 리더들의 말과 글을 통해서 그들의 머릿속에 있는 비전을 가시화하는 것이 디자이너가 꼭 해야 할 일이라는 것을요. ‘백문이 불여일견: 백 번 듣는 것이 한 번 보는 것만 못하다’라는 말처럼, 비전을 가시화한 이미지는 팀원의 이해를 도울 수 있습니다. 리더가 앞으로 우리가 나아갈 비전에 대해 팀원들에게 제시할 때, 비전과 함께 보는 청사진이 되어줄 수 있죠.

또 여러 안을 제시해서 리더들이 끊임없이 더 나은 결정을 할 수 있도록 도와야 합니다. 하나의 아이디어를 구현하기 위한 방법에는 수십 가지가 있지만, 그중에서 가장 나은 안은 무엇인지, 미처 고려하지 못한 부분이 있진 않은지 가시화해서 리더들이 더 중요한 부분을 더 깊게 고민할 수 있도록 서포트할 수 있습니다.

리더는 올바른 비전을 제시하고, 디자인 팀은 가시화하고 개선하며, 개발 팀은 빠르게 구현해 검증할 수 있게 하는 것이 *PMF를 찾기까지 각 팀이 해야 할 역할이 아닐까 생각해봅니다.

*PMF: Product Market Fit
*Pivot: 피벗은 현 비즈니스의 일부를 중심축으로 회전, 전환, 혁신을 모색하는 것

속도와 디테일, 각각 중요한 때가 따로 있다.

이전에 제가 아무리 디자인을 해도 실제 앱에서는 디테일이 구현되지 않는 것을 보며 아쉽기도 했고, 디자인 팀과 개발 팀의 협업 과정에서 무언가 문제가 있다고 생각해서 저희 팀 CTO에게 얘기를 꺼냈던 적이 있습니다. 그때 CTO는 이렇게 대답해줬어요. 회사가 생존 모드를 벗어나기 전까지는 Pixel perfect를 이뤄내는 것보다 빠르게 구현하는 것이 더 중요하기 때문에 그때까지는 조금 용인해달라고요.

최근까지 회사는 *80/20 법칙, Go ship! 의 마인드셋 갖고 있었습니다. 지금 중요한 기능을 최대한 빠르게 전달하는 것이 먼저였기에, 디테일보다는 빠르게 디자인하고, 반복하고, 구현해 릴리즈하는 것이 중요했습니다. (*80/20 법칙, 즉 파레토의 법칙은 핵심적인 20%의 노력으로 80%의 결과를 얻을 수 있다는 내용입니다. 따라서 가장 핵심이 되는 20%에 집중해야 하며, 어떻게 핵심적인 20%에 집중할 수 있는지에 관한 것이 80/20 법칙의 핵심입니다)

하지만 최근 회사는 80/20 법칙에서 벗어나 “99% things that matter”의 마인드셋으로 바꾸었습니다. 이제는 유저들이 사랑하는 앱을 만들기 위해서 속도뿐만 아니라 사소한 디테일 하나도 중요해진 시기가 온 것이죠.

아래는 저희 회사의 이전 목표와 현재 목표입니다. 꽤 차이가 있죠?
Old objective: Get product shipped and barely usable ASAP.
Primary objective: Build a product that customers love.

이러한 경험을 통해 속도와 디테일, 각각 중요한 때가 따로 있다는 것을 배웠습니다. 프로덕트의 가치를 검증하기 까지는 디테일한 부분을 어느 정도 포기하더라도 구현과 속도가 중요하고, 그 후에 디테일을 채워나가야한다는 것을요.

그리고 팀원 모두가 같은 마인드셋으로 얼라인될 수 있게 공유하는 것 또한 매우 중요하다는 것도 알게 되었습니다. 저희는 리더십이 매 릴리즈마다 현재 가장 중요한 ‘Release philosophy’와 우선적으로 구현해야 하는 기능을 공유해주는데요. 이런 명확한 목표 제시를 통해 제가 지금 무엇에 더 신경 써야 하는지 알 수 있었습니다.

(저희 회사의 꽤나 귀여운 치킨 전략?이에요.)
Release philosophy
🐣 v0 — Barely functioning
🐥 v0.5 — Stable
🐔 v1. — Stable, usable, scalable
🐓 v1.5 — Customer love

알고 나면 두렵지 않다.

프로덕트 디자이너는 디자인만큼이나 인더스트리(도메인)에 대한 이해, 개발에 대한 이해가 필수적이라는 것 또한 배웠습니다. 인더스트리에 대한 지식은 단기간에 습득하기 어렵고 계속해서 변화하기 때문에 꾸준히 관심을 두고 기본기를 익히고 트렌드를 따라가야 한다는 것, 또 유저를 이해하기 위해 알아야할 지식이 있다면 빠르게 공부해서 익히는 것이 낫다는 것을 알았습니다.

저는 데이터 스페셜리스트를 위한 툴을 디자인하고 있었지만 제가 데이터 스페셜리스트가 아니기에 공감하지 못하는 부분이 상당히 많았습니다. 그러던 올해 6월쯤 막연하게 어렵다고 생각만 하던 SQL 강의를 수강했고, 공부하고 나자 유저의 페인포인트에 조금이나마 공감 할 수 있었고, 유저의 입장에서 기능을 되돌아 볼 수 있었습니다.

지금 약간의 시간과 돈을 투자해서 배울 수 있는 게 있다면 고민하기보다는 바로 배우기! 특히 요새는 학습을 위한 좋은 강의와 도구가 많기 때문에, 약간의 시간과 돈을 투자해서 학습해두면 결국엔 그것이 자신의 실력과 무기가 될 수 있다는 것을 알게 되었습니다.

프로덕트를 만든다는 것.

사실 저는 제가 이 세상에 없더라도 사람들이 유용하게 쓰거나 기억할 수 있는 무언가를 만들고 싶다는 생각에서 디자인을 시작했는데요. 최근 문득 제가 만드는 프로덕트가 회사의 비전과 이익을 위해 사용자를 중독시켜야 하는 것이 아니라, 더 잘 만들수록 사용자에게 더 큰 가치를 제공할 수 있는 프로덕트임에 감사함을 느꼈습니다.

개인적으로 제게 큰 영향을 끼친 두 가지 프로덕트가 있는데요.

  • 제가 개인적인 지식을 정리하고 모아두는 패러다임을 바꾼 Notion
  • 제가 디자인 파일을 관리하고 협업하는 패러다임을 바꾼 Figma

매일같이 프로덕트를 사용하고, 생겨나고 사라지는 프로덕트를 지켜보면서 잘 만든 강력한 프로덕트는 사용자의 행동과 습관, 결국엔 사고방식 마저 변화시킬 수 있는 강력한 힘을 가졌다는 것을 배웁니다.

그렇기에 실력만큼 진심 또한 중요하지 않을까 생각합니다. 언제나 우리가 만드는 프로덕트가 사용자에게 어떤 영향을 끼칠 수 있는지 생각하고, 사용자의 삶을 좀 더 나은 방향으로 이끌어 갈 수 있도록 노력해야겠다고 다짐해봅니다.

--

--