Wat is DesignOps? Waarom heeft je team dit nodig? En hoe kan DesignOps uw ontwerp- / ontwikkelingsteam helpen slagen? Dit artikel geeft antwoord op deze vragen en biedt u ook handige tips voor het beginnen met de implementatie van dit nieuwe concept in uw ontwikkelteam.
In de moderne wereld is het de snelheid van het ontwikkelteam die vaak de levensvatbaarheid van een product bepaalt. Tegelijkertijd is er één belangrijk element dat het belangrijkst en het meest problematisch is: ontwerp.
Ontwerp wordt vaak een bottleneck en heeft een grote impact op het hele ontwikkelingsproces, ongeacht de grootte van uw team. Soms helpen bovenmenselijke inspanningen van een ontwerpleider het ontwerpproces, maar zodra de werkbelasting toeneemt, moet u uw team opschalen.
Hoe vaak heb je gezien:
Als een of meer van deze geluiden bekend voorkomen, is het hoog tijd om DesOps (Design Operations) te implementeren.
De term DesOps of DesignOps is een replica van de term DevOps wat een software engineering-praktijk is die gericht is op het verenigen van ontwikkelingsprocessen om meer efficiëntie te creëren. Net als DevOps-specialisten zijn DesOps-specialisten ervaren ontwerpers met managementvaardigheden die het ontwerpproces begrijpen in de bredere context van productontwikkeling.
Hoewel we misschien niet allemaal de term "DesOps" in onze functie hebben, zijn veel oudere ontwerpers al verantwoordelijk voor dezelfde rol. Van het opzetten van ontwerpprocessen tot het ontwikkelen van ontwerpsystemen tot het maken van strategieën en het beheren van ontwerpteams, DesOps is een steeds meer gevraagde rol.
Wat er echt toe doet, is dat deze aanpak schaalbaar en relevant is, zelfs in teams met een enkele ontwerper. Dus, hoe begin je DesOps te implementeren?
Ontwerpers moeten weten wanneer hun taak compleet is en klaar is om te worden doorgegeven aan het ontwikkelteam. Bijvoorbeeld, ontwerpers hebben behoefte aan een duidelijk begrip van welke staten elk scherm moet hebben en welke activa nodig zullen zijn voor het ontwikkelteam om die activa te bouwen.
Het kan zijn dat dit een gebied is dat ontwerpers inherent moeten begrijpen. Maar het is eigenlijk een van de meest voorkomende punten van wrijving in een project en moet niet worden genegeerd. Als je duidelijk verwoordt wat nodig is, dan verminder je conflicten en zorg je ervoor dat iedereen zijn verantwoordelijkheden begrijpt.
De voordelen hiervan zijn: het zorgt ervoor dat een stabiel ontwikkelingsritme wordt gehandhaafd; het vermindert de totale ontwikkelingstijd; het vermindert het aantal discussies dat nodig is tussen ontwerpers, ontwikkelaars en leads.
Voor het laatste punt hebben we specifiek bekeken wat de ontwerper moet overbrengen aan ontwikkelaars. Dit punt gaat over de vorm die de ontwerper moet gebruiken om de design-mockups, gepolijst ontwerp, prototypen, moodboards over te brengen - wat heeft de ontwerper nodig om zijn bedoelingen effectief over te brengen in een formaat dat de ontwikkelaars kunnen begrijpen.
Er zijn talloze opties, zoals Zeplin of InVision maar een van de meest voorkomende klachten van ontwikkelaars is dat deze indelingen niet alles bieden wat ze nodig hebben (zoals geëxporteerde items). Dat komt echter meestal doordat ontwerpers hun ontwerpen niet goed hebben geëxporteerd. Door te verduidelijken voor ontwerpers wat ze naar verwachting zullen produceren, kunnen ze de juiste assets gemakkelijk doorgeven.
U moet een intern document maken dat specifieke technische vereisten bevat voor activa, ontwerphulpmiddelen, samenwerking met ontwikkelaars en andere teamleden; tot slot moet dit document duidelijk aangeven wanneer en hoe ontwerpen moeten worden geleverd.
Een reeks ontwerp- en engineeringoplossingen, evenals handleidingen voor hun implementatie, zullen een aantal voordelen garanderen: productintegriteit; eenvoudiger en sneller aan boord komen van nieuwe teamleden; efficiënter werk van zowel ontwerpers als ontwikkelaars (omdat ze kunnen communiceren in één taal die wordt gedefinieerd door het ontwerpsysteem).
De voordelen hiervan zijn: verbeterde algehele kwaliteit van het werk; vermindert "verzakking" wanneer u het team opschaalt; verhoogt de snelheid van zowel ontwerp als ontwikkeling.
We houden allemaal van coole nieuwe tools, maar een effectief team werkt met een uniforme set tools en zorgt ervoor dat deze eenheid jouw verantwoordelijkheid is.
Alle hulpprogramma's moeten up-to-date zijn, maar als een update om welke reden dan ook wordt overgeslagen, moet iedereen deze overslaan.
De voordelen hiervan zijn: meer teambetrokkenheid; verhoogde ontwerp- en ontwikkelingssnelheid; verbeterde teamsamenwerking.
Ontwikkelaars hebben meer geluk met deze taak, omdat versiebeheer voor code een volwassen industrie is met veel opties. Het is moeilijk om een vergelijkbare aanpak voor ontwerpers te produceren, omdat processen zo divers zijn, maar in het afgelopen jaar zijn tools zoals Abstract , Kaktus , en Fabriek zijn steeds populairder geworden. U kunt zelfs meerdere ontwerpers laten werken aan één lay-out met iets als Figma .
De voordelen hiervan zijn: verbeterde communicatie; vereenvoudigde teamschaling; snelle ontwerpprocessen, omdat meerdere ontwerpers productief aan één project kunnen werken.
Als u alle functionaliteit met betrekking tot ontwerpen wilt beschrijven, probeert u 'visuele documentatie' te gebruiken in plaats van technische specificaties te schrijven. In de meeste gevallen volstaat het dat een ontwikkelaar een interactief prototype heeft om de basislogica te begrijpen en antwoorden op de meeste vragen te vinden.
De voordelen hiervan zijn: minder tijd aan het schrijven van technische specificaties; vermindert de omvang van het werk voor technische schrijvers; ontwikkelaars besteden minder tijd aan het lezen van documentatie en meer tijd aan het schrijven van code; ontwerpers zijn productiever; versneld ontwikkelingsritme.
Er is absoluut geen plaats voor ontwerp in veel populaire softwareontwikkelingsmethodologieën; welk ontwikkelingsproces u ook gebruikt, zoek ruimte voor ontwerpers.
De voordelen hiervan zijn: een verenigd team met verbeterde communicatie; verhoogde ontwikkelsnelheid; minder nabewerking en downtime van ontwikkelaars.
Je moet constant de groei van kwantitatieve en kwalitatieve indicatoren laten zien dankzij de geïmplementeerde veranderingen, zowel voor teamleden als voor topmanagement. Zonder dit zal een team niet graag veranderen, terwijl het topmanagement niet zal begrijpen waar en waarom extra middelen worden uitgegeven. Constante verzameling en presentatie van positieve resultaten na het implementeren van wijzigingen zal u helpen om geloofwaardigheid en de nodige autoriteit te verkrijgen voor verdere wijzigingen in de teamworkflow.
Voordelen zijn: verhoogde motivatie en een sterker team; facilitering van nieuwe regels en praktijken; ondersteuning voor toekomstige innovatie.
De term "DesOps" is vrij nieuw en begint net zijn betekenis te krijgen; de eerste DesOps-conferentie werd alleen gehouden in november, in New York.
Voor nu zou ik dit gewoon een cultuur noemen die gericht is op het ontwikkelen en faciliteren van solide ontwerpprocessen. Maar ik denk dat we dit in de nabije toekomst als een afzonderlijke ontwerprol in elk productteam zullen hebben. Ik geloof echter dat we het veilig kunnen hebben over het belang van het introduceren van deze praktijken om de efficiëntie van de ontwerpworkflow en de productontwikkeling in het algemeen te verbeteren.