디자인 시스템을 만들때 마주하는 고민사항 24가지, 실험, 그리고 해답.
디자인 시스템의 필요성과 중요성에 대해서는 잘 알겠다고요? 하지만 어디서부터 시작할지, 어떻게 하는 것인지 가늠은 되지만 구체적으로 우리가 가진 문제점은 어떻게 해결하면 좋은지, Figma의 Auto layout과 Variant, Property는 어떻게 사용해야 효율적인지, 어떻게해야 고생은 덜하는지! 자잘 자잘한 디테일에 대한 실용적인 대답은 찾지 못하셨나요? 아무리 디자인에 정답은 없다지만, 출발점은 있어야하지 않을까요? 저 또한 같은 질문을 했지만 20만원짜리 강의들, 실리콘밸리의 영문 기사에서도 찾을 수 없었습니다. 지난 반년간 디자인 시스템을 만들면서 마주한 질문과 해답을 공유해드리겠습니다!
디자이너 1인, 기획자 1인, 개발자 4인,
2달, 101개 화면, 605 컴포넌트, 149색상, 17텍스트 스타일, Monorepo
Background & Overview
2020.11, 가벼운 학습지가 해결해야할 사항은 이랬습니다.
Sketch에서 Figma로 열어서 깨진 컴포넌트들 다시 연결하기, 파일별 네이밍 ‘rectangular copy34’ 청산하고 컨벤션 규칙 세우기, 페이지 반응형으로 만들기!
2021.2, 메인 서비스의 디자인 시스템이 미확립된 상태에서 신규 비즈니스가 생겼습니다! 아무것도 없는 빈 페이지에서 새로운 온라인 교육 플랫폼을 만드는 것이죠. 정리되어 있지 않은 기존의 서비스 파일을 불러와서 써도 될까요? 새로 만든다면 어디서 어떻게 만들어야할까요?
20–30개의 디자인 시스템 포스팅을 읽고, Microsoft Fluent Web/Android/iOS, Shopify Polaris for Admin, Asana, Slack, Pegasus Design System, Ant Design System 의 Figma 내 디자인 시스템을 비교했습니다. 그 결과로 메인 서비스의 고도화를 진행하면서 동시에 신규 서비스의 화면을 무리없이 모두 만들어낼 수 있었습니다.
하기 질문 리스트에서 궁금했던 부분을 찾아 확인해보세요.
질문 리스트
- 디자이너 혼자서 작업해도 디자인 시스템을 만들어야할까?
- 레거시를 청산하고 디자인 시스템을 만드는 전체 과정은 어떻게 될까?
- 디자인 파일 레거시는 어떻게 청산하면 좋을까?
Top Down, 아니면 Bottom up? - 네이밍 컨벤션 ‘/’ 대쉬를 얼만큼 사용해야할까?
아트보드, 마스터 컴포넌트 레이어 이름에서 써도 될까?
폴더링은 어떻게 해야하지? - Variant, Property는 어떻게 표기하면 좋을까?
Right, Left, Active, Inactive.. On? Off? - 텍스트 스타일을 어떻게 정의해야할까?
- 텍스트 스타일의 네이밍은 어떻게 해야할까?
H1,H2,H3.. Title, Subtitle../48 Bold, 24 Bold, 18 Medium.. - 영문과 한글을 어떻게 호환할까?
- 텍스트의 line-height는 4의 배수여야할까?
- 텍스트 스타일로 UI 스타일을 관리할 수 있을까?
- 색상 가이드는 어떻게 만들면 좋을까?
- 색상의 이름을 어떻게 지어야할까?
- 그림자 스타일은 몇 단개면 될까?
- Line을 Shadow로 설정해도 될까?
- 피그마 Page의 트리구조는 어떻게하면 좋을까?
페이지 네이밍, 아트보드 네이밍. - 만들어야하는 컴포넌트의 종류 어떤게 있을까?
Icon, Form, Check box, Radio, Input, Option, Select, Card, Modal, button.. - Atom? Token? 어떻게 정의할까?
- PC와 Mobile의 스크린 사이즈 기준을 어떻게 잡을까?
- 8px? 왜 4의 배수로 작업해야할까?
- 추천하는 플러그인
- 하나를 바꾸면 모든 화면이 바뀌는 마스터 페이지, 마스터 컴포넌트는 어떻게 설계할까?
- 제플린을 사용해야할까?
- 제플린에서 스타일 가이드라인을 어떻게 활용할까?
- 제플린에서 페이지 네이밍을 어떻게 해야할까?
용어
- 아트보드=Frame : 어도비에서 사용하는 Artboard를 Figma에서는 Frame이라는 이름으로 사용합니다. 본문에는 이 글자가 혼용되어 있습니다.
- 텍스트 스타일=Text Styles : 텍스트의 스타일을 관리하는 Figma의 Text Styles를 의미합니다.
1. 디자이너 혼자서 작업해도 디자인 시스템을 만들어야할까?
Painpoints
- ‘여기 간격 값이 뭐였더라? 서체 크기가 몇이었지? 색상 값이 뭐였더라..’
- ‘Sketch에서 Figma로 import해서 파일이 다 깨져있어..텍스트에 색상이 2개씩 적용된 것은 아예 글자가 다 날아가서 보이지도 않아.’
- ‘레이어별로 네이밍이 된 것 같아보이는데, 살펴보면 다 copy copy copy..’
- ‘메인 서비스의 UI시스템이 없는데 새로운 서비스의 UI시스템을 2달 내로 만들 수 있을까? 어디서부터 시작해야하지..’
- ‘컴포넌트 하나를 수정할 때 마다 모든 페이지에 찾아가서 다 일일히 수정해야하면 야근을 피할 수 없을거야.’
다른 보드를 찾아서 규칙을 확인하는 시간에 UI를 완성하고, 다시 보드를 찾아서 보고 확인하는 시간에 UI를 완성하고, 더 나아가서 사용자조사를 할 수 있으면 어떨까요? 간격을 기억하기 쉽고, 반복 작업을 피하고, UI 스타일을 손쉽게 바꿀 수 있습니다.
언제까지나 혼자서 디자인을 할 수는 없을거에요. 팀이 생길 것입니다. 다른 사람도 이해할 수 있는 컴포넌트 구조를 어떻게 만들면 좋을까요? 항상 그것을 염두하여 구조를 설계합니다.
2. 레거시를 청산하고 디자인 시스템을 만드는 전체 과정은 어떻게 될까?
전체 프로세스
사업 방향, 프로젝트 목표 이해하기 → 이해관계자, 기획자, 개발자 인터뷰, 시스템 필요성 공감하기→ AS IS — TO BE 설립을 위해 지금 UI 업무 시스템 및 스타일, 작업 방식 확인하기 → 여러가지 타사 사례 수집 후 분석하여 벤치마킹할 것과 개선할 점 파악하기 → 구체적인 디자인 시스템 제작하기. (많이 고민이 일어나는 지점) → UI 제작하기→ 디자인 Hand-off 제플린에 스타일 가이드, 컴포넌트, 화면설계 이전하고 파일 트리 구조 만들기 → 디자인 시스템 활용하여 협업하기 → 개선하기.
3. 디자인 파일 레거시는 어떻게 청산하면 좋을까?
Top Down, 아니면 Bottom up?
레이아웃과 컴포넌트의 이름은 copy와 group의 향연, Auto Layout과 Variant그룹화는 없는 상태. 스타일도 제각각. 그렇지만 전체 UI는 나와있는 상태. 어디서 어떻게 해결하면 좋을까요?
- Top Down : 규칙을 만들어서 일괄적으로 적용하기. 중간에 발견하는 예외사례는 규칙 내에 강제적으로 포함한다.
- Bottom Up : 사용중인 서체 크기, 버튼 스타일, 그림자, 색상 등을 모두 열거하고 확인하여 공통점을 묶어가며 조금씩 바꾸어가는 방법. 마지막에 규칙이 도출된다.
정답은 두 방법을 모두 활용하는 것입니다. 둘 중의 하나만 선택하려고 하면 고민이 길어지고 속도가 나지 않아요. 시간이 얼마나 낭비될지 두려워하지 말고 Bottom Up 방식을 따라 먼저 전체 볼륨을 파악해보세요. Page에 ‘레거시 확인하기'를 하나 만들어서 통일하고 싶은 컴포넌트를 모아보세요. 규칙을 찾아보세요. 규칙이 없다면 Top Down 방식으로 좋은 규칙을 만들어서 적용해보세요.
좋은 규칙이 무엇인지 모르겠다고요? 각 항목마다 고민이 되는 사항을 아래에서 찾아보세요. 여러가지 시도와 실패 사례를 통해 무엇이 적합할지 고민해보세요.
4. 네이밍 컨벤션 ‘/’ 대쉬를 얼만큼 사용해야할까?
아트보드(Frame), 마스터 컴포넌트 레이어 이름에서 써도 될까?
폴더링은 어떻게 해야하지?
피그마의 레이어 이름에 ‘/’를 사용하면 파일 추출시에 폴더링이 된다는 것을 아시나요? 이 기능을 활용해서 일괄 추출때 모든 컴포넌트가 한 폴더에 정리되어 있게 만들 수 있어요! 처음부터 이 시스템을 활용하여 한번에 베스트 프렉티스를 만들겠다는 부담은 내려놓으세요. Command(Ctrl)+R을 통해서 레이어 이름을 쉽게 바꿀 수 있습니다.
대쉬 ‘/’를 레이어 이름에 남발하지 않는 것을 추천드려요. 개발자에게 특정 svg 파일 하나를 전달하기 위해 폴더안의 폴더 클릭하는 것을 피하고 싶다면요.
마스터 컴포넌트에서도 대쉬‘/’로 위계를 구분할 필요는 없습니다. 제플린을 사용하지 않고 모든 컴포넌트를 일괄 다운로드해야한다면 그 때 상황에 맞게 ‘/’와 이름 바꾸기 기능을 이용하여 폴더링 시스템을 만들어보세요.
폴더링 방식은 1. PC/Mobile/iPad 디바이스별로 나누기, 2. 페이지별로 나누기, 3. 컴포넌트별로 나누기 등이 있습니다.
색상 스타일과 텍스트 스타일에서 ‘/’로 폴더링을 사용하여 하위 색상값 구분을하면 정리가 잘 됩니다. 한번에 많은 색상을 만들고 관리한다면 Styler와 Design System Organizer를 사용해보세요.
네이밍 컨벤션 참고자료: Best Practices for design system naming conventions.
가벼운 학습지를 맡은 지난 11월에 읽었습니다. 좋은 네이밍 컨벤션으로 피그마 파일을 시작하고 싶었거든요. 돌이켜보면 이 글을 읽고 만든 네이밍 컨벤션은 아주 많은 문제점을 가지고 있었습니다. 해당 글의 전반적인 분류법은 도움이 되지만, 추천하지 않는 방법을 언급드릴게요.
- Button을 btn으로 줄여쓰지 마세요. 다른 약자와 헷갈려서 코드상에서 오류를 일으킬 수 있는 것은 약자로 쓰지 않는게 좋습니다. 길어져도 모든 글자를 다 쓰세요.
- ‘/’로 표시된 대로 네이밍에 모든 대쉬를 붙이지 마세요. 폴더링됩니다. 게다가 필요없는 중복값을 계속 써야해요. 중복값을 쓰지 마세요. 이건 마치 개발에서 모든 코드를 div로 쓰는 것과 같습니다. li, oi, article, p, 등 여러가지를 쓰듯이 여기서도 그렇게 하세요. Frame이름, 컴포넌트가 지칭하는 이름만 간략하게 명시하세요.
- Right, Left를 네이밍에 쓰지 마세요. 화살표, 버튼과 같이 한번 명명되면 위치가 변하지 않을 컴포넌트의 Property로 사용하세요.
*위의 링크에서 안내하는 사항을 모두 따르고자 ‘/’대쉬를 남발하지 마세요. 이러한 안내 포스팅을 따라 한 레이어에 이름을 모두 정의할 필요는 없습니다. 각각의 레이어의 이름만 간략하게 한 두 단어로 정의하세요. Frame이나 그룹 내부, Auto layout 내부에 각각의 이름을 짓고 전체에는 다른 이름을 지어주세요.
5.Variant, Property는 어떻게 표기하면 좋을까?
Right, Left, Active, Inactive.. On? Off?
Figma의 Variant와 Property기능을 활용하면 스케치로 UI를 만들고 관리하는 것보다 몇 배는 많은 시간을 절약할 수 있습니다. Property속성을 on/off로 만들면 각 컴포넌트를 토글로 관리할 수 있거든요.
Property의 메뉴를 드롭다운으로 만들면 무슨 항목이 있는지, 어떤식으로 네이밍 컨벤션했는지 기억해야합니다. 우리는 그 모든 것을 기억할 수 없죠. 버튼으로 예를 들어 보겠습니다.
- Type : Active, inactive, Enable, Disable.
- Active : on/off
Disable : on/off
Property(속성)값을 2개를 만들어 on/off로 사용하는 것이 훨씬 빠릅니다. 드롭다운에서 숨겨진 상태값을 열어 확인하고 선택하는데에 3초가 걸린다면 이미 화면에 노출되어 있는 속성값을 읽고 토글하는데에 걸리는 시간은 1초정도 밖에 걸리지 않죠.
그렇다면 속성값으로 쓰기에 나쁜 이름과 좋은 이름은 무엇일까요?
스타일 속성으로 Property 규칙을 세우는 것은 정말로 비효율적입니다. 예를 들어 Radius값 같은 것을 표기할 필요는 없습니다. 그만큼 스타일을 다양하게 사용하여 UI를 만들 것이 아니니까요.
자주 활용하고 구분하는 방식을 속성 이름으로 쓰세요. Active, Disable, Size, Type, Outline, Check, Filled, Direction, Selection, Icon, Hover, Click, 등을 사용하세요. Property 리스트가 길어져도 이렇게 쓰는 것이 확장성이 높습니다. 단순한 규칙을 따르기위해 생기는 복잡성, 이런 복잡성은 다양함이고 우리를 더욱 편하고 빠르게합니다.
*Tip : on/off, Yes/No, True/False 대응되는 단어면 토글 기능으로 구현됩니다.
6. 텍스트 스타일을 어떻게 정의해야할까?
레모네이드의 개발팀의 주간회고에 이 안건은 3번이나 나왔습니다. 시우님(팀장님)이 조언하시길, 7~8개의 크기차이면 충분하다 했죠. 가벼운 학습지의 글자크기와 굵기대로 다 나눠보니 이게 웬걸, 20개도 넘겠던걸요? 8,9,10,11,12,13,14,15,16,17,18,19,20..px! 가능한 사이즈란 사이즈는 모두 나왔던걸요? 여기에 Bold, Medium, Regular을 곱하면 또 어떻고요!
이럴때는 Top Down방식으로 적절한 사이즈를 정해 일괄 수정합니다. 플러그인 Similayer와 Typesacles를 사용해서요. (*플러그인에 관해서는 20번을 참조해주세요.) 적절한 사이즈는 어떻게 고르냐고요? 화면에 여러 스케일을 나열해보세요. 그리고 적합한 사이즈를 뽑아서 조합해보세요. Auto layout기능으로 위치를 바꿔가면서 비율이 어떻게 달라지면 좋을지 스타일을 빼고 넣어보세요.
글자 크기가 클수록 제목용 서체입니다. 제목용 서체는 글자의 형태가 잘 보이고 결함이 있어도 눈에 잘 띄지 않죠. 개성있는 서체를 사용해도 됩니다. 그리고 굵기가 서비스의 분위기를 좌우합니다.
본문용 서체로는 14px을 많이 사용합니다. iOS디바이스 에서는 13px을 기본 사이즈로 사용하기도 하지만요. 정보를 읽는 피로도를 낮추기위해 16px을 기본 사이즈로 사용하기도 합니다. 50대 이상의 사용자가 늘어남에 따라 전반적인 글자 크기를 키우고 Bold를 활용하는 추세가 2019년부터 생겼습니다. 왓챠, 카카오톡, 샐러드뱅크, 차이카드, 네이버 등 많은 서비스에서 굵고 큰 글자의 네비게이션을 볼 수 있습니다.
기준 서체를 잡고 그 아래로 더 작은 서체, 더 큰 서체를 정하세요.
7. 텍스트 스타일의 네이밍은 어떻게 해야할까?
H1,H2,H3.. Title, Subtitle../48 Bold, 24 Bold, 18 Medium..
이거 참 어려운 부분입니다. 디자인 시스템을 검색하면 나오는 레퍼런스들은 모두 이상적이거든요. 오히려 스타일 가이드에 가깝달까요? 포트폴리오가 아니라 운영하는 서비스를 위해서는 어떤 규칙을 가져야 할까요? 수 많은 엣지 케이스와 확장성을 고려해야하는데 말이죠.
H1,H2,H3.. Body, footer.. 편한점과 한계점
누구나 이름만 보고 클릭하여 사용할 수 있습니다. UI의 내밀한 규칙을 모르는 사람도 이해하기 쉽죠. h1에서 h6까지 적용하면 개발자와의 소통도 편해질 겁니다. 하지만 예외사항을 커버할 수 없는 단점이 있습니다. Body1과 Body2의 차이를 이름에서 알 수 없습니다. 본문에서 Bold처리를 한다면 어떻게 할까요? 디자인 시스템에서는 어떻게 관리할 것인가요? h1크기가 headline이 아닌 곳에서 사용된다면 어떻게 하나요? 또 다른 한계점은, H1의 속성을 이름에서 알 수 없다는 것입니다. 또한 어느 페이지, 어느 컴포넌트에서 사용되었는지 모르죠.
48 Bold, 24 Bold, 18 Medium..편한점과 한계점 * 추천하는 방식입니다.
서체를 선택할때 중요하게 고려하는 2가지가 뭘까요? 크기와 굵기입니다. 스타일 선택에 기준이되는 요소를 이름에 드러내 놓습니다. 디자이너가 사용하기에 적합하고 편한 방식입니다. 한계점은, 해당 스타일이 Header에 사용되는지, Navigation에 사용되었는지 사용처를 모른다는 것입니다.
하지만 그런 것을 일일히 기록하고 알아야 할 필요는 없습니다. 특히 텍스트 스타일 최초 설정 후 바꿀 생각이 없다면요. 그리고 최초 설정값을 바꾸지 않는 것이 정신건강에 좋습니다.
서비스 환경별로 서체크기를 달리 쓴다면 환경 이름을 앞에 붙이고 ‘/’를 사용하여 폴더링 해보세요.
PC / 48 Bold, PC /24 Bold, iOS/ 48 Bold, iOS/24 Bold, Android / 48 Bold, Android/24 Bold..
Similayer를 사용하여 일괄적으로 변경할 수 있습니다.
8. 영문과 한글을 어떻게 호환할까?
신규 서비스 패스트원에는 영어를 사용하는 티처, 한글을 사용하는 학생 두 사용자 집단이 있습니다. 영문과 국문이 모두 필요했죠. 이런 상황이 아니어도 다국어 환경은 고려되어야합니다.
- Font-family가 다국어를 지원하는가?
- 서비스의 사용자 군이 영어와 국문을 모두 사용하는가?
- 서비스 내에 영어를 사용하는 비율이 큰가?
영어를 사용하는 비중이 낮다면 한글 중심의 서체를 설정하고 영어는 따로 설정하지 않아도 됩니다. 그러나 영어와 한국어를 구분하여 사용하고 싶다면 디자인 시스템에서 이렇게 사용해보세요.
7번에서 소개한 규칙 서체크기 + 굵기 (ex. 24 Bold)에 언어+서체이름을 추가합니다.
9. 텍스트의 line-height는 4의 배수여야할까?
Microsoft의 Fluent를 확인하면 iOS, Web, Anroid에 따라서 텍스트 스타일이 각기 다르게 설정되어있습니다. line-height는 Web에서는 4의 배수거나 짝수로 덜어지지만, iOS에서는 홀수로 떨어지기도 하죠.
Input Field나 아이콘 등 텍스트와 나란히 쓰는 컴포넌트들이 4px 배수로 만들어져있다면 텍스트의 높이도 4의 배수로 떨어지게 맞추는 것이 좋습니다. 단일 단위로 사용할 때도 Auto layout에서 여백 규칙을 망가트리지 않거든요.
이 때 주의할 사항은 각 폰트별로 x-height가 다르게 설정되어 있어 원하는 것보다 글자의 하단 여백이 넓을 수 있는 것입니다. 가벼운 학습지에서도 이런 현상이 발생하여 개발팀 내에서 회의 안건으로 다룬 적이 있습니다. 팀과 같이 공유하고 해결책을 만드세요.
10. 텍스트 스타일로 UI 스타일을 관리할 수 있을까?
텍스트 스타일의 폰트 패밀리를 하나 바꾸어서 모든 서체의 폰트 패밀리가 변경되게끔 관리할 수 있습니다. SF Pro Display를 쓰다가 Noto Sans로 일괄 수정할 수 있죠.
여기서 주의할 점은 신규 기능의 UI스타일을 실험하기 위해 텍스트 스타일을 명명하여 활용할 때입니다. 예를 들어 Card를 새로 하나 만든다고 할게요. Card내에 사용된 텍스트의 스타일 이름이 Title, Subtitle, Button이라고 해보겠습니다. 레이아웃을 서로 다르게 만든게 3가지 안이 있습니다. 여기서 폰트 패밀리를 SF Pro Display에서 Noto Sans로 바꾸어서 확인해볼 수 있겠죠? 이런 실험적인 방식은 규칙화되고 정리된 디자인시스템이 있는 피그마 파일에서는 시도하지 마세요. 실험하고 지울 수 있어도 새로운 파일에서 새로 설정하는 것이 좋습니다. [Playground]라는 이름의 신규 file, 혹은 pages에 추가하여 실험하세요.
컴포넌트 디자인을 실험할 때 텍스트 스타일을 지정해서 마스터로 변경하기 보다는 Similayer를 통해 스타일화 되지 않은 텍스트들을 관리하는 것을 추천드립니다.
11. 색상 가이드는 어떻게 만들면 좋을까?
색상의 이름을 써야할까? 새로운 이름을 지어주어야 할까? 색상 값을 적어야할까? Hex, RGB 모든 코드를 적어야할까? Opacity로 구분해야할까, 아니면 Tint로 구분해야할까? 색상 가이드의 레이아웃은 어떻게 하면 좋을까? 색상별 설명을 넣을까?
색상 가이드의 방식은 회사마다 다릅니다. 프로젝트 크기에 따라서도 다르죠. 운영되는 서비스를 위해서는 어느 정도 까지의 확장성을 고려해야할까요? 한 색상마다 기입해줘야하는 정보가 많으면 관리가 어려울까요? 처음에 시간 들여 만들면 마케팅 팀의 디자이너, 인쇄물을 만드는 디자이너와도 커뮤니케이션 하기 편할까요?
레모네이드 팀은 Hex코드를 색상코드로 사용합니다. 때문에 RGB까지 명명해줄 필요는 없었죠. 디자인 시스템 구축 초기에 색상이 선정되지 않았을 경우에는 색상이 변할 수 있으므로 색상 이름, 색상값의 정보를 미리 적어두지 않아도 좋습니다.
*마스터 컴포넌트를 만들거나 Similayer로 추후에 일괄적으로 기입란을 만들면 됩니다.
Shopify와 Microsoft의 Color styles 방식은 인상깊습니다. Shopify는 동일한 색상을 여러 상황에 쓰게끔 만들지 않고 중복되더라도 색상의 기능에 집중했거든요. Text의 Default색상 #202223와 Icon의 Default 색상 #202223은 같은 코드값이지만 각기 다른 스타일로 정의되어있습니다.
이렇게 Surface, Background, Primary, Secondary, Border 등을 만들면 색상이 굉장히 많아집니다. (건한님이 모든 149개의 색상을 다 코드에 넣어주시느라 고생을 하셨죠!) 패스트원은 기능에 따라 색상을 중복 정의해서 사용한 반면, 가벼운 학습지는 색상을 1번만 정의해서 여러 환경에 썼습니다. Text와 Icon의 색상이 같은 스타일로 정의 되어 있는 것이죠. 기능별로 색상을 정의하면서 비효율 적이고 일을 더 번거롭게 만드는 것은 아닌지 고민했습니다.
결론은, 이렇게 진행할 경우 디자인 스타일 통일이 더 쉬웠어요. Text 색상도 한정되고 Icon도 일정한 색상만 적용되었거든요. 게다가 Text에 Text이름이 아닌 색상이 적용되어있으면, 개발자가 확인 후 고칠수도 있었거든요. 잘못된 색상 배정을 교정해 줄 지원군이 많이 생깁니다.
12. 색상의 이름을 어떻게 지어야할까?
회색을 예로 들어볼까요?
회색 색상 3가지를 만든다면 어떻게 이름을 지을까요?
- Color + Number : Grey1, Gery2, Grey3
- Color + Opacity : Grey 100, Grey 90, Grey 80
회색이 배경에 쓰인다면 이렇게 만들어 볼 수도 있습니다. 기능을 더해서요!
- Function+State : Background/Default, Background/Pressed, Background/Disable
대쉬'/’를 사용하여 폴더링을 해보세요. 색상 팔레트의 위치와 순서를 기억하기 쉬워집니다.
Figma Community에서 잘 만들어진 디자인 시스템 파일을 열어 알맞은 사례를 찾아보세요. 그리고 그 색상 가이드 및 템플릿을 복사하여 수정하면 고민 시간을 줄이고 출발점을 만들 수 있습니다.
13. 그림자 스타일은 몇 단개면 될까?
가벼운 학습지의 쉐도우 스타일을 모두 모아보니 13개가 넘었습니다! 상황에 맞게 바꾸어가면서 사용하니 스타일도 다르고 규칙성도 없었죠. 반성하고, Shopify의 Polaris for admin:Shadow를 참고했습니다. 상황에 맞게 사용할 그림자를 정의합니다. 더 많은 스타일을 쓰고 싶어도 참아요!
6가지의 그림자 스타일을 사용하고 추가로 2가지를 더했습니다. 빛이 왼쪽에서 오른쪽으로 올 때 버튼에 사용하기 위함이죠. 하지만 자주 사용하지 않습니다. 최대한 6가지 그림자로 해결을 하고 있습니다.
14. Line을 Shadow로 설정해도 될까?
Shadow의 Blur를 0으로 맞추면 라인처럼 사용할 수 있습니다. Card나 Input box, List등을 나눌 때 그룹화된 Auto layout이나 Frame에 Effects로 라인 그림자를 설정하면 컨테이너 밖에나 안에 선을 만들어 사용할 수 있어요! 그러면 vector 1 라는 이름의 레이어나 Rectangle 55 와 같은 레이어 없이 관리할 수 있죠! 레이어 네이밍도 하지 않아도 되고 관리가 쉬워집니다. 개발에서도 동일하게 설정하여 사용할 수도 있어요. 단점은, Spread가 1px이든 2px이든 그림자의 높이는 가이드로 잡을 수 없다는 것이에요. 이 부분 때문에 개발팀 내부의 합의가 필요합니다.
15. 피그마 Page의 트리구조는 어떻게하면 좋을까?
페이지 네이밍, 아트보드 네이밍.
여러개의 파일을 관리하고 싶지 않습니다. 프로젝트별로 신규 파일을 만들어서 각 파일마다 라이브러리를 불러올 정도의 팀 규모도, 서비스 규모도 아니고요. 1명이 2–3개 이상의 기능 제작과 서비스를 담당한다면 모든 것은 한 파일 내에 위치한 것이 좋습니다. Figma의 Page 네이밍을 페이지별로, 기능별로, 프로젝트 이름별로, 컴포넌트별로.. 여러 방법으로 나눌 생각을 했습니다. 그러다가 링크드인에서 아주 좋은 사례를 발견했죠. 마스터 페이지, 작업 페이지, 그리고 가장 중요한 ‘Playground’ 페이지로 나누는 것입니다. 가벼운 학습지와 패스트원은 여기에 조금 더 기능을 보탰습니다.
- PC up to date, Mobile up to date, Master components, +01. Master pages, +02. Playground, + 03.Image guideline, +03. (Feature prototype), +04.History
- Member up to date, Teacher up to date, Master components, +01.Master Pages, +02. Playground : style, +03. Service team communication
페이지의 기능별로 나누었습니다. 마케팅 팀 및 디자인 팀에서 확인할 가이드라인만 모은 ‘image guideline’, 서비스 기획팀과 상의할 때 사용할 ‘Service team communication’ 페이지도 모두 한 파일에 관리됩니다.
Master pages에서는 PC와 Mobile이 모두 같이 있습니다. 사용자군이 2개 이상일 경우에는 모든 사용자군의 서비스 화면이 같이 있습니다. 여기서 파일을 수정합니다. 그러면 통일성을 유지하기 쉬워집니다. 만들어진 화면은 컴포넌트화합니다. 그렇게 컴포넌트화 한 화면을 바탕으로 모달을 얹을 수도 있고, 빈 화면을 디자인할 수도 있습니다. 가장 최초의 마스터 페이지를 변경하면 모든 것이 바뀌죠. 어도비 인디자인의 마스터 페이지와 같은 기능을 사용할 수 있습니다. 단, 마스터 컴포넌트화 된 Frame(페이지)들은 Zeplin으로 추출이 되지 않습니다. 모든 것은 마스터 컴포넌트화 되지 않은 Frame이어야 추출이 가능합니다. 때문에 Up to date페이지들이 있습니다. 여기에서 만들어진 화면을 다시 Frame화하고 동일한 이름으로 설정해줍니다. 이름 변경 단축키를 사용하면 빠르게 할 수 있습니다. 그러면 모든 화면을 모아서 볼 수 있고, 최신의 화면을 공유하는 페이지로 사용할 수 있습니다. 프로토타입을 이곳에서 연결할 수도 있습니다.
16. 만들어야하는 컴포넌트의 종류 어떤게 있을까?
Icon, Form, Check box, Radio, Input, Option, Select, Card, Modal, button..
디자인 시스템에서 필수적으로 포함해야하는 항목이 있습니다.
- Button : Primary, Secondary, etc
- Form : Input, Option, Select / Check box, Radio, Label.
- Table : Header, List, Controller, Pagination.
- Navigation : Global Navigation Bar, Right and Left Navigation Bar, Footer, etc.
- Icon, Card, Filter, Avatar.
- Modal
- Notification : Guide message, Index, Flag.
- Skeleton, Empty page.
- Text style, Color style, Spacing, Shadow, Grid.
이것은 운영되는 서비스의 최소한의 항목을 포함합니다. 사용자군이 다양한 서비스나 복잡도가 높은 서비스의 피그마 파일을 참고하면 더 많은 항목을 찾아볼 수 있습니다.
해당 컴포넌트들을 Auto layout를 활용하여 반응형 환경을 대응할 수 있도록 만들기를 추천드립니다. 픽셀 간격을 정하고 관리하고 기억하는 것은 어려울 수 있지만, 새로 생기는 기능과 UI를 확장하는데에 든든한 가이드가 될 것입니다.
17.Atom? Token? 어떻게 정의할까?
Atom과 Token이 도대체 뭘까요? 책 <디자인 FM>에서 토스는 디자인 시스템에서 토큰을 사용했다고 소개했습니다.
토큰은 디자인 스타일 가이드와 달리 규칙(Rule)를 보고 외워 재적용하지 않고 바로 사용할 수 있는 상태의 디자인 컴포넌트 혹은 코드를 의미합니다.
Design tokens are the visual design atoms of the design system — specifically, they are named entities that store visual design attributes. We use them in place of hard-coded values (such as hex values for color or pixel values for spacing) in order to maintain a scalable and consistent visual system for UI development.
디자인 토큰이 무엇인지 조사하면서 Atomic Design(아토믹 디자인)을 알게되었습니다. 개발에서 표현하는 Atoms > Molecules > Organisms > Templates >Pages를 지칭하는 개념으로 작은 원자단위부터 만들어 분자, 조직, 템플릿, 페이지를 구성하는 방법입니다. 마스터 컴포넌트를 활용하다보면 어디까지 쪼개 두어야 관리가 원활할지 고민하게 됩니다. 스타일을 아이디에이션 하는 경우에는 더더욱 그렇죠.
Atomic Design System을 따를 경우에는 많은 단계를 분리하여 네이밍하고 관리해야하는 단점이 있습니다. 템플릿과 페이지를 어떻게 구분할 것인가요? 템플릿을 변형해서 사용할 때 Overrides 할 수 없는 점은 어떻게 극복할까요? Molecules와 Organisms을 어떻게 구분하고 나눌까요?
이러한 복잡성 때문에 Lemonade에서는 Atom과 Token으로만 구분하기로 했습니다. Molecules부터 Templates에 해당하는 것은 Token인 것이죠.
그렇게 시스템을 구분하여 가벼운 학습지의 파일을 정리했습니다. 그리고 2021년 3월, 패스트원의 디자인 시스템을 새로 빌딩하면서 Atom과 Token으로 구분하고 네이밍 컨벤션 하는 것이 소용이 없고 심지어 방해가 된다는 것을 깨달았습니다.
Atom인지 Atom이 모여 Token을 이루는지를 고민하여 나누는 것보다 더 중요한 것은 쉽게 찾을 수 있게 분류하는 것입니다. 어떠한 분류체계가 이러한 사고를 방해한다면 아예 사용하지 않는 게 나을 수 있습니다. 본질은 다른 사람이 보기에도 이해가능한 구조를 만드는 것이니까요. 애매한 기준을 양산하는 시스템은 비효율적입니다.
18. PC와 Mobile의 스크린 사이즈 기준을 어떻게 잡을까?
Desktop(PC)사이즈 : 1920, 1440 어떤 것을 기준으로 해야할까요? 가벼운 학습지와 패스트원은 LG, 삼성의 작은 화면 노트북1280px을 대응하기 위해 1920px을 사용하고 1200px 안에서 작업합니다.
Mobile사이즈 : 360, 375, 414 어떤 것을 기준으로 해야할까요? 혹자는 가장 넓은 사이즈 414px을 기준으로 작은 화면을 고려하는 것이 좋다고 합니다. 하지만 이럴 경우 320px과 같은 iPhone mini,SE를 포함하기가 까다롭습니다. 오히려 가장 좁은 width사이즈로 작업하고 늘이는 것이 낫죠. 레모네이드팀은 break point를 600px로 잡고 피그마에서는 360px을 기준으로 작업합니다. Android표준이고 4px로 나눌 때 깔끔하기 때문입니다.
19. 8px? 왜 4의 배수로 작업해야할까?
가벼운학습지는 5px의 배수로 작업되어있었습니다. 360을 15px의 패딩을 주면 사용 가능한 동시에 가변하는 너비는 330px이 됩니다. 5px의 배수로 만들면 375px화면에도 대응하기 편리하지만 문제가 있었습니다. 5의 배수로만 모든 것을 나누기엔 5px보다 작은 간격도 사용해야했습니다. 그러다보니 짝수를 사용하게 되고 짝수와 홀수가 혼합되면서 규칙이 없어져갔습니다. 이 문제를 신규 서비스에도 동일하게 가져갈 수는 없어 조사하던 중 8px의 배수로 작업해야한다는 글들을 읽었습니다.
왜 그리드는 8px이 기본이 되어야할까요?
컴포넌트를 추출할 때 0.75배, 1배, 2배 크기로 추출합니다. 안드로이드 화면을 위해 0.75배 혹은 1.5배로 로 추출할 경우, 5px로 제작된 컴포넌트는 소수점 단위로 크기가 변하는 문제점을 만듭니다.
또한 8의 배수로 Spacing을 설정할 경우 적절한 크기 대비가 나옵니다. 5px의 간격은 다소 넓게 됩니다.
여러 문제를 확인한 후, 패스트원은 4px의 배수로 만들었습니다. 4px의 배수로만 만든다는 규칙은 간단하고 명료해서 4의 배수로 구성되지 않는 간격이나 값을 오류로 인지하고 수정하기 편리했습니다.
20. 추천하는 플러그인
유료 플러그인
- Design System Organizer
초기에 Styles의 구조를 정리하기에 편리합니다. 1달정도의 시험 버전만으로도 충분합니다.
구독 플러그인
- Icon8
아이콘을 만들지 말고 조합해서 사용하세요! 월 13달러에 1시간만 절약해도 흑자입니다.
무료 플러그인
- Find and Replace, Similayer, Typescales, Zeplin, Component Replacer, Styler, Breakpoints.
Find and Replace: 특정 단어를 안쓰기로 했습니다. 예를 들어 ‘수업'을 모두 ‘레슨’으로 바꾸기로 했어요. 하나하나 모두 찾아서 바꾼다면 에러는 피할 수 없겠죠! 하지만 Text의 글자를 한번에 바꿀 수 있다면요? 엄청난 시간을 절약하고 정확함을 보일 수 있습니다. 그래도 한번 더 체크해야하지만요 : )
Similayer : Radius가 같은, 색상이 같은, 마스터 컴포넌트가 같은, Stroke굵기가 같은, 폰트 패밀리가 같은..등등 수많은 같은 것들을 모아줍니다! 엉망진창인 파일에서 규칙을 찾기 위해서 이 플러그인을 꼭 써보세요! 든든한 보조자가 되어 줄 것입니다.
Typescales : 가장 아름다운 크기 변화는 무엇일까요? 이 플러그인은 가장 기본이되는 본문 텍스트로부터 3단계 작은 크기, 5단계 큰 크기 등 원하시는대로, 원하는 비율만큼 설정해서 쓸 수 있습니다.
Zeplin : 개발자와 소통하기위한 필수 플러그인이죠!
Component Replacer : 단일 컴포넌트들을 변경한다면 쓰세요! 단, 기존에 만들어진 마스터 컴포넌트의 카피로 대체되는 것이 아니라, 이 플러그인으로 대체된 파일이 새로운 마스터 컴포넌트가 되어버린다는 점에서 그리 유용하지는 않습니다. 규칙 파괴자가 될 수 있으니 조심히 써야해요.
Styler : 레이아웃의 이름을 Styles 규칙대로 짓고 이 플러그인을 쓰면 짠! 단 한번에 100개의 Styles를 만들어버릴 수 있습니다. 100개를 한번에 업데이트 할 수도 있어요. 만약에 Styler가 없었다면, 밤 새 Styles를 고치고, 대조하고, 눈이 시뻘게 졌을 거에요.
Breakpoints : PC에서 태블릿으로 그리고 모바일로. 반응형으로 줄어드는 화면을 어떻게 테스트 하시겠어요? 바로 이 플러그인으로 확인하세요!
21. 하나를 바꾸면 모든 화면이 바뀌는 마스터 페이지, 마스터 컴포넌트는 어떻게 설계할까?
피그마의 구조는 다음과 같은 고려사항을 반영해 설계했습니다.
- 컴포넌트는 모두 마스터 컴포넌트 페이지에 포함될 것 : 아이디에이션이 끝난 마스터 컴포넌트는 마스터 컴포넌트 페이지에서 관리한다.
- 공통된 페이지를 연출하기 위해 한 번 수정한 컴포넌트를 복사 붙여넣기 하지 않아도되게 할 것 : 페이지를 마스터화하여 재활용 한다.
- 제플린에 추출하기가 편리할 것 : 페이지를 마스터화하여 추출 가능한 형태를 모아둔 페이지를 만든다.
- 라이브러리를 활용하기 편하게 할 것. 브랜드 가이드라인과 마스터 컴포넌트를 분리한다.
- 아이디어를 발산할 때 정리에 얽매이지 않게 한다 : Playground 페이지를 만들어 사용한다.
- 기각된 시안들을 복구하지 않고도 볼 수 있어야 한다 : History 페이지에 Backlog처럼 모아둔다.
- 이미지를 활용하기 위한 가이드라인이 다른 팀과도 공유하기 편리해야한다 : 이미지 가이드라인 페이지에 모은다.
22. 제플린을 사용해야할까?
피그마의 inspect를 사용하면 UI간의 간격 및 스펙을 확인할 수 있습니다. 디자이너가 작업하는 것을 실시간으로 확인할 수 있고, 댓글로 의견을 나눌 수 있습니다. 그런 피그마를 두고 제플린을 활용해야할까요?
피그마에서도 플러그인을 사용하면 여러 개발 언어로 변환이 가능할 것입니다. 하지만 피그마를 사용하게 되면 아래와 같은 단점을 감수해야합니다.
- 개발자가 피그마 사용법을 배워야한다. 페이지를 보는 법, 연결된 마스터 컴포넌트를 찾는 법.
- 완성되지 않은 페이지, 아이디에이션 단계의 화면까지 모두 개발자에게 노출된다.
- Edit 기능을 활용하여 반응형으로 제작할 경우 개발자 계정 하나당 과금된다.
*레모네이드 개발팀은 11월부터 2월까지 피그마를 사용하여 개발하고 그 이후로는 제플린을 사용하고 있습니다. 두 방식의 장단점을 비교하기위해 불편한 점을 구글 서베이로 수집했습니다.
제플린을 이용하면 다음과 같은 장점이 있습니다.
- 완성된 페이지와 진행중인 페이지를 구분할 수 있다.
- 페이지별 버전만 확인이 가능하다.
- 마스터 컴포넌트가 사용된 페이지를 따로 모아 확인 가능하다.
- 페이지 검색이 쉽다.
- 색상, 텍스트 스타일, 스페이싱, 컴포넌트에 관해 스타일 가이드를 이용할 수 있다.
- 댓글을 화면 기능 스펙 문서로 사용할 수 있다.
피그마는 디자인+기획을 아이디에이션하고 소통하여 완성하는 공간으로,
제플린은 정리된 기능과 화면을 구현하는 데서 필요한 정보를 나누는 공간으로 활용하면 기획, 디자인, 개발이 뭉쳐 혼란스러워지는 상황을 피할 수 있습니다.
Lean 방식으로 세 구성원이 모두 모여 아이디에이션을 해도 구현 단계에서는 커뮤니케이션 공간을 분리해 두는 것이 필요할 것입니다.
23. 제플린에서 스타일 가이드라인을 어떻게 활용할까?
피그마에서 Zeplin의 Plug-in을 사용하여 Export할 때 컴포넌트를 선택하면 Styleguide쪽으로 보낼 수 있습니다. 그리고 제플린에서는 스타일 가이드를 이용하여 Color, Text Style, Spacing, Components를 관리할 수 있습니다.
- 사용자 타입 A의 Primary의 hover 색상을 버튼에 적용하면 어떨까요?
모든 색상값이나 텍스트 속성을 기억하기는 어렵기 때문에 스타일 가이드에 정의된 이름을 두고 팀과 협업할 수 있습니다.
피그마에서는 하나의 컴포넌트가 어떤 페이지에 연결되어있는지 확인할 수 없습니다. 파생된 컴포넌트가 어떤 마스터 컴포넌트에 연결되어있는지는 볼 수 있지만요. 제플린의 스타일 가이드에서는 각기의 마스터 컴포넌트가 어떤 페이지에 연결되어있는지 모아서 볼 수 있습니다. 전체 스타일을 바꾸거나 컴포넌트를 관리할 때 참고할 수 있습니다.
24. 제플린에서 페이지 네이밍을 어떻게 해야할까?
레모네이드에서는 0.0.0+페이지 이름을 기본 시스템으로 사용합니다.
첫번째.두번째.세번째 각 자리의 의미는 이러합니다.
- 첫번째 : 네비게이션의 페이지가 전환 될 정도로 큰 분류.
- 두번째 : 한 페이지 내에서 기능 변화가 일어나고 화면이 달라보이지만 여전히 같은 곳일 때.
- 세번째 : 메세지가 달라지거나 UI가 거의 유사한 상태에서 자잘한 effect,info변경을 보여줄 때.
PC(Desktop)과 Mobile의 구분은 이렇게 합니다. PC화면에는 0.0.0숫자 앞에 아무것도 덧붙이지 않습니다. Mobile에는 m_를 덧붙입니다. Tablet을 대응할 경우에는 t_를 붙입니다.
후기
디자인 시스템은 서비스의 규모, 팀의 규모에 따라 다릅니다. 앞서 제시한 사례들이 무조건 맞을 수 없습니다. 팀원과 합의하여 더 효과적인 방법을 찾으세요. 그리고 더 좋은 사례들을 공유해 주세요!
사람들은 쉽게 틀에 얽매이곤 합니다. 이는 디자이너, 아트디렉터, 카피라이터, 사업가 모두 마찬가집니다. 시야가 좁아지고 합리적이거나 합리적인 것처럼 보이는 어떤 것에 스스로를 가둡니다. 이런 일은 ‘반드시' 이렇게 해야 한다는 말을 듣고 결국 나중에 가서 보면 ‘반드시' 그렇게 할 필요는 없었음을 깨닫게 됩니다.
디자이너가 ‘반드시'해야 할 일은 수많은 디자이너가 빠져 있는 편견과 고정관념으로부터 최대한 자유로워지는 것입니다. 그리고 그것은 디자이너의 역할이기도 합니다. 마음을 깨끗이 비우고, 일상적인 틀에 안주하지 않으며, 언제나 놀고 실험하고 바꾸고 변형할 준비를 해야합니다. — 알빈 러스틱,1954, <디자이너란 무엇인가>
참고자료
Lyft Design System :
왜 디자인 시스템을 써야할까? Documentation, 디자인 일관성, Sketch, Github.
포스팅내 이미지를 통해 마스터 컴포넌트의 labeling을 어떻게 하면 좋은지 배웠습니다.
작성자 :
박상은 Sang-eun Park (Sanni)
반복작업을 무척 싫어하는 디자이너. 단순 반복작업할 시간에 아이디에이션을 할 수 있도록! AI가 나타나는 그날까지 모든 좋은 기능이란 기능은 다 써서 시간을 단축합시다.
