Ontwerpsysteemlagen

Tijd om systemen volwassen te maken om werkniveaus te ondersteunen

Ons ontwerpsysteem, de enige bron van waarheid. Enkelvoud, centraal, perfect. De enige plaats waar u alle antwoorden vindt. Zijn systemen bestemd om slechts één set van de beste dingen te hebben? Ik ben niet overtuigd.

Waarom zou je ontwerpsystemen beperken tot dingen van de hoogste kwaliteit die voor iedereen relevant zijn? Is er ruimte tussen de kern van een ontwerpsysteem en adopters voor minder perfecte functies om te leven? Een plek om werkideeën te delen, experimenten uit te voeren en de kwaliteit in de loop van de tijd te stabiliseren?

Ik stel voor dat ontwerpsystemen een mogelijkheid bieden voor een taxonomie van flexibele niveaus onder een kern van de hoogste kwaliteit. Door lagen te gebruiken, kunnen systemen de mogelijkheden en kwaliteit van betekenisvolle functiesets stapsgewijs verbeteren en ideeën van een team of groep naar boven bevorderen via een architectuur die iedereen deelt.

Een systeem kan lagen ondersteunen

Ideeën borrelen op. Ze kunnen beginnen met een idee in de geest van één persoon. Dat idee is handig voor een medewerker in de buurt. Anderen realiseren zich geleidelijk dat ze de behoefte delen. Uiteindelijk kan een idee wel of niet voor iedereen relevant zijn. We kunnen systemen ontwerpen om dergelijke niveaus te weerspiegelen.

Architecturen beginnen - maar hoeven niet te stoppen - met twee niveaus van een systeem en het neemt producten aan. Een hiërarchie op twee niveaus is eenvoudig en gemakkelijk te begrijpen.

Toch zijn niet alle componenten en andere functies even waardevol, verhard tot hetzelfde kwaliteitsniveau of relevant voor zoveel mensen. Hoe hoger het niveau, hoe breder iets wordt gedeeld.

Afhaalmaaltijden: anticipeer dat naarmate een systeem groeit, het kan profiteren van extra niveaus om ontwerpelementen, code en documentatie te maken en te delen. Lagere niveaus kunnen spaties zijn voor functies die niet tot de kern van een systeem hoeven te behoren die voor iedereen zichtbaar is.

Bovenaan een 'kern' die voor iedereen relevant is

Zodra een systeem functies van verschillende kwaliteit en relevantie blootlegt, moet een kern worden gescheiden als de hoogste kwaliteit en voor iedereen het meest relevant.

Op dit punt is de kern van een ontwerpsysteem voorspelbaar: de kleur, typografie, iconografie en ruimte van een visuele stijl toegepast op componenten zoals koppen, knop, pictogram, selectievakje, invoer en anderen die iedereen duidelijk nodig heeft. Totdat je de kern goed hebt, kun je de verfijnde dingen niet met vertrouwen maken.

De kern wordt centraal beheerd en gedocumenteerd door een kerngroep of aangewezen ontwerpteamteam (s). Gemeenschappen van ontwerp en engineering hebben een grote invloed, maar ze hebben ook een team nodig dat erop wijst dat verantwoordelijk en verantwoordelijk is voor het aanhoudende succes van een kern.

Afhaalmaaltijden: Zodra aanvullende systeemlagen beginnen te ontstaan, wijst u een "kernlaag" aan die nuttig is voor alle gebruikers en wordt onderhouden door een identificeerbare kerngroep. Noem het wat je wilt - kern, basis, basis, wat dan ook - om deze meest essentiële functies bovenaan duidelijk aan te duiden.

Begin met Tiers voor WITHIN Business Units…

Functiesets vormen van nature binnen organisatiegrenzen, zoals de hieronder weergegeven groepen A, B, C en D.

Tier 2-subsystemen die verschillende bedrijfsonderdelen ondersteunen (A, B, C, D)

