디자이너를 채용하기 전에 이 사람이 일을 효과적으로 할 수 있는 업무 환경을 조성하라. 어떤 직원이든 작업 도구나 권한이 없어서 성공하기 어려운 업무 환경으로 영입하는 것은 그들에게 부당하다. 그리고 당신은 어렵게 번 돈을 크게 낭비하는 셈이다. 게다가 새로운 사람과 어떻게 지내야 할지를 모르는 다른 직원들은 부담만 갖게 된다.
 

 
이 이야기의 교훈은 당신의 업무 환경으로 디자이너를 데려오기만 해서는 그들이 성공하길 기대할 수 없다는 것이다. 당신의 기대를 명확하게 계획해야 하고, 당신이 기대한 바를 디자이너가 할 수 있도록 무대를 만들어줘야 한다.
 
* 호더쇼: 호더란 물건을 버리지 못하고 모으는 일종의 강박장애를 겪는 사람이며, 호더쇼는 낡고 필요 없는 물건이나 쓰레기를 집 안에 쌓아두는 행동을 반복하는 사람의 집을 치워주는 미국 TV쇼다.
 

제 1계명: 직장에 새로운 규율 도입하기

직원 중에 디자이너가 없다고 생각해보자. 직원들은 저마다 맡은 일을 잘 수행해왔다. 자, 이제 당신이 디자이너를 새로 영입한다. 직원들이 디자이너를 고용하자고 그렇게 노래를 불러놓고도, 정작 디자이너가 들어오면 갈등이 생긴다. 인간은 익숙하고 편안한 것의 노예니까. 그들은 디자이너가 없어서 일하기 어렵다고 불평하더니 디자이너를 구해도 어떤 일에 대한 자신들의 권한을 포기해야 하므로 여전히 불평한다. 쉽지 않다. 다른 사람의 일까지 떠맡아 해야 한다는 불만은 이제 그 일을 다른 사람에게 줘야 한다는 불만으로 바뀐다. 인간이란 존재가 참 놀랍지 않은가.

디자이너는 회사가 만들어내는 결과물을 분명히 바꾸고, 회사의 운영 방식에도 영향을 끼친다. 디자이너가 들어오면 당신은 업무 흐름을 새로운 사람에게 맞춰야 하고, 그들이 업무 흐름에 적응하도록 여지를 줘야 한다.

어떤 사람을 구성원 속으로 밀어 넣기 전에 모든 직원을 앉혀 놓고 왜 디자이너를 채용하는지, 회사에 어떻게 이익이 되는지, 디자이너의 책임과 역할이 무엇인지 설명하라. 전 직원의 일이 좀 더 수월해지려면 (칼퇴근이 가능해지려면!) 디자이너의 역량이 어떻게 회사에 더해져야 하는지를 설명하라. 오랫동안 디자이너가 없이 일해준 직원들에게 고마움을 표하라. 새로운 디자이너 덕분에 그들이 더 이상 떠맡을 필요가 없게 된 일들에 대해 이야기해줘라. 더불어 새로운 디자이너가 팀에 합류할 때 문제들이 생길 수도 있다고 말해줘라.

그러고 나서 그 문제들이 발생했을 때는 디자이너를 도와줘라.

당신의 디자이너는 맨 윗사람의 도움 없이 일을 기똥차게 잘할 수 없다. 그들의 업무가 제품이 작동하는 방법과 사람들이 서로 소통하고 일하는 방식을 바꾼다면 (모든 디자인이 그렇듯), 여러 사람을 짜증이 나게 할 것이다. 동료가 당신의 사무실로 달려와서 “디자이너가 죄다 바꾸고 있어요!”라고 말하면 “바로 그런 일을 하라고 내가 디자이너에게 월급을 주는 겁니다.”라고 콕 찍어 말해줘라. 명심하라. 디자이너는 자신의 이익만을 위해서 그 자리에 있는 게 아니다. 그들은 당신을 대변한다.

디자이너를 영입하는 일이 어려울 수 있다. 그래도 형편없는 디자이너가 이미 자리 잡고 있는 직장으로 디자이너를 영입하는 일보다 훨씬 쉽다. 산업 현장에서 흔히 일어나는 일화를 하나 소개하겠다. 한번은 동료들이 내 자리로 오더니 자신들의 바자회에 사용할 홍보 표지판을 만들어 달라고 요청했다. 그건 내 일이 아니라고 알려줬더니, 그들은 이전에 함께 일했던 디자이너는 그런 일도 항상 했다고 대답했다. 나는 그들에게 이전 디자이너는 마감일을 제대로 지키지 못해 잘렸다는 점을 상기시켜줬다. 그제야 더 이상 부탁하지 않았다. 내가 그들의 요청을 흔쾌히 들어 줬다면 디자이너는 동료들의 바자회 표지판이나 만드는 사람이라는 이미지가 완전히 박혔을 수도 있다.
새로운 디자이너가 일을 시작하기 전에 이런 헛소리들은 깔끔히 정리해줘라. 이 메시지는 당신의 입으로 전하는 게 훨씬 쉽다. 새로운 사람에게 이 일을 떠넘기지 마라.
 

