Microsoft Outlook 디자인 프로세스 개요 (Abstracting the Microsoft Outlook Design Process)

이 글은 Joe WoodwardAbstracting the Microsoft Outlook Design Process글을 번역했습니다. 저의 모든 글은 허가를 받고 진행 하였습니다

설계 팀에서 파일 구성 및 협업 개선 방법

presentation
이미지 설명: 디자인 설계 시스템에서 선택한 UI 구성 요소입니다.
디자이너로서 파일 스토리지와 팀 커뮤니케이션을 위해 다양한 도구를 사용했지만, 그다지 강력한 툴은 없었습니다. 소중한 시간과 에너지를 낭비하면서 파일을 잃어버리거나 누군가의 최신 디자인을 찾느라 몇 시간이나 소비한 적이 수없이 생각납니다.
개발자들은 한동안 Git와 같은 버전 제어 시스템을 사용했지만, 지금까지 디자이너를 위한 유사한 메커니즘을 사용할 수 없었습니다.
Abstract은 디자이너가 프로젝트에서 협업할 수 있도록 도와주는 도구입니다. 설계 작업을 위한 중앙 허브를 팀과 함께 제공하여 설계 구성요소 및 파일을 관리하고 유지 관리하는 데 도움이 됩니다. 디자이너가 스케치 파일을 Abstract으로 한 번 가져온 다음 여기서 파일을 열기만 하면 됩니다.
몇 년 전에 Miles와 Victor는 Outlook 팀에서 Abstract를 사용하기 시작했고 그 이후로 Microsoft의 디자인 팀에서 채택되었습니다. 이 게시물에서는 Abstract을 사용하는 방법에 대해 논의하고 NAT의 파일 구조, 프로세스, 파일 유지 관리 방식 및 개선될 수 있는 일부 프로세스를 병합하여 공유할 것입니다. 이 과정은 대규모 팀에게 효과가 있지만, 우리는 여전히 그것을 알아내고 있으며, 우리가 이것을 개선할 수 있는 방법을 듣고 싶습니다.

프로젝트의 파일 구조를 설계합니다.

우리의 프로젝트는 Android, iOS, Mac, 웹 및 Universal(Windows 10의 메일 및 일정관리) 플랫폼으로 나뉩니다. 이러한 프로젝트 내에서 당사의 파일은 앱의 다양한 섹션으로 나뉩니다. 다음은 파일을 빠르게 실행하기 위해 파일을 "iOS UI-Kit", "Mail" 및 "Calendar"와 같은 섹션으로 구분하는 Abstract 내부의 iOS 파일 구조의 예입니다.
presentation
먼저, 신규 디자이너 및 외부 파트너를 위한 파일입니다. 여기에는 디자인 설계 원리, Abstract 사용 방법, assets 내보내기 및 스케치 플러그인 사용에 대한 몇 가지 유용한 정보가 포함되어 있습니다.
presentation
Start Here file
다음으로 UI-Kit은 Sketch 라이브러리로, 모든 구성 요소, 타이포그래피, 아이콘 및 색상을 포함합니다. 디자인 설계 파일의 모든 화면은 이 라이브러리의 연결된 심볼들을 사용합니다.
UI-Kit는 두 페이지로 나뉩니다. 하나는 심볼용이고 다른 하나는 모든 디자인 설계 구성요소 스티커 시트용입니다. 후자에는 각 요소에 대한 자세한 정보와 직관적인 레이아웃이 포함되어 있어 원하는 것을 신속하게 찾을 수 있습니다.
presentation
iOS UI-Kit 파일에는 심볼 자체와 구성 요소의 스티커 시트가 모두 포함되어 있습니다.
나머지 파일은 앱의 다른 부분(온보드, 메일, 일정관리, 검색, 설정 등)을 나타냅니다. 각 범주를 구분하여 작업하는 동안 파일 속도가 느려지고 지연되는 것을 방지할 수 있습니다. 또한 디자인을 병합할 때 이점이 있습니다. 새로운 기능을 생성할 때 앱의 특정 부분만 터치하면 되는 경우가 많기 때문에 충돌 횟수가 줄어듭니다.

디자인 설계 프로세스를 단계별로 수행합니다.

