Een ontwerpsysteem starten

Van het uitstippelen van een strategie tot het lanceren van 1.0 en daarna

Het starten van een ontwerpsysteem voor een productportfolio is geen typisch project. Natuurlijk levert de inspanning herkenbare resultaten op, zoals een beeldtaal en UI-componenten. Het moet vertrouwd aanvoelen, door iteraties van ontwerp, ontwikkeling en documentatie bladeren.

De belofte van het systeem is echter geen geleverde bibliotheek. De belofte van het systeem is het mogelijk maken van een consistente ervaring verspreid over producten en ondersteund met een betrouwbare, voorspelbare praktijk. Systeementhousiasten moeten ondernemers worden, ideeën pitchen en verkopen die een mogelijk resistente organisatie ertoe brengen om zich te engageren. Na verloop van tijd bereikt een systeem betekenisvolle resultaten door te coördineren en samen te werken over de organisatorische grenzen en vervelende cultuur. Het is een proces.

Deze boog om een ​​systeem te starten - een strategie uit te stippelen, een eerste release te lanceren en regelmatig te werken om adoptie en gemeenschap te bevorderen - is effectief gebleken in de vijf systemen die ik sinds begin 2016 heb geleid. Ze zijn allemaal gemaakt, geadopteerd en blijven werken vandaag met hier beschreven activiteiten en tijdlijnen. Moge de aanpak inspireren als je een reis begint naar een systeem dat blijft bestaan.

Commit voor een systeemstrategie

Een ontwerpsysteem begint niet met het kiezen van een eerste kleur. Plaats in plaats daarvan een systeem in een strategie die de behoeften van de klant onderscheidt, doelen stelt, onderzoekt en convergeert in een ontwerprichting, een strategie pakt en de inzet van een organisatie verkrijgt.

Ontdek klantbehoeften

Zoals elk product dat we ontwerpen en ontwikkelen, moet een ontwerpsysteem tegemoetkomen aan de behoeften van het aannemen van productteams binnen het huidige landschap van cultuur, tools, bestaande systemen en werkwijzen.

Ontdekkingsactiviteiten kunnen zijn:

  • Interviews met belangrijke (potentiële) bijdragers, beïnvloeders en leiders om perspectief, attitudes, cultuur en bestaande praktijken te beoordelen.
  • Onderzoek naar een bredere organisatie van de attitudes en houding van stakeholders ten opzichte van een systeem, prioriteiten / behoeften, ambities en bedreigingen.
  • Vereisten verzamelen via taakanalyse, technische planning en conventie-instelling (met behulp van tools zoals de Front End-vragenlijst van Brad Frost).
  • Productrondleidingen om onder te dompelen in as-is producten en in-flight ontwerpen waarop het systeem van toepassing is, met screenshots en aantekeningen.
  • Systeem (en) beoordelingen die as-is ontwerpactiva, codebibliotheken, normdocumentatie diepte en kwaliteit, en bestuursmodellen beoordelen.

Betrek belanghebbenden bij inclusieve workshops

Ontdekking kan leiden tot persoonlijke presentaties en werksessies om de voortgang samen te vatten en meer input te verzamelen. We zullen grote groepen ontwerpers, ingenieurs, leidinggevenden en anderen bijeenroepen voor sessies om:

  • Presenteer ontdekking en onderzoeksresultaten en aanbevelingen.
  • Definieer systeem- en productenbereik via oefeningen zoals Onderdelen, Producten & Mensen en Component Cut Up voorraden van bestaande producten.
  • Bespreek modellen en kandidaten voor systeemteams en leiders, participatie van de gemeenschap en bijdragen.
  • Verzamel ingenieurs en tech-managers om aannames te bevestigen, framework (s) te kiezen en ontwikkelomgeving en hostingbehoeften te identificeren.
  • Roadmap aankomende systeemactiviteit inclusief referentieontwerpconcepten, eerste releasecyclusproces en hoe we succes meten.

Convergeren op een conceptuele richting

Vaker wel dan niet, valt het opzetten van een ontwerpsysteem samen met het ontwikkelen van een nieuwe beeldtaal vanaf de basis en het toepassen van die taal op UI-componenten die productteams overeenkomen te gebruiken. Uw succes hangt af van uw organisatie aan boord krijgen met de richting die u opgaat.

Daarom is het van cruciaal belang om conceptueel uw nieuwe visuele richting te demonstreren met foto's van uw productervaring voor en nadat een systeem van toepassing is. Dit proces moet leden van uw gemeenschap bij elke stap van de weg omvatten en zelfs in dienst nemen.

