디자인의 드리블화 (원제: The Dribbblisation of Design) - 폴 애덤스

디자인의 드리블화 (원제: The Dribbblisation of Design) - 폴 애덤스

저자: Paul Adams (Head of Product Design at Intercom. Before that Facebook and Google.)

---

위의 날씨 앱들 중 단 한가지만 실제 문제를 해결하려 하고 있다.

최근 프로덕트/인터랙션 디자인 영역에서는 성격이 다른 두 가지 현상이 일어나고 있다. 한편에선 Ryan Singer나 Julie Zhuo 같은 훌륭한 디자이너들의 통찰력 있는 글들이 우리의 디자인을 더 진전시키고 있고, 다른 한편으로는 드리블에 작업을 올리고 이야기 나누는 사람들이 갈수록 늘어나며 우리의 디자인을 후퇴시키고 있다. 이 글은 단지 드리블에 대한 것이 아닌, 드리블 커뮤니티가 어떤것에 더 가치를 두고 있는가에 대한 이야기다. 나는 이 글에서 '프로덕트 디자인'이라는 용어를 주로 사용하겠지만, UX와 인터랙션 디자인을 포괄하는 개념으로 생각하면 된다.

"멋지네요!" - 드리블 커뮤니티가 겉만 번지르르한 작업들을 대하는 법

필자는 지난해 페이스북과 인터콤에서 일하면서 수많은 입사지원서의 프로덕트 디자인 작업들을 검토해보며 한가지 우려스러운 현상을 발견했다. 대다수의 디자이너들이 실제적 비즈니스 문제는 해결하려 하지 않고, 다른 디자이너들의 감탄스러운 반응을 얻어보려 정신이 팔려있다는 것이다. 사실 이것은 오래전부터 광고업계에 존재해온 문제와 비슷한 형태인데 (그들이 클라이언트의 비즈니스를 깊이 이해하려 하기보다는 광고제에서 상을 받는데 혈안이 되있다는것), 이제는 프로덕트/인터랙션 디자인 영역에서 중요한 문제가 되어가고 있다.

근래에 필자가 받았던 입사지원서의 프로덕트 디자인 작업들은 대부분 드리블에 올리려고 만든 껍데기들이었다. 보기엔 이쁘지만 쓸모 없고, 플랫 디자인과 픽셀단위의 완벽함을 추구하지만 실제 비즈니스 목표와 무관하고, 사람들의 일상적 문제를 해결하지도 못하는 그런 작업들 말이다. 드리블이 이런 형태의 커뮤니티가 되어버린데는 컬러 팔레트를 앞세우고 UI의 겉으로 보여지는 부분만 강조하도록 구성된 드리블 자체의 영향도 없지 않다. 본래 매체는 메시지를 변화시킨다. 드리블에서 사람들은 다른 사람들의 작업을 보고, 그냥 따라한다. 드리블에 올라온 상당수의 작업들이 다 비슷하게 생겼다. 소셜 소프트웨어건, 회계 소프트웨어건, 마케팅 사이트건, 날씨 앱이건, 전부 동일한 스타일이 적용되어 있다.

가장 중요한 프로덕트 디자인 작업은 대부분 가장 보기 안좋은 것들이다

반면 지원자들 중 가장 좋았던건 본인의 사고 과정을 보낸 사람들이었다. 스케치, 다이어그램, 장/단점, 실제 문제들, 선택과 해결책들, 인터랙션과 애니메이션을 표현한 프로토타입들, 움직이고 변하는 것들, 그리고 실제 데이터를 사용한 작업들.

최악의 지원자들은 플랫한 PNG이미지 파일들, 와이어프레임으로 가득찬 PDF, 문제가 해결되었는지에 대한 설명도 없고 비즈니스나 기술적 제약들에 대한 설명도 없는, 심지어 문맥조차 없는 작업들을 보낸 사람들이었다. 이런 픽셀단위의 완벽을 추구하고 레티나 해상도에 맞춰진 PNG이미지들은 드리블에선 보기 좋아보일지 몰라도 실제 프로덕트 제작 환경에서 중요한 디자인 절차들의 가치를 떨어뜨린다.

이것이 왜 야후 로고, iOS7, 페이스북, 트위터, 아메리칸 에어라인 등을 다시 디자인 하는것이 어리석은 일인지에 대한 이유이다. 이런 프로젝트에서 사람들은 요구사항, 제한사항, 기업의 규약 등에 대한 지식도 없이, 아무런 문맥도 없는 상태에서 결정을 내려가며 작업한다.

프로덕트 디자인의 목표가 주어진 제약 속에서 문제를 해결하는 것이라면, 자신을 프로덕트/UX 디자이너라고 소개하는 사람들의 상당수가 사실 디지털 아트를 하고 있는 것이다. 그들은 아티스트이고 스타일리스트다. 보기에 아름다운것을 만드는건 물론 중요한 일이지만, 그것은 프로덕트 디자인이 아니다.

프로덕트 디자인은 미션, 비전, 그리고 아키텍처에 관한 것이다

