심벌과 디자인 시스템
신입에게 알려주는 스케치, 심벌로 만드는 디자인 시스템
Sketch 63.1에서 만든 내용입니다.
Sketch 69가 업데이트되면서 많은 내용이 변경되었습니다.
Sketch 73이 되면서 클라우드 부분이 강화되었습니다. 이제 온라인으로 작업하시는 것도 나쁘지 않습니다.
모바일보다 데스크톱에서 보는 게 좋습니다.
신입에게
심벌을 설명하기
신입을 위한 스케치에 대한 글을 쓸 때, 가장 고민한 부분이 심벌 부분입니다.
이걸 제일 처음 설명할 때는 이렇게 말했습니다.
"여러 번 바꿔야 하는 부분을 심벌로 만들면, 한 번만 작업하면 됩니다."
쉽지만 좋은 설명은 아닙니다. 심벌을 관리하는 것이 여러 번 반복해서 수정하는 일이기 때문입니다. 심벌을 만들면, 작업 시간이 줄어든다고 하지만, 실제로는 일이 더 꼬일 수도 있습니다.
그래서 디자인 시스템과 스케치 심벌에 대한 이야기를 준비했습니다.
디자인 시스템과
디자인
디자인 시스템에 대해서 여러 가지 생각과 이야기가 있습니다.
프로그래머가 보면, 개발 환경과 밀접한 관련이 있는 제품을 만들기 위한 개발 라이브러리 혹은 프레임워크라고 볼 수도 있습니다.
디자인만 분리해보면, 디자인을 구성하는 수많은 요소들과 그 요소들을 정의하고 규칙을 제공하는 가이드라인, 컴포넌트, 패턴 등이 보입니다.
디자인 시스템은 제품의 구성 요소를 작은 부분의 모듈로 나누어서 팀원과 협업하거나 디자인 프로세스의 효율성과 합리성을 높입니다. 그래서 서로 다른 직군이 효율적인 작업을 진행하기 위해 쉽게 사용할 수 있는 단위와 구조가 중요합니다.
집에서 요리를 하기 위해 마트에 가면, 다양한 요리가 될 수 있는 재료들이 적당한 포장으로 나뉘어 있는 상태를 생각해보시면 좋을 듯 합니다.
스케치와
디자인 시스템
Sketch의 홈페이지 혹은 미디엄 아티클을 보면, 스케치를 통해서 디자인 시스템을 만들고 관리하기 위한 기능들을 지속적으로 업데이트하고 있습니다.
스케치의 컴포넌트 뷰는 4가지 탭으로 구분되어 있습니다.
Symbols
Text Styles
Layer Styles
Colors
심벌에는 Text Styles과 Layer Styles, Colors를 포함할 수 있고, 스케치 파일을 Library로 다른 스케치 파일에서 참조하는 방식으로 스케치로 만드는 디자인 시스템을 구성할 수 있습니다.
Sketch는 Cloud를 이용해서 원격에서 라이브러리를 관리하고, 업데이트할 수 있는 방법을 만들고 개선하고 있습니다. 2020년의 스케치 업데이트 계획을 보면, 업데이트 목표 중에 하나는 공동의 협업 과정을 강화하는 것으로 되어 있습니다.
디자인 시스템과
스케치의 관계
디자인 시스템을 이야기할 때 가장 많이 들을 수 있는 말이 '협업'입니다.
옛날 옛적에는 디자인 툴이 포토샵 밖에 없던 시절에는 기획과 디자인의 툴이 매우 명확하게 나눠져 있었습니다. MS에서 나온 소프트웨어로 기획을 하면, Adobe에서 나온 툴로 디자인을 합니다. 그리고 개발자는 문서화된 가이드라인과 이미지 파일을 받아서 제품을 개발했습니다.
시간이 지나면서 매년 다양한 프로토타이핑 툴과 벡터 기반의 UI 툴이 Mac OS 기반으로 출시되었습니다.
애플의 맥북은 윈도우 기반 노트북보다 3배 정도 비싸지만, UI 디자인을 하는 경우, 소프트웨어가 맥에 집중되어 있기 때문에 맥북이 있는 것이 좋습니다. 비싸지만...
요즘 UI 툴들은 간결한 UI를 가지고 디지털 제품을 디자인하는데 전문화되어 있었습니다. 모든 분야의 디자인을 할 수 있는 포토샵과는 달랐습니다.
스케치는 빠르게 성장했고, 접근성이 매우 쉬운 툴입니다. 하나의 팀이 기획 혹은 UX, 프로토타이핑, 디자인을 스케치에서 진행할 수 있습니다. 작업이 끝나면, 제플린으로 개발자에게 전달하기 편리하며, 기존의 어도비 혹은 다른 프로토타이핑 툴과 플러그인으로 작업 결과를 Export 할 수 있습니다.
2019년 설문 결과를 보면, 기획자, UX 디자이너, UI 디자이너, 개발자가 함께 사용하는 툴 중에서 가장 활용도가 높습니다.
아토믹 디자인으로
보는 스케치의 심벌
아토믹 디자인(Atomic Design)은 사람들이 자주 쓰는 프로세스를 설명하기 좋습니다. 원자, 분자, 유기체로 만들어지는 비유는 과학적이지만, 갑자기 템플릿이 나오고 페이지가 됩니다.(DNA가 나오면 모를까...)
실무적인 비유로 이해를 돕기 위해 아토믹 디자인의 기본적인 과정과 스케치의 보통 프로세스를 비교해보았습니다. 스케치의 심벌은 아토믹 디자인의 원자-분자-유기체 부분과 템플릿 부분과 겹칩니다. Symbol은 기본값을 가진 템플릿으로 Override를 통해서 아토믹 디자인에서 말하는 페이지와 비슷한 상태가 됩니다.
원자-분자-유기체의 경우는 디자인의 요소들을 모아서 컴포넌트를 구성하고, 콘텐츠를 제외한 컴포넌트의 구성을 템플릿으로 실제 데이터를 받아서 제품의 화면 하나가 완성됩니다.
논리적인 구성입니다.
구인 공고를 보거나 인터뷰를 할 때, 가장 고민되는 것이 논리적인 디자이너 혹은 논리적인 커뮤니케이션이 가능한 사람을 구하는 경우 입니다. 논리적이라는 것은 '같은 상황'과 '같은 조건'에서 뭔가 하게 되면, 비슷한 결과가 나오는 것 혹은 나의 감성적이나 기분, 기호, 취향을 떠난 결정이나 생각이라고 생각하시면 편합니다.
그럼 여기서 질문이 생깁니다.
"어디까지 어떻게 구분해야 하나요?"
구분을 하기 위한
규칙을 이해하기
구분하기는 디자인의 기본적인 방법입니다. 분류 방식에 의해서 정보의 전달력이 달라집니다. 분류를 한 후에는 정보의 위계를 정해야 합니다. UI 디자인은 정보를 기반으로 디자인하고, 정보의 특징은 위계와 구조가 있습니다.
가장 중요하다고 판단한 정보 외의 나머지 정보를 제거하면, 심플한 디자인이 됩니다.
그런데 UI 디자인을 할 때는 어떻게 해도, 심플해지지 않는 부분에 직면하게 됩니다. 어떤 경우에는 이해하기 쉬운 복잡성이 필수적입니다. 많은 정보를 정확하게 표현하려면, 같은 점과 다른 점, 비슷한 점을 구분해야 합니다. 그래서 명확함(Clearity)이 중요해집니다.
핵심은 정의하고 분류한 후, 구조를 만들고, 공유하고, 개선하는 과정입니다.
구체적인 예시로 이미 많은 디자인 시스템이 공개되어 있습니다. 머티리얼 디자인(Material Design)이나, 부트스트랩(Bootstrap), 카본 디자인 시스템(Carbon Design System)을 참고해 보면서 프로젝트에 맞는 방식을 좋습니다.
심벌 만들기
이제 본론이네...생각보다 심벌을 만드는 과정은 절차가 많습니다. 원하는 레이어를 생각하고, Create Symbol을 선택하면, 심벌 대화 상자를 볼 수 있습니다.
심벌은 Text, Stroke, Shape 다른 Symbol을 포함할 수 있습니다. 스케치에서 선택 가능한 모든 것이 심벌이 될 수 있습니다. 극단적으로 한 스크린에 포함되는 모든 것을 심벌로 만들 수 있습니다.
Smart Layout을 설명하는 부분의 비중이 큽니다. 스마트 레이아웃은 다른 글에서 많이 설명해서 넘어갑니다. 나중에 심벌 패널에서도 조정할 수 있습니다.
왼쪽 하단에 Send Symbol to "Symbols" Page가 있는데, 체크를 안 하게 되면, 해당 페이지에 생깁니다. 관리가 어려워지기 때문에 가급적 체크해 두시기 바랍니다.
심벌은 Source Symbol과 Instances로 나뉘게 됩니다. "Symbols Pages"에 있는 Source를 변경하면, 다른 Page 혹은 파일에 있는 심벌이 변경됩니다. 다른 파일의 심벌까지 수정하려면, 라이브러리로 만들어야 합니다.
심벌의 오버라이드
체크박스를 몇 개 꺼두는 것만으로도 일이 줄어드는 매직!Layer 패널에서 레이어에 이름을 정해두면, Source 심벌에서 어떤 부분을 Override 할지 선택할 수 있습니다. 변경되는 부분만 선택해두면, 인스턴스를 깔끔하게 관리할 수 있습니다.
이름을 잘 써두면, 명확합니다.
어떻게 하든 간에 일일이 수정이 힘든 경우는 Data Tool을 사용해서 쉽게 임시 정보(Dummy Data)를 넣어보면서 상태를 테스트할 수 있습니다. 아직은 폴더 별 관리이고, 텍스트의 경우는 텍스트 파일을 일일이 링크해야 해서 조금 불편하긴 합니다.
저의 경우는 어떤 데이터가 들어갈지 미리 확인해보는 편이라 작업 전에 Asset 폴더를 만들어서 준비를 해두는 편입니다.
이미지를 넣을 때, Mask를 많이 사용하는데, 엄청 중요한 이미지가 아니라면, 미리 사진을 준비해 두고 데이터 툴로 넣는게 Mask보다 낫습니다.
스케치 심벌을 만들 때,
모든 리스트에 쓸 수 있는 하나의 심벌을 만들 수도 있고,
각각의 리스트에 적합한 여러 개의 심벌을 만들 수도 있습니다.
더미 데이터를 만들 때,
글자 수에서 최소값과 최대값과 형식을 항상 생각하고,
사진의 경우는 저화질이나 잘 맞지 않는 크기의 사진을 한 두장 준비해 두면 테스트하기 좋습니다.
Canvas와 Components
스케치69로 업데이트가 되면서 심벌을 Insert 메뉴를 통해서 아트보드에 추가할 수 있게 되었습니다. 기존의 방식보다 더 효율적입니다. 잘 안 쓰는 단축키인데, 컨트롤+1과 컨트롤+2로 쉽게 오갈 수 있습니다. 편리합니다.
스케치69에서는 이 기능이 베타입니다.컴포넌트 뷰를 보면, 차례대로 심벌, 텍스트 스타일, 레이어 스타일, 컬러를 관리할 수 있습니다. v60에서 컴포넌트 패널로 그룹핑과 이름 변경이 쉬워졌고, v69에서는 Views로 변경되었습니다. 심벌은 스타일을 포함할 수 있습니다. 작은 프로젝트를 해도 작업을 하다가 보면, 숫자가 많아지기 때문에 이름을 잘 짓는 것이 중요합니다.
이름을 잘 지으면, 구조와 협업, 이해.
3마리의 토끼를 잡을 수 있습니다.
이름 짓는 법,
이름은 꼭 써두는 것이 좋다.
비슷한 것들을 비슷하게 시작하게 이름을 적으면, 심벌을 바꿀 때 좋다.
복사를 하면, 이름을 꼭 확인해 보자!
심벌의 경우, 접두사(Prefix, 아이콘인 경우 ico, ic) 혹은 심벌의 의미나 용도를 설명한다.
상태(State)를 표현하는 접미사(Suffix)로 적으면 좋다.
띄어쓰기를 하는 경우는 언더바('_')를 사용한다. 하이픈('-')의 경우, 안드로이드에서 문제가 될 수 있다.
띄어쓰기를 안 하는 경우는 영문 대문자로 구분하기도 한다. DesiginFile
텍스트 스타일의 경우, HTML에서 사용하는 H1, H2, P 혹은 Title, HeroTitle 등을 쓸 수도 있다.
이름은 맘대로 짓지 말고, 팀별로 간단한 규칙을 이야기해 보면 좋다.
모든 상황에 대한 규칙을 미리 만들지 말고, 지킬 수 있는 간단한 상황에 대한 규칙만 만들어라.
스케치 파일을
라이브러리로 만들기
의외로 라이브러리는 특별하지 않습니다. 그냥 '너로 정했다.' 하면 됩니다.라이브러리를 만들면, 간단한 디자인 시스템을 구성하고, 가이드를 편하게 치면서, 전체 제품에 들어가는 화면을 통제할 수 있습니다. 물론 계획이 필요합니다.
하나의 프로젝트를 작업할 때 여러 가지 방식을 생각할 수 있습니다.
라이브러리를 만들 때,
버전별로 라이브러리를 만든다.
하나의 라이브러리에 버전별로 심벌을 만든다.
하나의 프로젝트에,
모든 것을 포함하는 하나의 라이브러리를 만든다.
텍스트, 레이어, 심벌, 아이콘 등 여러 개의 라이브러리 파일을 만든다.
라이브러리를 참조하여,
기능별로 여러 개의 스케치 파일을 나누어 여러 사람이 작업한다.
하나의 스케치 파일 안에 기능별로 페이지로 나누어 작업한다.
플랫폼 별로,
iOS와 Android, Web 별로 라이브러리를 만든다.
모든 플랫폼에 적용할 수 있는 하나의 라이브러리를 만든다.
워크스페이스
조합하면, 여러 가지 방식으로 구성할 수 있습니다.
다만 스케치에서 스케치 클라우드에 클라우드 파일로 라이브러리를 만들 수 있습니다.
다만, 스케치 클라우드(Sketch Cloud)를 이용하는 경우는 꼭 모든 파일을 오프라인으로 백업하시기 바랍니다. 잦은 업데이트를 할 경우는 드롭박스가 더 나을 수 있습니다. 스케치69가 되었는데, 아직도 불안하네요.
스케치 73에서는 클라우드가 Workspace로 변하면서 스케치의 플랜도 변경되었습니다. 워크스페이스에는 Owner가 있고, 편집자를 할당합니다. 편집자(Editor) 당 비용이 월간 혹은 연간 책정됩니다. 그래서 프로젝트를 시작할 때, 온라인으로 시작할 것인지, 오프라인으로 시작할 것인지 선택하면 됩니다.(드랍박스는 이제 사용하지 않아도 됩니다.)
워크스페이스는 크게 Draft, Libraries, Share로 나뉩니다. 클라우드로 시작하면, 오프라인과 달리 모든 작업이 공유되서, 개별 작업은 드레프트에서 진행하시는 것이 좋습니다. 이 부분은 확실히 피그마의 프로세스를 벤치마킹 한 듯 합니다. 클라우드 부분은 많이 복잡해져서 나중에 다른 글에서 보강하도록 하겠습니다.
일을 시작할 때, 너무 많은 것들을 생각하면, 그 생각 때문에 아무 것도 못할 수 있습니다. 힘들 수 있죠. 하지만 몇 번 연습해보면, 처음 작은 계획을 세우는 것으 더 안전하게 일을 끝낼 수 있는 방법일 수 있습니다.
하나의 라이브러리를 만들면서 프로젝트의 규모와 특징을 생각해 보면 좋겠습니다.
팁을 드리면, 파일이 작을수록 빠르게 제작할 수 있지만, 유지보수가 점점 힘들어집니다. 파일이 많으면, 초반에 관리가 힘들지만, 나중에 문서화가 잘 되어 있으면 유지보수는 쉽습니다.
구분이 잘 되어 있으면 재활용하기도 쉽습니다 자동화를 위한 패턴을 찾거나 개별 기능을 개선하기도 쉽습니다.
간단한 툴과
복잡한 프로세스
스케치는 생각보다 간단하고 명확한 툴입니다. 하지만 스케치가 나오고 업데이트되는 환경은 매우 복잡합니다. 스케치는 간단한 룰을 제공하고, 복잡한 제품을 만들 수 있는 환경을 제공합니다.
그런데 이 부분에서 질문이 많이 생깁니다.
경험이 없으면, 막막합니다. 사수가 없거나 혼자 디자인해야 하는 경우, 이 모든 것이 무슨 의미가 있을까요?
하지만 이름을 짓고, 링크하고 파일 하나에 모든 심벌과 구성 요소를 구성하는 작업은 더 좋은 제품을 만드는데 큰 도움이 됩니다. 아마, 스케치가 영원히 성장하지 않고, 다른 어떤 툴이 등장해서 그 툴을 배워야 할 때가 생길 수도 있습니다. 당장 피그마를 사용할 수도 있습니다.
좋은 노하우는 경험에서 나오는 경우가 많기 때문에 시간을 들여서 고민한 결과는 툴을 넘어서 논리적인 프로세스를 만드는 밑거름 될 겁니다.
스케치를 여러 가지 방법으로 쓰면서 알려주고 싶은 것들을 가볍게 적기 시작한 일인데, 거의 1년간 계속 쓰게 되었네요. 사수 없이 막막한 실무에 처한 분들에게 작은 도움이 되길 바랍니다.