제 2계명: 디자이너가 책임지는 업무 파악하기

‘디자이너는 디자인을 책임진다’는 말은 당연한 소리처럼 들릴 것이다. 그렇지 않은가? 여기서 말하는 디자인이란, 보이는 방법뿐 아니라 문제를 푸는 해결책을 나타내기도 한다. 대기업에서 근무하던 그 젊고 훌륭한 디자이너가 기억나는가? 그는 전략 회의에 참석하지 못했다. 그에게 작업이 주어졌을 즈음에는 아주 사소한 세부 사항까지도 다 정해져 있었고 그는 그저 실행에 옮겨야 했다. 그는 디자인을 한 것이 아니다. 다른 누군가의 디자인을 그대로 실행에 옮겼을 뿐이다.

사실 그는 단호하게 자기주장을 해야 했다. 하지만 이 글에서는 당신이 주인공이다. 디자인은 문제에 대한 해결책이고, 당신은 이를 다루는 전문가에게 돈을 준다. 정의에 따라 풀어보자면, 디자이너는 그 문제들을 해결하는 고유한 자격을 갖춘 사람들이다. 그들은 당신이 생각하지 못한 해결책을 제시하도록 교육을 받았다. 당신의 디자이너는 전략 회의에 참여하고 싶어 안달이 났을 것이다.

디자이너가 자신의 역량을 최대한 발휘하도록 만들어라. 그들을 전략 회의에 참여시켜라. 그들이 그저 주어진 해결책을 실행에 옮기는 일만 하는 것이 아니라 문제 해결에 직접 관여할 수 있도록 만들어라. 무엇보다도 그들이 이것을 업무 일부분으로 여길 수 있도록 해야 한다. 만약 그렇지 않다면, 당신의 디자인은 디자이너가 아닌 일반 사람들이 생각해낸 수준과 별로 다를 게 없다.
 

제 3계명: 디자이너에게 필요한 공간과 권한 제공하기

사무장, 회계사, 개발자가 가진 권한이 아주 명확한 것처럼 당신의 회사도 디자이너가 어떤 권한을 가졌는지를 제대로 이해해야 한다. 그렇다면 이제 권한의 개념을 “그들이 소유한 것들”로 확장해서 이야기해보자. 경리가 회계 장부를 갖고 있고, 개발자는 코드를 마음대로 하는 것과 마찬가지다. (그렇다. 나는 당신이 그 모든 기술을 갖추고 있다는 사실을 알고 있다. 그러니 여기서 나와 함께 일하자)

디자이너를 전적으로 신뢰하라. 만드는 데에 가장 적격인 그들에게 결정할 수 있는 권한을 줘라. 디자이너를 회사로 영입하기 전에, 업무 흐름이나 결과물 일부분을 넘어 그들에게 어떤 권한을 줄지를 결정하라. 그들이 사용자 인터페이스에 대한 최종 결정권을 갖고 있는가? 다른 이해 당사자들에게 조언을 구해야 하는가? (언제나 좋은 생각이다) 모든 이해 당사자들로부터 승인을 받아야 하는가? (늘 그렇듯 정치판처럼 지저분한 상황이 연출된다. 진짜다)

정답은 당신이 운영하는 조직의 유형과 디자이너의 역량에 따라 달라진다. 하지만 어떤 결정을 내려야 하든지 간에, 디자이너에게 권한을 최대한 줘서 그들의 업무를 잘 완수할 수 있도록 해줘라. 아무도 회계사의 업무 방식에 대해 왈가왈부하지 않는다. 하지만 디자이너가 업무를 어떻게 해야 하는지를 참견하는 회사 100군데는 가봤다.

줏대 있고 경험 많은 디자이너는 자신이 맡아야 하는 자리를 개척하는 데에 아무 문제가 없을 것이다. 하지만 당신이 그들에게 권한을 주지 않으면, 그들도 그렇게 할 수 없다. 그렇지 않으면, 당신은 주변 사람들의 변덕에 따라서 움직이는 사람을 데려오는 위험을 감수해야 한다. 그런 사람은 팀의 정식 일원이 되지 못한다. 그저 회사의 다른 직원들이 픽셀을 그려 넣어야 할 때마다 사용하는 복사 기계에 지나지 않는다.
이런 식으로 웹 사이트의 사용자 인터페이스 작업을 하려던 사람이 결국 ‘베티가 잃어버린 고양이를 찾습니다.’와 같은 홍보 전단지나 만드는 신세로 전락하고 만다.
 

