Ontwerpsystemen definiëren

De kern leren kennen van wat uw systeem echt is

Het definiëren van ontwerpsystemen lijkt een enorme uitdaging. Het is niet alsof onze gemeenschap niet vele, vele, vele, vele, vele, vele, vele, vele, vele, vele, vele, vele, vele, vele pogingen heeft gedaan. Onlangs schreef Sarah Federman over het destilleren ervan tot de essentie en waarschuwt ons om te voorkomen dat we vast komen te zitten bij het definiëren van dingen en dogmatisch zijn over wat het is en wat niet.

Ontwerpsystemen is een groeiend veld gevormd door levendige, samenwerkende stemmen. Het is belangrijk om te bepalen wat een systeem is en hoe het past, anders lopen we het risico de waarde ervan te ondermijnen vanwege onsamenhangend begrip. We moeten geen uitdagingen aangaan en er is een gemeenschappelijke basis om te winnen. Mijn levensonderhoud hangt ervan af, het verkopen van ~ 15-25 ontwerpopdrachten per jaar aan klanten die de resultaten en outputs begrijpen (hint: niet alleen UI-kits, code en doc) en waarom ze ertoe doen.

"Wat is een ontwerpsysteem?"

Als ik ~ 30 seconden in een lift of over geanimeerde dia's heb, leid ik met:

Bijna altijd biedt een ontwerpsysteem een ​​bibliotheek met visuele stijlen en componenten die zijn gedocumenteerd en vrijgegeven als herbruikbare code voor ontwikkelaars en / of tool (s) voor ontwerpers. Een systeem kan ook richtlijnen bieden voor toegankelijkheid, pagina-indeling en redactioneel en minder vaak branding, data namelijk, UX-patronen en andere hulpmiddelen.
Een ontwerpsysteem wordt aangenomen en ondersteund voor andere teams die ervaringen maken. Deze teams gebruiken het om functies efficiënter te ontwikkelen en te verzenden om een ​​meer samenhangende klantreis te vormen.
Een ontwerpsysteem wordt gemaakt door een individu, team en / of community. Hoewel sommige minder formeel ontstaan, zetten organisaties nu kleine tot grote groepen in om systeemversies en -processen in de loop van de tijd te ontwikkelen en vrij te geven.

Als slechts 10 seconden, zal ik zeggen:

Een ontwerpsysteem biedt een bibliotheek met visuele stijl, componenten en andere problemen die zijn gedocumenteerd en vrijgegeven door een individu, team of community als code- en ontwerptools, zodat het adopteren van producten efficiënter en samenhangend kan zijn.

Als alleen een tweet, nou dan is er dit:

Formeel is een systeem een ​​reeks onderling verbonden delen die een verenigd geheel vormen. In het geval van ontwerpsystemen verwijst deze definitie eigenlijk naar niet één maar drie onderling verbonden systemen die u moet oplossen om succesvol te zijn:

  1. een set herbruikbare, onderling verbonden onderdelen,
  2. een reeks samenhangende, onderling verbonden producten, en
  3. een gemeenschap van samenwerkende, onderling verbonden mensen.

# 1. Een set herbruikbare, onderling verbonden onderdelen

Voor zijn primaire klanten is het systeem een ​​reeks tastbare resultaten die ze dagelijks tegenkomen. Ik begin duidelijk met:

Bijna altijd biedt een ontwerpsysteem een ​​bibliotheek met visuele stijlen en componenten die zijn gedocumenteerd en vrijgegeven als herbruikbare code voor ontwikkelaars en / of tool (s) voor ontwerpers.

Tegenwoordig verbindt een systeem van onderdelen een gecodificeerde visuele stijl (bijv. Kleur, ruimte, typografie) met samengestelde UI-componenten (knoppen, formulieren, koppen, zoveel meer) die worden gebruikt om interfaces te ontwerpen en bouwen.

