Een systeemteam ontwerpen

Modellen en lessen geleerd om een ​​team op te schalen voor een onderneming

De meeste organisaties beginnen systemen te begrijpen en waarom ze belangrijk zijn. Hoeveel kost het echter? Welk team hebben we nodig?

Een systeemteam bedient productteams

Het uitstekende boek Org Design for Design Orgs van Peter Merholz en Kristen Skinner beschrijft modellen en rollen in het samenstellen van ontwerpteams en -orgels. In het hoofdstuk Rollen en teamsamenstelling beschrijven ze een aanvullend onderzoeksteam dat in veel andere teams werkt:

"UX-onderzoekers hebben nu een kritische massa om hun eigen team te zijn ... [met] A Head of Research ... ter ondersteuning van de professionele groei van de onderzoekers en het handhaven van een wereldwijd inzicht in onderzoeksinzichten in alle producten en diensten van een bedrijf."

Toen ik dit las, dacht ik bij mezelf: "Yup, like design systems teams" om de wijdverbreide, eenvoudigere ontwerpproblemen op te lossen - een visuele taal, bruikbare interface-componenten, enz.

Met dit model in gedachten, was ik verrast om te horen dat Peter afgelopen november bij UI21 reflecteerde op (Spotify's) systeemteam als iemand die "een patch moest hacken, een organisatorische patch op [het] model [en]" die hij heeft beschreven. Misschien begrijp ik het niet. Maar ik heb in de loop van de jaren ~ 15-20 systeemteams gehad die veel teams bedienen, vergelijkbaar met (maar niet hetzelfde als) dergelijke onderzoekspraktijken.

Mijn ervaring is dat het optimale systeemteam multidisciplinair en onafhankelijk is om vele teams te bedienen die digitale dingen maken. Het systeemteam gedraagt ​​zich als een product dat wordt verbruikt door producten (en andere teams).

Wie zit er in dat team? Zijn ze voltijd of deeltijd? Welke disciplines moeten vertegenwoordigd zijn? Uit welk team (s) halen we ze?

Met deze vragen in gedachten, illustreert dit artikel de gemeenschappelijke fasen van groei van een systeemteam, geeft het voorbeelden van teams die ik de afgelopen vier jaar heb geleid en behandelt het patronen en mogelijke valkuilen waarmee u te maken kunt krijgen bij het vormen en beheren van een systeemteam.

Stadia van systeemteamgroei

De meeste mensen met wie ik spreek op klanten, conferenties en de Design System Slack van onze community evolueren in een van de vier stadia van groei: vrije timers, toegewezen individuen, toegewijd team en team-of-teams.

Fase # 1: reservetimers

Individuele aanpassingssystemen werken aan de rand van de tijd beschrijven vaak hoe hun gepassioneerde burst niet echt van de grond is gekomen:

"Ik ben alleen. Ik heb in mijn extra tijd een {Sketch-stickervel of mini-Bootstrap-codekit} gemaakt, maar niemand anders gebruikt het. Hoe zet ik de volgende stap? "

Systemen gebouwd op vrijdagmiddag of zondagavond duren niet. Een starter Sketch-sjabloon of startercode is beter dan niets. Spartaanse inspanningen zijn echter geen praktijk in de onderneming.

Afhaalmaaltijden: raak niet ontmoedigd! Veel systeemreizen beginnen zo. Bewijs dat uw tools leiden tot resultaten - consistentie, efficiëntie, hergebruik - in proefprojecten. Het is een springplank om te leren hoe systeeminspanningen anderen ten goede komen.

Fase 2: Toegewezen persoon (personen)

Omdat systeemwaarde wordt herkend, snijdt een manager de voorspelbare maar beperkte toewijzing (10% - 25%) van een individu uit een commitment van een productteam en publiceert hij de systeemverantwoordelijkheid aan teams en collega's. Met een mandaat en tijd begin je regelmatig tastbare output vrij te geven, of het nu gaat om gestandaardiseerde ontwerpelementen of een gecodeerde kit.

Op dit punt kunnen voorstanders van gelijkgestemde systemen beginnen met de coördinatie van ontwerp en engineering. Iemand kan een achterstand beginnen, maar het kan rotten met vaag gedefinieerde tickets die maanden rusten. Halfbakken documentatie borrelt op ongepolijste webpagina's of (oh nee!) Confluence. Updates vinden plaats, maar weinigen weten wanneer, hoe of waarom.

Om een ​​systeem te laten gedijen, moet het hoogwaardige output publiceren en de adopters betrouwbaar bedienen.

“Als je er goed in bent, creëer je vraag binnen je organisatie die niet kan voldoen aan de huidige toewijzingen.” - Jared Spool, Beyond the UX Tipping Point

Met een gestage stroom van reguliere output nemen uw klanten (productteams) onderdelen over, beginnen individuen de controle los te laten van door het systeem opgeloste problemen, en wordt het management warm voor het idee om een ​​toegewijd team te vormen.

Fase 3: Systeemteam –als – productteam

Streef bij het opzetten van een formeel systeemteam naar een mix met erkende autoriteit van zowel ontwerp- als engineeringdisciplines.

Systeemteamsamenstelling op hoog niveau, per grootte

Teams die ik onlangs heb gevormd en geleid zijn samengesteld als een combinatie van:

  • MOET HEBBEN: Designleden kunnen subdisciplines omvatten - visueel, interactie, informatiearchitectuur om er maar een paar te noemen - maar het team moet uitblinken in het maken van een elegante beeldtaal.
  • MOET HEBBEN: Engineering brengt een front-end focus met HTML & CSS-kennis, ervaren vaardigheden om conventies vast te stellen en het bouwen van tools.
  • MOET HEBBEN: Productmanagement en leiderschapsvaardigheden om visie vast te stellen, richting te sturen, routekaarten samen te stellen, acceptatie te bewaken en achterstanden, scrums en kritieken te organiseren.
  • KAN HEBBEN: Specialistische problemen zoals contentstrategie, toegankelijkheid, prestaties, SEO en meer. Hoewel waardevol, houd er rekening mee dat systemen eerst en vooral met ontwerp en engineering trouwen.
  • GEBRUIKELIJK NIET: QA en onderzoek. QA-financiering is vaak niet voldoende en systeemteams kunnen sowieso methoden vaststellen om de kwaliteit te beoordelen. Onderzoek kan bestaan ​​als een broer of zus voor productteams.

Fase 4: Systeemteam van teams

Sommige grote ondernemingen (zoals, ik vermoed dat Google, IBM, GE, Cisco of Microsoft) groeien systeeminspanningen om een ​​paraplu van meerdere onderling verbonden teams te omvatten om systeemdoelen te bereiken.

Team van teams

Voor de meesten van ons die veel minder producten serveren dan zij, is deze schaal volledig onrealistisch en onnodig. Natuurlijk is het handig om de verhoudingen te zien die aan elke oefening worden toegeschreven. Deze schaal kan echter afschrikken als het sponsor is van een systeemteam als productteam. Stem uw teamgrootte af op realistische doelstellingen en belangrijke resultaten die u wilt behalen.

Voorbeelden van systeemteams

Hoewel ik sinds 2006 continu heb deelgenomen aan ontwerpteamteams, is de praktijk rond 2012 enorm toegenomen toen responsief gebeurde, HTML & CSS werd versterkt en eenhoorns begonnen (gedeeltelijk) systematisch in code te ontwerpen.

De volgende voorbeelden geven een progressie weer van systeemteammodellen waar ik sindsdien bij betrokken ben.

Voorbeeld 1: eCommerce reageert responsief

Wat goed werkte: dit toegewijde team ontwierp en documenteerde uitgebreide normen in een op maat gemaakte webgebaseerde ervaring. Het was het "grote Kahuna" -systeem: stijl, interactie, componenten, patronen, merk, redactioneel, SEO, toegankelijkheid, de werken! Omdat de onderneming ~ 2 jaar nodig had om "responsief te worden", was het systeem van cruciaal belang bij het convergeren van een ongelijk klanttraject.

Wat ik sindsdien anders heb gedaan: zucht, engineering. Ons systeemteam heeft een robuuste componentenbibliotheek gebouwd om responsieve ontwerpen te prototypen en de standaardsite te bouwen. Toch hebben engineeringleiders zich verzet tegen onze code en hebben ze nooit een bibliotheek voor hun community gebouwd. Het resultaat? Dubbele inspanningen, inefficiënties en inconsistenties, behalve voor ontwikkelaars die onze code in hun builds steken.

Ik heb gezworen nooit meer een codeloos systeem na te streven in omgevingen die het duidelijk nodig hebben maar technische leads blokkeren de achtervolging.

Voorbeeld 2: een ontwerptaal voor een exploderende organisatie

Wat goed werkte: met het org-ballonvaarten van ~ 30 tot 200+ ontwerpers in 12–18 maanden leidde het systeemteam de ontwikkeling van een gedeelde ontwerptaal die is gedocumenteerd op een site met aangepaste standaarden (dus de front-end ontwikkelaar). Gezien de enorme, gedistribueerde schaal van de ontwerporganisatie hebben we federatieve ontwerpers ingeschakeld om interactie, UX en basisprincipes van pictogrammen te stimuleren.

Hoewel de reikwijdte kleiner was - alleen visuele stijl, knoppen en vormen in zes maanden werk - werd het geprezen als een succes gezien de schaal en uitdagingen waarmee het werd geconfronteerd.

Wat ik sindsdien anders heb gedaan: Meer intern personeel maken en verbinden. Hoewel we effectief output produceerden, werd het leiden van zo'n grote gemeenschap gespannen door geografie, technologie en toch onstabiele operationele praktijken. De org had daarvoor meer intern systeempersoneel en stabiliteit nodig.

En nogmaals: code. We hadden een kit moeten vrijgeven en later om vergeving moeten vragen.

Voorbeeld 3: de eenvoudige websitebibliotheek

Wat goed werkte: gewapend met een goed gedefinieerde beeldtaal van een apart bureau, hebben we een eenvoudige componentenbibliotheek ontworpen, gebouwd en gedocumenteerd voor diverse, inhoudrijke webeigenschappen. Ons team heeft met succes een eerste release in drie maanden geïmplementeerd en vervolgens gedurende een beperkte periode gevolgd door onderhoud en groei.

Wat ik anders heb gedaan Sindsdien: ondanks openlijke waarschuwingen over de vereiste capaciteit om het in leven te houden, ging de bibliotheek in winterslaap toen het personeel uiteenviel. Ons opvolgings- en uitrolplan was niet sterk genoeg om het vertrek van mijn bureau te weerstaan. Sindsdien heb ik in projecten assertief plannen en opvolging gepland met interne leiders tijdens de formatieve periode van een systeem.

Voorbeeld 4: Digitaal productecosysteem

Wat goed werkte: ik combineerde met een interne ontwerper om de stijl en componenten te ontwerpen en documenteren op basis van het herontwerp van vlaggenschipproducten dat we een kwart eerder hadden gedaan. Nog beter, engineering investeerde drie halftijdse ontwikkelaars van vlaggenschipproducten die systeemuitgangen stapsgewijs in continu productwerk verweefden.

We hebben in drie maanden een bibliotheek v1.0 uitgebracht en gevolgd door driemaandelijkse cycli om de tooling te verfijnen en de catalogus van de bibliotheek uit te breiden. Terwijl ontwerp, engineering en product bijeenkwamen voor de planning van 2017, verwelkomde de VP Engineering het systeem:

“Het belangrijkste dat we vorig jaar hebben gedaan, was dit systeem bouwen. Het is de basis van al onze toekomstige werkzaamheden. "

Voorbeeld 5: de bibliotheek met deelnemers

Wat tot nu toe goed heeft gewerkt: Terwijl we begonnen met het optimaliseren en uitbreiden van een bestaande kernbibliotheek, ontstonden extra bibliotheken in andere branches. Teams waren in de war: welke te adopteren? In plaats van te concurreren, hebben we onze inspanningen gecoördineerd en geïntegreerd in een groter team.

Er was een kortetermijnbelemmering om opnieuw te team en refactor-code om iedereen flexibel te bedienen. Scrums en planning werden ook langer. Onze weg vooruit zal echter samen in de nabije toekomst produceren, en de CEO en een andere VP lijken ervan overtuigd:

"Ik voelde en had toegegeven dat we twee bibliotheken zouden hebben, maar toen kwam er een derde. Ik ben heel blij om te zien dat we een manier hebben gevonden om er maar één te maken. "

Een ander onderdeel van het opschalen van de praktijk was het betrekken van de federatieve ontwerpgemeenschap om zorgen te maken: UX, pictogrammen, merk, grafieken, inhoud en toegankelijkheid. Hoewel geen van deze 'segmenteigenaren' specifieke capaciteit heeft, zijn ze nu allemaal aanspreekpunt voor gematigde discussies, het stimuleren van prioriteiten en het betrekken van collega's om output te leveren.

Geleerde lessen Systeemteams beheren

# 1. Gecodeerd ontwerp is waarheid. Blend ontwerp en engineering.

Ik heb sinds 2006 aan genoeg teams deelgenomen om sjabloonbibliotheken voor ontwerpactiva te maken en ontwerp te documenteren. Ik ben ervan overtuigd dat de waarde van een ontwerpsysteem tienvoudig toeneemt wanneer een brug wordt gevormd tussen sterk ontwerp en engineering.

Ja, er zijn voorwaarden van wereldwijde schaal (bijvoorbeeld: Google-materiaal) waarbij een ontwerpspecificatie zelfs zonder code essentieel is. In mijn praktijk realiseert het verenigen van een beeldtaal, componenten en andere frameworks in ingebouwde code echter de beloofde efficiëntie, duidelijkheid en onderhoudbaarheid van het systeem.

Afhaalmaaltijden: ongeacht de klant, mijn belangrijkste eerste onderzoek is wie van elk gebied kan samenwerken om dit gedeelde doel te bereiken.

# 2. Half-time capaciteit is een sterkte, geen zwakte

Zie je het patroon in elk team hierboven? Alle medewerkers zetten zich in voor de rust en blijven anders betrokken bij een product. In een middelgroot team creëren dergelijke verbintenissen relaties in 3-5 productteams. Dit geeft inzicht in wat belangrijke producten nodig hebben en minimaliseert vertekening naar een enkel product.

Ontwerpers en ingenieurs, handig als systeemteams en toch toegewezen aan uiteenlopende producten

Dit gaat gepaard met risico's:

  • Productleiders geven een half-time systeemcapaciteit toe maar wijzen nog steeds 32 of meer uren capaciteit per week toe voor hun product.
  • Teamleden die zich uitstrekken over meerdere conflicterende rituelen (scrum, planning, kritiek) die het aandeel van vergaderingen verstoren versus 'dingen gedaan krijgen'.

Afhaalmaaltijden: je kunt gaan met half-timers, verwacht gewoon af te stemmen. Over en weer beheren. Onderscheidende verbintenissen onderscheiden van verplichtingen die breken. Het wordt ingewikkeld, maar niet genoeg om de inspanning ernstig te schaden.

# 3. Balanceer continuïteit met rotatie

Voor systeemteams met meer dan 2 medewerkers uit elke discipline, identificeren we soms permanente leden die zijn bedoeld voor een verbintenis van een jaar of meer. Deze leden kunnen escaleren naar fulltime en niet alleen beslissingen en conventies volhouden, maar ook tribale rituelen. Continuïteit is belangrijk. Aan de andere kant zullen we ander systeempersoneel rouleren als adoptie plaatsvindt voor producten.

Na een eerste release gaan we bijvoorbeeld op zoek naar welke producten de "volgende golf" van gebruikers zijn. Binnen die producten zoeken we naar beschikbare en getalenteerde ontwerpers en ingenieurs die beschikbaar zijn voor een tour van drie of zes maanden met het systeemteam. Iedereen wint: het systeem is diepgaand en voorspelbaar toegepast en een product kan de kern uitbreiden en naar eigen voordeel ontwikkelen.

# 4. Anticipeer op periodieke contractie als een kans

Het is gebruikelijk dat sommige systeemmedewerkers na een significante systeemrelease teruggaan naar fulltime productwerk. Dat is oke.

Verander de verschuiving in taken rond het integreren van systeemproblemen, controleer hoe het voormalige systeemteamlid systeempotentieel in hun ruimte realiseert en gebruik deze productverbeteringen om het verhaal van systeemvoordelen en flexibiliteit op te bouwen.

# 5. Nieuwe leden aan boord als lakmoesproef van systeemkwaliteit

De integratie van een nieuw teamlid is een geweldige (en gemakkelijke) testcase van de helderheid van het ontwerp, de codekwaliteit en de naleving van systeembeloften.

Vorig jaar heeft een vierde ingenieur de sombere procesdocumentatie van het systeem op sommige gebieden, evenals een onvoldoende focus op specifieke toegankelijkheidstests, ingebracht en onmiddellijk blootgelegd. In de loop van de volgende maand hebben we allemaal ons best gedaan om die kwaliteiten te verbeteren. Ons nieuwe lid greep het moment om een ​​aantal van die uitdagingen op te lossen en vestigde een invloedrijke positie naast de 'lange timers' die al in het team zitten.

# 6. Systeempersoneel moet kiesdistricten overspannen

Bedient het systeem een ​​portfolio voor één maar niet alle bedrijfstakken? Dan is dat de grens van waar u het personeel vandaan haalt. Omspant het systeem marketing- en productorganisaties? Werk vervolgens hard om (minimaal) een regelmatige, zinvolle samenwerking tussen de twee tot stand te brengen of (idealiter) personeel van beide organisaties samen te voegen tot een praktijk.

Zonder de juiste weergave is het moeilijk om een ​​systeem te krijgen dat door mensen hier wordt gemaakt en door teams daar en overal wordt aangenomen.

27 april 2017: De diagrammen van het artikel zijn bijgewerkt om genderspecificiteit te verwijderen als reactie op de opmerking van een lezer.