제 4계명: 디자이너에게 필요한 작업 도구 갖추기

이러니저러니 말할 것 없이, 한번은 직장에서 회사가 불필요한 소프트웨어라고 여겼던 포토샵과 BBEdit 복제품을 얻기 위해서 엄격한 신청 절차를 거치며 첫 2주를 다 써 버린 적이 있었다. IT 업계 출신의 누군가가 1시간 동안 나에게 포토샵으로 작업해야 하는 일을 죄다 파워포인트로도 할 수 있는 방법을 설명해줬다. (나는 그를 말렸어야 했지만, 어느 순간 짜증이 누그러지면서 그가 얼마나 신중하게 이런 생각을 해냈을까 싶어서 흥미가 생겼다)

여느 장인처럼 디자이너 역시 자신들의 작업 도구와 한몸이나 마찬가지다. 그들이 필요한 작업 도구를 갖추고 있는지를 반드시 확인하라. 그들이 제대로 사용하는지를 알아보기 위해서 물어보는 건 당연하다. 그렇다고 모든 작업 도구의 기능을 전부 알 필요까지는 없다. 그냥 디자이너가 하는 대로 믿어줘라.
 

제 5계명: 성공 여부 가늠하기

디자이너를 위해서 당신의 팀은 얼마나 잘 준비되어 있는가? 디자이너는 사람들과 얼마나 잘 어울리고 있는가? 만약 디자이너가 목적을 달성하지 못하면 그들은 아무 일도 아닌 듯이 얼마나 전문가처럼 행동하는가? 어떤 직원이든 회사로 영입하기 전에 당신은 그들의 성공을 가늠할 방법을 알아야 한다. 계산하기 어려운가? 당신은 웹 사이트에서의 판매나 전환이 일정하게 증가하길 기대하는가? 앞으로 다가올 큰 프로젝트를 시간과 예산에 맞춰 제공하는 것이 목표인가?

당신의 비즈니스는 다양성이 필요하다. 그래서 나는 성공하는 디자인에 관한 기가 막힌 해답을 줄 수가 없다. 하지만 나는 이렇게 말할 수 있다. 당신의 성공 비법이 무엇이든 간에 디자이너는 그 비법을 알아야 하고, 이를 달성할 수 있는 권한도 반드시 가져야 한다고 말이다.

어쨌든 당신에게 들려줄 이야기가 있다. 한번은 고용 계약을 한 적이 있는데, 출근 첫날에 크리에이티브 디렉터가 나를 앉혀 놓고 자신이 나에게서 기대하는 바가 무엇인지, 내가 스튜디오의 다른 직원들과 얼마나 잘 맞을지 모르겠다고 말했다. (자기 자신도 정리가 안 된 것이다) 계약 기간이 끝날 즈음에, 그는 나와 계속 일을 할지 말지를 평가해야 했다. 그때 나는 어리고 멍청했다. 그래서인지 단호하게 밀고 나가지 못했고 가능하면 분위기에 잘 맞추자고 마음먹었다. (신입들이 으레 하는 실수다) 계약이 끝나자, 크리에이티브 디렉터가 나를 자신의 사무실로 불렀다. 그리고 그들이 기대한 만큼 내가 성과를 올리지 못했다고 말했다. 말도 안 되는 소리였다. 왜냐하면 양쪽 다 어떤 기대를 하고 있었는지 몰랐으니까. 기분이 정말 더러웠다. 내가 무엇을 더 잘할 수 있었을지도 궁금했다. 그리고 솔직히 말해, 크리에이티브 디렉터도 기분 별로였다고 확신한다. 성공에 대한 기대를 제대로 정하지 않았다는 사실을 깨달았을 테니까.

그러니까, 그렇게 행동하지 마라. 당신을 위해서 일하는 사람이 누구든지 간에, 그들이 일을 잘하지 못한다는 사실에 절대 놀라지 마라. 잘한다고 해도 마찬가지다. 그들이 성공하기 위해서 무엇을 해야 하는지를 알려줘라. 그들이 잘하고 있다고 알려줘라. 만약 그들이 잘하지 못한다면 그들이 방향을 잘 잡도록 도와줘라. 그리고 마지막으로 그들이 성과를 냈다 싶으면 바로 알려줘라.
 

직무 기술서를 만들고 디자이너를 찾아보자!