가장 큰 개념에서 부터 픽셀 단위의 디테일까지, 디자이너들은 언제나 그들이 소속된 기업의 미션, 비전, 그리고 프로덕트 아키텍처를 생각해야 한다. 그들이 하는 모든 작업은 모두 이 과정을 거쳐야 한다.

디자인은 회사의 미션에서부터 시작하고, 그리고 나서는 비전을 거쳐간다. 명백하고 실행가능한 미션과 비전 없이 조직 내에서 훌륭한 디자인을 하기란 너무 어려운 일이다. 이것의 중요성을 간과해선 안된다. 만약 당신의 기업이 명백한 미션을 가지고 있지 않다면, 그것을 만드는것 또한 디자이너의 몫이다.

미션과 비전을 거친 이후에는 프로덕트 아키텍처에 대해 생각할 차례다. 여기서 아키텍처는 기술적 아키텍처를 이야기하는것이 아니라, 프로덕트의 각 요소들이 서로 어떻게 연결되어 있는가, 한마디로 시스템에 대한 것이다. 필자가 페이스북에 첫 출근을 했던 날 아침, Chris Cox(프로덕트 부사장)가 회사 전반을 소개해주는 시간이 있었다. 여러 부서의 사람들이 듣는 가운데 그는 다양한 이야기를 하기보다는 페이스북의 프로덕트 아키텍처에 대한 설명과 이것이 어떻게 회사의 미션과 연결되어 있는지에 대해 집중적으로 이야기했다.

페이스북 프로덕트 아키텍처에는 사람들, 그들의 친구들, 그리고 그들의 관심사들로 구성된 디렉토리가 있고, 글로벌 브랜드부터 골목의 작은 상점까지의 비즈니스들을 담은 디렉토리가 있다. 그리고 그 최상단에는 그 모든것들의 관계를 나타내주는 지도가 있다. 이것은 프로덕트에 대한 너무나 명확한 설명이고, 회사의 미션과도 직접적으로 연결되어 있다. 나의 경험상 조직에서 명확하고 잘 정의된 프로덕트 아키텍처 없이 훌륭한 디자인을 하기란 너무 힘들다. 그리고 많은 경우에서 회사의 미션과 마찬가지로 이 아케틱처를 발전시키는것 역시 디자이너가 해야 할 일이다. 나는 외부 파트너들에게 페이스북을 설명할 때 아래와 같은 다이어그램을 화이트보드에 그리곤 했다.

프로덕트 아키텍처는 인포메이션 아키텍처가 아니다. 이것은 페이지들이 어떻게 연결되고, 버튼이 어떤기능을 하는지를 설명하는 프로토타입의 역할을 대신하지 않는다. 이것은 그보다 한단계 더 깊은, 구조에 대한 것이다. 이것은 시스템 내의 객체들이 서로 어떤 관계를 갖고 있는지를 보여준다. 인터콤에서도 역시 프로덕트 아키텍처의 문맥 상에서 디자인에 대해 생각하곤 한다:

난 드리블에서 이와같은 프로덕트 아키텍처에 대한 설명을 본 기억이 없다. 아직도 디자이너들을 만나 그들의 작업이 어떻게 미션, 비전과 연결되어 있고, 프로덕트 아키텍처 상에서 어떤 지점에 위치하는것이 적절한지 등에 대해 논하는것은 정말로 이례적인 일이다. 이것이 흔한 대화가 되어야 한다.

명확한 미션, 비전, 그리고 프로덕트 아키텍처를 확립하고 나면, 그 후엔 다른 디테일한 부분들에 대해 생각할 수 있다. 사람들의 목적, 어떤것이 그들을 행복하게 하고 성취감을 느끼게 하는지 등에 대한 부분들 말이다.

지저분한 스케치와 글씨로 이런것들을 설명하는 과정들이 드리블에 올리는 PNG파일보다 훨씬 더 중요하다. 프로세스의 시작부터 유저가 사용할 프로덕트가 되기까지, 프토샵 파일들이나 PNG파일들은 나에게는 가장 중요하지 않고 관심없는 부분들이다. 훨씬 더 중요한 것은 의사결정을 내리고, 장단점을 논하고, 기업의 비전을 위한 아이디어를 도출하고 프로덕트 아키텍처를 기반으로 이들을 발전시키기 위한 다양한 논의들이다. 화이트보드 스케치, 핸드 드로잉, 냅킨에 그려낸 문제 해결방안, 이런것들이 모두 드리블에 올라와야 한다. 그런것들을 보여달라. 심지어 어떤것을 만들것인지 글로 쓴 설명이 PNG나 PDF보다 더 중요하다.

디자인을 구성하는 4개의 레이어

디자인 프로세스는 여러 단계의 레이어로 구성되어 있다. 이 레이어들의 최적의 배열에 대해 가장 단순히 논하는 방법은 아래 4개의 레이어에 대해 생각해보는 것일 것이다.