Referentieontwerpen in een vroeg stadium voor de responsieve herontwerpperiode van Marriott.com 2012-2014.

Voor meer informatie over het voorbereiden en presenteren van concepten, lees referentieontwerpen voor systemen: paginaconcepten vergelijken voor en na, met een systeemwending.

Pitch een strategie met een duidelijk voorstel

Uiteindelijk is een strategie niets als de mensen die ertoe doen - zowel leidinggevenden met fondsen als gemeenschappen van producten die adopteren - er niet in geloven. Dus je moet een strategie pitchen. En dat betekent een presentatiedek maken.

Een voorbeeld van een pitch pitchdeck, vanaf later 2016

Onze typische strategie pitch presentatie omvat onderwerpen als:

  • Bepalen wat een ontwerpsysteem is en waarom het belangrijk is.
  • Verhalen die waarde uitdrukken, zoals het koppelen van de universele And You Thought-knoppen waren eenvoudig met andere uitdagingen die relevant zijn voor een organisatie.
  • Voorgestelde scope, timing, producten en processen opgenomen in 1.0 release, daaropvolgende productacceptatie en -ondersteuning en systeemontwikkeling en onderhoud dat volgt (het hoe en wanneer).
  • Aanbevolen multidisciplinaire systeemteamsamenstelling en hoe zij bijdragers en besluitvormers (de wie) zullen betrekken.

Zorg voor een commitment en een team

Wees niet verlegen. U vraagt ​​om een ​​nieuw product in uw organisatie te lanceren, dus u moet het vragen. Waar vraag je om?

  1. Capaciteit van personeel om een ​​systeem te maken en te onderhouden, nu en na de lancering.
  2. Producten - vaak heel veel producten - om te anticiperen op de verantwoordelijkheid om ergens in de toekomst belangrijke wijzigingen aan te brengen.
  3. Een gemeenschap en organisatie om te evolueren hoe het werkt, het werk deelt, beslissingen neemt en meer. Organisatorische verandering is moeilijk.

We verlaten vaak een veld met directe of stilzwijgende goedkeuring om ermee door te gaan. Ik heb nog meer drijfvermogen als een CEO naar mijn collega's in het bedrijf loopt en ik daarna achter elkaar aan het kruipen ben en zegt:

Wat je deelde is heel aantrekkelijk en waardevol. Goed werk. Laat me weten wat je nodig hebt om dit mogelijk te maken.

Maar mondelinge goedkeuringen betekenen niet morgen beginnen. Soms lopen dingen vast.

Veel factoren kunnen het momentum vertragen. Misschien heeft uw eerste worp een vervolgstap naar operaties en HR teweeggebracht om personeel te verplaatsen. Misschien moet u wachten op de volgende ronde in het kwartaalbudgetproces van een onderneming. Of er is gewoon een overgangsperiode wanneer het systeemteam overschakelt van verplichtingen van het productteam. Blijf op koers! Blijf volhardend! Je komt er wel.

Met goedkeuring ga je op een gegeven moment officieel een systeem maken.

Start een 1.0-release

Je hebt een organisatorisch mandaat en een team van ontwerpers, ingenieurs, leiders en anderen binnengehaald. Scope is duidelijk. Het is tijd om een ​​systeem sprint per sprint te ontwerpen, bouwen en documenteren om naar een eerste release te gaan.

Terwijl essentiële onderdelen tevoorschijn komen, biedt een alpha 0.1 vroege gebruikers een voorproefje. Naarmate de componentenbibliotheek groeit, kan vroege acceptatie beginnen met het gebruik van bèta-releases zoals 0.3 en hoger.

Hoewel sprints incrementele releases kunnen opleveren om uw proces te verstevigen, is uw oog op de prijs van de release gericht, waarna alle teams deze aannemen. Eenvoudigere bibliotheken kunnen 2-3 maanden duren, terwijl robuuste componentcatalogi - flexibel thema, geavanceerde tooling, robuuste documentatie - een paar maanden langer kunnen duren. Aan het einde van de cyclus vertegenwoordigt de 1.0 de "grote lancering" waarvan u publiceert en die in het algemeen beschikbaar is voor productteams.

Scope incrementeel leveren

Een eerste releasecyclus levert iets op waar niets was. Naarmate een systeem vordert, moeten haar klanten, sponsors en zelfs het team zelf een idee hebben van wat er wanneer zal gebeuren, evenals comfort in de onnauwkeurige timing van het afwerken van elk stuk.

Gedurende die tijd zal een nieuw gevormd team wennen aan een ontwikkelingsproces om elk onderdeel te leveren, hier afgebeeld als ontwerp / gebouwd in oranje en document / gepubliceerd in donkergrijs.