디자이너를 영입하기 전에 무엇보다도 중요한 준비사항은 그들의 참여로 회사나 조직에 얼마나 이익이 될지를 파악하는 것이다. 그들을 영입하면, 당신은 무엇을 할 수 있는가? 몇 년 후 당신의 모습을 설계해봐라. 무엇을 달성하고 싶은가? 그 목표들을 적어라. 당신이 적은 내용은 직무기술서의 기본이 된다.

디자이너가 했으면 하는 일을 목록으로 만들어라. 그들이 가지고 있어야 할 기술이 아니라 그러한 기술들로 어떤 작업들을 하고 싶은지를 작성하라. 당신에게 필요한 것이 브랜딩인가? 인터페이스 디자인인가? 일러스트레이션인가? 아니면, 구성인가? 어떤 사업을 진행하고 있는가? 편집인가? 당신은 카탈로그 디자인이 필요한 소매상인가? 모바일 환경에 대응해야 한다는 점도 잊지 마라. 단언컨대, 당신은 모바일 환경에도 대응해야 한다. (어제 이후로 좋은 시절은 다 지나갔다)

이 훈련의 결과는 다음과 같을 것이다. “우리는 모바일 경험이 있는 디자이너가 필요합니다. 물론 복잡한 데이터에 관한 브랜딩과 인터페이스 디자인도 할 줄 알아야 합니다.” 이제 더 이상 이런 목록은 작성하지 마라. 디자이너한테 돈만 더 많이 줘야 한다. 그리고 이 훈련을 통해 당신은 디자이너가 한 명 이상 필요하다는 사실을 깨닫게 된다. 일러스트가 가능하고 반응형 웹 사이트를 만들 수 있으며 애자일 작업 방식을 선호하는 유능한 디자이너는 외계인이다.
자. 이제 디자이너를 한 번 찾아보자!

디자인 – “사람들이 원하는 것은 자기 애완견 사진을 메일로 보내고 싶을 뿐이다.”

개발자를 위한 디자인 입문서

디자인은 한 회사의 운명을 완전히 바꿔 놓을 수도 있지만, 그것이 무엇인지 보편적으로 수용할 수 있는 정의는 아직 없다. 이 말이 무슨 뜻이냐 하면, 당신의 상사가 팀원들을 모두 모아 놓고 “앞으로 우리 회사는 디자인 중심의 문화를 지향하게 될 것입니다”라고 하는 말이 공언에 불과하게 될 수 있다는 뜻이다.

하지만 당신은 그 말에 귀를 기울이고 있다. 단지 듣기만 하는 것이 아니라, 그 말 이면에 있는 절실함마저 느끼고 있다. 들어보니까 무엇인가를 디자인하기 위한 선택은 매우 중요한 일인 것 같고, 그 이야기를 하는 사람도 중요한 인물이고 해서, 당신은 심하게 고개를 끄덕이고 있다. 하지만 마음 속으로는 “나는 당신이 무슨 소리를 지껄이는지 전혀 모르겠는데 아마 당신도 마찬가지일 거야”라고 생각할 것이다.

디자인에 초점을 맞추는 것이 마법처럼 한 회사를 변화시킬 수 있다는 데는 이론의 여지가 없다. 이를 위해 디자인 팀과 개발 팀이 회식이라도 자주 해야겠지만, 디자이너와 개발자 사이에는 근본적인 긴장이 존재하므로 이 긴장을 이해하는 것이야말로 디자인을 생각하는 좋은 출발점이 될 것이다.

디자이너와 개발자 – 긴장관계

디자이너와 개발자의 뿌리 깊은 긴장 관계를 제대로 이해하기 위해서는 소프트웨어가 시장의 주류가 된 시점으로 거슬러 올라가야 한다. 개인적인 생각이지만 그것은 아마도 인터넷이 막 등장했을 무렵일 것이다. 사실 소프트웨어는 넷스케이프(Netscape)가 등장하기 오래 전부터 엄청난 부가가치를 창출하고 있었다. 하지만 누구든 어디든 자기 애완견 사진을 메일로 보낼 수 있게 된 바로 그 순간, 진정한 의미의 소프트웨어 세상이 되었다고 말할 수 있다.

‘누구나’(그들의 애완견도 포함하여)의 시대가 도래하자 초기 소프트웨어 개발팀에게 과제가 주어졌다. 그전까지 그들은 누구나가 아닌 얼리어답터와 함께 얼리어답터 특유의 요구에 맞추어 작업했었다. 얼리어답터들은 다음과 같은 생각으로 수많은 크랩(crap, 엉터리)을 기꺼이 참아 주었다. “얼리어답터는 최신 제품, 최고 제품을 제일 먼저 다룰 수 있지만 그 제품은 한순간에 익스플로전(explosion, 프로그램의 작동이 멈추는 것; 편집자 주)될 수도 있다.” 작동하던 프로그램이 순간 멈춰도 얼리어답터들은 괜찮다고 생각한다. 왜냐하면 그들은 얼리어답터가 된다는 것 자체를 멋있다고 생각하기 때문이다.

