Days of Being Wild

Product Designer (2): 디자인 프로세스 시작과 끝

February 15, 2017

제품을 릴리즈하기 전까지의 디자인 업무 과정에서 디자이너라면 누구나 ‘어떻게’ 일하는지, 즉 프로세스에 대해 많은 관심이 있다. 조금만 검색해봐도 관련 포스트가 수두룩하다. 아이데이션, 브레인스토밍, 와이어프레이밍, 프로토타이핑, 사용자 인터뷰, 퍼소나 등등등 관련 기법과 용어도 다양하다. 툴도 많고 그런 툴을 업으로 하는 스타트업도 많다. 또한, 페이스북이나 아이데오 등 성공한 기업의 디자인 프로세스 역시 자주 소개된다.

나 역시 나름대로 많은 프로세스를 시험해봤다. 하지만 결국 내가 내린 결론은 바로 ‘같은 사무실에 있는 사람’이 가장 중요한 프로세스라는 것이다. ‘사람이 미래다’와 같은 추상적인 이야기가 아니다. 정말로 깨알같이 중요하다. 지난 글에서 언급한 것처럼 스타트업같은 소규모 조직에서는 어떤 시스템보다 구성원의 스타일이 업무에 훨씬 큰 영향을 미친다. 따라서 나와 함께 호흡하는 동료가 없는 프로세스는 허상이다.

CEO에 대해 얼마나 알고 있는가
사내 정치나 개인 신상에 대한 이야기가 아니다. CEO가 회사와 제품에 대해 어떤 생각을 하고 있는지 알아가는 것에서 디자인 프로세스가 시작된다. CEO가 우리 회사와 서비스에 대해 어떤 생각을 하고 있는지, 또한 중간에 어떻게 생각을 바꾸었는지 계속 추적하고 확인해야 한다. 지나가는 말이라도 CEO의 말이면 일을 하는 도중에라도 귀를 기울여야 한다. 때로는 CEO가 자가당착에 빠져있을 때 제대로 된 방향으로 나아갈 수 있도록 조언을 아끼지 말아야한다. CEO가 유튜버이고 그의 채널을 구독한다고 보면 된다. 디자인하는 디자이너가 아니라 CEO의 ‘비즈니스 파트너’로서 관점을 갖는 게, 디자인 프로세스의 시작이다.

개발자에 대해 얼마나 알고 있는가
대략적인 디자인 작업이 끝나면 실제 구현을 위해 개발자와 일하게 된다. 그런데 일하면서 써 온 언어가 다르다 보니 적지 않은 충돌을 겪는다. 그래서 많은 디자이너가 개발자와 협업 프로세스를 개선하기 위해 구글링을 하고, 툴도 써보고, 때로는 코드까지 공부한다. 하지만 외부의 무엇이 우리의 프로세스 내부에 적합할 가능성은 크지 않다. 적합한 프로세스를 찾기 위해서는 먼저 개발자와 업무의 근원에서부터 진지하고 지속적으로 대화를 해야 된다. 실제로 나는 사내 디자인 가이드라인을 만들면서 클라이언트 개발자와 가장 먼저 논의하고, 그들이 원하는 용어나 네이밍부터 디자인 적용 과정에서 겪는 어려움을 해결해줄 수 있는 규칙과 문서를 만들었다. 그리고 서버 개발자와 대화하면서 사용자의 데이터가 DB에 어떤 방식으로 저장되는지 알고 나니, 실제 디자인 과정에서 더 많은 아이디어를 얻을 수 있었고, 데이터를 불러오고 저장하는 UI에서 비효율적인 요소를 개선할 수 있었다. 이렇게 내 옆의 개발자와 시종일관 밀착된 관계를 유지하는 게 중요하다.

또한, 단순히 디자인의 구성이나 스펙을 설명할 게 아니라 페이지마다 내가 디자인하면서 생각한 것: 가장 중요하게 전달하고 싶은 의도, 힘을 주고 싶은 부분, 반대로 가볍게 처리한 부분까지 소상히 설명해야 한다. 그래야 디자이너가 사용자를 생각하고 고려한 관점에서 개발이 진행될 수 있다. 이후의 모든 이견이나 문제들이 그 관점을 벗어나지 않게 되며, 따라서 의견 차이로 인한 꽤 많은 시간낭비를 줄일 수 있다. 때로는 어떤 디자인 아이디어가 과도한 서버나 클라이언트 작업을 요구할 때는 아주 가볍게 포기할 수도 있어야 한다.

마지막으로 중요한 것은 개발자의 캐릭터다. 내가 만난 개발자의 대부분은 다른 직군과 비교해 각자가 굉장히 뚜렷한 고유의 캐릭터를 가지고 있었다. 예를 들어, 어떤 개발자는 항상 정리된 문서를 원하지만, 어떤 개발자는 문서를 싫어하고 단지 트렌디한 협업 툴을 쓰고 싶어 하는 욕구가 강했다. 심지어 어떤 개발자는 단순히 .psd 파일을 원하는 개발자도 있었다. 또한, 어떤 개발자는 페이지 전환 간 인터렉션을 중요하게 생각하는 개발자도 있고, 어떤 개발자는 버튼의 hover 상태에 집착하는 개발자도 있었다. 사소한 부분일지도 모르지만, 나의 사소한 고려가 개발자의 모티베이션에 적지 않은 영향을 준다. 그래서 하나의 협업 프로세스보다는, 각 개발자의 캐릭터에 맞는 개인별 맞춤 프로세스를 만들어가야 한다.

회사에서 내가 개발자와 협업하는 목표는 나의 머릿속에 있는 어떤 디자인 철학의 실현이 아니라, 제품의 빠르고 온전한 구현이다. 그렇다면 디자인이 내 손을 떠나 개발자의 구현 단계로 들어갔을 때부터 개발자가 주도권을 갖게 된다. 각 개발자의 고유한 캐릭터를 이해하고, 함께 제품을 만드는 것이 디자인 프로세스의 마지막이다.