나는 네 번째 레이어(Visual)에만 집중하고 나머지 레이어들은 크게 신경쓰지 않는 디자이너들을 수도없이 보아왔다. 그들은 위에서부터 아래로 작업하는것이 아닌 그 반대로 한다. 만약 Visual을 제외한 다른 레이어들이 해결되지 않았다면 그리드, 폰트, 컬러, 미적 스타일 등은 아무 소용이 없다. 많은 디자이너들이 스스로 위와 같은 절차로 작업하고 있다고 이야기하지만 실제로 보여주는 경우는 드물다. 왜냐하면 사실 멋진 그림을 그리거나 픽셀에 파묻혀있는것이 복잡한 비즈니스 의사결정이나 각기 다른 의견을 가진 사람들을 대하는것보다 더 재미있기 때문이다. 괜찮다, 그대로 Visual 레이어에 머물러라. 하지만 그건 아트이지 디자인은 아니다. 당신은 디지털 아티스트이지 디자이너가 아니다.

웹이 점점 더 많은 영역에 침투함에 따라 시스템을 디자인하는 일은 더 중요해질 것이다.

웹의 탄생은 산업혁명 이후 가장 큰 변화를 가져올 것이다. 웹은 모든곳에 존재한다. 우리의 가정에, 직장에, 우리가 자는 침대 머리맡에, 그리고 우리의 주머니속에 언제나 존재한다. 웹은 이미 우리가 타는 자동차, 우리가 입는 옷, 우리의 건강을 관리하는 과정에도 스며들고 있다. 늦어도 2020년이면 모든 비즈니스는 웹 비즈니스가 될것이다. Charles Eames가 했던 '결국 모든것은 연결된다' 는 말처럼 말이다.

고정된 웹페이지를 디자인하는 직업은 사라져가고 있다. 모바일 기술, API, SDK, 플랫폼과 프로덕트 간의 오픈 파트너십 등의 놀라운 성장은 우리가 시스템들을 디자인하게 될 미래를 명확하게 보여준다. 와이어프레임으로 가득찬 PDF는 더이상 가치가 없으며, 포토샵의 중요도는 점점 떨어지고 있다. 통찰력있는 디자이너들은 이미 스케치, 화이트보드 그리고 프로토타이핑 툴들(Quartz Composer, After Effects, Keynote, CSS/HTML)로 옮겨가고 있다.

사람들이 디자이너도 코딩을 해야 한다고 주장하는것에 대한 이유가 이것이다. 당신이 이것에 대해 동의하든 하지않든, 디자이너들은 결국 픽셀을 통해 문제와 해결책을 표현해야 하는 것이 아니라, 시스템을 구성하는 요소들간의 관계를 설명해야 하는 상황이 올것이다. 그러니 프로토타입을 만들고, 코딩을 시작하고, 실제 데이터가 보여주는 간과되고 예측할수 없었던 디테일한 부분들에 대해 신경써라. 실제 데이터들을 기반으로 인터랙션 디자인 작업을 하는것은 당신으로 하여금 그것이 어떻게 느껴지는지 더 잘 이해할수 있도록 해줄 것이다.

우리는 Job을 중심으로 디자인한다 (We're designing around Jobs)

인터콤에서는 Clay Christensen의 Jobs framework를 기반으로 프로덕트 디자인 작업을 진행한다. 우리는 모든 디자인 문제를 Job으로 규정하고, 프로세스를 개시하는 사건이나 상황, 동기와 목적, 그리고 원하는 결과등에 촛점을 맞춘다:

_____ 할 때, 나는 _____ 할 수 있도록 _____ 하길 원한다.

예: 중요한 새 고객이 가입했을 때, 나는 그들과 대화를 시작할 수 있도록, 통보 받기를 원한다.

이 방법은 명료하다. 우리는 이 Job을 미션을 통해 다듬고 적절한 우선순위를 부여할 수 있다. 이 방법은 우리가 계속해서 4개의 레이어를 모두 고려하도록 유지해준다. 이를 통해 우리는 우리 시스템중 어떤 부분이 이 Job의 일부인지, 그리고 이것을 가능하게 하기위해 어떤 관계와 인터랙션이 필요한지 볼 수 있으며, 4개의 레이어 중 위에서부터 아래의 순서로 디자인 작업을 진행할 수 있다.

이 외에도 우리는 디자인 작업을 위해 시스템 지향 환경을 반영한 패턴 라이브러리를 만들어가고 있다. 시간이 갈수록 우리는 포토샵보다 라이브러리의 코드를 이용해 디자인하는 일이 늘어날 것이다. 이것은 완벽한 프로세스는 아니지만 우리는 지속적으로 반복해가고 있다.

추가 내용

어떤 사람들은 내가 비주얼 디자인과 UX 디자인을 동일시 하고있다고 이야기 한다. 나는 그것에 동의하지 않는다. 인터랙티브 프로덕트를 디자인함에 있어서 인터랙션과 시스템 디자인을 고려하지 않고 비주얼 디자인을 논할수 없다. 이것은 그래픽 디자인이 아니다. 우리는 포스터나 도로 간판을 디자인하고 있는것이 아니다.

---

원문: http://insideintercom.io/the-dribbblisation-of-design/

Published by Jun on October 3rd, 2013