디자인 시스템을 만들때 마주하는 고민사항 23가지와 32개 팁.

디자인 시스템을 만들때 마주하는 고민사항 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, 메인 서비스의 디자인 시스템이 미확립된 상태에서 신규 비즈니스가 생겼습니다! 아무것도 없는 빈 페이지에서 새로운 온라인 교육 플랫폼을 만드는 것이죠. 정리되어 있지 않은 기존의 서비스 파일을 불러와서 써도 될까요? 새로 만든다면 어디서 어떻게만들어야할까요? 2030개의 디자인 시스템 포스팅을 읽고, Microsoft Fluent Web/Android/iOS, Shopify Polaris for Admin, Asana, Slack, Pegasus Design System, Ant Design System 의 Figma 내 디자인 시스템을 비교했습니다. 그 결과로 메인 서비스의 고도화를 진행하면서 동시에 신규 서비스의 화면을 무리없이 모두 만들어낼 수있었습니다. 하기 질문 리스트에서 궁금했던 부분을 찾아확인해보세요. 질문 리스트 디자이너 혼자서 작업해도 디자인 시스템을만들어야할까? 레거시를 청산하고 디자인 시스템을 만드는 전체 과정은 어떻게될까? 디자인 파일 레거시는 어떻게 청산하면 좋을까? Top Down, 아니면 Bottomup? 네이밍 컨벤션 / 대쉬를 얼만큼 사용해야할까? 아트보드, 마스터 컴포넌트 레이어 이름에서 써도 될까? 폴더링은 어떻게해야하지? Variant, Property는 어떻게 표기하면 좋을까? Right, Left, Active, Inactive.. On?Off? 텍스트 스타일을 어떻게정의해야할까? 텍스트 스타일의 네이밍은 어떻게 해야할까? H1,H2,H3.. Title, Subtitle../48 Bold, 24 Bold, 18Medium.. 영문과 한글을 어떻게호환할까? 텍스트의 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 copycopy.. 메인 서비스의 UI시스템이 없는데 새로운 서비스의 UI시스템을 2달 내로 만들 수 있을까? 어디서부터 시작해야하지.. 컴포넌트 하나를 수정할 때 마다 모든 페이지에 찾아가서 다 일일히 수정해야하면 야근을 피할 수없을거야. 다른 보드를 찾아서 규칙을 확인하는 시간에 UI를 완성하고, 다시 보드를 찾아서 보고 확인하는 시간에 UI를 완성하고, 더 나아가서 사용자조사를 할 수 있으면 어떨까요? 간격을 기억하기 쉽고, 반복 작업을 피하고, UI 스타일을 손쉽게 바꿀 수있습니다. 언제까지나 혼자서 디자인을 할 수는 없을거에요. 팀이 생길 것입니다. 다른 사람도 이해할 수 있는 컴포넌트 구조를 어떻게 만들면 좋을까요? 항상 그것을 염두하여 구조를설계합니다. 2. 레거시를 청산하고 디자인 시스템을 만드는 전체 과정은 어떻게될까? 전체 프로세스 사업 방향, 프로젝트 목표 이해하기 → 이해관계자, 기획자, 개발자 인터뷰, 시스템 필요성 공감하기→ AS IS — TO BE 설립을 위해 지금 UI 업무 시스템 및 스타일, 작업 방식 확인하기 → 여러가지 타사 사례 수집 후 분석하여 벤치마킹할 것과 개선할 점 파악하기 → 구체적인 디자인 시스템 제작하기. (많이 고민이 일어나는 지점) → UI 제작하기→ 디자인 Hand-off 제플린에 스타일 가이드, 컴포넌트, 화면설계 이전하고 파일 트리 구조 만들기 → 디자인 시스템 활용하여 협업하기 →개선하기. 3. 디자인 파일 레거시는 어떻게 청산하면 좋을까? Top Down, 아니면 Bottomup? 레이아웃과 컴포넌트의 이름은 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로 사용하세요. Best practices for design system naming conventions | Inside Design Blog *위의 링크에서 안내하는 사항을 모두 따르고자 /대쉬를 남발하지 마세요. 이러한 안내 포스팅을 따라 한 레이어에 이름을 모두 정의할 필요는 없습니다. 각각의 레이어의 이름만 간략하게 한 두 단어로 정의하세요. 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, 18Medium.. 이거 참 어려운 부분입니다. 디자인 시스템을 검색하면 나오는 레퍼런스들은 모두 이상적이거든요. 오히려 스타일 가이드에 가깝달까요? 포트폴리오가 아니라 운영하는 서비스를 위해서는 어떤 규칙을 가져야 할까요? 수 많은 엣지 케이스와 확장성을 고려해야하는데말이죠. 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 색상 #2022