Abstraktion af Microsoft Outlook-designprocessen

Hvordan abstrakt forbedrede filorganisation og samarbejde i vores designteam

Billedbeskrivelse: Et udvalg af UI-komponenter fra vores designsystem.

Som designer har jeg brugt forskellige værktøjer til fillagring og teamkommunikation, men ingen af ​​dem har været meget robuste. Jeg kan tænke på utallige gange, hvor jeg har mistet en fil eller brugt timer på at lede efter nogens mest opdaterede design - spildt dyrebar tid og energi.

Udviklere har haft versionskontrolsystemer som Git i et stykke tid, men lignende mekanismer for designere har ikke været tilgængelige - indtil nu.

Abstract er et værktøj bygget til at hjælpe vores designere med at samarbejde om projekter. Det giver vores team et centralt knudepunkt for vores designarbejde, og hjælper os med at administrere og vedligeholde designkomponenter og filer. Designere importerer Sketch-filer til Abstract én gang, og så åbner vi blot filerne derfra.

For et par år siden begyndte Miles og Victor at bruge Abstract i Outlook-teamet, og det er siden blevet vedtaget i designteam på tværs af Microsoft. I dette indlæg vil jeg diskutere, hvordan vi bruger Abstract og vil dele med dig vores filstruktur, sammenlægningsproces, filvedligeholdelsespraksis og nogle områder af vores proces, som vi mener kunne forbedres. Denne proces fungerer for et stort team, men vi finder stadig ud af det og vil meget gerne høre måder, vi kan forbedre dette på.

Design af et projekts filstruktur

Vores projekter er opdelt efter platform - Android, iOS, Mac, Web og Universal (Mail og kalender på Windows 10). Inde i disse projekter er vores filer opdelt i forskellige sektioner i vores app. Nedenfor er et eksempel på vores iOS-filstruktur inde i Abstract, hvor vi opdeler vores filer i sektioner som "iOS UI-Kit," "Mail" og "Kalender" for at holde filerne kørende hurtigt.

Først Start her er en fil til nye designere og eksterne partnere. Det indeholder information om vores designprincipper, hvordan man bruger Abstrakt, eksporterer aktiver og et par tip og tricks om brug af Sketch-plugins.

Start her-fil

Dernæst er UI-Kit Sketch-biblioteket, der indeholder alle vores komponenter, typografi, ikoner og farve. Alle skærme i designfilerne bruger linkede symboler fra dette bibliotek.

UI-kittet er opdelt i to sider - den ene til symboler og den anden til alt designkomponent-klistermark. Sidstnævnte indeholder detaljerede oplysninger om hvert element og et intuitivt layout, så vi hurtigt kan finde, hvad vi leder efter.

IOS UI-Kit-filen indeholder både et klistermærkeark med komponenter samt selve symbolerne

Resten af ​​filerne repræsenterer forskellige dele af appen - Onboarding, Mail, Kalender, Søgning, Indstillinger og mere. At adskille hver kategori hjælper os med at undgå langsomme filer og forsinkelse, mens vi arbejder. Det er også en fordel ved sammenlægning af design, for når vi opretter nye funktioner, har vi ofte kun brug for at røre ved bestemte dele af appen, hvilket til gengæld betyder færre konflikter

Gå igennem designprocessen

Det første trin er at oprette en gren, der tager alle Sketch-filer i masteren og opretter en kopi. Tænk på det som at duplikere en mappe. For at identificere grenen tildeler vi en enkel etiket til det stykke, vi arbejder på, og tilføjer den passende titel efter etiketten. Vi bruger typisk etiketter som "Feature", "Kit" eller "Exploration" til at beskrive projektet. Hos Outlook opfordres vi til at prøve nye ideer og ændre alt, hvad vi mener kan forbedres - det er når vi bruger et tag som "Udforskning." Disse etiketter giver andre teammedlemmer en vis kontekst og hjælper dem med at finde og forstå, hvad vi er arbejder på. Oprettelse af en gren er en enorm fordel, fordi det betyder, at flere designere kan arbejde på de samme filer og senere flette dem tilbage til masteren.

Eksempel på filialmærkning

