Sammanfattning av Microsoft Outlook Design Process

Hur abstrakt förbättrade filorganisationen och samarbetet i vårt designteam

Bildbeskrivning: Ett urval av UI-komponenter från vårt designsystem.

Som designer har jag använt olika verktyg för fillagring och teamkommunikation, men inga av dem har varit väldigt robusta. Jag kan tänka på otaliga gånger jag har tappat en fil eller tillbringat timmar på att leta efter någons mest uppdaterade design - slösa bort dyrbar tid och energi.

Utvecklare har haft versionskontrollsystem som Git ett tag, men liknande mekanismer för designers har inte funnits - förr än nu.

Sammanfattning är ett verktyg som byggs för att hjälpa våra designers att samarbeta om projekt. Det ger vårt team ett centralt nav för vårt designarbete, vilket hjälper oss att hantera och underhålla designkomponenter och filer. Formgivare importerar skissfiler till abstrakt en gång, och sedan öppnar vi bara filerna därifrån.

För några år sedan började Miles och Victor använda Abstract i Outlook-teamet och det har sedan antagits i designteam över hela Microsoft. I det här inlägget kommer jag att diskutera hur vi använder Abstract och kommer att dela med dig vår filstruktur, sammanslagningsprocess, filunderhållspraxis och vissa områden i vår process som vi tror kan förbättras. Den här processen fungerar för ett stort team men vi har fortfarande räknat ut det och skulle gärna höra hur vi kan förbättra detta.

Designa ett projekts filstruktur

Våra projekt är indelade efter plattform - Android, iOS, Mac, Web och Universal (Mail och kalender på Windows 10). Inuti dessa projekt är våra filer uppdelade i olika delar av vår app. Nedan är ett exempel på vår iOS-filstruktur inuti Abstract där vi delar våra filer i sektioner som "iOS UI-Kit", "Mail" och "Kalender" för att hålla filerna snabbt igång.

Först, här är en fil för nya designers och externa partners. Den innehåller information om våra designprinciper, hur du använder abstrakt, exporterar tillgångar och några tips och tricks om hur du använder Sketch-plugins.

Starta här-filen

Därefter är UI-Kit Sketch-biblioteket, som innehåller alla våra komponenter, typografi, ikoner och färg. Alla skärmar i designfilerna använder länkade symboler från detta bibliotek.

UI-satsen är uppdelad i två sidor - en för symboler och en annan för alla designkomponentens klistermärkeark. Det senare innehåller detaljerad information om varje element och en intuitiv layout så att vi snabbt kan hitta det vi letar efter.

IOS UI-Kit-filen innehåller både ett klistermärkeark med komponenter såväl som själva symbolerna

Resten av filerna representerar olika delar av appen - Onboarding, Mail, Kalender, Sök, Inställningar och mer. Att separera varje kategori hjälper oss att undvika långsamma filer och fördröjning medan vi arbetar. Det är också en fördel vid sammanslagning av design, för när vi skapar nya funktioner behöver vi ofta bara beröra vissa delar av appen, vilket i gengäld betyder färre konflikter

Gå igenom designprocessen

Det första steget är att skapa en gren, som tar alla skissfilerna i masteren och skapar en kopia. Tänk på det som att kopiera en mapp. För att identifiera grenen tilldelar vi en enkel etikett till det stycke som vi arbetar med och lägger till lämplig titel efter etiketten. Vi använder vanligtvis etiketter som "Feature", "Kit" eller "Exploration" för att beskriva projektet. Hos Outlook uppmuntras vi att prova nya idéer och ändra allt vi tror kan förbättras - det är när vi använder en tagg som "Utforskning." Dessa etiketter ger andra gruppmedlemmar ett visst sammanhang och hjälper dem att hitta och förstå vad vi är jobbar på. Att skapa en gren är en enorm fördel eftersom det innebär att flera designers kan arbeta på samma filer och senare slå dem tillbaka till master.

Exempel på filialmärkning

