이지훈 님은 ZUZU의 탄생부터 지금까지 함께하고 있는 ZUZU의 든든한 기둥이에요. 
지훈 님이 리드하는 ZUZU 프로덕트 디자이너 구성원(이하 ‘PD 구성원’)은 프로덕트의 앞단에서 고객의 불편을 해소하고, 나아가 시장의 비효율성을 혁신하기 위해 고군분투하고 있어요. PD 구성원이 ZUZU에서 어떤 경험을 하며, 어떻게 성장할 수 있는지, 자세히 들어보았어요! 

대학교 3학년 때 인터렉션에 관한 강의를 듣게 되었어요. 처음에는 큰 목표 없이 듣기 시작했는데, 수업도 듣고, 다른 회사들에서 인턴도 하면서 강점이 있다는 생각이 들었습니다. 그림을 못 그리기도 하고, 특별히 디자인 감각이 뛰어난 것도 아니라서 주변에 능력 있는 친구들이 많아서 나는 어떤 차별점을 가질 수 있을지 고민하고 있었는데… 이렇게 답을 찾아낸 것 같아요. 그래서 소모임도 만들고 관련된 쪽으로 계속 공부를 했습니다.(홍대 시디과 소모임 PROTO 많이 사랑해주세요.)

제가 다른 디자이너들이 가져야 하는 기준을 말하는 건 말도 안 된다고 생각해서 개인적인 기준을 말씀드릴게요. 가장 중요하게 생각하는 원칙은 ‘은탄환은 없다.’ 입니다. 디자인부터 일의 방식까지 모두요. (일하는 방식으로는 스크럼 같은 가벼운 프레임워크를 사용하지만 거기에 너무 매달리지 않으려고 노력합니다.) 누가 정한 방식대로만 일해야 한다거나, 반드시 특정 순서로 문제를 해결하는게 좋은 제품을 보장하지 않는다고 생각해요.

좋은 제품은 고객의 문제를 잘 해결해주는 제품이고 고객이 겪는 문제는 계속해서 변하니 우리의 문제 해결 방식들도 계속해서 변해야 해요.

특정 방식에 너무 얽매이지 않고, 진화하는 업계에 맞춰서 우리 자신도 계속 변화해야 하는 거죠. 다양한 디자인 방식을 공격적으로 시도하고 개선해 나가는 것이 중요해요. 이렇게 해야만 더 많은 문제를 효과적으로 해결할 수 있는 디자인 방식을 탐색하고, 제품에 적용할 수 있을 거로 생각해요.

특정 문제를 해결하는 UI 패턴은 매우 많잖아요. 그 중 어떤 것이 최선인지를 판단하는 것이 프로덕트 디자이너의 주요 역할이라고 생각합니다. 그런데 이런 고민 없이 하나의 방법으로만 일하는 방식이 굳어질까 봐 걱정됐어요.

조금 극단적인 예시를 들면, 우리 서비스에서 데이터를 로드하는걸 보여주는 컴포넌트는 스켈레톤을 사용해야 한다. 왜? 이전에도 계속해서 사용해왔기 때문이다. 이런 식으로 생각하지 않으려고 해요. 맥락(문제)에 따라서 새로운 컴포넌트를 만들어야 할 수도 있잖아요.

거창해보이지만 아래 2개가 전부입니다.

1. 디자인 툴을 쓰는 시간을 줄이고, 고객 또는 PD 구성원들과 직접 소통하면서 문제를 정확히 이해하고 있는지 파악하자

2. 동료들에게 디자인 리뷰를 받을 때, 내 디자인의 의도를 설명하지 말자 (최대한 화면만 보고 이해할 수 있게 하자)

아직 그 정도는 아니라고 생각하지만 좋게 평가해주셔서 감사합니다.

고객이 갖고 있는 문제들을 파악하기 위해서 많은 시간을 쏟으려고 합니다. 문제를 해결하려면 그 문제가 어떤 건지 정확히 알아내는게 가장 중요하다고 생각해요. 그 중에서도 특히 문제의 배경을 많이 보려고 해요. 고객이 이런 불편함을 왜 이야기한 것인지, 애초에 우리가 생각하지 못 한 것인지, 아니면 이후에 개선 계획이 있었는지 등등…

최종적으로 이런 문장 형태로 정리하고 구체적인 업무를 진행합니다.

- 이번 패치는 A라는 사용성 문제를 B라는 디자인 패턴을 적용해서 개선을 시도할 것임.

- 성공 여부는 정성, 정량적인 데이터 C를 통해서 확인할 수 있을 것으로 보임.

새로운 사람이 없을 때의 힘듦과 기존 사람이 퇴사했을 때 각각 힘듦의 차이를 비교해 봤을 때, 이미 있던 분들과 함께할 수 없을 때가 훨씬 더 힘들더라고요. 그래서 채용 과정에서 PD 구성원들의 의견을 많이 듣는 것이 중요하다고 생각합니다. easy come & easy go하는 조직이 되고 싶진 않아요. PD 구성원들을 모두 신뢰하기 때문에 이렇게 할 수 있는 것 같습니다. 

포트폴리오의 경우 지원자가 어떤 문제를 어떻게 정리하고 해결했는지, 그리고 자신이 문제를 잘 해결했다고 판단하는 기준이 무엇인지를 주로 봅니다.