하지만 ‘누구나’의 시대가 도래했을 때, 그 모든 ‘누구나’는 익스플로전을 원치 않았다. 소비자들은 제품이 정상적으로 작동되기를 원했다. 여기에서 “정상적으로 작동한다”라는 말을 개발자들은 “(프로그램이) 덜 멈추기를 바란다”라는 말로 들었는지 모르지만, 이것은 ‘누구나’가 원하는 바는 아니다. 소비자들이 원하는 것은 가능한 한 가장 간단한 방법으로 자기 애완견 사진을 보내는 것이다. 그들은 자바스크립트, 보안, 프레임, 플러그인 같은 것은 신경도 쓰지 않는다. 단지 그놈의 ‘강아지’ 사진을 보낼 때 어플리케이션(application, 응용 프로그램)이 멈추지 않기를 바랄 뿐이다.

“덜 익스플로전 되기를 바란다”는 개발자들의 생각과 “클릭 한 번으로 정확하게 애완견 사진을 보내고 싶다”는 사용자들의 생각 사이에서 디자인은 실질적인 연결다리 역할을 한다. 그런 점에서 좋은 디자인은 개발자들의 노력을 선보이는 동시에 그것을 사용자들에게 보이지 않게 숨기는 것과 같다.

여러 디자이너들과 함께 작업하는 동안 디자인의 역할에 대해 생각해 보았다.
내 개인적인 생각은 다음과 같다.

대부분의 사용자들이 무엇을 원하는지 이해한다.
그 중에 가장 중요한 것에 우선순위를 두고 집중한다.
이러한 지식을 이용해 사용자의 기대를 뛰어넘는다.

90년대 중반 무렵의 전통적인 개발자들은 이러한 역할을 제대로 하지 못했다. 우리는 비트의 설계자가 되도록 훈련받았으며, 우리가 비트를 설계할 수 있다는 것은 곧 쓸모 있는 비트를 만들 수 있다고 믿었다. 하지만 우리가 잘하는 것은 우리 자신에게 좋은 제품을 설계하는 것뿐이다. 그것은 결코 모든 이들을 위한 것이 아니다.

개발자들은 마치 스스로 프로그램 개발 과정을 잘 알고 있기 때문에 그것의 문제점을 중요하게 생각하지 않는 것처럼, 어플리케이션이 순간 멈추는 것을 아무렇지 않게 생각한다. 어떤 프로그램에 오류가 나면 그냥 어플리케이션을 다시 시작하면 된다고 생각하는 것이다. 그러나 대부분의 사용자들은 오류가 난 어플리케이션을 그런 식으로 보지 않는다. 그들은 뭔가 오류가 나면 깜짝 놀란다. 그리고 이렇게 생각한다. “혹시 심각한 고장이 난 것은 아닐까”

디자이너와 개발자를 위한 메모

수없이 많은 디자이너 무리에게는 미안한 말이지만 이 입문서는 주로 소프트웨어 개발자 주변에 사는 디자이너와 그들의 관행에 초점을 맞추고 있다. 이 책은 개발자들을 위해 개발자가 쓴 책이다. 나는 오랜 세월 동안 디자인계에 몸담고 있었지만 전문 디자이너로 훈련된 사람이 아니며 디자인의 역사와 기능에 대한 설명 또한 단순하고 부정확하며 불완전하게 하는데다가 개발자로서 편견까지 가지고 있어 디자이너들이 이 글을 보면 화가 날 수도 있을 것이다.

우리 개발자들이 하는 말의 의도가 아무리 좋더라도 디자인의 필수 항목을 제대로 경험한 적이 없기 때문에 그것에 대해서는 무지하다. 또 어떻게든 설명할 수 있는 일이라면 그 일을 할 수도 있을 것이라고 믿는데, 그것이 얼마나 어리석은 생각인지도 잘 알고 있다. 하지만 어떤 분야에서든 열의를 갖고 일을 하는 전문가들은 이렇게 늘 생각하는 것 같다.

개발자들은 무지를 불편해 하지만 그보다 더 심각한 문제는 우리 전문 영역 밖에 있는 이들에게 도움을 요청하는 일에 익숙하지 않다는 것이다. 이 입문서는 우리 디자이너와 개발자 사이에 단단한 다리를 놓는 첫 번째 단계가 될 것이다. 그러므로 기분 나쁘게 생각하지 말자. 이 입문서는 가장 권위 있는 디자인 가이드가 아니라 개발자들이 디자인에 대해 생각해 볼 수 있는 전환점이 될 것이다. 우리가 생각하는 바에 대해 독자가 어쩌다 무엇이라도 배우게 된다면 더욱 다행스러운 일이라고 생각한다.

