Design af et systemteam

Modeller og lektioner lært at skalere et team til en virksomhed

De fleste organisationer kommer til at forstå systemer, og hvorfor de er vigtige. Hvor meget koster det dog? Hvilket hold har vi brug for?

Et systemteam serverer produkt (eller lignende) hold

Peter Merholz og Kristen Skinners fremragende bog Org Design for Design Orgs beskriver modeller og roller i komponering af designteam og -organisationer. I kapitlet Roller og teamkomposition beskriver de et supplerende forskerteam, der tjener på tværs af mange andre teams:

"UX-forskere har nu kritisk masse til at være deres eget team… [med] Et forskningschef ... der understøtter den faglige vækst af forskerne og opretholder en global forståelse af forskningsindsigt i alle virksomhedens produkter og tjenester."

Da jeg læste dette, tænkte jeg for mig selv “Yup, som designsystemteam”, der løser de udbredte, enklere designproblemer - et visuelt sprog, brugbare interfacekomponenter osv.

Med denne model i tankerne blev jeg overrasket over at høre Peter reflektere over (Spotifys) systemteam i november sidste år på UI21 som en, der skulle “hacke en patch, en organisatorisk patch til [den] model [de]”, som han har beskrevet. Måske misforstår jeg. Men jeg har været på ~ 15-20 systemteam gennem årene, der tjener mange teams på lignende måde (men ikke det samme som) sådan forskningspraksis.

Efter min erfaring er det optimale systemteam multidisciplinært og uafhængigt til at tjene mange teams, der fremstiller digitale ting. Systemteamet opfører sig som et produkt, der forbruges af produkter (og andre teams).

Hvem er med på det hold? Er de på heltid eller deltid? Hvilke discipliner skal repræsenteres? Hvilket team (r) kilder vi dem fra?

Med disse spørgsmål i tankerne illustrerer denne artikel de almindelige vækststadier for et systemteam, deler eksempler på hold, som jeg har ledet de sidste fire år, og dækker mønstre og mulige faldgruber, du måtte stå overfor, når du danner og driver et systemteam.

Faser af systemteamvækst

De fleste enkeltpersoner, jeg snakker med på klienter, konferencer og vores samfunds Design System Slack udvikler sig på tværs af et af fire vækststadier: ekstra timere, tildelte enkeltpersoner, dedikeret team og team-of-teams.

Trin 1: Reservedele

Personer, der passer til systemet, arbejder i tidens kanter beskriver ofte, hvordan deres lidenskabelige burst ikke rigtig har taget fart:

"Jeg er på egen hånd. Jeg har oprettet et {Sketch sticker ark eller mini-Bootstrap code kit} i min ekstra tid, men ingen andre bruger det. Hvordan tager jeg det næste skridt? ”

Systemer, der er bygget fredag ​​eftermiddag eller søndag aften, holder ikke. En starter-skitskabelon eller en startkode er bedre end intet. Spartansk indsats er imidlertid ikke en virksomheds praksis ved at skabe.

Takeaway: Bliv ikke modløs! Mange systemrejser starter sådan. Bevis, at dine værktøjer fører til resultater - konsistens, effektivitet, genbrug - i pilotprojekter. Det er et springbræt for at uddanne, hvordan en systemindsats kommer andre til gode.

Trin 2: Tildelt person (er)

Da systemværdien genkendes, skærer en manager en persons forudsigelige, men alligevel begrænsede allokering (10%? 25%) fra et produktteamforpligtelse og offentliggør systemansvar til teams og kolleger. Bemyndiget med et mandat og tid, begynder du regelmæssigt at frigøre materielle output, hvad enten det er standardiserede designaktiver eller et kodet kit.

På dette tidspunkt kan ligesindede systemadvokater begynde at koordinere på tværs af design & engineering. En person starter muligvis en efterslæb, men det kan rådne med vagt definerede billetter, der hviler i flere måneder. Halvbagt dokumentation bobler på upolerede websider eller (åh nej!) Sammenflydelse. Opdateringer sker, men få ved, hvornår, hvordan eller hvorfor.

For at et system skal trives, skal det offentliggøre output af høj kvalitet og betjene adoptører pålideligt.

