Hva er DesignOps? Hvorfor trenger teamet ditt dette? Og hvordan kan DesignOps hjelpe design / utviklingslaget ditt å lykkes? Denne artikkelen svarer på disse spørsmålene og gir deg også nyttige tips om hvordan du begynner å implementere dette nye konseptet i utviklingslaget ditt.
I den moderne verden er utviklingslagets fart som ofte definerer levedyktigheten til et produkt. Samtidig er det et nøkkelelement som er viktigst og mest problematisk: design.
Design blir ofte en flaskehals og påvirker hele utviklingsprosessen, uansett størrelsen på laget ditt. Noen ganger bidrar superhuman innsats fra en designledning til å drive designprosessen, men så snart arbeidsbelastningen øker, må du skala laget ditt.
Hvor ofte har du sett:
Hvis noen eller alle disse er kjent, er det på tide å implementere DesOps (Design Operations).
Begrepet DesOps eller DesignOps er en kopi av begrepet DevOps som er en programvare engineering praksis som tar sikte på å forene utviklingsprosesser for å skape større effektivitet. I likhet med DevOps-spesialister er DesOps-spesialister erfarne designere med ledelsesevner som forstår designprosessen innenfor større sammenheng med produktutvikling.
Selv om vi kanskje ikke alle har "DesOps" -begrepet i vår jobbtittel, er mange senior designere allerede ansvarlige for samme rolle. DesOps er en stadig mer etterspurt rolle fra å etablere designprosesser, utvikle designsystemer, skape strategier og administrere designteam.
Det som virkelig betyr noe, er at denne tilnærmingen er skalerbar og relevant selv i lag med en enkelt designer. Så, hvordan begynner du å implementere DesOps?
Designere trenger å vite når jobben er ferdig og klar til å bli overført til utviklingslaget. For eksempel trenger designere en klar forståelse av hvilke stater hver skjerm må ha, og hvilke eiendeler vil det være nødvendig for utviklingslaget å bygge disse eiendelene.
Det kan føle at dette er et område som designere bør forstå. Men det er faktisk en av de vanligste friksjonspunktene i et prosjekt og bør ikke ignoreres. Hvis du formulerer det som kreves klart, vil du redusere konflikter og sikre at alle forstår deres ansvar.
Fordelene med dette er: det gjør det mulig å opprettholde en jevn utviklingstakt; det reduserer total utviklingstid; det reduserer antallet diskusjoner som er nødvendige mellom designere, utviklere og kundeemner.
For det siste poenget vurderte vi spesielt hva designeren burde formidle til utviklere. Dette punktet handler om hvilken form designeren skal bruke for å formidle designmockups, polert design, prototyper, humørbrett - hva må designeren gi for å effektivt formidle sine intensjoner i et format som utviklerne kan forstå.
Det finnes mange alternativer, for eksempel Zeplin eller InVision men en av de vanligste klager fra utviklere er at disse formatene ikke gir alt de trenger (for eksempel eksporterte eiendeler). Men det er vanligvis fordi designere ikke har riktig eksportert sine design. Ved å klargjøre for designere hva de forventes å produsere, kan de enkelt passere de riktige eiendelene.
Du bør opprette et internt dokument som inneholder spesifikke tekniske krav til eiendeler, designverktøy, samarbeid med utviklere og andre lagmedlemmer. Til slutt skal dette dokumentet klart definere når og hvordan design skal leveres.
Et sett med design- og ingeniørløsninger, samt veiledning for implementering, vil sikre en rekke fordeler: produktintegritet; enklere og raskere ombordstigning av nye lagmedlemmer; mer effektivt arbeid både designere og utviklere (som de kan kommunisere på ett språk definert av designsystemet).
Fordelene med dette er: forbedret total arbeidskvalitet; reduserer "sag" når du skaler laget; øker hastigheten til både design og utvikling.
Vi elsker alle kule nye verktøy, men et effektivt team arbeider med et ensartet sett med verktøy, og at denne enheten er ditt ansvar.
Alle verktøyene skal være oppdaterte, men hvis en oppdatering hoppes over en eller annen grunn, bør alle hoppe over det.
Fordelene ved dette inkluderer: økt lagsprosess; økt design og utvikling hastighet; forbedret teamsamarbeid.
Utviklere er heldigere med hensyn til denne oppgaven, fordi versjonskontroll for kode er en moden industri med mange alternativer. Det er vanskelig å produsere en lignende tilnærming til designere, da prosesser er så forskjellige, men i det siste året har verktøy som Abstrakt , Kaktus , og Anlegg har blitt stadig mer populært. Du kan til og med ha flere designere som arbeider på en enkelt layout med noe som Figma .
Fordelene med dette er: bedre kommunikasjon; forenklet team skalering; raske spor design prosesser som flere designere kan jobbe på et enkelt prosjekt produktivt.
For å beskrive all funksjonalitet knyttet til design, prøv å bruke "visuell dokumentasjon" i stedet for å skrive tekniske spesifikasjoner. I de fleste tilfeller er det nok for en utvikler å ha en interaktiv prototype for å forstå grunnleggende logikken og finne svar på de fleste spørsmål.
Fordelene med dette inkluderer: redusert tid skrive tech spesifikasjoner; reduserer omfanget av arbeid for tekniske forfattere; utviklere bruker mindre tid å lese dokumentasjon og mer tid skriving kode; designere er mer produktive; akselerert utviklings tempo.
Det er absolutt ingen plass for design i mange populære programvareutviklingsmetoder; Uansett utviklingsprosess du bruker, finn plass til designere.
Fordelene med dette er: et forent team med bedre kommunikasjon; økt utviklingshastighet; redusert omarbeidelse og nedetid for utviklere.
Du bør hele tiden demonstrere veksten av kvantitative og kvalitative indikatorer takket være de implementerte endringene, både for teammedlemmer og toppledelse. Uten dette vil et lag være motvillig til å endre, mens toppledelsen ikke vil kunne forstå hvor og hvorfor flere ressurser blir brukt. Konstant innsamling og presentasjon av positive resultater etter implementering av endringer, vil hjelpe deg med å oppnå troverdighet og nødvendig autoritet for videre endringer i team-arbeidsflyten.
Fordelene er: økt motivasjon og et sterkere lag; tilrettelegging av nye regler og praksis støtte for fremtidig innovasjon.
Begrepet "DesOps" er ganske nytt og begynner bare å skaffe seg sin mening; de første DesOps-konferanse ble bare holdt i november i New York.
For nå vil jeg bare kalle dette en kultur som har som mål å utvikle og legge til rette for solide designprosesser. Men jeg føler at i nær fremtid vil vi få dette som en egen designrolle i alle produktgrupper. Men jeg føler at vi allerede trygt kan snakke om viktigheten av å innføre disse praksisen for å forbedre effektiviteten av design arbeidsflyt og produktutvikling generelt.