디자이너도 코딩 공부해야 해요?
몰라도 되지만 알면 새로운 세계가 열립니다!
대학 시절부터 코딩에 흥미가 있었는데요. 처음에는 퍼블리싱에 관심이 생겨서 HTML, CSS, jQuery를 공부하다가, 갑자기 미디어아트가 재밌어 보여서 Arduino, Processing을 배워보기도 했고, 3D 모델링과 게임 개발에 흥미가 생겨서 Unity도 잠깐 공부했었습니다. 하지만 명확한 목표도 없었고, 나와 맞지 않는다는 결론을 내리게 되었고, 무엇 하나 제대로 하지 못 하는 상태로 공부를 그만두었습니다.
다시 코딩에 관심을 가지게 된 계기
“개발에 대한 이해가 업무의 효율성을 극대화해 줄 수 있지 않을까?”
프로덕트 디자인을 하다 보면 반복적이고 비효율적인 작업들을 자주 마주치는데, “개발에 대한 이해가 업무의 효율성을 극대화해 줄 수 있지 않을까?”라는 생각을 하게 되었습니다.
첫째, 반복되는 작업을 없애주고 디자인의 일관성을 유지할 수 있게 디자인 시스템을 만들어야겠다는 생각이 들었습니다.
둘째, 간단한 디자인 수정은 직접 처리할 수 있다면 좋겠다는 생각이 들었습니다. 간혹 “저거 진짜 간단한 디자인 수정인데, 자꾸 우선순위에 밀리네… 그냥 내가 할 수 있으면 좋겠다.”는 생각을 하곤 했습니다.
셋째, CSS를 잘 알면 개발자가 바로 이해할 수 있는 형태로 소통할 수 있겠다는 생각이 들었습니다. QA 과정에서 수정 사항이 줄어들 것이며, 개발자도 더 쉽고 빠르게 작업을 진행할 수 있겠다고 생각했습니다.
넷째, 프로토타이핑 및 웹사이트 빌더로 Framer를 사용하고 있는데, 코드를 활용하면 더 효율적으로 작업할 수 있었고, Framer의 GUI만으로 구현할 수 없는 다양한 기능과 디자인을 도전할 수 있었습니다. 하지만 코딩을 못하니 소스 코드를 찾아봐도 응용이 불가능했고 디자인하는데 많은 한계를 느끼게 되었습니다.
회사 내 재능기부로 코딩을 배울 기회를 얻었습니다.
마침 회사의 프론트엔드 테크리드 분께서 지인들에게 코딩을 가르치고 있었는데요. 저도 “지금이 마지막 기회다” 싶어서 참가했습니다. 주말이나 평일 밤에 짬 내서 하느라 진도가 느렸고, 마지막 백엔드 부분을 배울 때는 의지가 꺾여버렸지만 그래도 마지막까지 포기하지 않고 6개월 만에 기초 공부를 끝냈습니다!
실무에 적용하기 1 - Framer로 웹사이트 개편
공부가 끝나갈 무렵 *리캐치의 웹사이트를 개편하게 되었습니다. 리캐치를 도입했을 때의 효용을 표현하기 위해 가격안내 페이지에 “ROI Calculator”를 넣기로 했는데요. 이를 통해 리캐치 도입비용 대비 잠재고객을 더 많이 확보함으로써 결과적으로는 더 큰 매출을 낼 수 있다는 것을 전달하고 싶었습니다
Framer에서 Typescript로 직접 Component를 만들 수 있고, Override로 인터페이스에서 제공하지 않는 기능을 추가할 수도 있습니다. 유저가 값을 입력하면 리캐치의 구독료와 효용을 출력하도록 만들었습니다. 그리고 Framer에서 NPM에서 제공하는 각종 유용한 라이브러리를 import할 수 있습니다. 대표적인 그래프 라이브러리인 React Chart Js를 이용해서 멋진 그래프를 그려주었습니다.
CSS 스타일링을 훨씬 간편하게 만들어주는 라이브러인 styled-component도 import해서 디자인을 입혀주었습니다.
(하지만 배포하고나니 Framer상에서 적용한 styled-components가 불안정한 모습을 보였습니다. 그래서 눈물을 머금고 inline으로 다 바꿨습니다 ㅠ)
제품의 효용과 예상 도입 비용을 재밌는 방식으로 풀어냈고, 직접 코딩으로 구현했다는게 뜻 깊습니다. 우여곡절이 많았지만 무사히 배포되었습니다!
웹사이트의 경우 직접 개발하는 곳도 있겠지만 대부분 웹사이트 빌더를 쓰는 추세인데요. 기능보다는 디자인과 콘텐츠의 비중이 높은 경우, 웹사이트 빌더를 이용해 디자이너가 직접 만드는 게 훨씬 효율적이었습니다. 저희는 Framer라는 툴을 선택했고 Framer는 React Typescript 그 자체라 코딩 지식을 활용할 수 있는 좋은 테스트베드였습니다.
실무에 적용하기 2 — 직접 코드 수정하기
간단해 보이는 디자인 수정 업무이지만, 우선순위 때문에 뒷전으로 밀리는 경우가 많습니다. 이런 상황에서 직접 코드를 수정하여 구현하는 시도를 해보았습니다. 수정 사항을 자유롭게 반영할 수 있고, 직접 구현되는 모습을 보며 뿌듯함을 느낄 수 있었습니다. 그러나 현실적으로 어려운 일이라고 생각합니다. 단순한 수정은 가능하지만, 조금 깊이 들어가면 구조적인 수정이 필요한 경우가 많기 때문입니다.
후기 — 개발자의 마음을 이해하게 되었습니다.
- 직접 해보니 CSS 작업은 상상 이상으로 귀찮았습니다. 재활용성을 고려하면 코드도 깔끔해지고 시간도 단축되겠다는 생각이 들었습니다. (코드가 길어지는 마법! 내가 개발할 때는 대충 같은 디자인 돌려씀 ㅋㅋ)
- 이미 잘 만들어진 디자인 시스템을 가져다 쓰는 건 참 편한 일입니다. (상당수 내가 만든 것보다 훌륭함)
- 컴포넌트는 어떻게 구성되어 있고, 컴포넌트들이 어떻게 모여서 하나의 화면을 만드는지 이해를 한다면 더 구조적이고 논리적인 디자인을 할 수 있습니다.
- Figma의 Autolayout을 잘 이용해서 디자인하면 개발이 편합니다. 제가 직접 개발할 때도 Figma로 먼저 만들고 CSS 코드를 복사해서 만들었습니다. 하나부터 코딩하려니 마음대로 안되더라고요. Figma in VScode 최고!
그래서, 디자이너도 코딩 공부해야 해요?
디자인하면서 코딩이 직접적으로 도움이 되었던 순간은 웹사이트를 만들 때였습니다. 생각보다 커스텀 하고 싶은 순간이 자주 생깁니다. 그럴 때마다 “내가 개발할 수 있을 거 같아!”라는 생각이 들면서, 툴에 디자인을 맞추지 않는 자유를 얻을 수 있었습니다.
프로덕트 디자인을 하는 과정에서는 코딩이 필수는 아니지만, CSS에 대한 이해와 디자인 시스템에 대한 이해는 필수라고 생각합니다. 더불어 어떤 컴포넌트가 어떤 구조로 설계되는지 어떻게 그 컴포넌트가 모여서 하나의 화면을 구성하는지는 경력을 쌓으면서 배워나가야 한다고 생각합니다. 최근 Figma의 config 2023에서 소개된 업데이트에서도 이러한 변화를 확인할 수 있었는데요. Figma의 Auto layout이나 Framer의 Stack은 필수이고, Design Token과 Component에 Props 개념이 구체화되면서 개발자와 디자이너 간 소통의 간극을 줄여나가고 있습니다.
저희는 빠른 시장 검증을 위해 상용화된 디자인 시스템인 Ant Design을 활용하고 있습니다. 몇몇 회사에서는 Storybook을 적극 활용하거나, 컴포넌트를 디자이너가 직접 개발하는 경우도 있습니다.
디자이너와 개발자가 협업하여 효율적인 작업 환경을 만들고, 작업의 효율화를 통해 얻은 시간을 유저 테스트, 인터뷰, UX Writing 등에 투자할 수 있을 것입니다. 개발자도 더 빠르게 개발해서 가설 검증을 돕거나 안정성이나 퀄리티를 높이는 데 사용할 수 있지 않을까요?