”Hvis du er god til det, skaber du efterspørgsel i din organisation, der ikke kan opfylde de nuværende tildelinger.” - Jared Spool, ud over UX-tippunktet

Med en jævn strøm af regelmæssige output, dine kunder (produktteam) adopterer dele, enkeltpersoner begynder at give afkald på kontrol til systemløste problemer, og ledelse varmer til ideen om at danne et dedikeret team.

Trin 3: Systemteam-som-produkt-team

Når du opretter et formelt systemteam, stræbe efter en blanding med anerkendt autoritet fra både design og ingeniørdiscipliner.

Systemteamsammensætning på højt niveau, efter størrelse

Hold, jeg for nylig har dannet og ledet, er sammensat som en blanding af:

  • SKAL HAVE: Designmedlemmer kan spænde over undergrænser - visuel, interaktion, informationsarkitektur for at nævne nogle få - men teamet skal udmærke sig i at skabe et elegant visuelt sprog.
  • SKAL have: Engineering bringer et front-end fokus med HTML & CSS viden, erfarne færdigheder til at etablere konventioner og værktøjsopbygning.
  • BØR HAVE: Produktstyrings- og ledelsesevner for at etablere vision, drive retning, sammenstille køreplaner, overvåge vedtagelse og organisere efterslæb, scrums og kritikker.
  • KAN HADE: Specielle bekymringer som indholdsstrategi, tilgængelighed, ydeevne, SEO og mere. Selvom det er værdifuldt, skal du huske, at systemer først og fremmest gifter sig med design og teknik.
  • USUELT HAR IKKE: QA og forskning. QA-finansiering er ofte ikke tilstrækkelig, og systemteam kan alligevel etablere praksis for at vurdere kvalitet. Forskning kan eksistere som en søskentjeneste til produkthold.

Fase 4: System Team of Teams

Nogle massive virksomheder (som jeg formoder, Google, IBM, GE, Cisco eller Microsoft) udvikler systembestræbelser på at spænde over en paraply af flere indbyrdes forbundne teams for at nå systemmål.

Hold af hold

For de fleste af os, der serverer langt færre produkter end de gør, er denne skala helt urealistisk og unødvendig. Selvfølgelig er det nyttigt at se proportioner, der tilskrives hver praksis. Imidlertid kan denne skala skræmme væk ville være sponsorer af et Systems Team-as-Product Team. Tilpas din teamstørrelse med realistiske mål og nøgleresultater, du vil opnå.

Eksempler på systemteam

Selvom jeg kontinuerligt har deltaget i designsystemteams siden 2006, forandrede praksis sig betydeligt omkring 2012, da responsiv skete, HTML & CSS blev styrket, og enhjørninger startede (delvist) systematisk i kode.

Følgende eksempler udtrykker en progression af systemteammodeller, jeg har været involveret i siden da.

Eksempel 1: eCommerce Going Responsive

Hvad fungerede godt: Dette dedikerede team designede og dokumenterede rigelige standarder i en tilpasset webbaseret oplevelse. Det var det "store kahuna" -system: stil, interaktion, komponenter, mønstre, brand, redaktion, SEO, tilgængelighed, værkerne! Da virksomheden tog ~ 2 år at “gå lydhør”, var systemet kritisk for at konvergere en forskellig kunderejse.

Hvad jeg har gjort anderledes siden: Suk, teknik. Vores systemteam opbyggede et robust komponentbibliotek til prototype responsive design og opbygning af standardwebstedet. Ikke desto mindre modtog ingeniørledere vores kode og har aldrig bygget et bibliotek til deres samfund. Resultatet? Duplikativ indsats, ineffektivitet og uoverensstemmelser undtagen for devs, der snigede vores kode til deres bygninger.

Jeg har lovet at aldrig forfølge et kodeløst system igen i miljøer, der åbenbart har brug for det, men ingeniørledninger blokerer for forfølgelsen.

Eksempel 2: Et designsprog til en eksploderende organisation

