디자이너와 개발자 사이의 어딘가에서
디자이너도 코딩을 해야하는가?
1. 고민의 시작
서비스 설계 문서를 작성할 때, 대대적인 리뉴얼이든, 소소한 기능 업데이트든, 보통 수십 페이지에서 많게는 수백 페이지에 이르는 방대한 문서를 작성하고는 했습니다. 화면에 포함되는 요소들을 하나씩 표현하고, 동선도 화면별로 그리다 보니 자연스레 페이지가 늘어나기 일쑤였습니다. 서비스를 완성하기 위해 반드시 필요한 과정이었지만, 작성하는 사람도, 문서를 보는 사람도 여간 지치는 일이 아니었습니다.
디자인 시안으로 커뮤니케이션 하는 경우도 마찬가지였습니다. 정적인 현재 화면을 보면서 Look & Feel을 확인하기에는 좋았으나, 실제 사용할 때 어떤 경험을 하게 될 지는 알 수 없었습니다. 화면의 움직임을 표현할 때에는 다양한 의성어와 의태어를 동원하는 민망한 상황이 벌어지기도 했습니다.
문서량도 줄이고, 인터랙션도 잘 표현할 수 있는 새로운 방법이 필요한 시기였습니다.
2. 인터랙션디자인 랩
수 많은 프로토타이핑 툴이 있었지만, 각자 지향하는 바가 달랐습니다. IxD LAB은 그 이름대로 인터랙션디자인에 대해서 고민하는 조직이었기 때문에 인터랙션을 효과적으로 구현할 수 있는 툴이 필요했습니다.
Pixate와 Principle이 비교적 쉽게 인터랙션을 구현할 수 있었지만, 툴이 제공하는 기능에서 벗어나지 못하는 한계가 있었습니다.
각각의 툴이 가지고 있는 장단점은 http://www.cooper.com/prototyping-tools 에서 한 눈에 비교할 수 있습니다.
몇 가지 툴을 사용해 본 결과, 학습 난이도(Learning Curve)와 결과물의 수준(Fidelity)은 비례한다는 것을 확인하였습니다.
따라서 프로젝트에 따라 Pixate와 같은 툴들도 사용하지만, 높은 자유도를 위해서는 스크립트를 기반으로 한 Framer 같은 툴을 사용하게 되었습니다. 또한 필요에 따라 Xcode와 Eclipse 등으로 실제 네이티브 개발을 진행하기도 하며, 상황에 따라 적합한 툴을 활용해 보기로 했습니다.
3. 스크립트 > 스트레스 > 스트랭스
코딩에 대한 기본 지식이 부족한 상황에서 스크립트를 작성하려다 보니 간단한 인터랙션을 구현하는 데에도 오랜 시간이 걸렸습니다. ‘차라리 그냥 개발자에게 부탁하는 게 낫지 않을까?’ 라는 생각이 때때로 엄습해 왔지만, 매번 부탁할 수도 없는 노릇이었습니다.
우선, 기초 체력을 위해 자바스크립트에 대한 공부를 시작하기로 했습니다. 기본 업무와 병행하다 보니 오랜 시간이 필요했지만, 생활코딩과 코드아카데미에서 스크립트에 대한 기본적인 지식과 스킬을 배울 수 있었습니다. 공부해야 하는 양과 내용이 조금 다를 뿐, 어떠한 툴을 선택하든지 익숙해지기까지 공부는 필수적일 것입니다.
또한 Framer는 공식 커뮤니티가 활성화 되어 있다는 장점이 있습니다. 막히는 부분이 생겼을 때, 언제든지 커뮤니티에 질문을 올리면 전세계 디자이너들로 부터 도움을 받을 수 있었습니다. 언제 어디서든 물어볼 사람이 있다는 것과 언제든지 제작자와 커뮤니케이션 할 수 있다는 장점 덕분에, 점점 더 많은 디자이너들이 Framer를 선택하게 되는 것 같습니다.
어느 정도 기초 체력을 키우고 나니, 간단한 인터랙션을 구현하는 데에는 그리 오랜 시간이 걸리지 않게 되었고, 점점 더 복잡한 인터랙션에 도전하게 되었습니다. 말로만 설명하던 것을 실제 눈 앞에 보여줄 수 있게 되었고, 생각하는 것을 보다 명확하게 표현할 수 있게 되었습니다.
그리고 무엇보다 “그 모든 것이 정말 재미있었습니다.”
4. 디자이너도 코딩을 해야 하는가?
비록 간단한 수준의 스크립트를 작성하는 정도지만, 기존의 디자인 작업과는 전혀 다른 과정을 경험하고 있습니다. 선을 긋고 색을 칠하기 보다는 코드를 써내려가고 에러를 고민합니다. 아마 최근에는 이런 상황에 놓인 디자이너가 많아지고 있을 줄로 압니다. 이를 두고 일부에서는 Full Stack Designer 혹은 Frontend Designer가 등장했다고 표현하기도 합니다.
이쯤되면 스스로에게 질문하게 됩니다.
‘디자이너도 코딩을 해야 하는가?’
이 질문에 쉽게 답을 할 수는 없을 것 같습니다. 현재 IxD LAB에서는 스스로 코딩을 익히고 있는 디자이너가 있지만, 모든 디자이너가 그럴 필요는 없기 때문입니다. 각자의 상황에 맞는 선택을 할 필요가 있습니다. 단순히 동선 확인을 위한 프로토타입에 굳이 스크립트를 사용하면서 고민할 필요는 없을 것입니다. 이는 마치 모기를 보고 칼을 뽑는 것과 같습니다.
프로토타이핑 툴은 어디까지나 ‘툴’ 일 뿐입니다. 중요한 것은, 왜 이 작업이 필요한가? 무엇을 전달하고 싶은 것인가? 하는 보다 근본적인 질문들에 대해 고민해 보는 것입니다. 그리고 그에 맞는 답을 찾아 실행에 옮기면 될 것입니다. A라는 툴이 B라는 툴 보다 결코 우월하지 않으며, 디자이너가 코딩을 하지 못하는 건 어찌보면 당연할 수도 있습니다.
다만 한 가지, 자신만의 성을 쌓고 그 안에 안주하는 것은 디자이너로서도, 조직의 구성원으로서도 좋은 영향을 주지는 못할 것입니다. 자신의 영역을 확고히 하면서도 다른 영역에 대한 이해와 포용이 있을 때에 비로소 완성도 있는 결과물이 탄생할 수 있다는 점을 우리는 모두 경험을 통해 알고 있습니다. 디자이너와 개발자 사이의 어딘가에서 IxD LAB과 같이 인터랙션에 대해서 고민하는 사람들의 더 많은 역할들을 기대해 봅니다.
Kakao IxD Lab 블로그에 기고한 글을 일부 수정하여 발행했습니다. http://ixd.kr/?p=1117