다음의 세가지 축약어(Acronyms)가 문제점의 발단

“우리에게는 디자이너가 필요하다”라는 말은 아마 당신이 신입 소프트웨어 개발자로서 디자인에 대해 처음 들어본 말일 것이다. 그때 당신은 의아해 했을 것이다. ”음, 나는 아직 일을 시작하지도 않았는데 왜 그들이 필요하다는 걸까” 그에 대한 대답은 결코 간단하지 않고 이 글의 범위 밖에 있지만 다음의 세 가지 주요 축약어부터 설명하고자 한다.

다른 직업과 마찬가지로 디자인도 온갖 줄여서 쓴 단어들로 가득하다. 하지만 여기서는 당신의 상사가 디자인이 중요하다고 강조한 바로 그 시점에 자주 언급되었을 만한 세 가지 축약어에 집중할 것이다.

#1 GD(Graphic Design, 그래픽 디자인)

그래픽 디자이너들은 세상을 이렇게 본다.
(그래픽 디자이너들은 아래 그림처럼 ‘픽셀’ 단위로 바라본다는 의미임 : 편집자주)

안타깝게도 그래픽 디자이너를 설명하는 데 가장 흔히 쓰이는 말은 혼란스럽게도 바로 ‘디자이너’이다. 그 이유는 두 가지다. 첫째, 그는 개발 부문 외에 있는 기술을 가지고 이 제품을 완성하도록 고용된 최초의 인력이다. 둘째, 그는 ‘아름다움’을 책임지고 있다. 작업 책임자가 제품의 최초 프로토타입을 보고 이렇게 말할 것이다. “이건 개발자가 대충 만들어 놓은 것 같은데…” (당신은 고개를 끄덕인다) 그리고 “이걸 고쳐 놓을 디자이너가 필요해!” (당신의 눈길은 공허해진다)

당신: 뭘 고쳐요?
책임자: 글쎄… 뭐랄까… 좀 더 아름다워야 하지 않을까.

아직도 이 블로그에서 빠져나가지 않은 디자이너가 있다면, 아마 지금 의자 위에 올라가 스크린 앞에서 소리를 지르고 있을 것이다: “난 그런 사람 알아!”

그렇다, 나도 그런 사람을 알고 있다. 그는 좋은 의도를 가지고 있겠지만 멍청이다.

그래픽 디자이너의 장기는 시각적인 것에 있다. 포토샵이나 일러스트레이터 같은 어플리케이션을 통해 그래픽 디자이너는 추상적인 생각에 시각적인 형태를 부여한다. 그렇다. 그들이 하는 작업은 아름답다. 하지만 단지 아름답기만 한 것은 아니다. 그것은 말을 한다. 무엇인가에 대한 의견을 가지고 있어서 그것을 보는 사람이라면 누구라도 그 의견을 알 수 있다. 그렇다. 디자이너는 당신의 어플리케이션이나 웹 사이트에 어떤 명확하고 믿을 만한 전문성을 부여한다. 그렇지만 어떤 것을 잘 그려 놓았다고 해서 꼭 그 제품을 더 사용하기 쉽게 만들어 주는 것은 아니다.

문제는 작업 책임자가 그래픽 디자이너의 사무실로 들어가서 이렇게 말할 때 시작된다. “당신은 디자이너잖아. 이 제품에서 개발자 냄새를 지우게 도와줄 수 있나?” 이제, 당신처럼 이 그래픽 디자이너도 뭔가 더 하고 싶어한다. 더 많은 책임을 지려고 한다. 그리하여 그 제품이 어떻게 작동하는지, 사용자가 누구인지도 모르면서 그들은 이렇게 생각하며 그 일을 하겠다고 나선다. ‘그럼, 난 디자이너잖아. 그렇지?’

그렇게 해서 디자이너들이 작업을 맡게 된다. 그들은 포토샵으로 눈에 보기 좋은 프로토타입을 만든다. 이 그래픽 디자이너는 대부분의 개발자들이 할 수 없는 일을 했고 중요한 디자인 작업을 진행했지만 엄청나게 새로운 디자인을 한 것은 아니다. 당신의 제품은 단순히 아름다운 얼굴을 가지게 되었을 뿐이다. 제품이 어떻게 보이느냐가 중요한 만큼 어떻게 작동하는가도 똑같이 중요하니까 말이다.

이 입문서의 각 파트 끝에는 내 디자인 철학을 형성하는 데 도움을 준 디자인 관련 서적을 세 권씩 소개할 것이다. 디자인의 본질에 대해 궁금하면 참고 문헌을 보길 바란다.