Dit uitgangspunt bevat een hoop intenties en onthult overtuigingen: een systeem dient ontwikkelaars en ontwerpers, in die volgorde. Een systeem moet goed gedocumenteerd zijn. Een systeem moet stijl- en UI-componenten bieden. Maar elk systeem is anders, dus ik zal het bereik van een systeem uitbreiden met:

Een systeem kan ook richtlijnen bieden voor toegankelijkheid, pagina-indeling en redactioneel en minder vaak branding, data namelijk, UX-patronen en andere hulpmiddelen.

Deze variabiliteit bevordert nuttige gesprekken die grenzen trekken rond wat een organisatie wil en nodig heeft. Sommige zorgen (altijd stijl en componenten) worden veel vaker gerealiseerd dan andere (redactionele richtlijnen en datavisualisatie).

# 2. Een reeks samenhangende, onderling verbonden producten

Woorden als "aanbieding" en "vrijgegeven" zijn opzettelijk en vormen het ontwerpsysteem als een product dat voldoet aan de behoeften van klanten (voornamelijk ontwikkelaars en ontwerpers die zelf producten maken) via tastbare resultaten die zij gebruiken.

Het aanroepen van productconcepten leidt tot een cascade van concepten die nuttig zijn voor diegenen die bekend zijn met productbeheer, ook van toepassing op een systeem: routekaart, achterstand, releases, programma-incrementen, sprints, afhankelijkheden. Als u zich echter alleen op de ontwikkeling van onderdelen concentreert, bestaat het risico dat systemen niet werken. Vooral de klanten van het systeem!

Een ontwerpsysteem wordt aangenomen en ondersteund voor andere teams die ervaringen maken. Deze teams gebruiken het om functies efficiënter te ontwikkelen en te verzenden om een ​​meer samenhangende klantreis te vormen.

Ontwerpsystemen investeren in marketing voor productteams om de set met onderdelen te consumeren om een ​​uniforme en samenhangende holistische ervaring te vormen. Het bevorderen van adoptie vereist duidelijke berichten om anderen te verkopen om een ​​systeem te adopteren en zichzelf (individueel en collectief) te verbeteren door de voordelen ervan in de loop van de tijd als afhankelijkheid te realiseren.

Productbeheer roept ook op hoe ontwerpsystemen passen in productactiviteiten, zoals de levering van DevOps ("Hoe geven we het vrij? Hoe is het geautomatiseerd?"), Integratie ("Hoe versie? Wat is een grote verandering? Hoe, hoe vaak, en wanneer upgraden we? ") en infrastructuur (" Waar is onze repo? Waar wordt ons document gehost? Is het openbaar? ").

Gemakkelijk te missen in de bovenstaande definitie wordt ondersteund voor, framing van de ondersteuning en service van de klant. Effectieve documentatie is essentieel. Verder moeten er paden zijn naar en tijd om hulp te bieden, te reageren op verzoeken, patches te repareren en te raadplegen, allemaal in een open en responsieve omgeving.

Om een ​​ontwerpsysteem (en de moeite die nodig is om het goed te laten werken) als alleen ontwikkelde stijl, componenten en middelen te beschouwen - met uitzondering van de marketing, service, integratie en activiteiten waarvan succes afhankelijk is - is te beperkt.

# 3. Een gemeenschap van onderling verbonden medewerkers

Om belanghebbenden te helpen de impact van een systeem te begrijpen, leid ik ook gesprekken door de mensen en activiteiten die nodig zijn om een ​​systeem te bedienen.

Een ontwerpsysteem wordt gemaakt door een individu, team en / of community. Hoewel sommige minder formeel ontstaan, zetten organisaties nu kleine tot grote groepen in om systeemversies en -processen in de loop van de tijd te ontwikkelen en vrij te geven.

Kenmerkend voor een systeemteam als een productteam is de keuze in termen die bekend zijn bij product- en marketingprofessionals: is dit belangrijk genoeg om er een team achter te zetten? Dat team kan rituelen aannemen, werk demonstreren en een stappenplan ontwikkelen om deel uit te maken van de manier waarop bedrijven producten maken.

