구조적인 사고에 기반한 피그마 디자인
완성도 높은 프로덕트 구현을 위한 전달력
제품을 만들어 나가는 과정에서 프로덕트 디자이너는 정말 중요한 위치에 서 있습니다. 문제 정의부터 아이디어를 실체화하는 데까지 정말 많은 기여를 하는 사람이기 때문이에요.
프로덕트 디자이너는 마치 찰흙처럼 아무 형체도 없던 것을 디테일한 부분까지 살려서 완벽한 형체로 만들어냅니다. 보는 이로 하여금 전달하고자 하는 의도를 명확하게 표현하는 것, 그것이 여러 직무 중 프로덕트 디자이너 만이 고유하게 지닌 전문성이라고 생각합니다.
사용자의 니즈를 충족시키는 프로덕트를 만들기 위해서는 우리 조직 내부에서도 추상화된 아이디어부터 구체적인 결과물이 도출될 때까지 명확한 전달 과정이 필요합니다. 오늘은 이것을 주제로 이야기해보고 싶어요.
사용자에게 우리의 의도를 잘 전달하기 위해서는 두 가지 전제가 존재합니다.
사용자가 이해하기 쉽도록 프로덕트 디자이너가 잘 설계하고 디자인해야 한다.
잘 만든 디자인을 개발자가 잘 구현해야 한다.
1에 대해서는 여기서 이야기하지는 않겠습니다. 이에 대해서도 할 이야기가 많으나, 오늘 이야기하고 싶은 주제는 1번과 관련된 것은 아니므로 이 부분에 대해서는 다른 글로 찾아뵙겠습니다.
2번 ‘잘 만든 디자인을 잘 구현해야 한다’가 되기 위해서는 아시다시피 디자이너와 개발자 간의 노력이 필요합니다. 디자이너는 어떻게 구현되는지 조금이라도 관심을 가져야 하고, 개발자는 왜 디자이너가 이런 사소한 것에 집착하는지 이해하는 자세를 가져야 하죠.
‘개발자가 잘 구현하게 한다’는 것의 실체는 무엇일까?
프로덕트 디자이너들은 자신이 의도한 대로 구현이 제대로 안되면 실망하고, 스트레스를 받습니다. 보통 QA를 통해 많이 발견하게 되죠. 이것이 여러 스프린트동안 동일한 패턴의 문제가 계속 발생한다면 눈썰미와 디자인에 소질이 없는 개발자만의 문제일까요? 그건 아닙니다. 디자이너도 구현에 있어 비슷한 문제가 왜 자주 리포트되는지 고민하고 개선해야 합니다.
이 문제을 꿰뚫는 핵심은 구조적인 사고에 있다고 생각합니다. Schema 2022에서 피그마 VP인 Sho Kuwamoto는 창의적이고 쉽게 그려낼 수 있는 자유 형식의 디자인(Freeform Design)만으로는 실제 구현까지는 부족하며, 구조화된 디자인(Structured Design)적 사고가 뒷받침되어야 안정적인 구현을 이루어낼 수 있다고 말합니다. 또한, 이 두 종류의 디자인은 어느 한쪽에 치중한 것이 아닌 동등하게 중요한 영역임을 강조했습니다.
프로덕트 디자이너를 시작하는 대부분의 사람들은 Structured Design에 대한 사고가 높지 않습니다. 그럴 수밖에 없는 게, 그들은 UX/UI에 관심 있고 프로덕트 디자이너를 시작했지 저처럼 개발을 먼저 시작하고 UX/UI를 하지 않았기 때문에 자연스러운 현상인 것이지요. 하지만 이 글을 계기로 ‘아이디어를 잘 실현시킨다’는 관점에서 두 디자인의 중요성에 대해 꼭 한 번쯤 깨닫고 넘어가셨으면 좋겠습니다.
일단 구조적인 사고를 얕게 알게 되는 것만으로도 개발자와의 커뮤니케이션 능력도 늘고, 이전보다 향상된 생산성에 기반하여 고객에게 전달할 수 있다는 측면에서 장점이 있습니다. 하지만 이게 끝이 아닌 점점 깊이 들어갈수록 전문적이고 심오한 영역을 경험하실 수 있을 텐데요. 그것이 바로 디자인시스템입니다.
제가 좋아하는 사람 둘을 언급할 차례가 되었네요. 피그마를 극한으로 끌어올려 사용할 수 있다는 것은 한편으로는 디자인시스템을 정말 잘 이해하고 있다고 말해도 무방합니다. Mr.Biscuit은 Freeform Design과 Structured Design을 포함하여 나아가 디자인시스템, 생산성이 얼마나 중요한지를 ‘Figma Skill Tree’로써 말하고 있고요(참고로 Mr.Biscuit은 피그마로된 Ant Design System 라이브러리 만든 사람입니다). 피그마 소속의 Luis Ouriach는 디자인시스템 컨퍼런스에 참여하여 디자인시스템 컴포넌트의 구조 설계와 Complex File Organization이 얼마나 어려운지 이야기하기도 합니다.
단순히 ‘개발자에게 잘 전달해야지~’를 너머 프로덕트 생산성과 확장성을 아우르는 조직적인 체계 확립으로 이어질 수 있는 부분이라고 생각해요.
어떻게 하면 구조적인 사고에 기반하여 디자인할 수 있을까?
코딩을 배우세요 ㅎㅎ.
농담이고요. 고급 과정(디자인 시스템, 반응형 레이아웃)을 제외하고, 구조적인 디자인의 시작을 화면 디자인 기준으로 먼저 말씀드리자면 아래 세 가지를 말씀드릴 수 있을 것 같아요.
레이어의 구조
레이어의 이름
레이어 간 간격
레이어 구조
출처. Design good practices레이어의 구조는 화면 기준으로 큰 덩이부터 아주 잘게 나누어진 작은 요소 하나하나까지 맞춰주면 좋습니다. 저 같은 경우, 캔버스에 위아래로 배치된 요소 기준으로 레이어 패널에 상하순으로 정렬시켜 놓고 Tab, Shift+Tab을 하며 포커스를 이동하며 조작하고, 캔버스에 좌우로 배치된 요소 기준으로는 역시 레이어 패널에 좌우로 정렬시켜 놓는 원칙을 따릅니다. 이유는 캔버스와 레이어에서 보이는 순서 및 방향을 일치시키니 인지하고 조작하기 쉬웠기 때문입니다.
그루핑이 필요한 요소는 ‘Container’로 프레임화 시켜 관리하고 있어요. 이때, 꼭 아셨으면 하는 두 가지가 있는데요. 첫 번째, 묶음이 필요하다면 그룹이 아닌 프레임을 되도록 사용하기와 두 번째, 불필요한 프레임 마구 만들지 말기입니다.
첫 번째에 대한 이유는 여기를 확인하시면 될 것 같고요. 두 번째에 대한 이유는 실제 개발하는 데 있어, 이유 없이 불필요한 프레임을 겹겹이 쌓아놓는 건 개발로 구현하기에는 UI적인 redundancy가 올라간다고 생각되기 때문입니다. 되도록 간단하게, 꼭 필요한 상황에서 만드는 것이 바람직합니다.
레이어 이름
저 역시도 레이어 이름 짓기에 대한 고민을 하고 적용해 오면서 나름대로 변천사가 있는데요, 수많은 계절을 거쳐 제가 확립한 결론은 위 그림과 같아요. 하이픈을 기준으로 좌측은 형태적인 이름, 우측은 Contextual 한 이름을 동시에 적어주는 것으로요. 그러면 어떤 요소이며, 그 요소가 이 컨텍스트에서는 어떤 의도로 사용되어 있는지 정확히 이해할 수 있거든요.
물론 이게 Best Practice이고 정답이냐라고 묻는다면 꼭 그렇지는 않습니다. 다만, 정답에 가깝도록 많은 고민을 했다고는 말씀드릴 수 있을 것 같아요. 저만큼, 또는 저보다 많이 고민한 세계의 여러 사람들의 예시링크도 여러분들의 참고를 위해 붙여놓도록 하겠습니다. (예시 1, 예시 2)
출처. Design good practices컴포넌트에 대한 인스턴스는 마스터컴포넌트 명을 그대로 갖다 쓰시는 경우가 있는데요, 이 부분은 명백히 잘못된 부분입니다. 인스턴스는 해당 컨텍스트에 맞게 자기만의 이름을 가질 수 있어요. 사람이라는 마스터 컴포넌트에 대해 모든 사람이 이름 없이 사람, 사람, 사람은 아니잖아요? 사람마다 이름이 있듯이 피그마안에서 생겨난 컴포넌트의 인스턴스도 컨텍스트에 맞는 이름을 정해주면 좋을 것 같아요.
출처. Design good practices위에서 제가 정립한 레이어 네이밍 컨벤션에 의하면, 저는 형태적인 이름과 Contextual 한 이름 둘 다 써주는데요. 형태적인 이름만 적어주는 예시는 존재하지만, Contextual한 이름만 적어낸 예시는 존재하지 않아요. 왜냐하면, Contextual 한 이름을 적어내면 애초에 그 요소가 갖는 본래 의미를 알 수 없거든요. 예를 들어, Button - Shop Now 또는 Button으로는 적을 수는 있겠지만, Shop Now라고 적으면 그게 버튼인지 아닌지 레이어만으로는 판별하고 다른 것과 구분 지을 수 없는 것처럼요.
레이어 간 간격
레이어 간 간격은 하나의 기본적인 약속이에요. 디자이너 간 약속, 그리고 디자이너와 개발자 간 약속이요. 사실 이게 디자인시스템의 첫걸음이라고 할 수도 있어요. 요새는 8pt 그리드, 4pt 그리드를 주로 많이 사용하실 텐데요. 저희 팀 역시도 4pt 그리드를 기본적으로 따르는 것으로 소통하고 있어요.
이렇게 8 또는 4pt 그리드를 사용하는 이유에 대해서는 브런치에도 많은 글들에 적혀있겠지만 다른 데 가서 읽기 귀찮으실 수 있으니 세줄 요약해 드리면 아래와 같습니다.
Consistent UI
고객에게 좋다! 고객에게는 알게 모르게 일관적인 느낌을 전달한다! 이야~ 이 집 깔끔하네!
Fewer Decision = Less time
디자이너에게 좋다! 이 간격을 6으로 할까? 7로 할까? 8로 할까? 묻지도 따지지 말고 8, 16, 24! 디자인 쉽다!
개발자들에게 좋다! 대충 봐도 아 8이겠거니 16이겠거니! 얼쑤! 마크업 쉽다!
Multi-platform design
이 세계는 정말 다양한 화면사이즈가 있다네! 그것을 모두 매끄럽게 대응하는 건 되도록 짝수가 좋다네!
예를 들어, 1024 너비에서는 5, 10pt grid는 호환성이 낮다.
위와 같은 이유로 간격이라는 최소한의 약속만으로도 개발자의 UX는 향상될 수 있습니다.
정리하며
사실 이 글을 작성하게 된 이유는 우리나라에는 UX 전반적인 내용, 문제정의, 가설과 검증, Inspiration 등의 글들에 비해 실무자들에게 실용적이고 회사에 가자마자 실속을 챙길 수 있을 만한 글들이 조금 부족하다는 느낌이 들어서 발행하게 된 것 같아요. 우리나라 프로덕트 디자이너분들 다 잘하시고, 성장에 대한 갈망도 많으시리라 생각되는데 답답하거나 물어볼 사람이 제한적일 때도 꽤 있을 거라 생각되었거든요. 제 옆자리를 너머 이전 직장에서, 또는 옆팀에서 저를 찾아와 질문을 하고 ‘아! 하나 배웠다!’는 표정과 말을 전해받으면 그렇게 뿌듯할 수가 없답니다. 이 글을 보시는 여러분들도 좋은 영향받으셨으면 좋겠습니다.
감사합니다. 다음 글에서 뵐게요~ 안녕!
참고자료
Groups and Frames, Figma Best Practices
[https://www.figma.com/best-practices/groups-versus-frames/]
AMA with Figma Design Systems London #5, Luis Ouriach
[https://youtu.be/6DOav3P2fzA?t=533]
Figma Skill Tree, Mr.Biscuit
[https://www.figma.com/community/file/1047077832299989222]
Schema 2022 Tokyo Opening Keynote, Sho Kuwamoto
[https://www.youtube.com/watch?v=EKIj_-QkbZQ]
Design good practices
[https://goodpractices.design/]
Guide: Layer naming conventions, Luis Ouriach
[https://www.figma.com/community/file/1064955840810792842]
The 8-Point Grid