첫 번째 단계는 마스터의 모든 스케치 파일을 가져오고 복제본으로 브런치를 생성합니다. 폴더를 복제하는 것과 같다고 생각하세요. 브런치를 식별하기 위해 작업 중인 부분에 간단한 레이블을 할당하고 레이블 뒤에 적절한 제목을 추가합니다. 일반적으로 "Feature", "Kit" 또는 "Exploration"과 같은 레이블을 사용하여 프로젝트를 설명합니다. Outlook에서는 새로운 아이디어를 시도해보고 개선될 수 있다고 생각되는 모든 것을 바꾸도록 권장합니다. 바로 "Exploration"과 같은 태그를 사용하는 때입니다. 이 라벨은 다른 팀원들에게 약간의 맥락을 제공하고 우리가 작업하고 있는 것을 찾고 이해할 수 있도록 도와줍니다. 여러 설계자가 동일한 파일에서 작업한 후 나중에 마스터로 다시 병합할 수 있으므로 분기를 만드는 것이 큰 이점이 됩니다.
presentation
브런치 라벨링 예시
새 브런치에 Abstract 내에서 새 파일을 만듭니다. 저는 이 파일의 이름을 "Working"과 같은 것으로 지어 다른 사람들이 최신의 반복이 어디에 있는지 알 수 있도록 도와줍니다. 그런 다음 다른 파일의 아트보드를 이 파일로 복사할 수 있습니다. 그러면 흐름을 시각화하거나 기존 화면을 변경하는 데 도움이 됩니다.
presentation
“working”파일 생성
Abstract에서 열린 스케치 파일에는 Preview & Commit 옵션과 함께 약간의 floating dialog가 포함되어 있습니다. 그러면 서버에 작업을 저장하고 팀의 다른 사용자가 변경 사항을 볼 수 있습니다. 커밋(Commit)은 마스터에 영향을 주지 않고 브런치만 업데이트합니다. 우리 팀에서는 하루에 한 번 일을 하는 일반적인 규칙을 따르는 것을 좋아합니다. 변경 내용을 커밋하기 전에 변경 내용을 요약하는 설명 노트를 추가합니다. 항상 모든 변경 사항에 액세스할 수 있으므로 필요한 경우 변경 내용을 되돌리거나 이전 버전의 파일을 검토할 수 있습니다.
presentation
매일 커밋
디자인 설계가 완료되면 도면층을 정리하고 설계를 마스터 파일에 병합해야 합니다. 도면층 이름이 정확한지 확인하고 화면에 표시되는 순서(위부터 아래까지)를 따릅니다. 이 작업은 모든 화면에 대해 반복해야 합니다. [Kit]라는 새 브런치를 만들어 새 화면에 적절한 파일로 복사하거나 최신 라이브러리 구성 요소를 사용하여 이러한 화면을 처음부터 다시 만들 수 있습니다. 새 파일을 시작하는 이유는 마스터에게 기본 화면만 가져오기 때문입니다. 나중에 Abstract 아카이브의 이전 지점을 언제든지 다시 방문할 수 있습니다. 시간이 조금 많이 소요되고 더 정기적으로 기능을 통합하지 못하게 합니다. 합병(merge) 과정을 개선할 수 있는 제안이 있으신 분들께 연락을 받고 싶습니다.
presentation
아래는 브런치를 생성하고 라이브러리의 UI 구성 요소를 사용하여 앱의 화면을 설계하는 방법을 보여 줍니다. Abstract와 Seagate의 구성요소 라이브러리를 조합하여 빠르고 효율적으로 작업하면서 팀에 완전한 투명성과 가시성을 제공합니다. 우리는 동일한 파일에서 작업하고 있으며, 모든 사용자가 새 파일을 사용할 수 있습니다.
presentation
이미지 설명: UI 구성 요소를 사용하여 Outlook 화면을 만듭니다.
병합(merge) 버튼을 선택하기 전에 팀의 모든 사용자에게 검토를 요청할 수 있습니다. 연결된 심볼 레이어들, 올바른 이름 지정, 중복 심볼 및 라이브러리의 변경 사항을 확인합니다. 검토자는 대개 Abstract의 주석 섹션이나 특정 아트보드에 피드백을 남겨 모든 것을 같은 장소에 보관합니다. 검토가 완료되면 설계를 병합(merge)하고 이전 브런치를 보관합니다.
presentation

유지 관리를 위한 모범 사례입니다.

저희 팀은 키트를 기능과 함께 업데이트해야 하는 책임을 공유하며, Sketch 파일을 정상 상태로 유지하고 키트를 지속적으로 개선하고 업데이트하는 작업을 진행하게 되었습니다. 특히 운영 체제 업데이트나 주요 설계 오버홀을 고려하게 됩니다.
디자이너는 언제든지 키트에 대한 피드백을 제공하여 문제를 제기하거나 잠재적 개선 사항에 대한 대화를 시작할 수 있습니다. 우리는 GitHub 이슈에서 이 피드백을 추적하여, 그 당시의 모든 사람이 기여하도록 허용합니다. 다음은 중복 아이콘을 제거하고 모든 아이콘에 색상 재지정을 추가하는 등 UI-Kit에 대해 추적한 피드백 종류에 대한 예입니다.
presentation
UI-kit의 이슈를 추적하는 Gitub 이슈가 있습니다.
NAT의 프로세스와 UI-kit는 보다 개방적이고 협업적인 접근 방식을 통해 설계할 때 마이크로소프트의 디자인 팀에 의해 채택되었습니다. Fluent Design이 모바일에서 발전함에 따라 Microsoft 제품을 통해 공통 요소를 확인할 수 있습니다.
우리는 여전히 배우고 있으며 우리의 과정을 개선할 방법을 끊임없이 찾고 있습니다. 우리는 다른 팀들이 디자인 설계 과정에서 Abstract를 어떻게 활용하고 있는지, 그리고 우리가 어떻게 개선할 수 있는지에 대한 제안을 듣고 싶습니다.

이 글은 번역 글입니다. 원본 링크입니다.


안녕하세요! Early adopter입니다.
페이스북 [DTF] 디자인 번역 공장 - Design Translation Factory 그룹도 많이 가입해주시길 바랍니다.
"보버"에서 "디자인 번역 공장" 연재를 저와 함께 해주실 분을 찾습니다. 하단 "리뷰" 또는 "페이스북"으로 편하게 메시지 주세요!
PS. 제가 사용하는 블로그 "보버"에 "함께 쓰는 블로그"라는 기능이 요번에 추가됐네요 ㅋ (미디엄에 퍼블리케이션 같은 기능..)
하단 링크 글을 보시면 "디자인 번역 공장"에 어떻게 함께 연재할 수 있는지 자세히 설명되어있습니다. 또는 쉽게 FB 메시지 주세요!
https://bit.ly/2L6WsZp