#2-IxD(Interaction design, 인터렉션 디자인)

IxD는 세상을 이렇게 본다.

인터렉션 디자이너는 놀라운 일을 한다. 그들은 형태로부터 기능을 추출한다. 가장 좋아하는 어플리케이션을 정기적으로 둘러볼 때 당신이 어떻게 하는지 생각해 보라. 당신은 익숙한 경로를 따라갈 것이다. 우리는 그것을 작업 흐름(workflow)이라고 부른다. 작업 흐름은 일련의 마우스 클릭과 드래그로 구성되며 당신의 전광석화 같은 키보드 움직임을 동반한다. 이것이 당신과 어플리케이션의 접점이다.

인터렉션 디자이너의 장기는 작업 흐름을 돌보고 작업을 진행시키는 것에 있다. 인터렉션 디자이너는 와이어프레임과 작업 흐름을 능숙하게 이용하여 사용자가 그 어플리케이션을 통달할 수 있게 되는 과정을 단계별로 정의하고 세분한다.

위 그림처럼 기능을 단축해서 설명하면 설명의 의도를 이해하지 못하는 이들에게는 혼란스러울 것이다. 이것이 어플리케이션이 어떻게 보일까에 대한 것일까? 그렇지 않다. 이것은 인터렉션에 대한 것이다. 이것은 그 어플리케이션이 어떻게 보이는가가 아닌 어떻게 작업하는가를 설명하고자 하는 사용자 인터페이스를 대략적으로 나타낸 것이다. 그렇다면 어플리케이션이 어떻게 보일까? 저 텍스트에 그림자 효과를 줄 수 있을까? 나는 그림자 효과와 푸른 색을 좋아하고 또 텍스트를 입체감있게 표현하고 싶은데… 그런 이야기를 하려면 이제 그만하고 가보는 것이 좋겠다.

기능을 형태에서 분리한다는 것도 생각의 전환을 요구하는 것이지만 기능과 형태 중 어떤 한 쪽 없이는 다른 한 쪽을 생각할 수 없다고 믿는 사람들도 상당히 많이 존재한다. 내 생각에 정답은 그 중간쯤에 있는 것 같다. 인터렉션에 대해서 전략적으로 생각하기 위해 픽셀 단위의 완벽한 구성이 필요하다고 생각지는 않지만 프로토타입 작업을 할 때는 샘플 인터렉션 및 애니메이션 작업을 거치는 것이 훨씬 더 풍부한 논의를 할 수 있게 도와 준다고 믿는다.

간략하게 끄적이는 식으로 제품이 어떻게 작동하는지 설명할 수도 있지만 그럴 경우 디자인의 여러 가지 개성적인 요소를 놓치게 된다. 뿐만 아니라 디자인에 대한 완벽하고 훌륭한 대화가 자칫 그림자 효과에 대한 쓸모 없는 토론으로 변질되는 수가 있다. 실제로 색상, 글꼴, 간격 등의 요소는 제품의 분위기에 기여하는 중요한 요소이다. 제품의 분위기는 그 제품이 어떻게 작동하는가와 똑같이 아주 중요하다.

IxD의 연장선상에 있는 두 가지 약어가 있는데 이것들은 꼭 한 번쯤 살펴볼 가치가 있다.

HCI 분야에서 일하고 있는 사람들을 접했던 내 경험에 의하면 그들은 뛰어난 연구자들이다. 만일 당신이 당신의 어플리케이션에서 사용자들이 시도할 수 있는 모든 가능한 작업 흐름과 그 작업 흐름을 완료하는 데 걸리는 시간 그리고 이 작업 흐름이 당신의 사용자들에게 미치는 정량화된 감정적 상처 목록을 모두 알고 싶다면 HCI 전문가를 찾아서 그에게 18개월을 주면 아마 <한 박자 쉬고> 놀라운 결과를 얻게 될 것이다.

이제 참고 문헌을 소개할 차례다. 이 책들은 누구나 접할 수 있는 것이기 때문에 골랐다. 이 책들을 읽는 것이 완벽한 디자인 교육을 보장하지는 않지만 디자인의 여러 부분에 대해 훌륭하고 견고한 취향을 갖게 해 줄 것이다.

#3 UxD(User eXperience Design, 사용자 경험 디자인)

UxD를 설명하기 위해 여기에 세 가지 그림을 제시하였다.

사용자. 경험. 디자인. 이 중에 당신은 어디에 신경을 쓰는가? 물론, 당신은 이 모든 것에 신경을 쓸 것이다. 시각적 디자인은 물론이고 인터렉션 디자인에도 신경을 쓰겠지만 당신이 가장 신경을 쓰는 것은 아마도 사용자 경험일 것이다.

