본 글은 Microsoft design Medium에 기재된 글을 각종 번역기와 의역, 배경지식을 활용해 번역한 글입니다. 최대한 이해가 가기 쉽게 번역했지만, 영어 능력이 좋으시다면 이 글 보다는 아래의 원글을 보시는 것을 권해드립니다. (본 글의 저작권은 Joe Woodward와 Microsoft design에 있습니다.)
또한, 브런치·마스터 등 Git의 용어를 사용하기 때문에 이에 대한 지식이 있으셔야 이해하기 쉽습니다. 만약, Git에 대해 잘 모른다면 진유림 님이 공개하신 초보자를 위한 Git&GitHub을 읽어보시는 것을 추천합니다.
디자이너로서, 우리는 팀 커뮤니케이션을 위한 다양한 도구와 저장소를 사용했지만, 그 어떤 것도 완벽한 만족을 주지 못했습니다. 필자는 파일을 잃어버리거나 최신 디자인을 찾는 데 많은 시간을 할애해 효율성이 떨어지고 에너지를 낭비한 일들이 떠오릅니다.
개발자들은 Git과 같은 분산 버전 관리 시스템을 가지고 있지만, 지금까지 디자이너를 위한 시스템은 존재하지 않습니다. (의역: 유사한 메커니즘이 없다는 것을 관련 시스템이 존재하지 않는다고 쉽게 번역했습니다.)
Abstract는 디자이너가 프로젝트를 함에 있어 다른 사람들과 함께 공동 작업을 할 수 있도록 도와주는 도구입니다. 그것은 우리 팀과 함께 작업을 위한 중심 역할을 제공함으로써 각종 구성요소와 작업파일을 관리하고 유지할 수 있습니다. 디자이너는 Abstract에서 Sketch 작업파일을 가져온 후 간단하게 엽니다.
몇년 전, Miles과 Victor은 Outlook 팀에서 Abstract를 사용하기 시작했으며 이후 Microsoft 디자인 팀에 정식으로 채택되었습니다.
이 글에서는 Abstract을 사용하는 방법에 대해 이야기하고, 파일구조와 (다른사람들과 함께 작업한 파일)병합 프로세스, 파일 유지 관리방법 및 개선에 도움을 주는 일부 과정에 대해 나누고자 합니다.
이 과정은 대규모 팀에서 효과가 있다는 것을 느낄 수 있었지만, 우리는 계속해서 Abstract을 사용하며 미처 발견하지 못한 문제를 파악하고 개선할 수 있는 방법을 알고 싶습니다.
프로젝트의 파일 구조 설계
우리 프로젝트는 Android, iOS, Mac, Web 및 Universal App(Windows 10에 탑재된 기본 앱 — Mail, Calendar) 플랫폼으로 나뉩니다. 이 프로젝트 내부에는 파일들을 다양한 섹션으로 나누었습니다. 다음은 파일을 빨리 실행하기 위해 “iOS UI-Kit”, “Mail” 및 “Calendar”와 같은 섹션으로 파일을 분리하는 Abstract 내부의 iOS 파일 구조의 예시입니다.
첫째, 여기에는 새로 들어온 디자이너와 외부 파트너를 위한 파일이 있습니다. 파일 안에는 디자인 원칙과 Abstract 사용법, 에셋 내보내기 및 Sketch 플러그인 사용에 대한 몇 가지 팁과 노하우 등의 정보가 담겨있습니다.
다음으로 UI-Kit은 모든 컴포넌트, 타이포그래피, 아이콘 및 색상이 포함된 Sketch 라이브러리입니다. 디자인 파일에는 이 라이브러리에서 가져온(링크) 심볼이 사용됩니다.
UI-Kit은 두 개의 페이지로 나뉩니다. 하나는 심볼용이고 다른 하나는 UI 컴포넌트 라이브러리입니다. 후자에는 각 요소에 대한 자세한 정보와 직관적인 레이아웃이 포함되어 있어 원하는 것을 빠르게 찾을 수 있습니다.
sticker sheet라는 용어가 무엇인지 몰라 검색했더니, 우리가 아는 UI Library 혹은 UI 컴포넌트와 동일한 뜻을 가지고 있습니다. 따라서 sticker sheet을 UI 컴포넌트 라이브러리로 바꾸어 번역했습니다.
나머지 파일은 Onboarding, Mail, Calendar, 검색, 설정 등의 앱의 다른 부분을 나타냅니다. 각 카테고리를 분리하면 작업 시 파일이 커져 느려지거나 버벅대는 것을 피할 수 있습니다. 또한 새로운 기능을 만들 때 종종 앱의 특정 부분만 선택하면 되기 때문에 디자인 병합할 때 장점이 있습니다. 따라서 충돌 같은 것은 거의 발생하지 않습니다.
디자인 프로세스의 단계적 실행
첫 번째 단계는, Master에서 모든 Sketch 파일을 가져와 사본을 만드는 것입니다. 폴더 복제(복&붙)와 같이 생각하세요.
branch를 식별하기 위해 레이블 뒤에 적당한 제목을 추가해 작업 중인 부분에 간단한 레이블을 지정합니다. 우리는 일반적으로 “Feature”, “Kit” 또는 “Exploration”과 같은 레이블을 사용하여 프로젝트를 설명합니다.
Outlook에서는 새로운 아이디어를 시도하고 향상할 수 있다고 생각된다면 모든 것을 바꿀 것을 권장합니다. 즉 “Exploration”과 같은 태그를 사용하는 것입니다. 이 레이블은 다른 팀원에게 상황을 알려주고 우리가 무엇을 발견하고 이해할 수 있도록 도와줍니다. 작업. 분기를 만드는 것은 여러 디자이너가 동일한 파일에서 작업 한 다음 나중에 마스터로 다시 병합할 수 있기 때문에 큰 이점입니다.
새 branch에서 Abstract 안에 새 파일을 만듭니다. 저는 파일을 “Working”과 같이 이름을 지어 다른 사람들이 최근 작업 파일이 어디에 위치하는지 알 수 있게 도와줍니다. 그런 다음 다른 파일의 Artboard를 하나의 파일로 복사할 수 있습니다. 이는 작업흐름을 시각화하거나 기존 화면을 바꾸는 데 도움이 됩니다.
Abstract에서 연 Sketch 파일에는 Preview & Commit라는 버튼이 생깁니다. 서버에 작업을 저장하고 다른 팀원들이 변경 사항을 볼 수 있도록 합니다. 커 맛은 마스터에 영향을 끼치지 않으며, 단지 Branch만 업데이트합니다. 팀에서는 하루에 한 번씩 커밋하는 규칙을 따르고 있습니다. 변경 사항을 적용하기 전에 내가 변경한 작업 내용에 관해 설명하는 메모를 추가합니다. 필자는 항상 모든 변경 사항에 접근할 수 있으며, 언제든지 필요한 경우 이전 버전을 통해 변경 사항을 되돌릴 수 있습니다.
디자인이 끝나면, 레이어를 정리하고 디자인 파일을 마스터에 병합해야 합니다. Shape 이름이 정확한지 확인하고 순서가 화면에 표시되는 대로 (위에서 아래로) 따라야 합니다. 이는 모든 화면에 그대로 적용됩니다.
[Kit] 라벨이 붙은 새 Branch를 만들고 새 화면에서 해당 파일에 복사하거나 최신 라이브러리 컴포넌트를 이용해 처음부터 디자인 작업을 할 수 있습니다.
새로 파일을 만드는 이유는 주요 화면만을 마스터에서 가져오기 위함입니다.
그리고 나중에 언제든지 Abstract 아카이브에서 이전 분기에 접근할 수 있습니다. 이는 시간이 많이 소요되며, 우리가 주기적으로 작업을 합치는 것을 방해합니다. 우리는 병합 과정을 개선할 방법을 아는 사람이 있다면 의견을 구하고 싶습니다.
다음은 분기를 만들고, 라이브러리의 UI 컴포넌트를 사용해 앱을 디자인하는 방법을 보여줍니다. Abstract와 우리가 만든 컴포넌트 라이브러리를 통해 팀에 투명성과 가시성을 제공하면서 신속하고 효율적으로 작업할 수 있습니다. 우리는 같은 파일에서 작업하고 있으며 새로운 파일은 모든 사람이 사용할 수 있습니다.
UI 컴포넌트를 사용하여 Outlook 디자인하기
병합 버튼을 누르기 전에 팀원에게 검토를 요청할 수 있습니다. 링크된 심볼 레이어, 정확한 이름 지정, 심볼 중복 및 라이브러리의 변경 사항을 살펴봅니다. 리뷰어는 대게 모든 것을 같은 장소에 보관하면서 Abstract 혹은 Artboard의 특정 부분에 코멘트를 남깁니다. 검토가 끝나면 합병하고 이전 Branch를 보관합니다.
유지 관리의 우수 사례
우리 팀은 Kit를 유지 보수할 책임이 있으며, Sketch 파일을 최적화된 상태로 유지하고 지속적으로 Kit을 개선하고 업데이트하는 작업(특히 운영체제 업데이트로 인한 디자인 설계 변화에 대응)을 합니다.
디자이너들은 언제든지 kit에 의견을 남길 수 있고, 문제를 제기하거나 개선안에 대해 대화할 수 있습니다. 우리는 Github issue란에서 피드백을 확인하고 문제해결에 기여할 수 있도록 합니다. 다음은 중복된 아이콘을 제거하고 모든 아이콘에 바뀐 색상을 지정하는 것을 포함해 UI-Kit에서 추적한 피드백 예시입니다.
우리의 과정과 UI-Kit은 더 개방적이고 협업적인 접근 방식으로 디자인하면서 마이크로소프트 디자인 팀에 채택됐습니다. Fluent Design이 모바일 환경으로 진화함에 따라 마이크로소프트 제품을 통해 공통적인 요소들을 보시게 될 것입니다.
우리는 여전히 공부하고 있고, 과정을 개선할 방법을 끊임없이 찾고 있습니다. 우리는 다른 팀들이 디자인 작업에서 Abstract를 어떻게 활용하고 있는지, 그리고 우리가 어떻게 개선할 수 있는지에 대한 제안을 듣고 싶습니다.
여러분의 의견을 자유롭게 남겨주세요. 💬
Microsoft Design을 통해 알아두기 위해서는 Dribbble, Twitter 및 Facebook을 따르거나 Windows Insider에 가입하세요. 우리와 함께 일하고 싶으시다면 careers.microsoft.com에 방문하세요.
이 글은 💙을 담아 Miles Fitzgerald 및 Outlook 팀의 도움으로 작성되었습니다.