Hvad fungerede godt: Med org-ballooning fra ~ 30 til 200+ designere på 12-18 måneder førte systemteamet udviklingen af ​​et delt designsprog, der er dokumenteret på et tilpasset standardwebsted (således front-end-udvikleren). I betragtning af den massive, distribuerede skala fra designorganet, beskæftigede vi forbundne designere til at drive grundlæggende interaktion, UX og ikon.

Mens omfanget var mindre - bare visuel stil, knapper og former i seks måneders arbejde - blev det hyldet som en succes i betragtning af omfanget og udfordringerne.

Hvad jeg har gjort anderledes siden: Mere internt personale fremstiller og forbinder. Mens vi effektivt producerede output, blev hyrde for et så stort samfund belastet af geografi, teknologi og alligevel ustabil driftspraksis. Organet havde brug for mere internt systempersonale og stabilitet til det.

Og igen: kode. Vi skulle have frigivet et sæt og bedt om tilgivelse senere.

Eksempel 3: Det enkle webstedsbibliotek

Hvad fungerede godt: Bevæbnet med et veldefineret visuelt sprog fra et separat bureau, designede, byggede og dokumenterede vi et enkelt komponentbibliotek til forskellige, indholdsrige webejendomme. Vores team implementerede en første udgivelse på tre måneder med succes og fulgte op med vedligeholdelse og vækst i en begrænset periode.

Hvad jeg har gjort anderledes siden: På trods af åbenlyse advarsler om kapacitet, der kræves for at holde det i live, gik biblioteket i dvale, da personalet spredte sig. Vores successions- og rollout-plan var ikke stærk nok til at modstå mit agenturs afgang. I projekter siden har jeg assertivt planlagt tildelinger og succession med interne ledere gennem et systems formative periode.

Eksempel 4: Digital produktøkosystem

Hvad fungerede godt: Jeg parrede mig med en in-house designer for at designe og dokumentere stil og komponenter baseret på flagskibsprodukt redesign, som vi havde gjort et kvart år tidligere. Endnu bedre investerede engineering tre halvtidsudviklere fra flagskibsprodukter, der vævede systemudgange trinvist i løbende produktarbejde.

Vi udgav et bibliotek v1.0 på tre måneder og fulgte med kvartalsvise cyklusser for at forbedre værktøjet og udvide bibliotekets katalog. Da design, engineering og produkt indkaldt til planlægning i 2017, kom VP Engineering med hylde til systemet:

”Det vigtigste, vi gjorde sidste år, var at opbygge dette system. Det er grundlaget for alt vores fremtidige arbejde. ”

Eksempel 5: Biblioteket med konkurrenter

Hvad der har fungeret godt indtil videre: Mens vi begyndte at optimere og udvide et eksisterende kernebibliotek, dukkede yderligere biblioteker op i andre brancher. Holdene var forvirrede: hvad man skal vedtage? I stedet for at konkurrere koordinerede vi indsatsen og integreres i et større, enkelt hold.

Der var et kortvarigt træk for at re-team og refactor-kode for fleksibelt at tjene alle. Scrums og planlægning blev også længere. Imidlertid vil vores vej fremad producere sammen i en overskuelig fremtid, og administrerende direktør og en anden VP synes overbevist:

”Jeg sansede og havde indrømmet, at vi ville have to biblioteker, men så dukkede en tredje op. Det glæder mig, at vi har fundet en måde at lave en. ”

En anden komponent i skalering af praksis var at engagere det fødererede designfællesskab til egne bekymringer: UX, ikoner, brand, diagrammer, indhold og tilgængelighed. Selvom ingen af ​​disse "segmentejere" har dedikeret kapacitet, er alle nu kontaktpunkter for moderate diskussioner, driver prioriteter og engagerer peers til at levere output.

Erfaringer Administreret systemteam

# 1. Kodet design er sandhed. Blend Design og Engineering.

Jeg har deltaget i nok hold siden 2006 med at lave design-skabelonbiblioteker og dokumentere design. Jeg er overbevist om, at et design-systems værdi øges ti gange, når der dannes en bro mellem stærk design og teknisk praksis.

Ja, der er forhold i verdensomspændende skala (eksempel: Google-materiale), hvor en designspecifikation, selv uden kode, er afgørende. I min praksis er det imidlertid, at forene et visuelt sprog, komponenter og andre rammer til indbygget kode, at systemets lovede effektivitet, klarhed og vedligeholdelighed realiseres.

