반도체 공장을 위한 디자인시스템
배경
반도체 제품이 생산이 끝난 후에는 검사가 필요합니다. 국내의 한 기업은 이 분야에서 글로벌 1위 기업입니다. 저희는 이 기업의 프로그램을 통합하며, 하나의 디자인 시스템을 구축하는 과업을 수행하게 되었습니다.
목표
반도체 제품은 크게 3가지의 항목을 검사하게 됩니다. 그것은 장비 / 코팅 / 납땜입니다.
검사의 목적은 다르지만, 유저의 워크플로우는 비슷했습니다. 유저는 이미지를 보고, 검사결과를 확인하고 설정을 수정합니다. 그러나, 각 제품은 비슷한 테스크를 수행하더라도 다른 UI로 개발되었습니다.
우리의 목표는 이 3가지 검사 시스템을 하나의 프로그램으로 합치는 것이었습니다.
문제정의
하나의 프로그램으로 통합한다고 하더라도, 유저와 팀 각각 해결해야하는 문제가 있었습니다.
❶ 사용성 문제
<구조화되지 않은 메뉴>
관련된 메뉴들이 길게만 나열되어 있어서, 사용자는 각 기능간의 관계를 이해하기 어려웠습니다.
<숨겨진 메뉴>
또한 메뉴들이 숨겨져있어서, 놓치기 쉬웠습니다.
❷ 확장성 문제
<매번 중복개발되는 UI>
같은 버튼, 메뉴, 세팅들이 각각 프로그램마다 따로 개발되고 있었습니다. 이러한 비효율의 반복은 디자인과 개발이 불필요한 업무를 하게 만들었습니다.
<Figma-Unity 사이의 구현기준 부재>
디자이너와 개발자는 각자의 프로그램에서 다른 기준을 사용중이었습니다. 예를 들어, 만약 3px의 외곽선이 구현이 필요하다고 하면, 개발자는 이를 Unity에서 구현하는 방법이 정의되어있지 않아 불가능하다고 응답하였습니다. 그 결과 팀은 항상 반복적으로 구현기준에 대해서 논의를 해야했습니다.
<언어별 중복제작>
같은 이슈가 현지화에서도 반복되었습니다.
저희는 컴포넌트를 한국어, 영어, 일본어, 중국어 등 여러 언어에 맞춰서 제작했습니다.
언어가 새로 추가될때마다, 컴포넌트의 수가 증가하고 있었습니다.
Solution
저희는 현재 UI를 디자인시스템으로 제작하면, 같은 사용성 문제가 남아있을 것이라고 판단했습니다. 그래서 저희는 UI 개선 후 이를 패턴화하여 디자인시스템으로 만들기로 결정했습니다.
문제해결 접근법
디자인 시스템을 구축하기 위한 단계를 설정했습니다.
❶ UI 리디자인 ❷ Visual Foundation ❸ 설정 Component 제작 ❹ 구현기준 통일과 토큰화
UI 리디자인과 Visual Foundation 설정은 사용자의 사용성 문제를 해결하기 위해, 나머지는 팀의 확장성을 해결하기 위해 진행되었습니다.
UI Redesign
이전 UI에서는 Viewer, Result, Setting이 비슷한 비주얼 강도를 가지고 있었습니다.
각 메뉴들끼리 우선순위가 정리되어있지 않아, 유저는 무엇이 중요한지 화면을 주의깊게 확인해야했습니다.
❶ 명확한 스크린 영역 설정
그래서 새로운 UI에서는 3개의 영역으로 명확하게 분리했습니다. 각 영역은 명확한 역할을 가집니다.
❷ 관계를 보여주는 메뉴
또한 긴 설정 메뉴도 기능 기반의 카드 UI로 변경했습니다.
여백, 텍스트 사이즈 그리고 배경 색까지도 메뉴의 위계에 따른 차이를 보여주도록 제작했습니다.
이러한 Visual의 설정은 설정 사이의 관계를 이해하기 더 쉽게 만들어줍니다.
❸ Redesign Output
Visual Foundation
UI 리디자인 이후, 우리는 새로운 비주얼 규칙을 만들었습니다. 일관성있는 아이콘의 규격을 정의하고, 언어별로 파편화되어있던 타이포시스템을 하나로 서체로 통일했습니다.
그리고 설정에 관련된 색상들을 단순화하여, 긴급한 정보가 먼저 보이도록 수정했습니다.
Component & Token System
디자인 시스템을 기반으로 작업할때는 Brad Frost의 Atomic Design 이론을 바탕으로 작업했습니다.
다만 아토믹 디자인을 그대로 사용하지는 않았고, 저희의 사정에 맞게 수정해서 사용하였습니다. 일반적인 컴포넌트는 Atoic과 Modular 레벨에서 사용되었고, Specific function들은 Template 레벨로 정리되었습니다.
❶ Language Tokens
이전에는 언어별로 여러 컴포넌트를 만들어야했습니다. 이를 개선하기 위해, 언어별 텍스트를 Figma Variants로 정의하여 언어 토큰을 만들었습니다.
이제 하나의 컴포넌트는 여러개의 언어를 지원하게 되었습니다. 이것들은 중복개발을 피하고, 신규 언어를 추가하기 쉬운 환경을 만들었습니다.
❷ Figma–Unity Standards
이전까지는 공유된 기준이 없어서, 개발자들이 Figma를 눈으로 보고 Unity로 구현해야했습니다.
Unity에서는 Shader 형식으로 효과를 구현한다는 방식을 개발로 부터 전달받은 후, 공통된 기준을 만들기 위해 Figma 디자인을 3D로 구현해가며 구현기준을 맞췄습니다.
Unity는 카메라 거리에 따라 Shader의 값을 조정해야하는 문제가 있었지만, 지정된 카메라 거리등이 있어서 여러 테스트끝에 통합된 기준을 만들 수 있었습니다.
Documentation
최종적으로, 모든 유형을 하나의 디자인 시스템 가이드 내에 문서화하였습니다. 문서는 Anatomy → Component → Usage 순으로 작성되었습니다.
Anatomy 섹션은 구성요소들이 어떤 유형으로 구성되었는지 정의합니다.
Component 섹션은 구조, 상태, 사용가능한 프로퍼티에 대한 정의가 있습니다. 또한 이 섹션에서는 실제 컴포넌트를 복사해서 사용할 수 있습니다.
Usage 섹션은 컴포넌트가 실제 제품에서 어떻게 사용되는지 작성해두었습니다. 또한 예외 케이스에 대해서도 적어두었습니다.
성과
디자인시스템 첫번째 배포 이후 변화가 있었습니다.
기존 662개나 되던 컴포넌트의 수를 221개로 줄일 수 있었습니다.
현지 디자이너들이 저희 팀으로 보내오던 문의가 16건에서 3건으로 감소하였습니다. 유저들은 이전보다 훨씬 가독성이 좋아졌다는 반응이었습니다.
디자인 시스템 이전에는 현지화, 디자인, 개발 부서가 별개의 기준을 바탕으로 프로그램을 만들고 있었습니다. 그 결과 각 부서사이 소통을 하는데 많은 시간이 소모되었습니다.
디자인 시스템 도입 이후에는 같은 구조를 갖게 되었습니다. Product Design Team은 다국어 토큰, 재사용 가능한 컴포넌트, 통일된 기준을 바탕으로 소통합니다. 이러한 변화는 각 프로덕트마다 구현기준을 정의하는 빈도를 줄이는데 기여하였습니다.
마무리
일반적으로 디자인시스템은 Web 환경에서 주로 이루어집니다. 반도체 검사장비라는 특수 분야의 디자인 시스템은 그 자체로 도전이었습니다. 하지만 제한 사항이 명확했던만큼, 방법을 찾기도 더 용이했었습니다.
오랜만에 Zero → One을 했던 좋은 경험이었습니다.