Design Spectrum E07 후기
코드와 데이터로 디자인 하기
지난 7월 29일 디캠프에서 열렸던 디자인 스펙트럼에 다녀왔습니다.
개인적인 사정과 한 번의 신청 실패로 4월에 있었던 E03 이후 3개월 만에 참가를 하게 되었네요. 매 행사가 지날수록 디자인 스펙트럼 참가 신청 경쟁이 빡세진 것 같습니다. 4월 행사까진 그래도 30분~1시간의 텀이 있었던 것 같았는데 이번엔 15분 만에 100명이 넘는 신청 인원이 마감되어버렸네요. 디자인 스펙트럼이 흥하고 있다는 뜻이기도 하고, 이번 7월 디자인 스펙트럼이 '코드와 데이터로 디자인 하기'로 다루는 주제로 많은 사람들이 흥미를 가지는 주제였던 것도 한 몫하지 않았나 생각이 듭니다.
저는 후기를 밋업이나 행사를 다녀오고 난 뒤 휘발되지 않도록 회고하는 목적으로 작성을 합니다. 그래서 인상 깊은 내용들 위주로 쓰기에 다소 주관적입니다. 때문에 제가 작성한 내용들이 변질되지 않았나 하고 간혹 걱정이 들고 하는데 이 점 이해 부탁드립니다. (_ _)
주제인 '코드와 데이터로 디자인 하기'만 보면 강의 세미나 같아 보일 수도 있지만, 그런 건 전혀 없이 주제를 소재로 개인의 계기와 흥미, 관점, 어떤 노력을 해왔는지에 대한 소중한 경험담을 공유해주셨습니다. 덕분에 부담 없이 재밌게 경청하며 큰 동기부여를 얻었습니다.
이번 패널분들은 온라인상에서 많은 사람들에게 인사이트를 주시는 분들이었기에, 잘하는 사람들이 해주는 이야기가 개인적으로 궁금했었습니다. 온라인을 통해서는 주로 그들의 결과물과 정리된 아웃풋들로만 접했기에 '뭐든지 한 번에 척척'이라는 선입견 아닌 선입견을 가지고 있었습니다. 하지만 우리가 보고 있는 게 100이라면 그 뒤에는 그분들의 1000의 노력이 있었고, 그 속엔 많은 실패와 좌절 또한 포함되어 있었습니다. "이 분은 잘하는 사람이니깐 그냥 잘한다~."라고 했던 예전의 감상들이 매우 실례였다는 생각이 들었습니다.
더불어 계속 생존하고 나아가는 디자이너가 되기 위해서 어떤 방향으로 자신을 확장시켜 나갈지 고민해보게 하는 시간이었습니다. 이 것이 꼭 코드와 데이터일 필요는 없다고는 하셨지만 이 두 가지가 IT 환경 속의 디자이너에겐 가장 강력한 경쟁력 될 수 있는 존재들이었기에 학상 이슈가 되고 있는 것 같습니다.
프레젠테이션
안지용(비바리퍼블리카)
디자이너 입장에서 코드를 이해하고 활용에 대한 이야기를 개인 프로젝트와 실무에서의 경험을 공유하며 풀어주셨습니다.
시작은 개인 프로젝트였던 Listener's Playlist(http://lp.anzi.kr/)의 제작 과정을 공유해주셨는데, 단순히 구현한 방법들에 대한 소개가 아닌 초기 시안부터 특정 부분의 구현을 위해 어떤 고민과 노력들을 하셨는지 자세히 이야기해주셨습니다. (뭐든지 뚝딱 한 번에 깔끔하게 만들어지는 건 없었습니다.)
보통 디자이너가 개인 프로젝트를 하면 정적인 부분(목업)에서 멈추게 되는데, 코드를 다루게 되면 표현의 범위를 확장시킬 수 있고, 이를 위해 자연스럽게 기술 가능성 등을 점검하게 되고, 런칭 후에는 피드백을 반영할 수 있게 된다고 하셨습니다.
개인 프로젝트를 하시면서 첫 번째로 표현의 범위 확장, 정적인 프레임에서 벗어나는 걸 중요하게 여기셨다고 합니다. 이에 대한 첫 단계로 활용하는 기본적인 툴에 변화를 주었다고 합니다.(포토샵에서 스케치로)
스케치로 시안을 먼저 제작하셨고(Listener's Playlist 첫 화면의 물결), 이것이 시안으로 멈추면 의미가 없다고 생각하셨기에 구현을 위한 준비를 하셨습니다. 물결의 파동을 위해 수많은 리서치와 코드들을 복붙을 하시며 구현 가능성을 체크하셨습니다.(에버노트로 정리된 많은 양의 스크랩들을 보여주시며..)
상상했던 결과물이 100이라 치면 처음 제작한 결과물의 퀄리티는 10이었기에 좌절도 맛보았지만, 처음부터 바로 100을 만들려고 하면 대부분 초기에 포기를 하게 됩니다. 때문에 1부터 조금씩 쌓아가며 만들어가셨다고 했습니다.
중간중간 남긴 작업노트도 보여주셨는데 인상 깊었습니다. 포폴을 위해 하나의 개인작을 하는 것이 아니라 자신의 스펙트럼을 넓혀간다는 느낌을 받았기 때문입니다.
회사 실무에 대한 이야기로 개발자와의 커뮤니케이션에 대한 부분을 다뤘는데, 청자의 언어로 PT를 해야 그들을 설득할 수 있듯이, 코드를 알면 자신의 디자인을 개발자의 언어로 설득할 수 있게 된다고 합니다.
시각적 커뮤니케이션으로 정적인 화면에서 커뮤니케이션을 하게 되면 개인의 관점과 배경의 차이로 이야기를 듣고 떠오르는 그림은 각자 다를 수도 있습니다. 때문에 이 격차를 줄여주는 것이 프로토타이핑이라고 하셨습니다.
두 번째로 컴포넌트의 모듈화를 통해 반복적인 작업 줄이고, 코드와 최대한 씽크를 맞춰 후에 생길 유지보수 비용을 크게 줄 일 수 있다고 하셨습니다. 물론 모듈화가 유연하지 않을 수도 있다는 점도 있지만, 때문에 초기 계획 단계 때 많은 노력이 필요할 꺼라 하셨습니다. 이 부분에 공감하는 것이 의미 있게 쓸 수 있는 시간을 소 잃고 외양간 고치는데 소비하는 건 정말 아깝다는 생각이 듭니다.
그리고 마지막 협업 팁으로 시스템 UI와 커스텀 UI에 대해 말해주셨습니다. 이 부분에서 개발자와의 불협화음이 자주 발생하는데, 디자이너 입장에선 시스템 UI 사용이 달갑게 느껴지지는 않지만, 시스템 UI 사용이 제품에 치명적인 악영향을 주는 게 아니라면 사용하는 방법으로 풀어나가는 것도 고려해봄을 추천하셨습니다. 이 경우 지용님은 보통 타협을 보시고 여기서 발생한 창의적 욕구불만은 개인 프로젝트를 통해 해소를 하신다고 합니다..
개인적으로는 지용님께서 '디자이너에게 코드가 이래서 좋다'가 아닌 자신의 경쟁력으로써 코드를 익히게 된 이유와 작업하실 때의 여러 가지 계기와 생각, 노력들에 대한 히스토리를 상세하게 공유해주셔서 좋았습니다. 나만의 경쟁력을 위해 어떤 노력을 해야 할지에 대해 다시 한번 생각해보는 시간이 되었습니다.
진유림(스마트스터디)
유림님은 개발자이시지만 디자인 친화적이시고 실제로도 디자인 영역과 밀접하게 일을 하시고 계신다고 합니다. 회사에서도 직함이 Artistic Software Engineer라고 합니다.
앞에서 지용님께서 코드 학습에 대한 동기부여를 주셨다면, 유림님은 디자이너가 코드를 학습함에 있어 어떤 식으로 하는 게 부담이 안되는지 과거에 하셨던 개인 프로젝트들을 예시로 보여주셨습니다.
예시와 함께했던 발표였기에 글로 옮기기엔 다소 무리가 있어.. 여기선 전반적으로 어떤 이야기를 해주셨는지에 대해서만 정리를 해야 할 것 같습니다.
팜므어 번역기, FOOD-TODO, YOP이라는 개인 프로젝트들을 개발 난이도 순서대로 소개하시면서 어떤 원리로 구현이 되는지, 기능 구현에 초점을 맞춰 차근차근 설명을 해주셨습니다.
그 밖에 Github, Firebase 등의 활용법과 개념들을 다뤄주셨습니다. 전반적으로 개발에 대한 기초 강의를 듣는 기분이었고 이해하기 쉽게 설명해주셨습니다.
회사 서비스의 반응형 웹을 제작할 때 시안을 받고 당황하신 적이 있으셨는데, 이게 디자이너 입장에서 큰 이슈가 아닌 영역이지만 개발자 입장에선 코드 구조의 문제로 작업 시간 대비 효율이 크게 안 나오는 경우가 있다고 합니다. 이럴 땐 개발자에게 일찍이 해당 부분에 대해 논의를 나누고 우선순위를 정하는 것이 좋다고 하셨습니다.
디자이너와 개발자의 관점이 다르기에 "디자인 때문에 개발 설계를 변경해야 할 때 화난다.", "운영 편의 개선 작업이 만족스러웠습니다.", "보이는 게 없는 코딩을 금방 질린다.", "난 개발자 대상으로 개발하는 게 좋다." 등과 같은 케이스들이 나올 때가 있다고 합니다. 하지만 이런 부분은 개인의 가치판단을 해서는 안 되는 부분이라고 하셨습니다. 서로의 개인 관점일 뿐 하나의 제품을 위한 것이 아니기 때문이죠.
"개발이 구리면 시작을 못하고, 디자인이 구리면 지속되지 못한다."
개발에 관심이 있으시다면 망설이지 말고 원하는 만큼 아름답게, 실용적이게 혹은 쓸 데 없게, 아무 상관없이 당장 한걸음 시작해보는 걸 추천하셨습니다.
이지훈(전 에바종)
지훈님은 산업공학을 전공하시다가 디자인으로 전향하셨는데, 산업공학을 전공했음에도 처음엔 디자인의 정성적인 영역을 데이터의 숫자로 다룰 수 없다는 생각을 가지 셨었다고 합니다. 이런 생각이 바뀌게 된 여러 가지 계기가 있었지만 그중 가장 큰 영향을 준 것이 '그래서 디자인이 하는 게 뭔데?'와 같은 질문들이었다고 합니다.
어떻게 하면 디자이너가 비즈니스에 만만하게 보이지 않을까?라는 맥락으로 데이터에 대한 고민을 시작하게 되었다고 하셨습니다.
서비스의 UX를 다루지 않는 조직에 첫 UX디자이너로 들어오면서 디자인을 데이터로 증명하고 마케팅, 비즈니스 영역에 영향을 줬던 에피소드들을 공유해주시며 디자인과 데이터의 관계를 설명해주셨습니다. 이전에 몸 담고 계셨던 디자인 조직은 디자이너들만 모였기에 정성적인 부분 위주로 많이 다뤘고, 이 때문에 데이터를 통한 자신의 디자인의 결과를 증명하고자 하는 니즈를 계속 가지고 계셨다고 하셨습니다.
모두가 무언가를 하려면 계기가 필요하듯.. 지훈 님의 데이터를 통한 디자인 증명에 대한 계기는 조직의 환경이 컸던 것 같습니다.
디자인 영역은 개인의 관점마다 가치가 쉽게 오르고 내릴 수 있었기에 데이터가 이런 부분에서 소음을 줄이고 교통정리를 확실히 해주는 요소라는 생각이 들었습니다.
모바일 웹 개편 후 모바일 거래액이 2달 만에 2배 이상 상승하는 일이 있었고, 이는 PC 웹과의 거래액이 완전히 뒤바뀌었고 이는 비즈니스적으로도 큰 영향을 줬던 일이었다고 하셨습니다. 이를 조직에 공유를 했고 큰 인정을 받기 시작했다고 하셨습니다. 하지만 지훈님께선 모든 프로젝트에 똑같은 에너지를 쏟아오셨고, 물론 각 작업마다 목적은 달랐다곤 하지만 유독 이 작업에 조직이 큰 반응을 했던 것에 많은 혼란을 느끼셨다고 하셨습니다. 이는 데이터를 더 면밀히 관찰하게 하는 계기가 되었다고 합니다.
구글 애널리틱스를 통해 앞에서 소개하셨던 작업들의 데이터를 보여주시며 유저 플로우, 트래픽을 조사를 통해 가설 검증에 대한 이야기를 해주셨습니다.
이때 자사의 서비스를 유저가 인지하는 부분이 랜딩 페이지가 아니었고 광고를 통해 유입되는 상황이 많았고, 2:1로 생각했던 PC와 모바일의 비중이 5:1이었다는 사실 또한 데이터를 통해 알게 되었다고 합니다. 유저의 영향이 5배나 차이나는 영역들을 똑같은 에너지를 쏟아 작업하는 것보단 어디에 임팩트를 줄지 계획을 잡을 수 있게 되었다고 합니다.
디자이너로써 지표를 기준으로 소통을 비즈니스 화하기 시작하면 경험상 비즈니스에서 디자인을 인정할 수밖에 없는 상황이 오게 된다고 합니다. 디자인의 중요도를 비즈니스 적으로 크게 보게 된다고 하셨습니다.
비즈니스 영역의 지표가 상승한다면 그것이 디자인 때문 일 수도 있고, 단순히 제공하는 상품 때문일 수도 있기에 많은 변수를 고려해야 한다고 합니다.
지표에 집착하다 보니 고객의 경험에 대해(정성적인 요소) 깊게 생각하지 않고, 증명할 수 없다면 우선순위에서 필터링해버리는 자신의 모습을 되돌아보기도 하셨다고 합니다.
비즈니스의 인정을 받는 디자인을 한다기보다는 비즈니스는 애초에 디자인의 모든 스펙트럼을 이해할 수 없다는 것을 전제로, 디자인이 비즈니스 관점에서도 증명할 수 있는 가치가 이 만큼 있다는 최소가치를 지키는 부분에 초점을 둬야 한다고 하셨습니다.
패널토크
패널토크는 오픈채팅방을 통해 각 패널분들께 하고 싶은 질문하고, 스펙트럼 측에서 취합 후 선별을 한 걸로 진행되었습니다. (그 뒤 나머지 질문들은 감사하게도 각 패널분들께서 오픈채팅방을 통해 답을 해주셨습니다.)
개인적인 경험들을 기반으로 답변을 해주셔서 재밌고 유용한 시간이었습니다. 저의 후기에는 그중 몇 가지만 간략화하여 공유드리겠습니다.
Q. [지용님께] 디자이너가 그렇게 코드를 알게 되기까지의 과정 혹은 학습의 단계가 궁금합니다.
A. 일단 스스로에게 동기부여를 하는 게 중요한 거 같다. 목적 없이 하면 아무것도 안된다. 중학생 때부터 HTML, CSS를 접해왔는데 긴 시간 동안은 단순한 노가다식 작업만 해왔다. 후에 자바스크립트를 접하면서 만들고 싶은 것들 중 일부를 만들고 재미를 느끼면서 공부에 가속도가 붙었던 것 같다.
Q. [지용님께] 모든 컴포넌트들이 모듈화 되어있으면 디자이너의 자유도, 창의성이 제한될 것 같습니다. 혹시 이에 대한 경험이나 해결책이 있으신지 궁금합니다.
A. 모듈화를 하면 확장성의 자유와 유연성이 떨어지는 건 맞다고 생각한다. 하지만 생각해볼 부분이..GD의 빅뱅 안에서의 음악과 개인 앨범의 음악의 색깔은 다른 것처럼.. 내가 어떤 조직에 속해 있다면 그 조직의 일을 해야 한다고 생각한다. 개인의 욕심이 치고 나가면 원맨 밴드가 될 뿐이다. 개인의 자유도와 창의성이 저해될 수는 있다. 하지만 같이 하는 작업에서의 자유도와 창의성인지 혹은 개인의 자유도와 창의성인지 구분해놓고 같이 고민하는 것들이라면 같이 끌어올릴 수 있다. 모듈화를 지정했다고 그것을 영원히 쓰는 게 아닌 것처럼..
Q. [유림님께] 개발자 입장에서 같이 일하는 디자이너에게 기대하는 개발 이해도의 수준이 궁금합니다.
A. ui 패턴들을 명확히 알고 디자인적 사고로 제안해주시는 게 중요한 것 같다. 그리고 디자인 제안 시 단순히 예쁘다! 와 같은 감성적인 이유보단 디자인 한 부분에 대한 논리적인 이유를 설명해준 것도 중요한 것 같다. 필요한 작업이라는 이유를 명확히 개발자에게 전달해주면 개발자에게 동기부여가 된다.
Q. [유림님께] 디자이너가 코드를 공부하지만 완전하지 않은 초보인 상태여도 개발자와 커뮤니케이션 시 많은 도움이 되는가? 아니면 어느 정도 높은 수준의 이해도를 가졌을 때 커뮤니케이션을 하는 게 좋나?
A. 이런 얘기를 많이 들었다. '개발 조금 배운 디자이너가 위험하다.' 하지만 이런 부분은 사람마다 다를 것이다. 결국 조금 배웠더라도 장점이 훨씬 많다고 생각한다.
Q. [지훈님께] GA 관련해서 보기 시작했는데 제가 보고 있는 데이터 값이 좋은 범위에 속하는지 아닌지 기준을 잘 모르겠습니다. 이에 대한 팁이 있을까요?
A. A/B테스팅 툴 같은걸 활용하실 때는 통계학적으로 유의미한 결과가 나왔을 때 승자를 선언한다. 그렇기에 툴들을 활용한다면 자연스럽게 해소가 되기에, 그런 환경에 있다면 이를 추천해드리는데 보통 이런 환경에서 일하는 경우가 드문 것 같다. 데이터 값이 차이가 있다는 건 바로 보이지만 이게 표준편차 범위 내에 있다면 통계학적 기준으로 볼 때는 성과가 있는 것이 아니다고 판단한다. 하지만 개인적으로는 이런 고민을 할 필요가 없다고 생각한다. 설득해야 할 상대가 통계학을 잘 모른다면 의미가 없기 때문이다. 이 상대의 기준에 맞는 데이터를 추려서 전달하고, 어떤 것에 반응하는지 보고 판단하여 기준을 세우는 것도 하나의 방법이다.
Q. [공통질문] 디자이너가 코드와 데이터를 이해하는 것이 필수 불가결인가요?
A.
(지용) 개인적인 견해지만, 질문을 디자이너가 ui작업만 하는 게 맞나요?라고 바꿔 볼 수도 있다. 예를 들어 은행 지점에 점원이 있는데 이젠 모두가 인터넷 은행을 써서 그 지점에 가지 않는다면 그 점원은 가치가 없는 직원으로 판단될 수도 있다. 디자이너가 변하는 환경에서 가치를 증명하려면 그림만으론 설득할 수 없는 것 같다. 내가 코드를 보는 이유도 이 중 하나다.
(유림) 디자이너 분들이 다른 영역으로 확장하는 것은 사고의 확장으로 볼 수도 있다. 기존의 하지 못했던 사고를 하게 되면서 더 넓은 사람이 되는 것 같아 좋은 것 같습니다.
(지훈) 정확한 아웃풋을 기대하고 하지 말고, 그냥 한번 해보는 것도 나쁘지 않다고 생각한다. 사고의 관점이 넓어지는 것 같다. 단순히 이 부분을 코드와 데이터로만 한정 짓지 말고, 본인이 어떤 것을 할 수 있는 어떤 그릇의 사람인지 먼저 고민해보는 것도 좋은 것 같다. 내가 어떤 결을 가진 사람이고, 내 상황이 어떤지 무엇을 하면 좋을지 고민하고, 내 상황에 맞는 자신의 능력을 활용할 수 있는 플러스알파가 뭔지 생각하는 게 바람직한 것 같다.
3개월 만에 참여했던 디자인 스펙트럼이어서 그런지.. 동기부여가 많이 되는 시간이었습니다.
코드와 데이터에 대한 이야기들도 좋았지만, 예를 들어주신 패널분들의 경험담이 더 기억에 남는 것 같습니다. 일이나 작업을 하면서 한 번에 100을 완성하려 하지 않고.. 작게 작게 목표를 위해 1부터 100까지 계속 다듬어 가는 과정이 저에게 인상 깊게 다가왔던 것 같습니다.
무언가를 하고 싶은데, 상상했던 그림이 한두 번 만에 안 나올 때 벽을 보게 되고 괴로워하다가 미루고 미루다가 포기를 했던 부끄러운 경험이 있었기에 더 그랬던 것 같습니다.
변하는 환경에 생존하는 디자이너가 되기 위해 나는 무엇을 해야 나만의 능력을 끌어올릴 수 있는지.. 고민해보는 시간을 가져봐야겠습니다.
감사합니다.