Voor planning op hoog niveau zijn gedetailleerde workflows per item niet belangrijk. De volgorde of namen van specifieke componenten in het bovenstaande voorbeeld ook niet (hoewel dat eerlijk gezegd een vrij algemene reikwijdte en volgorde van levering is). In plaats daarvan concentreer ik me op hoe ons team is:

  • Onderdelen geleidelijk over sprints leveren.
  • Later meer onderdelen per sprint leveren naarmate de productiviteit toeneemt.

Wat moet iedereen vertrouwen? Dat het systeemteam een ​​eerste bibliotheek zal leveren - durf ik "MVP?" Te zeggen - dat tegen een voorspelbare tijd kan worden aangenomen. Daarom zal ik herhaaldelijk benadrukken dat we op koers zijn om een ​​1.0 te lanceren die een sterke visuele basis en 12 tot 16 UI-componenten levert.

Operate Beyond the 1.0 Release

Vanaf het begin van het streven naar een ontwerpsysteem, zelfs al tijdens uw interviews en workshops tijdens Discovery, is het essentieel om te communiceren dat een ontwerpsysteem geen project is, maar een product. Het zal na verloop van tijd worden geoefend, geleverd en onderhouden dat niet eindigt met 1.0.

Als gevolg hiervan werk ik met leiderschap om capaciteit en processen te regelen voor wat de volgende stap is, aangezien het team midden in een intense eerste releasecyclus zit.

De tweede ontwikkelingscyclus vestigt zich ook in een regelmatige cadans van planning en levering, zoals kwartalen van zes of zeven sprints. Het doel is geen onverwachte 2.0 te lanceren, die voorbarig en tumultueus zou zijn. In plaats daarvan, in tegenstelling tot een intense duw naar 1.0, moet het team met discipline beginnen te presteren en worden gezien als "business as usual".

Overschakelen van formatie naar bewerkingen

Dit doorlopende programma vereist een draaipunt van een formatieve naar operationele mindset. Niet langer beperkt tot het leveren van kernfuncties, diversifiëren de activiteiten naar:

  • Defecten uitbreiden, optimaliseren en verhelpen om te behouden wat er is.
  • Het leveren van nieuwe functies die belangrijk zijn voor het bedrijf.
  • Coördineren en ondersteunen van productacceptatie met training, gepaarde integratie, help, monitoring en rapportage.
  • Cultiveren van een gemeenschap van invloed en bijdragen van ontwerpers en ingenieurs.
De nadruk op een adoptieplan legt de nadruk op de relatie tussen een systeem en producten die het bedient

Vooral het helpen van een productorganisatie bij het aannemen van een ontwerpsysteem vereist opzettelijke, gerichte en moeizame samenwerking. Wees uitgerust met een beknopt presentatiedek en demo, en klaar om het keer op keer te presenteren. Door acceptatie te benadrukken in een plan op hoog niveau, ontstaat een nuttige focus op uw belangrijkste relaties: een systeem en alle adoptieproducten.

Investeer het programma in regelmatige tijdsverhogingen

Deze periodes houden een groeiende bibliotheek in stand, maar moeten ook aantoonbare bedrijfswaarde blijven leveren. Net als de eigen patronen van een systeem, bouwt en levert het programma in stappen het patroon van nieuwswaardige vooruitgang, synchronisatie met producten en routekaarten.

Voor elk kwartaal zou je epics kunnen leveren zoals:

  • In Q3, navigatiecomponenten, patronen en responsieve lay-outs.
  • In Q4, diverse waarschuwingscomponenten met redactionele begeleiding, plus beweging!
  • In Q1 volgend jaar, datavisualisatie, grafieken en robuuste illustraties.
  • In Q2 volgend jaar, een brede subcatalogus van componenten voor hero en content.

Oudere systeemprogramma's verlengen de tijdschaal nog meer en groeien uit tot het vaststellen van doelstellingen of thema's die jaarlijks opnieuw worden bekeken en bijgehouden, net als elk ander product, portfolio en programma binnen een onderneming.

Dit lijkt misschien ver weg of zelfs eng als je een systeem van de grond krijgt. Maar zelfs als u eerst de essentiële dingen levert, kunt u concepten van regelmatige planningscadans, epics en thema's gebruiken om te illustreren waar uw systeemreis naartoe kan gaan.

Wil je beginnen met een ontwerpsysteem of moet je dieper duiken om producten en spelers te bespreken? EightShapes geeft workshops voor systeemplanning en begeleidt klanten bij ontwerpsystemen. Laten we praten!