In gevallen die ik heb opgemerkt, is dit team verantwoordelijk voor de workflows, verbindingen en communitybetrokkenheid binnen een onderneming om te beslissen hoe een systeem wordt toegepast en ontwikkeld. In het verleden aangeduid als 'governance', zal ik die term vermijden om een ​​toon van samenwerking boven controle te verkiezen.

Van buitenaf is het mogelijk dat een ontwerper, ingenieur of iemand anders in een gemeenschap het uitvoeringsniveau achter dergelijke activiteiten niet voelt. Dat betekent niet dat ze maanden of jaren niet opzettelijk zijn ontwikkeld, beheerd, ondersteund en gebruikt. Deze uitvoering van gemeenschapsinteracties is een moeizaam maar ontastbaar product dat een systeem succesvol maakt.

Een systeemdefinitie op hoog niveau opstellen

Hoewel dit niet mijn bedoeling was, bracht dit schrijven me terug in het kader van een workshop Onderdelen, Producten en Mensen die ik al jaren heb. Deze activiteit leidt deelnemers door een voorgeschreven protocol om te detailleren op welke onderdelen hun systeem nodig is, op welke producten het van toepassing is en wie het werk doet.

Onderdelen, producten en personen Werkbladactiviteit

Het is echter redelijk om aan deze nauwgezette activiteit vooraf te gaan of deze te vervangen door een slankere, invulbare sjabloon om begrip te vergroten:

Ons ontwerpsysteem biedt
_______ [toepassingsgebied] _______
vrijgegeven als
_______ [kituitgangen] _____
en gedocumenteerd om
_______ [kit doc site] _____
gemaakt door
_______[mensen]_________
om te dienen
_______ [producten] _______
producten en ervaringen.

Na jaren van bijdragen aan ontwerpsystemen, zou deze verklaring vergelijkbare maar altijd unieke antwoorden opleveren. Een systeem waar ik nu aan werk zou deze lege plekken opvullen als:

Ons ontwerpsysteem biedt
visuele stijl, toegankelijke UI-componenten, grafieken, redactionele richtlijnen, UX-patronen en branding
vrijgegeven als een
HTML & CSS-framework via npm, Sketch en andere PDF & AI-sjablonen
en gedocumenteerd om
designsystem.companyname.com
gemaakt door
een systeemteam van 1 ontwerpdirecteur, 1 productmanager, 2 ontwerpers, 3 ingenieurs en een community van ~ 15 communitybijdragers
om te dienen
~ 50 web-apps, een paar native app en beperkte branding
producten en ervaringen.

Een systeem dat ik nu begin, vertoont een andere samenstelling die een andere benadering vereist van hoe het wordt gemaakt en verbruikt:

Ons ontwerpsysteem biedt
visuele stijl, UI-componenten en toegankelijkheidsprocedures
vrijgegeven als een
Reageer op componentenbibliotheek en schetsactiva via Lingo
en gedocumenteerd om
designsystems.companyname.com
gemaakt door
een systeemteam van 1 systeemleider, 1 productmanager, 1 ontwerper en 2 front-end ontwikkelaars die samenwerken met een op React gebaseerd engineeringteam
om te dienen
~ 10 webgebaseerde en 2 native app
producten en ervaringen.

Wat onze gemeenschap flummoxt is de variabiliteit van de systeemsamenstelling. De consistente doelstelling - producten efficiënter produceren die een samenhangende ervaring opleveren - wordt op vele manieren bereikt door verschillende soorten groepen met verschillende aandachtsgebieden te betrekken.

Er is geen de facto formule, geen winnende methode (maar we worden beter). In plaats daarvan vereist het succes van het systeem dat u het aanpast aan de voorwaarden en beperkingen van de onderneming die het bedient.

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!