디자인 시스템에서 Sketch Assistants의 강력함
-
Sketch가 Salesforce팀과 함께 조직 규모에 맞는 디자인을 논의하며 훌륭한 디자인 시스템의 핵심을 발견하는 것과 Assistants(사전에 규칙을 만들어서 디자인 작업 시 가이드해주는 시스템)에 대해 이야기를 해보려 합니다.
좋은 디자인 시스템은 모든 디자이너의 삶을 편안하게 만들어 줍니다. 좋은 디자인 시스템은 검증받은 구조 내에서 디자이너가 작업하는 데 필요한 요소와 지침을 제공해 줍니다. 또한 개발자가 예측 가능하고 일관된 컴포넌트를 사용할 수 있도록 지원해주며 일관된 디자이너 환경을 통해 기업이 새로운 제품을 더 빠르게 디자인하고 개발할 수 있도록 지원해 주기도 합니다.
여러분이 디자인 시스템을 알고 있다면 Salesforce도 알고 있을 것입니다. Salesforce의 SLDS(세일즈포스 라이트닝 디자인 시스템)는 수천 개의 컴포넌트, 명확한 지침 및 합리적인 선택을 하도록 판단력을 갖추었으며 색상과 크기에 대한 고려해야 할 대상들은 Sketch Library로 쉽게 해결됩니다.
SLDS는 2015년 출시 이후 많은 발전을 거듭해 왔지만, 키루파 치나탐비(Kirupa Chinnathambi) PM 수석 이사와 시스템에 대해 이야기를 나눈 후에도 지금의 핵심 목표는 변하지 않았다는 걸 깨달았습니다. "라이트닝 디자인 시스템의 창립 엔지니어 중 한 명인 Stephanie Rewis가 설명한 바와 같이, 초기 목표는 팀이 UX 가이드의 최신 버전을 채택할 수 있는 확장 가능하고 지속 가능한 방법을 제공하는 것이었습니다."라고 말했습니다. 팀에게 있어 이는 잘 정리된 문서, 풍부한 비주얼 에셋, 강력한 커뮤니케이션 채널 및 피드백 루프 등을 의미하기도 합니다.
오늘 우리는 2개의 목표와 그에 따른 좋은 결과물을 만들었는데 처음 SLDS가 나왔을 땐 다른 참조할 레퍼런스가 없어 저희는 밑바닥부터 새롭게 개척했습니다. 지금은 SLDS가 어디까지 구현해줄 수 있지 가능한지 리서치, 고객 피드백, 원격 측정, 업계 트렌드 등에 맞춰 지속적으로 개선을 하고 있습니다. 그렇게 계속 개선을 하는 와중에 처음 세운 두 개의 목표의 본질에서 크게 벗어나지는 않은 거 같습니다. SLDS가 큰 성공을 거두기까지 다른 중요한 항목이 있다면 SLDS는 디자인 중심이 아닌 인간 중심이라는 것에 있다고 봅니다.
"가장 큰 관점(aspects) 중 하나는 SLDS 디자인 시스템을 사용하여 UX 구축팀과 좋은 관계를 유지하는 것입니다." SLDS을 사용하면 회사의 다양한 제품을 개발하고 있는 Salesforce의 내부 팀에서부터 자체 솔루션을 위해 플랫폼을 사용하는 외부 디자이너 및 개발자에 이르기까지 모두가 디자인 시스템을 사용할 수 있습니다.
"방대한 에코시스템 전반에 걸쳐 직간접적으로 긴밀한 커뮤니케이션을 유지하는 것은 시간 소모가 많지만 제대로 된 것을 만드는데 시간을 들일 수 있도록 해주기 때문에 큰 보람이 있습니다."
또한 이러한 연관성은 디자인 및 엔지니어링의 역할이 어떻게 지속적으로 발전하고 있는지를 보여주는 또 다른 중요한 이점을 팀에게 제공합니다. 좀 더 정확한 도트 라인 로드맵(dotted-line roadmap)을 확보하여 창의적으로 만들 수 있습니다."라고 설명합니다. "디자인 시스템 팀에게는 상당히 독특한 디자인 및 개발자 도구에 대한 우리의 투자는 우리가 이러한 통찰력에 대해 겨냥한 방식(targeted way)으로 대응하는 방법의 한 예입니다."
Salesforce의 Lightning Design System Linter의 경우 강력한 Sketch 플러그인, 전용 UI 디자인 키트 그리고 가장 최근에는 새로운 기능인 Assistants가 있습니다.
Sketch 68에서 Assistants가 나왔을 때 디자인 파일이 가진 문제를 찾아내고, 디자인 시스템과 일관성을 유지하며, 공동 작업을 위해 파일을 준비하는 데 도움을 제공하고 싶었습니다. Salesforce의 Assistants는 디자이너가 별도의 사전 학습 없이 쉽게 SLDS 규칙을 준수하도록 도움을 주었습니다.
LSDS 개발 리드인 John Earle는 “이러한 시스템을 이용하여에 대한 규칙을 정의하는 디자인과 개발 관점에서 대단히 중요합니다.”라고 말했습니다. 하지만 Salesforce팀에게 있어 그것은 단지 (Assistants로 만든) 규칙들을 쉽게 따르도록 만드는 것이 중요했습니다.
그러나 "라이트닝 디자인 시스템처럼 광범위한 시스템을 통해 숙련된 Salesforce 디자이너 조차 디자인 토큰과 일치하지 않는 색상 값이나 텍스트 크기를 쉽게 사용하는 실수를 범하기도 했습니다." 이러한 작은 실수는 계단식 영향을 미치므로 코드에 하드 코딩된 값(예외 처리)이 생성됩니다. 그리고 나중에 한번 적용된 걸 변경하기 쉽지 않기 때문에 최종 사용자의 경험 일관성이 떨어지게 됩니다.
Sketch 문서에서 SLDS Linter를 사용하는 것은 아주 간단한데 일단 적용만 해놓으면 백그라운드로 구동(별도의 버튼 클릭 등의 확인 행위 없이)되어 디자인 작업 시 규칙을 벗어나는 경우 작업자에게 알림으로 경고합니다. 예) 컬러나 서체 등이 규격에서 벗어난 경우..
"사용자(디자이너)에게 이러한 규칙을 지속적으로 알리고, 그 규칙을 준수하는지 확인하는 것은 규칙 자체만큼이나 중요합니다."라고 John은 얘기합니다, "대부분의 규칙은 시스템 내 메타데이터에 직접 적용되는데 API는 이러한 규칙을 배포 및 제어해야 하므로 SLDS Validator와 같은 시행(강제로 제어하는) 도구를 만들었던 거고 지금은 라이트닝 디자인 시스템 Linter를 사용하면 됩니다."
라이트닝 디자인 시스템의 Sketch 플러그인, Sketch UI 키트, Salesforce가 제공하는 글꼴, 색상 및 아이콘과 결합하면 매우 강력한 구성이 됩니다. 디자인해야 할 모든 컴포넌트와 에셋뿐만 아니라 올바르게 사용하는 방법에 대한 정보도 가지고 있어 위에 언급한 실수를 Assistants가 즉시 알려줍니다.
"우리 디자인 시스템의 사용 대상은 디자이너, 개발자에서 제품 관리자에서 어드민에 이르며 , 그리고 혼자 다양한 역할을 수행하는 얼떨결에 디자이너가 된 사람에 이르기까지 모든 부분에 걸쳐 총망라해 있습니다."라고 Kirupa는 말합니다. "가장 보람 있는 부분은 이러한 다양한 기술에 걸쳐 고객이 제공하는 가이드, 툴 그리고 즉시 사용 가능한 솔루션을 사용하여 자신만의 사용자 경험을 구현하게 하는 것입니다."
그 뜻은 이제 모두가 Sketch에 모든 시간을 할애해도 상관없다는 것을 의미합니다.
아니면 코드가 편하면
라이트닝 디자인 시스템은 아름답고, 성능이 좋으며, 접근하기 쉬운 제품 경험을 쌓는 데 도움이 될 수 있습니다. 강력한 Assistants가 이 모든 것을 뒷받침합니다.
SLDS Linter 구축 경험에 관해서 알고 싶었습니다. 우리 팀은 Assistants를 쉽게 제작 가능하게 디자인했는데 그들의 고된 작업이 성과를 거두었을까요?
"Assistants를 정말 잘 만들었어요!"라고 존이 웃는다. "설정이 아주 빨랐고, 몇 분 만에 첫 번째 규칙을 만들어 실행했습니다. 콘텍스트 객체( context object)를 통해 문서 속성에 쉽게 접근할 수 있어 필요한 항목을 찾기 위해 레이어를 검색할 필요가 없었습니다. Typescript 환경은 적절한 인터페이스를 준수할 수 있도록 도와주며 VS(MS Visual Studio) 코드에서 자동 완성 기능을 제공합니다. 그리고 무엇보다 Jest(자바스크립 테스트 프레임워크)가 개발 중에 변경 사항을 감시하도록 할 수 있으므로 수동으로 코드를 다시 컴파일할 필요가 없습니다. 개발 환경은 문서화가 잘되어 있고 현대화되어 작업하기 너무 편리합니다..
Salesforce만큼 크고 성공적인 팀으로부터 이렇게 좋은 소식을 듣게 되어 기쁩니다. 그렇다고 Sketch 디자인 검증(design validation)을 위한 계획이 끝난 것은 아직 아닙니다. "Assistants의 초기 출시했을 때 바닥부터 하나하나 다 까 보면서 파악했습니다."라고 John은 말하며, "향후에는 레이어 간 사이 및 간격을 검증(validate)할 예정입니다. 그리고 개발자를 위한 디자인 스펙을 생성하기 위해 Assistants를 라이트닝 디자인 시스템 플러그인에 연결할 것입니다. 이러한 디자인 사양은 디자인 시스템 토큰 값과 컴포넌트 청사진(component blue-print)을 참조하기 때문에 개발자가 사용할 내용을 찾기 위해 별도의 노력을 하지 않게 될 것입니다."
Assistants 외에도 Salesforce의 미래는 밝습니다. 여기서 저희 미래 계획을 공개할 순 없지만 그래도 일부분 얘기하자면: "우리는 안내 지침 및 문서, 유관 툴 지원, (스타일링 후크를 통한) 풍부한 컴포넌트 스타일, 접근성(WCAG 2.0 및 2.1 포함), 모바일 친화적 개선, 개선된 컬러 시스템 등 지난 1년 동안 적극적으로 논의한 주요 분야에 지속적으로 투자할 것입니다."
하지만 키루파에게 있어, 미래의 어떤 계획보다 더 흥미로운 것은 사람들이 어떻게 라이트닝 디자인 시스템을 사용하여 놀라운 작업을 만들어 내는지를 보는 것입니다. 때때로, 팀이 계획하지 않은 것을 멀리 훨씬 뛰어넘어가기도 합니다. "어느 날 Dreamforce에 있는 저희 부스(디자인 행사?)에 어떤 사람들이 들러 어떻게 라이트닝 디자인 시스템을 사용하여 데이터를 탐색하는 가상현실 경험을 구축하는지를 설명했을 때가 기억에 남는데 미래에서 온 사람들인가?? 하는 생각이 들기도 했습니다."
요약
디자인 시스템을 유지보수하기 위해 Assistants가 아주 좋다.
Assistants를 쓰면 선행 학습이 많이 줄어든다 = 진입장벽 낮음
Assistants는 typescript라서 개발자가 만들어 줘야한다.
플러그인 같기도 하지만 Assistants를 잘 활용하면 아주 강력한 기능이란건 누구던 부정하지는 못할겁니다.
개인적으로 느끼기엔 온전한 디자인 시스템을 구축은 스타트업 보다는 엔터프라이즈가 더 맞지 않을까?하고 생각이 들었습니다. 이유는 디자인 시스템을 만들기 위해 자체 플러그인도 필요하며 어시스턴츠도 필요한데 이를 위해선 전담 개발인력이 필요하기 때문입니다. 이외에 스타트업 보다는 다양한 플랫폼과 서비스들이 이미 돌아가고 있기 때문에 다양한 케이스나 예외 케이스를 사전에 인지가능하기 때문이라 생각듭니다.
어느시점에 디자이너가 코드를 해야할까요? 저는 어설프게 발만 담굴바엔 안하는게 맞다라는게 제 생각인데...그러한 생각들이 조금식 바뀌고 있네요.