Vad är DesignOps? Varför behöver ditt lag detta? Och hur kan DesignOps hjälpa ditt design / utvecklingsteam att lyckas? Denna artikel svarar på dessa frågor och ger dig också användbara tips om hur du börjar implementera detta nya koncept i ditt utvecklingsteam.
I den moderna världen är det utvecklingslagets hastighet som ofta definierar en produkts lönsamhet. Samtidigt finns det ett nyckelelement som är viktigast och mest problematiskt: design.
Design blir ofta en flaskhals och påverkar hela utvecklingsprocessen, oavsett storlek på ditt lag. Ibland bidrar superhumana ansträngningar från en designledning till att driva designprocessen, men så snart arbetsbelastningen ökar måste du skala ditt team.
Hur ofta har du sett:
Om någon eller alla dessa låter bekanta, är det dags att implementera DesOps (Design Operations).
Termen DesOps eller DesignOps är en replika av termen DevOps vilket är en mjukvaruteknik som syftar till att förena utvecklingsprocesser för att skapa större effektivitet. I likhet med DevOps-specialister är DesOps-specialister erfarna designers med ledningsförmåga som förstår designprocessen inom det större sammanhanget för produktutveckling.
Även om vi kanske inte alla har "DesOps" termen i vår jobbtitel, är många senior designers redan ansvariga för samma roll. DesOps är en alltmer efterfrågad roll från att skapa designprocesser, utveckla designsystem, skapa strategier och hantera designteam.
Det som verkligen betyder är att detta tillvägagångssätt är skalbart och relevant även i lag med en enda formgivare. Så, hur börjar du med att implementera DesOps?
Designers behöver veta när deras jobb är färdigt och redo att gå vidare till utvecklingslaget. Till exempel behöver designers en tydlig förståelse för vilka stater varje skärm måste ha, och vilka tillgångar kommer att krävas för utvecklingsteamet att bygga dessa tillgångar.
Det kan tyckas att detta är ett område som designers ska förstå. Men det är faktiskt en av de vanligaste friktionspunkterna i ett projekt och bör inte ignoreras. Om du formulerar vad som krävs klart, kommer du att minska konflikter och se till att alla förstår sitt ansvar.
Fördelarna med detta är: det möjliggör en stadig utvecklingstakt, det minskar den totala utvecklings tiden; det minskar antalet diskussioner som behövs mellan designers, utvecklare och leads.
För sista punkten övervägde vi specifikt vad designern skulle förmedla till utvecklare. Denna punkt handlar om vilken form formgivaren ska använda för att förmedla designmockups, polerad design, prototyper, humörbrädor - vad behöver designern för att effektivt förmedla sina avsikter i ett format som utvecklarna kan förstå.
Det finns många alternativ, till exempel Zeplin eller InVision men en av de vanligaste klagomålen från utvecklare är att dessa format inte ger allt de behöver (till exempel exporterade tillgångar). Men det är oftast för att designers inte har exporterat sina konstruktioner korrekt. Genom att förtydliga för designers vad de förväntas producera, kan de enkelt överföra rätt tillgångar.
Du bör skapa ett internt dokument som innehåller specifika tekniska krav för tillgångar, designverktyg, samarbete med utvecklare och andra lagmedlemmar. Slutligen ska det här dokumentet tydligt definiera när och hur mönster ska levereras.
En uppsättning design- och tekniklösningar samt guider för deras genomförande kommer att säkerställa ett antal fördelar: produktintegritet; enklare och snabbare ombord på nya lagmedlemmar; mer effektivt arbete hos både designers och utvecklare (som de kan kommunicera på ett språk definierat av designsystemet).
Fördelarna med detta är: förbättrad övergripande kvalitet på arbetet; reducerar "sag" när du skala laget; ökar hastigheten för både design och utveckling.
Vi alla älskar coola nya verktyg, men ett effektivt team arbetar med en enhetlig uppsättning verktyg, och att säkerställa denna enhet är ditt ansvar.
Alla verktyg borde vara aktuella, men om en uppdatering hoppas av någon anledning, ska alla hoppa över det.
Fördelarna med detta är: ökat lagspel ökad design och utveckling hastighet; förbättrat team samarbete.
Utvecklare är lyckligare när det gäller denna uppgift, eftersom versionskontroll för kod är en mogen bransch med många alternativ. Det är svårt att producera ett liknande tillvägagångssätt för designers, eftersom processer är så olika, men under det senaste året har verktyg som Abstrakt , Kaktus , och Växt har blivit alltmer populär. Du kan till och med ha flera designers som arbetar på en enda layout med något liknande Figma .
Fördelarna med detta är: förbättrad kommunikation; förenklad teamskalning; Snabba spårdesignprocesser som flera designers kan arbeta på ett enda projekt produktivt.
För att beskriva all funktionalitet relaterad till mönster, försök använda "visuell dokumentation" istället för att skriva tekniska specifikationer. I de flesta fall räcker det för en utvecklare att ha en interaktiv prototyp för att förstå den grundläggande logiken och hitta svar på de flesta frågor.
Fördelarna med detta inkluderar: reducerad tidskrivning av tekniska specifikationer; Minskar arbetsskala för tekniska författare; utvecklare spenderar mindre tid läs dokumentation och mer tid skriv kod designers är mer produktiva; accelererad utveckling takt.
Det finns absolut ingen plats för design i många populära mjukvaruutvecklingsmetoder. vilken utvecklingsprocess du använder, hitta utrymme för designers.
Fördelarna med detta är: ett förenat team med förbättrad kommunikation; ökad utvecklingshastighet; reducerat omarbetande och utvecklarens stillestånd.
Du bör ständigt visa tillväxten av kvantitativa och kvalitativa indikatorer tack vare de genomförda förändringarna, för både lagmedlemmar och toppledare. Utan detta kommer ett team att vara ovilliga att förändra, medan toppledningen inte kommer att kunna förstå var och varför ytterligare resurser spenderas. Konstant insamling och presentation av positiva resultat efter genomförande av förändringar hjälper dig att få trovärdighet och nödvändig auktoritet för vidare förändringar i arbetsflödet.
Fördelarna inkluderar: ökad motivation och ett starkare lag; underlättande av nya regler och praxis stöd för framtida innovation.
Termen "DesOps" är ganska ny och börjar bara förvärva sin mening; de första DesOps-konferensen hölls bara i november i New York.
För nu vill jag bara kalla detta en kultur som syftar till att utveckla och underlätta solida designprocesser. Men jag känner att vi inom den närmaste framtiden kommer att ha detta som en separat designroll i varje produktgrupp. Men jag känner att vi redan säkert kan prata om vikten av att införa dessa metoder för att förbättra effektiviteten i designflödet och produktutvecklingen i allmänhet.