Mijn waarnemingen in ontwerpsystemen suggereren dat dit al gebeurt, maar op een ad hoc manier die niet wordt bestuurd door een systeemteam. Eén systeemteam bood een Core-set met Sketch-middelen en componentcode. In het wild maakten platformontwerpers in groepen A en B verschillende extensies voor een schetspakket, en een ingenieur had een "C-kit" van componentcode voor hun groep gemaakt. In dergelijke gevallen kan een systeemprogramma een model vormen en hulpmiddelen bieden voor dergelijke uitbreidingen van ontwerp en code.

... en ook machtigen lagen ACROSS-eenheden

Een systeem hoeft functiesets niet te beperken tot organisatorische grenzen. Met tiers kan een community ook over grenzen heen delen. Ik zal systeemteams eraan herinneren dat hun zichtbaarheid in producten niet alleen een sterkte, maar een verantwoordelijkheid is. Het vinden van kansen en het activeren van verbindingen is onderdeel van het werk, zelfs als het verder gaat dan wat er in hun systeemkern zit.

Overweeg de meerdere contactpunten van een ecosysteem met een rich-text-editor. Het is niet alleen een editorvenster met alinea's, koppen, lijsten en andere inhoud. Er zijn werkbalken voor opmaak. Dialogen voor uploaden. Volledig scherm schakelt om meeslepend te componeren. Editors zijn niet goedkoop. Terwijl een team in groep A het aanneemt, hoort groep B erover en krijgt een gedeelde investering vorm.

In hetzelfde ecosysteem kunnen andere gedeelde investeringen ontstaan, zoals experimenten met componenten voor navigatie, sociale en andere functies onder de kern.

Afhaalmaaltijden: wees een matchmaker die inspanningen tussen teams verbindt. Bied tools - repo- en componentsteiger, Sketch-sjablonen, doc-fill-in-the-blanks - om gesprekken te starten zodat hun eerste date uitgroeit tot een vruchtbare relatie.

Breid het gebruik van systeemtools voor gelaagd werk uit

Dus, hoe zou je lagen binnen een organisatie rollen? Een benadering zou zijn om een ​​eerste fase te besturen voor een paar sets binnen teams - redacteur, navigatie, sociaal. Dit zou u de mogelijkheid bieden om de toegangsrechten, onboarding, workflow en zelfs potentiële promotie te testen. Naarmate die piloten slagen, verdiept u de tooling in een tweede fase om meer autonoom en uitgebreid gebruik op een derde niveau binnen teams te ondersteunen.

Eén systeem dat ongeveer 25 teams ondersteunt, heeft doelbewust hun core-ui-architectuur ingebouwd in een broer / zus-verkooprei-repository afhankelijk van de componenten en stijl van core-ui. De verkoop-ui catalogus breidde zich snel uit ten opzichte van de trager evoluerende kern. Controles waren los. Leveringstermijnen werden gehaald. Sommigen zagen een puinhoop.

Voorbeeld: verkooporganisatie die een uitgebreide componentenbibliotheek bouwt

Toch zag het systeemteam kansen. Er waren duidelijke kandidaten om te promoten van verkoop-ui tot kern-ui. Tools voor het verbeteren van de kwaliteit (linting, visuele regressietests) vonden plaats in een eerder ragtag-groep. Bovenal integreerden verkoopteams kern-ui-functies in alles wat ze deden zonder na te denken. Zonder het te beseffen, waren ze nu een tweede niveau van dat ontwerpsysteem.

Afhaalmaaltijden: bedrijfseenheden en productlijnen zijn gemotiveerd om snel te werken, doelen te bereiken en opnieuw te gebruiken met hun aangrenzende squadrons. Systeemtools kunnen snelle, systematische ontwerp- en ontwikkelingspraktijken ondersteunen om groepen vooruit te helpen, zonder noodzakelijkerwijs de kern van het systeem te compliceren.

Modelrechten voor zichtbaarheid en controle

Wanneer een ontwerpteamteam een ​​kern ondersteunt, is het duidelijk dat zij verantwoordelijk zijn voor een groot deel van het ontwerp, de codering en documentatie van die kern. Als gevolg hiervan zullen ze voorgestelde bijdragen bekijken die die kern zeer zorgvuldig veranderen. Voor elke laag onder de kern hebben echter meer mensen meer open machtigingen nodig om middelen bij te dragen, uit te breiden en te onderhouden.