I den nye gren opretter jeg en ny fil fra Abstract. Jeg navngiver filen som "Working", som hjælper andre med at vide, hvor de seneste iterationer er. Derefter kan jeg kopiere tegnebræt fra andre filer til denne - det hjælper med at visualisere en flow eller ændre en eksisterende skærm.

Opret en

En skissefil, der er åbnet fra abstrakt, indeholder en lille flydende dialog med muligheden Preview & Commit. Det gemmer arbejde på serveren og giver andre på teamet mulighed for at se ændringer. Forpligtelse påvirker ikke masteren, det opdaterer bare grenen. I mit team vil vi gerne følge den generelle regel om at begå arbejde en gang om dagen. Før jeg foretager ændringer, tilføjer jeg en beskrivende note, der skitserer de ændringer, jeg har foretaget. Jeg har altid adgang til enhver ændring, så om nødvendigt kan jeg vende tilbage til en ændring eller se gennem de tidligere versioner af en fil.

Engager dagligt

Når et design er afsluttet, er det tid til at rydde lagene og flette designet til masterfilerne. Sørg for, at lagnavne er nøjagtige, og at rækkefølgen følger det, du ser på skærmen (fra top til bund). Dette skal gentages for hver skærm. Jeg kan enten oprette en ny ny gren mærket [Kit] og kopiere i de nye skærme til den relevante fil, eller jeg kan genoprette disse skærme fra bunden ved hjælp af de nyeste bibliotekskomponenter. Årsagen til, at jeg starter en ny fil, er kun at bringe hovedskærmbillederne ind til masteren. Jeg kan altid besøge den gamle gren senere i det abstrakte arkiv. Det er lidt tidskrævende og afskrækker os fra at flette funktioner mere regelmæssigt. Vi vil meget gerne høre fra alle, der har forslag til forbedring af fusionsprocessen.

Nedenfor er en demonstration af, hvordan vi kan oprette en gren og bruge UI-komponenterne fra biblioteket til at designe skærme i vores app. Det er denne kombination af Abstract og vores komponentbibliotek, der giver os mulighed for at arbejde hurtigt og effektivt samtidig med, at teamet giver fuld gennemsigtighed og synlighed. Vi arbejder ud fra de samme filer, og vores nye filer er tilgængelige for alle.

Billedbeskrivelse: Opbygning af Outlook-skærme ved hjælp af vores UI-komponenter.

Før jeg vælger fusionsknappen, kan jeg anmode om en gennemgang fra alle på teamet. Vi kigger efter sammenkoblede symbollag, korrekt navngivning, duplikatsymboler og ændringer i biblioteket. Gæstgivere efterlader normalt feedback i kommentarfeltet i Abstrakt eller på specifikke tegnebræt, og holder alt på samme sted. Når anmeldelser er afsluttet, fletter vi designet og arkiverer den gamle gren.

Bedste fremgangsmåder til vedligeholdelse

Mit team deler ansvaret for at opdatere kittet med deres funktioner, og jeg leder til arbejde for at holde Sketch-filerne sunde og løbende forbedre og opdatere kittet - især for at tage højde for operativsystemopdateringer eller større revisioner af design.

Designere kan til enhver tid give feedback om sætene, rejse problemer eller indlede samtaler om potentielle forbedringer. Vi sporer denne feedback i et GitHub-emne, så alle på tid til at bidrage. Nedenfor er et eksempel på den slags feedback, vi sporet til UI-kittet, herunder fjerne duplikatikoner og tilføje farveoverskridelser til alle ikoner.

Et Github-emne til sporing af problemer med UI-kit

Vores proces og UI-kit er omfavnet af designteams på tværs af Microsoft, når vi designer med en mere åben og samarbejdende tilgang. Efterhånden som Fluent Design udvikler sig på mobil, ser vi fælles elementer gennem Microsoft-produkter.

Vi lærer stadig og leder konstant efter måder at forbedre vores proces på. Vi ville meget gerne høre, hvordan andre teams bruger Abstract i deres designproces og forslag til, hvordan vi kunne forbedre vores.

Del dine ideer i kommentarerne .

Følg os på Dribbble, Twitter og Facebook eller tilmeld dig vores Windows Insider-program for at være uvidende om Microsoft Design. Og hvis du er interesseret i at blive medlem af vores team, skal du gå til aka.ms/DesignCareers.

Skrevet med og ved hjælp af Miles Fitzgerald og Outlook-teamet.