Abstract을 사용한 Microsoft Outlook 디자인 과정

디자인 팀에서 Abstract으로 파일을 구성하고 공동으로 작업하는 방법

본 글은 Microsoft design Medium에 기제된 글을 각종 번역기와 의역, 배경지식을 활용해 번역한 글입니다. 최대한 이해가 가기 쉽게 번역했지만 영어 능력이 좋으시다면 이 글 보다는 아래의 원글을 보시는 것을 권해드립니다. (본 글의 저작권은 Joe WoodwardMicrosoft design에 있습니다.)

또한, 브런치·마스터 등 Git의 용어를 사용하기 때문에 이에 대한 지식이 있으셔야 이해하기 쉽습니다. 만약, Git에 대해 잘 모른다면 진유림님이 공개하신 초보자를 위한 Git&GitHub 를 읽어보시는 것을 추천합니다.

이미지 설명: 디자인 시스템에서 채택한 UI 콤포넌트

디자이너로서, 우리는 팀 커뮤니케이션을 위한 다양한 도구와 저장소를 사용했지만, 그 어떤것도 완벽한 만족을 주지 못했습니다. 필자는 파일을 잃어버리거나 최신 디자인을 찾는데 많은 시간을 할애해 효율성이 떨어지고 에너지를 낭비한 일들이 떠오릅니다.

개발자들은 Git과 같은 분산 버전 관리 시스템을 가지고 있지만, 지금까지 디자이너를 위한 시스템은 존재하지 않습니다. (의역: 유사한 메커니즘이 없다는 것을 관련 시스템이 존재하지 않는다고 쉽게 번역했습니다.)

Abstract은 디자이너가 프로젝트를 함에 있어 다른 사람들과 함께 공동작업을 할 수 있도록 도와주는 도구입니다. 그것은 우리 팀과 함께 작업을 위한 중심 역할을 제공함으로써 각종 구성요소와 작업파일을 관리하고 유지할 수 있습니다. 디자이너는 Abstract에서 Sketch 작업파일을 가져온 후 간단하게 엽니다.

몇년 전, MilesVictor은 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 컴포턴트 라이브러리로 바꾸어 번역했습니다.
iOS UI-Kit 파일에는 스티커 시트와 UI 컴포넌트 라이브러리가 들어 있습니다.

나머지 파일은 Onboarding, Mail, Calendar, 검색, 설정등의 앱의 다른 부분을 나타냅니다. 각 카테고리를 분리하면 작업시 파일이 커져 느려지거나 버벅대는 것을 피할 수 있습니다. 또한 새로운 기능을 만들 때 종종 앱의 특정 부분만 선택하면 되기 때문에 디자인 병합할 때 장점이 있습니다. 따라서 충돌같은 것은 거의 발생하지 않습니다.

디자인 프로세스의 단계적 실행

첫 번째 단계는, Master에서 모든 Sketch 파일을 가져와 사본을 만드는 것입니다. 폴더 복제(복&붙)과 같이 생각하세요. branch를 식별하기 위해 레이블 뒤에 적당한 제목을 추가해 작업중인 부분에 간단한 레이블을 지정합니다. 우리는 일반적으로 “Feature”, “Kit”또는 “Exploration”과 같은 레이블을 사용하여 프로젝트를 설명합니다. Outlook에서는 새로운 아이디어를 시도하고 향상시킬 수 있다고 생각된다면 모든 것을 바꿀 것을 권장합니다. 즉 “Exploration”과 같은 태그를 사용하는 것입니다.이 레이블은 다른 팀원에게 상황을 알려주고 우리가 무엇을 발견하고 이해할 수 있도록 도와줍니다. 작업. 분기를 만드는 것은 여러 디자이너가 동일한 파일에서 작업 한 다음 나중에 마스터로 다시 병합할 수 있기 때문에 큰 이점입니다.

Branch에 레이블을 다는 모습

새 branch 에서 Abstract안에 새 파일을 만듭니다. 저는 파일을 “Working”과 같이 이름을 지어 다른 사람들이 최근작업 파일이 어디에 위치하는지 알 수 있게 도와줍니다. 그런 다음 다른 파일의 Artboard를 하나의 파일로 복사할 수 있습니다. 이는 작업흐름을 시각화 하거나 기존 화면을 바꾸는데 도움이 됩니다.

“working” 파일을 만드는 모습

Abstract에서 연 Sketch 파일에는 Preview&Commit 라는 버튼이 생깁니다. 서버에 작업을 저장하고 다른 팀원들이 변경사항을 볼 수 있도록 합니다. 커밋은 마스터에 영향을 끼치지 않으며, 단지 Branch만 업데이트합니다. 팀에서는 하루에 한번씩 커밋하는 규칙을 따르고 있습니다. 변경사항을 적용하기 전에 내가 변경한 작업내용에 대해 설명하는 메모를 추가합니다. 필자는 항상 모든 변경사항에 접근할 수 있으며, 언제든지 필요한 경우 이전 버전을 통해 변경사항을 되돌릴 수 있습니다.

하루에 한번 커밋

디자인이 끝나면, 레이어를 정리하고 디자인 파일을 마스터에 병합해야 합니다. Shape 이름이 정확한지 확인하고 순서가 화면에 표시되는대로 (위에서 아래로) 따라야 합니다. 이는 모든 화면에 그대로 적용됩니다. [Kit] 라벨이 붙은 새 Branch을 만들고 새 화면에서 해당 파일에 복사하거나 최신 라이브러리 콤포넌트를 이용해 처음부터 디자인 작업을 할 수 있습니다. 새로 파일을 만드는 이유는 주요 화면만을 마스터에서 가져오기 위함입니다. 그리고 나중에 언제든지 Abstract 아카이브에서 이전 분기에 접근할 수 있습니다. 이는 시간이 많이 소요되며, 우리가 주기적으로 작업을 합치는 것을 방해합니다. 우리는 병합 과정을 개선할 수 있는 방법을 아는 사람이 있다면 의견을 구하고 싶습니다.

다음은 분기를 만들고, 라이브러리의 UI 콤포넌트를 사용해 앱을 디자인 하는 방법을 보여줍니다. Abstract와 우리가 만든 콤포넌트 라이브러리를 통해 팀에 투명성과 가시성을 제공하면서 신속하고 효율적으로 작업할 수 있습니다. 우리는 같은 파일에서 작업하고 있으며 새로운 파일은 모든 사람이 사용할 수 있습니다.

이미지 설명 : UI 콤포넌트를 사용하여 Outlook 디자인 하기

병합 버튼을 누르기 전에 팀원에게 검토를 요청 할 수 있습니다. 링크된 심볼 레이어, 정확한 이름 지정, 심볼 중복 및 라이브러리의 변경 사항을 살펴봅니다. 리뷰어는 대게 모든 것을 같은 장소에 보관하면서 Absrtact 혹은 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 팀의 도움으로 작성되었습니다.