고도화된 디자인 핸드오프 방안
디자인 핸드오프에 대해 잘 아시나요? 그리고 잘하고 계세요? 이번에는 어떻게하면 프로덕트 디자이너가 개발자에게 디자인을 잘 전달할 수 있을까에 대한 이야기를 해보려합니다. 맨 마지막에는 제가 실무에서 개발자분들께 전달하는 양식도 살포시 공유드려볼테니 끝까지 읽어주세요! ㅎㅎ
디자인 핸드오프?
우선 디자인 핸드오프에 대해 짚고 넘어가야겠죠? ‘Hand off’는 ‘손을 떠나다’ 라는 의미를 갖고 있습니다. 업계 용어로 대입하자면 ‘개발자가 구현할 수 있도록 디자인 작업물을 만들어 떠나보내다.’ 라고 생각하시면 될 것 같네요.
PM, 디자이너들은 잘 정돈된 핸드오프의 중요성을 느끼지 못하곤 합니다. 정작 중요하게 느끼는 사람은 그걸 직접 만드는 프론트엔드 개발자이죠. 처음에 디자이너가 되었을 때, 정말 의아했어요. 자기가 작업한 디자인을 의도대로 구현하되게끔 하기 위해서는 그만큼의 논리적이고 구조적인 사고를 토대로 디자인해야하는 부분이 필요하거든요. 하지만 주니어 디자이너 대부분은 그것을 모르고 있었고, 아마 지금도 어디선가에서는 많이들 놓치고 있을 거예요. 그래서 개발자가 필요로 하는 정보는 무엇이고, 자기가 하고자 하는 디자인의 의도가 정확하게 전달되기 위해서 어떤것이 필요할지에 대해 말해보려고요.
핸드오프에서 중요한 항목 세가지
크게 세가지로 나눌 수 있어요.
(화면 기준) 유저 플로우
각 화면 별 유즈 케이스
Responsive Layout 대응
User Flow
어떤 프로젝트가 진행되고 있고 디자인 시안 작업이 마무리되는 시점에 개발자가 가장 궁금해하는 것은 ‘그래서 이 프로젝트는 플로우가 어떻게 되는데? 각각의 화면은 어떻게 생겼는데?’일 거예요. 어떤 화면 흐름으로 설계되어있는지 보여준다면 다음과 같은 효과가 있었던 것 같아요.
개발자
큰 틀에서의 정보구조 설계에 도움이 된다.
구현에 있어 문제되는 지점을 파악할 수 있다.
구현 일정을 가시화할 수 있다. (스토리포인트 산정)
개발자를 포함한 모든 구성원
기획을 Shaping Up 해나가는 관점에서 모두의 얼라인을 맞추고 다음단계로 넘어갈 수 있다.
다양한 측면(Viability/Usability/Feasibility)에서 디테일한 의견을 나눌 수 있다.
Use Cases
숲을 바라보고 이해했다면 이제는 나무를 봐야겠죠? 유저 플로우에 따른 각 화면에 대한 상황별 케이스를 전달할 수 있다면 개발자에게나 다른 프로덕트 구성원에게나 큰 도움이 될 거예요. 프로덕트를 만드는 초보자들이 자주하는 실수 또는 놓치는 부분 중 하나가 이상적인 화면 딱 하나만 놓고 전달한다는 점인데, 그런 점에 있어 다양한 유즈케이스를 만들어서 화면으로 만들지 않으면 당신은 개발자분들의 질문폭격에 넉다운 될 수도 있어요.
질문폭격에 당황하거나 미워하지마시고, 당신이 부족하다고 생각하셔야 합니다. 유저는 다양한 케이스를 맞닥뜨릴 수 있기 때문이에요. 당신이 진정 UX를 좋아하는 사람이라면, 그리고 한명의 유저라면 다양한 케이스에 대해 꼭 고민해서 개발자분이 구현하실 수 있도록 만들어주세요. 하나의 화면만 봐도 아래와 같이 다양한 케이스를 보시게 될 수 있으니 참고해주세요.
Loading : 로딩 중
Empty (None) : 데이터 없음
One : 데이터 하나 있을 때
Some : 데이터 몇개 있을 때
Too Many : 데이터가 엄청 많을 때
Error : 에러
Success : 성공
Interactive : 화면 내에서 일어날 수 있는 인터렉션들
필자가 속한 팀에서는 디자인 시안을 확정짓고 난 다음에는 다양한 유즈케이스에 대해 생각해보고, 꼭 핸드오프에 포함시켜서 작업하는 것을 강조합니다. 위에서 말씀드렸듯 어짜피 개발하는 도중에 해당 유즈케이스는 밝혀지기 마련이에요. 그에 따라 필요시 개발자분들로부터 디자인 요청이 오기 때문에 사전에 작업하는 차원에서 말씀드리곤 합니다.
사실 이런 부분들은 경험이 쌓이게되면 누구나 자연스럽게 여러 유즈케이스를 포함한 핸드오프를 하시게 될텐데요, 그 때까지 매번 두들겨 맞으면서(스트레스받으면서) 배우시기 보다는 먼저 이런저런 케이스들을 고민해보시면 PM, 개발자분들로부터 ‘아 우리 디자이너분이 참 꼼꼼하네’라는 칭찬 정도는 들으실 수 있을 것 같아요.
Responsive Layout
유저플로우, 유즈케이스 모두 고려해서 핸드오프를 잘했다고 말할 수 있는가? 아니요! 또 중요한 한가지가 남아있습니다. 반응형 대응이에요. 모바일 앱만 보았을 때는 엄청 민감하게 고민할 사안은 아닙니다만 여러분이 하고 계시는 프로덕트가 웹이라면 더욱 집중해서 고민해야할 과제입니다.
Responsive하다라는 것은 무엇일까요? 그건 또 이야기가 길어지니 나중에 포스팅하여 말씀드리겠습니다. 디자인 핸드오프 시에는 디자인단에서 심도있게 Responsive Layout을 고려하여 전달하는 것이 원래는 옳습니다. 하지만 보통 디자이너가 웹개발을 배우지는 않잖아요? 그래서 많이들 누락하시고, 어려워하세요. 그에따라 커뮤니케이션 문제도 발생하고, 실제 구현된 산출물과 디자인간의 괴리가 생기기까지도 하죠.
이 글을 읽는 독자 여러분, 특히 프로덕트 디자이너분들! 본래 화면이라는 것은 다양한 디바이스에서, 다양한 뷰포트 사이즈에서 존재할 수 있습니다. 스마트폰부터 태블릿, 데스크탑, TV, 심지어 차, 키오스크까지 하나의 프로덕트를 다양한 곳에서 볼 수 있다는 것을 여러분들은 꼭 인지하고 계셔야 합니다.
웹을 예시로 들어보죠. 만약 여러분이 하나의 화면을 가지고 360 사이즈와 1920(또는 2560) 사이즈에서 보여지는 디자인만 만들어놓았다면 어쩌면 여러분은 직무유기라고 볼 수도 있고, 개발자분이 디자인을 대신해주고 있구나라고 생각해도 전혀 이상하지 않을 수도 있어요. 360과 2560사이 구간은 어떻게 보여질지 작업하시는 디자이너분들 한번이라도 상상해보셨습니까? 여러분의 디자인이 768에서는 어떻게 보여질까요? 1024, 1280, 1440, 1920에서는?
자기가 작업하며 보고있는 사이즈가 전부인 줄알고 디자인하는 사고는 버려야합니다. 그런 점에 있어서 구간별 레이아웃, 사이즈, 간격 등에 대한 정의는 다양한 화면에서 접근하는 유저들을 고려한 매우 세심하고 포용적인 행동이라고 볼 수 있겠습니다.
프로덕트에서 사용하는 Breakpoint를 개발자와 디자이너가 함께 규정한 뒤, 해당 Breakpoint를 기준으로 나뉘어진 구간에 따라 변화되는 지점을 디자인하고 투명하게 공유하세요. 그러면 개인에게는 역량 성장의 발판을, 팀원에게는 신뢰를, 유저에게는 더 좋은 퀄리티의 디자인으로써 로열티를 가져오리라 확신합니다.
그래서, 제가 고안해낸 방법은요!
실무에서 디자이너를 포함한 모든 프로덕트 구성원이 함께 피그마를 보면서 빠르게 소통할 수 있는 방안을 고도화해나갔고, 결론적으로 위 세가지를 모두 만족하는 구조가 되었어요.
Userflow in Figjam File.
목적 : 전체적인 플로우를 확인하면서 피드백을 받고, 얼라인을 맞추기 위함.
보는 대상 : 프로덕트 팀(PM/PO, PD, FE, BE)과 이와 관련된 이해관계자 모두
작업 방법
유저플로우는 프로젝트마다 디자인을 끝마친 각 화면을 피그잼에 놓고 이어놓기! 단, Project A 피그잼 파일안에는 반드시 Project A와 관련된 화면만 있어야 한다.
각 화면 상단에는 화면 타이틀이 존재하며, 상세한 유즈케이스와 반응형 레이아웃을 확인하고 싶다면 해당 화면의 피그마 파일로 이동시키기! (화면 타이틀 우측 상단 링크)
보는이가 플로우와 디테일을 원하는대로 확인할 수 있도록 사용자 온보딩은 필수!
More Details in Figma Design File.
목적 : 각 화면별로 상세한 스펙(수치)을 확인하고 여러 유즈케이스, 반응형 레이아웃에 대한 설계를 확인하고 구현하기 위함.
보는 대상 : 프로덕트 팀(PM/PO, PD, FE, BE). 그 중 제일 많이 보는건 PD와 FE.
작업 방법
(웹을 예시로) 정해놓은 구간에 따라 디자인을 한다.
상황별 유즈케이스는 하단에 작업한다.
디자인에 대한 설명(반응형에 따른 변화, 인터렉션, 레이아웃에 대한 자세한 의도 등)은 코멘트를 달아둔다.
수정발생 시, 구분자(추가/수정/삭제)에 따라 코멘트를 달아둔다.
정리
유저플로우와 상세화면을 별도로 관리되어 프로젝트에 맞게 디자인 진행 후 화면들을 모아 피그잼에서 소통하는 방식은 보이지는 않지만 팀의 깔끔한 소통에 도움을 줄 수 있습니다. 디자이너가 아니더라도 프로덕트팀 모든 직군이 피그잼/피그마를 자연스럽게 키고 그에 대해 대화하는 모습을 확인하면서 이전보다 매끄러워졌다는 생각을 하게되었거든요. 이렇게 팀의 생산성을 위해 고민하는 것이 즐겁다는 것도 위와같은 경험을 통해서도 다시금 느끼곤 합니다.
앞으로도 도움이 되는 글 계속 발행해보겠습니다. 긴글 읽어주셔서 감사해요.
Q&A. 글을 쓴 이후에 지인으로부터 질문이 들어와서 답변남깁니다.
Q. 유저플로우를 피그마보다 피그잼을 활용하는 명확한 이유가 있을까용?
1.
피그마에는 궁극적으로는 많은 화면이 작업되는 공간으로 쓰이는 것은 도메인(바운디드 컨텍스트)를 뭉개는 행위로 이어질 수 있으며, 다수의 화면이 모아진 피그마 파일은 작업하는 브랜치가 모호하게 생성할 수밖에 없게됩니다.
2.
피그마라는 파일자체가 명확히는 작업하는 프로덕트 디자이너와 작업하는 프론트엔드 개발자가 주로 보는 화면입니다. 그에따라 좌우패널에 레이어와 스펙을 확인할 수 있는 공간이 디폴트로 나타나게 되는데요. 이 부분을 확인할 필요없는 사람도 볼 수 밖에 없는게 (화면을 꽉 차게 볼 수 없는) 좋지않은 경험으로 다가옵니다.
그에 비해 피그잼은 애초에 이 프로덕트(프로젝트)에 관심있는 모든 사람이 볼 수 있는 화면으로 설계되어있습니다. 좌우 패널없이 모르는 사람도 들어오자마자 한눈에 보기 쉽고, 조금의 설명을 적어놓으면 온보딩도 빠르게 할 수 있습니다.
3.
피그마보다 피그잼이 연결이 훨씬 쉽습니다.
참고자료
How to make programmers happy and design-to-developer handoff less painful, Helen Shabanova
File structure best practice guide, Luis Ouriach
[https://www.figma.com/community/file/1004041613962064465]
