디자이너가 개발자와 일하며 겪는 4가지
지금이라도 알아서 다행이다
개발자와 디자이너는 다르다.
아무래도 각자의 분야에 일을 하는 사람이기에 시선이 다른거 같다.
또한 다소 감각적인 것을 쫒는 디자이너와 실현 불가능을 쫒는 개발자의 차이도 있을 것이다.
실제로 게임 프로그램을 보고 있을 때,
개발자는 클라이언트의 고생, 서버로서 고생, 데이터 고민 등을 한다.
디자이너는 “휴 이 게임 디자이너 고생 많았겠네”라는 말을 한다.
실제로 나는 IT회사에 면접을 보러 다닐 때
몇 군데에서 이런 질문을 받은 적이 있다.
매우 다른 분야에 사람들과 일을 해야 할 텐데,
괜찮으시겠어요? 예를 들어 개발자와 디자이너요
오늘은 이 질문에 대한 답을 적어보고 싶다.
예전에 알았으면 좋았을 것들이며, 지금도 여전히 하나하나 발견하고 있으니 말이다.
디자이너와 개발자가 함께 일하면서 겪는 사례는
지금까지 크게 4가지가 있었던 거 같다.
# 첫 번째 이야기
모든 디자인이 구현되는 건 아니다
디자이너 : "~버튼을 누르면 ~~ 가 등장해서 사용자가 ~시 이런 모습이 나왔으면 좋겠습니다."
개발자 : "지금으로선 구현이 어려울 거 같습니다. ~를 구축하려면 타임라인을 맞추기 어렵습니다."
개발자 : "~한 인터렉션은 ~~ 기 때문에 구현이 어려울 거 같습니다."
대체적으로 디자이너는 디자인 과정이 모두 완료된 후 개발자에게 전달한다.
개발자는 구현 작업에 들어간다. 하지만 모든 디자인이 서비스에 구현될 수 없다.
이렇게 되면 디자이너는 디자인 수정을 해야 하고, 개발자는 다시 디자인을 기다려야 한다.
그럼 전체적인 타임라인이 늘어지게 된다.
첫 번째 이야기에 - 해결책
개발환경을 이해하려고 노력한다
누군가를 이해하기 위해 가장 확실한 방법은 내가 그 사람이 되어 보는 것이다.
그 사람이 되어 겪을 수 있는 상황을 상상하고, 어떤 마음일지를 생각하면 100%는 아니더라도
70%는 이해할 수 있다고 생각한다. 그래서 나는 개발자의 직무를 이해하려고 노력했다.
최대한 개발자와 수다를 많이 떨려고 했다.
자리에 찾아가 궁금한 개발 지식도 물어보고 구현한 것들이 어떤 원리로 만들어졌는지 물어본다.
다행히 친절히 대답해주셔서 자세히는 알 수 없지만, 어떤 원리로 돌아가는지
이해할 수 있었다. 그 결과, 머릿속에 가설들이 세워졌고
'이건 이런 원리이니, 가능할 수도 있겠다'
라고 생각하며, 디자인하기 전 한번 더 확인하게 되었다. 이런 과정이 더 많은 소통을 하게 도와준 거 같다.
# 두 번째 이야기
디자인할 땐 몰랐던 오류를 찾게 된다
개발자 : "~페이지에서 사용자가 ~~ 버튼을 눌렀을 땐 ~한 화면이 있어야 할거 같습니다"
개발자 : "~~ 버튼 클릭 시 ~~ 한 상황도 있으니 ~~ 화면이 있는 게 좋지 않을까요?"
디자이너 : "아 그렇군요. 제가 그 부분은 놓친 거 같습니다. 지금 작업해서 전달드리겠습니다"
계정과 프로필 관련해서 디자인 작업을 했을 때였다. 사용자가 계정을 수정한 후에 안내할 팝업창이나 alert창을 잊은 것이다. 다행히 프런트엔드 개발자분께서 오류를 찾고 전달 주셨다.
개발에 경우, 직접 하나하나 코드를 이용해 구현해 나가는 작업이기에
디자이너보다 사용자의 한걸음, 한걸음을 캐치할 수 있었던 거 같다.
또한, 여러 경우의 수를 두고 코드를 짜야하니 다양한 사용자의 행동을 예상할 수 있는 거 같았다.
하지만, 이러한 오류가 작업 때마다 발생하게 되면 서로 추가적인 업무가 늘어나며
치명적인 오류일 경우엔 전체적인 일정이 늦어질 때가 있다.
두 번째 이야기에 - 해결책
내가 개발자라고 생각해보자
첫 번째 해결책과 같은 맥락에 얘기이기도 하다.
이전에 프로젝트를 진행할 때 유독 서버 개발자에게 질문이 많았던 적이 있었다.
계속해서 오류를 찾아내고, 굉장히 서로 지친 상태였다. 나의 서버에 대한 이해가 부족했기 때문이다.
나는 프로젝트 중간에 결국 서버 개발자에게 이렇게 말했다.
"왜 저는 디자인할 땐 몰랐을까요? 저도 너무 답답해요"
서버 개발자는 이런 말을 했었다.
"휴, 저도 왜 그런지 알아요. 서버를 생각해야 보이는 오류였으니깐요."
서버를 생각해야 보이는 오류라.. 그 말에서 나는 해결책을 찾았다. 디자인만 알려고 하지 말고 내가
어느 정도 프론트엔드, 서버, 데이터에 기본 원리만 알아도 오류를 미리 캐치할 수 있지 않았을까?
하고 말이다. 그때 이후로 나는 서버 개발자가 사용하는 용어가 모를 때마다 물어봤었다.
그리고 지금은 오래전에 손놓았던 개발 공부를 하고 있다.
html, css, jquery를 어느 정도 할 수 있으며, javascript를 공부하고 있다(...너무 어렵다^^)
이런 과정이 때론 개발에 아이디어를 제시하기도 하고, 개발자와 대화할 때
디자인에 어떤 문제가 있는지 왜 문제가 되는지 이해가 빨라졌다.
# 세 번째 이야기
모르는 사람이 봐도 흐름이 이해돼야 한다
개발자 : "~~ 을 클릭하면 ~~ 것이 나오는 게 맞나요?"
개발자 : "~~ 화면은 ~~ 을 거치면 나오는 것이 맞나요?"
새로운 기능이 들어가게 되면, 플로우 단위가 생기게 된다. 디자인 완료 시엔 제플린을 통해 전달하며 코멘트를 달아 플로우를 설명한다. 하지만 개발자분께 플로우를 설명해 달라는 메시지를 받게 됐고 그 빈도수가 많아지자 나의 전달 방식이 잘못됐다는 걸 인지하기 시작했다.
세 번째 이야기에 - 해결책
누가 봐도 이해되는 디자인과 흐름
디자인을 하다 보면 디자인 늪에 빠진다.
계속 보다 보면 자신의 디자인에 빠져들고, 객관화가 힘들어진다.
예를 들어 플로우가 어려운 디자인이 계속 보다 보면 이해가 되니깐 복잡한 플로우인지 인식하기 힘들다.
이런 과정에서 나는 개발자에게 아무런 고민 없이 디자인을 전달했던 거 같다.
가장 정확한 해결책은 "프로젝트를 모르는 누가 봐도 이해되는 디자인과 흐름" 이어야 한다는 것이다.
'당연히 개발 자니깐 이 정도로 표기하면 아시겠지'라는 마인드는 서로의 소통을 가로막는다.
따라서, 그 누가 봐도 이해가 되도록 아주 자세히 적어 놓기 시작했다.
1) 제플린에 자세한 코멘트를 달았고, 예상치 못한 상황에 나올 수 있는 화면들도 추가 하기 시작했다.
그리고 가장 좋은 방법은 2) 인터렉션이 담긴 영상을 전달하는 것이다.
프로토 파이 프로그램은 다소 짧은 시간 내에 인터렉션을 표현할 수 있다. (물론 기능이 제한적이라 불편한 것도 있다.) 이 작업을 하면서 나는 더 이득을 봤다. 직접 프로트 타입 영상을 담아내니 어디에 오류가 있는지
캐치할 수가 있었다. 또한 "이렇게 해주세요~ 이거 누르면 이렇게 뿅~..."이라는 추상적인 전달도
가시적으로 전달이 되니 소통이 더 쉽게 느껴졌다. 또 한 가지, 3) 프로젝트 관련 문서를 만드는 것이 좋다.
왜 이 프로젝트가 시작됐는지부터 디자인 참고사항을 적어두면 프로젝트 자체에 대한 질문이 줄어들고
더 빠른 이해를 할 수 있게 도와준다.
# 네 번째 이야기
디바이스별 최적화를 놓치면 업무가 과중된다
개발자 : "이 사이즈에 태블릿 pc로 전환됩니다~ 디자인 수정이 필요합니다."
개발자 : "아이폰 5s에서는 이렇게 보입니다"
디자이너 : "(뚜둔...).. 아... 제가 고려를 못했네요 수정해서 전달드리겠습니다"
디바이스별 최적화를 아예 생각하지 않은 건 아니었다.
웹, 태블릿 pc, 모바일 기준으로 디자인을 전달했지만 더 자세힌 가이드가 필요했다.
왜냐하면 프런트엔드 개발자들이 직접 언제 반응형 디자인으로 바뀌어야 하는지
최소 사이즈와 최대 사이즈를 체크해야 했기 때문이다. 또한 모바일이 어느 핸드폰에서는
화면이 아주 예뻤지만, 내 핸드폰에서는 이상하고 이런 현상들이 많았다.
네 번째 이야기에 - 해결책
나만의 디바이스별 최적화 가이드 제작
일단 이런 상황에서는 개발자와의 많은 대화가 중요하다.
웹, 태블릿 pc, 모바일 별 변화하는 최소 사이즈와 최대 사이즈를 체킹 해야 한다.
예를 들어 1200px까지는 반응형 디자인이지만 1201px부터 웹 환경으로 변화합니다.
라는 기준을 먼저 체크하고 있어야 한다.
그다음은, 나만의 디바이스별 최적화 가이드가 꼭 필요하다.
디바이스별 디자인 해상도라고 웹에 검색을 해보면 정말 많은 가이드가 나온다.
어떤 사람은 결국 0000 사이즈에 작업을 한다고 하고, 어떤 이는 0000에 작업을 한다.
나는 그 기준을 찾을 수 없었다. 고민하다 찾은 방법은 데이터를 수집하는 것이었다.
필요한 데이터는 스크린 점유율과 다른 사람들에 디자인 사례이다.
스크린 점유율은 브라우저 사용 현황을 통해 사용자들의 컴퓨터 환경을 파악하는 웹 트래픽 분석 기업
https://gs.statcounter.com/에서 확인할 수가 있다.
다른 디자이너들에 디자인 사례는 모아 두고, 지금까지 디자인했던 것들에 오류사항을
모아 보면 사이즈에 감이 오기 시작한다. 요즘에 나는 데이터를 모으고 있고
디바이스별 발생할 수 있는 오류들을 적어나가고 있다.
여기서 계속해서 신제품이 나오고 있다 라는 점을 잊지 않고 있어야 한다.
신제품에 따라 해상도가 변할 수 있다는 점을 인지하자.
지금까지에 4가지 스토리를 정리해보니
결국 답은 "다른 사람을 향한 이해"가 전체적인 해결책이었던 거 같다.
일하는 곳에서 이러한 해답은 다소 감성적으로 보이고 업무적인 느낌이 안 난다.
하지만 다른 사람을 향한 이해에 시도는 나에게 다른 사람이 가진 능력을 가질 수 있는 기회도 준다.
예를 들어, 00처럼 생각하면 00가 찾아냈던 오류를 나도 찾을 수 있다는 점이다.
나는 앞으로도 나와 함께 일하는 사람과
더 대화를 나누고 싶다. 그들을 이해하려고 노력한다면 오류와 오해보단
정말 '소통'을 할 수 있지 않을까?