Takeaway: Uanset klienten, er min vigtigste indledende undersøgelse, hvem der fra hvert område kan samarbejde for at nå dette fælles mål.

# 2. Halvtidskapacitet er en styrke, ikke svaghed

Bemærk mønsteret i hvert hold ovenfor? Alle medarbejdere er forpligtede på halvtidskapacitet, ellers forbliver forpligtede over for et produkt. I et moderat størrelse hold skaber sådanne forpligtelser forhold til 3-5 vigtige produkthold. Dette giver synlighed til, hvad vigtige produkter har brug for, og minimerer bias mod ethvert enkelt produkt.

Designere og ingeniører, som fungerer som systemteam, men alligevel tildelt forskellige produkter

Dette kommer med risici:

  • Produktledere, der indrømmer en halvtidssystemkapacitet, men tildeler stadig og forventer 32 eller flere timers kapacitet pr. Uge for deres produkt.
  • Holdmedlemmer, der kæmper for flere modstridende ritualer (skrum, planlægning, kritik), der fordrejer andelen af ​​møder kontra "at få ting gjort."

Takeaway: Du kan gå med halvtimer, bare forvente at justere. At styre op og på tværs. At skelne bøjede forpligtelser fra dem, der bryder. Det bliver kompliceret, men ikke nok til at alvorligt skade anstrengelsen.

# 3. Balancekontinuitet med rotation

For systemhold med 2+ ansatte fra enhver disciplin identificerer vi undertiden faste medlemmer beregnet til et engagement på et år eller mere. Disse medlemmer eskalerer muligvis til fuld tid og vedvarer ikke kun beslutninger og konventioner, men også stammritualer. Kontinuitet er vigtig. På den anden side roterer vi andet systempersonale, da adoption sker på tværs af produkter.

Efter en første udgivelse ser vi for eksempel efter, hvilke produkter der er "næste bølge" af adoptører. Inden for disse produkter vil vi kigge efter tilgængelige og talentfulde designere og ingeniører, der er tilgængelige for en tre eller seks måneders halvtidstur med systemteamet. Alle vinder: systemet læres dybt og forudsigeligt, og et produkt kan udvide og udvikle kernen til det til egen fordel.

# 4. Forudse periodisk sammentrækning som en mulighed

Det er almindeligt for nogle systemmedarbejdere at skifte tilbage til fuldtids produktarbejde efter en betydelig systemfrigivelse. Det er ok.

Parlay skiftet til opgaver omkring integrering af systemproblemer, overvåg, hvordan det tidligere systemteammedlem realiserer systempotentiale i deres rum, og brug disse produktforbedringer til at opbygge fortællingen om systemfordele og fleksibilitet.

# 5. Ombord nye medlemmer som Litmus-test af systemkvalitet

Integration af et nyt teammedlem er en stor (og nem) testtilfælde af dit systems designklarhed, kodekvalitet og overholdelse af systemløfter.

Sidste år ombordbragte en fjerde ingeniør og afslørede straks systemets ondskabelige procesdokumentation på nogle områder samt et utilstrækkeligt fokus på specifikke tilgængelighedstest. I løbet af den næste måned skrumpede vi alle sammen for at forbedre disse kvaliteter. Da vi begyndte at se øjeblikket, sprang vores nye medlem for at løse nogle af disse udfordringer og etablerede en indflydelsesrig position sammen med de ”lange timere”, der allerede var på holdet.

# 6. Systempersonale skal span valgkredse

Tjener systemet en portefølje til en, men ikke alle forretningsområder? Så er det grænsen for, hvor du stammer fra personalet. Er systemet, der spænder over marketing- og produktorganisationer? Arbejd derefter hårdt for at etablere (som minimum) regelmæssigt, meningsfuldt samarbejde mellem de to eller (ideelt) blande personale fra begge organisationer sammen til en praksis.

Uden ordentlig repræsentation er det svært at få et system lavet af folk herover vedtaget af hold derovre og overalt.

27. april 2017: Artikelens diagrammer blev opdateret for at fjerne kønsspecificitet som svar på en læsers kommentar.