면접 단계에서는 서비스에 대한 지식과 디자인에 대한 기본적 이해, 그리고 커뮤니케이션 능력을 중점적으로 살펴봅니다. 만들어 온 서비스에 대한 지식이 얼마나 깊은지, 기본적인 화면 디자인이나 설계에 대한 지식이 얼마나 있는지 등을 중요하게 보는 것 같아요. 커뮤니케이션 능력에 대해서는 이 사람과 함께라면 일이 진척될 것 같다는 생각이 드는지, 논의를 잘 이끌어갈 수 있는지도 눈여겨보고요. 평소에 말이 많은지 적은지는 중요하지 않아요. 저도 말을 안 하는 편이라… (웃음)

마지막으로, 문제 해결 능력도 중요시해요. 특정 프레임워크나 방식에 얽매이지 않고 다양한 방법으로 문제에 접근하고 해결하는 능력, 즉 유연한 사고력을 가진 사람들을 선호합니다. 특히 개발 과정에서 의외로 작은 변화가 큰 차이를 만들어 내는 경우가 많아서, 그런 상황에 잘 대처할 수 있는 사람을 찾는 편입니다.

프로덕트 디자이너가 화면 설계와 CSS 코드로 퍼블리싱하는건 중요해요. 저희가 작업해온 맥락 안에서 최종 결과물에 직접 손을 댈 수 있기 때문이에요. (스타트업이니까 가능하겠지만) 피그마를 최대한 적게 사용하도록 권장하고 있어요. 피그마는 디자인 과정에서 일종의 ‘고백’ 단계라고 보는데요. 그러니까 디자이너와 엔지니어가 종이나 화이트보드에 스케치 해보면서 계속 소통을 하다가 이제 더 이상 변동 없이 진행해도 되겠다는 생각이 들 때 피그마로 비로소 넘어가는 거죠. 썸을 다 타고, 서로 마음이나 생각을 확인하고 마침내 고백했을 때. 상대방이 ‘나도 너랑 똑같은 마음이야’라고 하듯이요.

그래서 디자인 과정에서는 화면을 그리기 전, 후 과정에서 엔지니어나 고객과 대화를 많이 하면서 생각을 나누도록 권장해요. 피그마 없이는 개발을 시작할 수 없는 워터폴(Waterfall) 방식으로 일하는 건 재미없다고 생각해요. 디자인 툴은 디자인의 최종 목적지가 아니라, 디자인을 확정해가는 과정에서 사용하는 도구일 뿐이라고 생각합니다. 그래서 디자인 툴 사용 시간을 줄이고 대신 더 많은 대화를 나누는 것을 선호하고, 필요하다면 CSS 코드 공부를 더 하려고 해요. 이건 최종 결과물을 직접 건드리는 것이니까요. 

화면에 보이는 모든 것들을 다 만든다고 생각하시면 될 것 같아요. 기획과 스케치, 그리고 화면에 시각화되는 과정을 모두 담당하고 있습니다. 이 모든 과정이 분절돼 있으면 안 된다고 생각해요. 

종이, 화이트보드 등 간단한 도구를 많이 쓰도록 권장하고 있고 화면 디자인은 피그마를 사용합니다. 홈페이지를 퍼블리싱할 때는 Hugo라는 정적 웹사이트 생성기를 사용하고 있고, 앱내에 스타일링은 styled-components를 쓰고 있습니다.

사실 더 좋은 게 있으면 언제든 바꿔도 된다는 생각하는 편이에요. 도구 자체가 핵심이 아니라고 생각하거든요.

슬랙을 통해 열심히 정보를 공유하는 걸 추천하고 있어요. 각자 현재 진행 중인 일을 최대한 자주, 그리고 짧게 공유하는 것을 권장하고 있어요. 내 일의 방향성을 동료에게 확인받을 수 있고, 같이 일하는 사람들에게도 내 상황을 알릴 수 있으니까요. 지금 PD 구성원들이 뭘 하는지 일일이 확인하려는게 아니라, 누군가의 일이 진행이 안 되고 있다면 그 원인을 빨리 파악하고 해결해 주기 위해서 이런 방식을 추천해요. 자기 작업을 많이 공유할수록 실력도 빨리 향상할 수 있다고 생각합니다. 

첫 번째, 문제의 이해도를 살피는 거예요. 이슈 제목만 보고 시작했는지, 아니면 관련된 문의들을 전반적으로 확인하고 그 정보를 비즈 부문과 공유하며 문제를 파악했는지 확인하죠. 문제의 맥락과 배경에 대한 이해가 중요하니까요.

두 번째, 적절한 UI 패턴을 사용해 문제를 해결하려고 했는지를 봅니다. UI 패턴이란 특정 문제를 해결하기 위한 이미 검증된 지식을 말하는데, 새로운 문제라도 이미 다른 사람들이 화면을 통해 해결했을 가능성이 높아요. 그래서 해당 문제를 해결하는 여러 UI 패턴의 장단점을 파악하여 그중에 우리 맥락에 맞는 걸 선택했는지, 그 과정이 논리적으로 타당한지를 중점적으로 봅니다.

이 두 가지는 개발에 들어가면 수정하기 어려운 부분이에요. 한 번 배포되면 수정 비용이 많이 늘어나니, 잘 판단해서 만드는지 확인하는 것이 중요해요.

다른 회사 디자인 조직에도 긍정적인 영향을 미치는 디자인 조직이 되고 싶어요. 저는 우리의 일하는 방식이 정말 좋다고 생각하는데, 과연 다른 디자이너들에게도 그럴까? 그냥 수소의 사람들한테만 사람들한테만 좋은 걸까? 하는 궁금증이 있어서요. Scrum 가이드라인처럼 저희도 저희의 일하는 방식을 잘 정리해서, 다른 디자인 조직에도 도움이 될만한 어떤 지침? 같은걸 만들어 보고 싶습니다.