I den nya grenen skapar jag en ny fil från Abstract. Jag namnger filen något som "Working", som hjälper andra att veta var de senaste iterationerna är. Då kan jag kopiera tavlor från andra filer till den här - det hjälper till att visualisera ett flöde eller ändra en befintlig skärm.

Skapa en

En skissfil som öppnas från abstrakt innehåller en liten flytande dialog med alternativet Förhandsgranska och begå. Det sparar arbete på servern och gör att andra i teamet kan se eventuella förändringar. Åtagandet påverkar inte mästaren, det uppdaterar bara grenen. I mitt team vill vi följa den allmänna regeln om att göra arbete en gång om dagen. Innan jag gör ändringar lägger jag till en beskrivande anmärkning som beskriver de ändringar jag har gjort. Jag har alltid tillgång till varje ändring, så vid behov kan jag återgå till en ändring eller titta igenom de tidigare versionerna av en fil.

Engagera sig dagligen

När en design är klar är det dags att städa lagren och slå samman designen till masterfilerna. Se till att lagrenamn är korrekta och att ordningen följer vad du ser på skärmen (från topp till botten). Detta bör upprepas för varje skärm. Jag kan antingen skapa en ny ny gren med namnet [Kit] och kopiera i de nya skärmarna till rätt fil, eller så kan jag skapa om dessa skärmar från grunden med de senaste bibliotekskomponenterna. Anledningen till att jag startar en ny fil är att bara ta in huvudskärmarna till befälhavaren. Jag kan alltid besöka den gamla grenen i det abstrakta arkivet senare. Det är lite tidskrävande och avskräcker oss från att slå samman funktioner mer regelbundet. Vi vill gärna höra från alla som har förslag på att förbättra sammanslagningsprocessen.

Nedan visas en demonstration av hur vi kan skapa en gren och använda UI-komponenterna från biblioteket för att designa skärmar i vår app. Det är denna kombination av Abstract och vårt komponentbibliotek som gör att vi kan arbeta snabbt och effektivt samtidigt som vi ger full insyn och synlighet för teamet. Vi arbetar från samma filer och våra nya filer är tillgängliga för alla.

Bildbeskrivning: Bygga Outlook-skärmar med våra UI-komponenter.

Innan jag väljer sammanslagningsknappen kan jag begära en granskning från någon i teamet. Vi letar efter länkade symbollager, korrekt namngivning, duplicerade symboler och förändringar i biblioteket. Granskarna lämnar vanligtvis feedback i kommentarerna i Sammanfattning eller på specifika tavlor och håller allt på samma plats. När recensioner har slutförts, slår vi samman designen och arkiverar den gamla grenen.

Bästa metoder för underhåll

Mitt team delar ansvaret för att uppdatera satsen med sina funktioner och jag leder till arbete för att hålla skissfilerna friska och kontinuerligt förbättra och uppdatera satsen - särskilt för att redovisa operativsystemuppdateringar eller för större designöversyner.

Formgivare kan ge feedback om seten när som helst, ta upp frågor eller inleda samtal om potentiella förbättringar. Vi spårar denna feedback i en GitHub-fråga, vilket gör att alla på tiden kan bidra. Nedan är ett exempel på de typer av feedback vi spårade för UI-kit, inklusive att ta bort duplicerade ikoner och lägga till färgöverskridanden till alla ikoner.

En Github-fråga för att spåra problem med UI-kit

Vår process och UI-kit har omfamnats av designteam över hela Microsoft när vi designar med ett mer öppet och samarbetsvilligt synsätt. När Fluent Design utvecklas på mobilen ser vi vanliga element genom Microsofts produkter.

Vi lär oss fortfarande och letar ständigt efter sätt att förbättra vår process. Vi skulle gärna höra hur andra team använder Abstract i sin designprocess och förslag på hur vi kan förbättra vårt.

Dela gärna dina idéer i kommentarerna .

Följ oss på Dribbble, Twitter och Facebook eller gå med i vårt Windows Insider-program för att hålla dig uppdaterad med Microsoft Design. Och om du är intresserad av att gå med i vårt team, gå över till aka.ms/DesignCareers.

Skrivet med och med hjälp av Miles Fitzgerald och Outlook-teamet.