Teams kunnen applicaties zoals Abstract en Lingo App gebruiken om Sketch-bibliotheekitems voor hun systeem te distribueren. De kit (en) biedt een kernknop, selectievakje en vele andere componenten voor de hele gemeenschap, hoewel alleen kernteamleden (en belangrijke partners) bewerkingsrechten hebben.

Extra kits (zoals Producten, Account, Gifting en Checkout) kunnen op basis van ervaring een tweede reeks subgroepen organiseren. Deze subgroepen kunnen componenten zoals kaart en formulieren uitbreiden en ook activa (zoals afbeeldingen) en componenten (zoals Accountkop) bevatten die alleen relevant zijn voor hun team. Hoewel elke kit zichtbaar is voor de hele ontwerpgemeenschap, zijn de bewerkingsrechten van elke kit beperkt tot ontwerpers in die business unit plus het kernteam.

Afhaalmaaltijden: modelrechten voor maximale zichtbaarheid en minimale risico's. Hoe meer ontwerpers en ontwikkelaars kunnen zien dat er werk in andere groepen wordt gedaan, ze kunnen verbindingen maken, redundantie verminderen en deelnemen aan een experiment.

Curator de naamruimte centraal

Zodra een systeem bijdragen van verschillende groepen aanmoedigt, kan het het wilde wilde westen worden. Je moet de prijs in de gaten houden: een bibliotheek die een architectuur deelt zonder conflicten en botsingen. Niemand heeft een selectievakje-knop, actieknop en vakje met vinkje-in-het-knop nodig.

Dat vereist dat de naamruimte wordt beheerd om ervoor te zorgen dat nieuwe functies:

  • overlappen niet met andere functiemogelijkheden
  • botst niet met andere functienamen wanneer deze wordt gebruikt of gepromoot
  • minimaliseert naamsveranderingen zodat early adopters later niet hoeven te refactoren

Naamgeving is moeilijk. Dat begrijpen we allemaal. Maar later hernoemen kan het werk echt afmaken. Een systeem brengt een gedeelde ruimte tot stand die een vocabulaire tussen ontwikkelaars en ontwerpers vereist. Omdat een systeem functies over sets verspreidt, moet u daarom normaliseren hoe elk ding wordt genoemd en hoe het is gegroepeerd.

Afhaalmaaltijden: Curator zorgvuldig de namen van sets en functies, met name componenten. Wees duidelijk over wie de naamgeving beheert en voorgestelde namen beoordeelt zodra deze verschijnen. Dit kan zelfs een specifieke persoon of kleine groep zijn die echt getalenteerd en / of gepassioneerd is.

Stel lagen in documentatie bloot

Net als teams verschillende functiesets gaan maken, zullen anderen die functiesets willen gebruiken waarin ze geïnteresseerd zijn. Ze willen ook geen functiesets zien waarin ze niet geïnteresseerd zijn. Dit is van invloed op hoe functies worden gepresenteerd in documentatie en tools, zoals:

  • Classificeren van documentatie sitenavigatie, catalogusstatus en detailpagina's
  • Verpakkingscode en ontwerpelementen, zoals Sketch-symbolen
  • Prioritering van kern- en breed relevante sets meer dan die welke minder relevant zijn
  • Aanpassen zodat gebruikers kunnen configureren wat ze doen en niet zien
  • Documentatie centraal integreren in één site-eigendom of - snik naar adem! - gezien meerdere doc-sites?

Afhaalmaaltijden: sets toevoegen voorbij een kern is een uitdaging voor informatiearchitectuur voor tools en documentatie. Het dwingt vragen van classificatie, organisatie en prioriteit. Stel je een doelstatus voor en bouw er vervolgens stapsgewijs hulpmiddelen voor op, één functie tegelijk.

Hoe hoger het niveau, hoe hoger de kwaliteit

De kenmerken van een kern moeten van de hoogste kwaliteit zijn. Naarmate lagen naar voren komen, zal de kwaliteit onder de kern variëren. De Atlaskit-codepakketten van Atlassian wijzen op een tweede niveau van functiegroepen voor zowel bedrijfseenheden (bitbucket) als functies voor groepen (editor, startpagina, zoeken en navigatie), waarbij de kwaliteit van sommige lager kan zijn dan die van Core. De locatiedocumentatie van IBM Carbon schuilt in twee niveaus: een impliciete kern en een "experimentele" tweede laag:

“Experimentele componenten, ontwerpen en andere bronnen worden gepresenteerd voor testen en feedback. Ze zijn niet bedoeld voor productiegebruik. ”- IBM Carbon

Functiekwaliteit zou moeten verbeteren naarmate een functie hoger stijgt. Daarom moet een systeem voor makers duidelijk maken hoe goed elke functie moet worden gemaakt en voor gebruikers hoe goed elke functie is gemaakt. Het is aan een systeem met twee of meer niveaus om de kwaliteit op elk niveau te differentiëren en duidelijk te communiceren.

Kenmerk kwaliteitscriteria per niveau

Eén model verscherpt kwaliteitscontrole op basis van hoe wijdverbreid de functie zal worden gebruikt binnen bedrijfseenheden:

  • Functies in de categorie "Binnen groep" moeten browsercontroles en code-linting doorstaan, toegankelijkheidsproblemen aanpakken die relevant zijn voor degenen die deze maken en moeten worden vormgegeven op een manier die consistent is met de kernontwerptaal.
  • De functies van het niveau "Across Groups" moeten ook responsief zijn, gebruikmaken van BEM CSS-methodologie, semantische versie, logboekwijzigingen, inkapselingstijl afhankelijk van ontwerptokens, installatie-eenheid en visuele regressietests, en moeten worden goedgekeurd door de volledige ontwerp- en / of ontwikkelingsgemeenschappen.
  • De toplaag van de kernlaag moet ook een uitgebreide toegankelijkheidscontrole doorstaan, formaatbepaling inschakelen (S, M en L), werken op verschillende achtergronden (wit, licht, donker, zwart en merk) en aangepaste thema's, analyses en internationaliseringsfuncties inschakelen, zoals rechts naar links.

Vandaag een systeem draaien en nauwelijks voldoen aan de kwaliteit van de "Within Group"? Ik beoordeel je niet. Uw adoptanten kunnen dat echter zijn. Overweeg dus welke kwaliteit nodig is en breng een pad in kaart om er te komen.

Afhaalmaaltijden: identificeer duidelijke en haalbare criteria om functies te plaatsen. Voor degenen die snel en los lopen, stel minimumverwachtingen in om ze niet te vertragen. Naarmate het gebruik van een functie toeneemt (en het vertrouwen toeneemt), moet u duidelijk maken welke stappen er zijn om het voor promotie te verharden. Zorg ervoor dat anderen, die in en niet geïnteresseerd zijn in niet-kernfuncties, weten waar ze aan beginnen.

Gebruik lagen in gesprekken over bijdragen

Niveaus bieden de mogelijkheid om te praten over hoe functies bevorderen van smalle experimenten tot wijdverbreid gebruik met behulp van duidelijke criteria. Die functie moet ergens naartoe gaan, en rijen bieden vangrails in gesprekken zoals:

  • Laten we editorfuncties organiseren als een set ... (de "Wat?")
  • ... gebouwd op niveau 2 ... (de "Waar?" En "Hoe goed?")
  • ... dat we 3 sprints nodig hebben (de "Hoeveel kost het?") ...
  • ... voor productgroepen A en C maar niet B, D of E (de "Wie?").

Waarom? Omdat systemen een architectuur bieden om consistenter te ontwerpen, efficiënter te bouwen en een hogere kwaliteit te bereiken. Er is geen reden om die waarde om dingen goed te maken te beperken tot alleen het systeemteam.

Afhaalmaaltijden: u kunt "bijdrage" -kansen als promotie in kaart brengen via niveaus van een systeem. Die bijdragers hebben een systeemarchitectuur nodig om mee te bouwen en systeemteamleden om kansen te identificeren en het proces te herderen.

Tiers zullen slagen wanneer een gemeenschap een taal en architectuur gebruikt om te delen. Tooling zal uitbreiden om meer deelnemers te verwelkomen, en activiteit zal duidelijk zijn binnen en tussen bedrijfsonderdelen. We zullen kijken.