내 경험상 UxD라는 용어는 학문적인 개념이 아니다. 이 용어는 내가 알고 있는 것을 남들도 알고 있다는 것을 근거(즉, 사용자 경험에 대한 공유를 뜻하는 말 – 편집자주)로 세월이 흐르면서 저절로 도입된 것이다. 디자이너라는 용어는 사용하기에 너무 일반적이고 그래픽 디자이너와 인터렉션 디자이너는 너무 구체적이다. 사용자 경험 디자이너는 과거에 약어로 사용되다가 어느 순간 전체에 대해 신경을 쓰는 것이 더 유리하다고 마음먹은 듯하다.

참으로 잘 된 일이다.

다양한 디자인 분야가 있고 각각의 분야는 그에 맞게 사용되는 때와 장소가 있다. 마찬가지로 자신에게 UxD라는 이름을 붙이거나 그렇게 생각하는 사람을 찾는 이유는 작업을 설정하고 전체 경험을 책임질 의지가 있는 사람이 필요하기 때문이다.

도서 목록의 마지막에는 디자인 고전도 포함되어 있다. 그렇다. 만화에 대한 책도 있다.

디자이너와 개발자여. 더 자주 함께 파티하라!

다양한 디자인 분야에서 사용성이 목록에서 빠진 게 눈에 띈다. 문제는 아무리 근사한 약어를 가지고 있더라도 나는 사용성을 포함시키지 않았을 것이다.

스티브 잡스가 애플로 복귀하기 전에는 일방향 거울(one-way mirror, 나는 상대방을 볼 수 있는데 상대방은 나를 볼 수 없게 만든 장치-편집자주)과 비디오 카메라가 있는 멋진 방을 갖춘 사용성 팀이 있었다. 이 조직은 괜찮은 중앙 집권형 조직이었다. 나는 이들이 상당한 업적을 이루었다고 확신하지만 잡스가 복귀하면서 문을 닫고 디자인 팀을 날려버렸다. 그리고 각 제품 팀이 예전 사용성 팀의 기능을 물려받았다.

나는 이 구조조정이 일어난 후에 들어왔으므로 진짜 이유는 잘 모르지만 내가 아는 것은 내가 한 번도 사용성 실험실을 사용해 본 적이 없다는 것과 사용성 팀이 없어진 후인 지난 10년간 애플이 가장 사용성 있는 제품을 창조했다는 것이다. 내 생각에 사용성 디자인 기능을 개발 팀 전체에 확산시키기로 한 선택은 분명한 메시지를 전달하고자 한 것으로 볼 수 있다. 개발자와 디자이너는… 더 자주 함께 파티를 해야 할 필요가 있다는 것이다.

개발자와 디자이너들이 서로의 일에 계속해서 간섭하지 않는 상황에서 제품을 책임지는 팀을 만든다는 것을 상상할 수 없다. 그렇다. 그들은 뇌의 반대쪽에서 기인하는 주장을 하며 다투기도 한다. 가끔은 예술과 과학 사이의 전투가 되기도 한다. 그러나 개발자와 디자이너가 원하는 것은 정확히 똑같다. 그들은 뭔가 중요한 것을 성공적으로 만들었다는 것을 인식할 때 느끼는 강한 만족감을 원한다.

디자인 중심의 문화란 그 디자인 문화에 책임이 있는 사람들이 서로를 마주 대하지 않는다면 그냥 내던져진 공허한 문장에 불과하다. 여러 용어와 약어들은 어떤 사람이 무엇을 하는지 이해할 수 있는 출발점을 제공한다. 그러나 당신이 시간을 내서 그들이 사랑하는 일을 어떻게 이루어 내는지 이해하려고 노력하는 데서 나오는 존중이 진짜 중요하다.

번역 : 심승희, 윤서연
윤문 : 김형주
이 글을 읽고 공감이 가시면 ‘그냥 퍼나르지 마시고’ 위에 있는 트위터나 페이스북 ‘좋아요’ 버튼을 한번 클릭해주세요. 저희가 번역자, 윤문자에게 정식으로 부탁한 글입니다.

※ 내용중에 오번역, 오탈자를 발견하신 경우에는 알려주시면 감사하겠습니다.

※ 웹액츄얼리 북스팀에서 웹디자인 관련 영문번역이나 윤문을 해주실 분을 찾습니다. 관심있으신 분은 저희에게 메일을 보내주시기 바랍니다. books@webactually.com

[편집자주]

워드프레스 제대로파기크리스 코이어 CHRIS COYIER 제프 스타 JEFF STARR 저국내 최초 워드프레스 활용 가이드 출간!

책 구매하기책 미리보기책 상세설명