Het minimaal haalbare ontwerpsysteem

Groeiend UXPin Design System opgeslagen in UXPin Design System Library

De afgelopen weken had ik het genoegen om te praten over de benadering van UXPin om een ​​ontwerpsysteem te bouwen op meerdere meet-ups en webinars (je kunt er hier een bekijken). Ik had veel plezier in het delen van onze ervaringen, veel geleerd door alle mooie gesprekken na mijn gesprekken.

Een vraag die mij meerdere keren werd gesteld, maar die ook tijdens mijn gesprekken met ons team bij UXPin aan de orde kwam, was:

Hoe lang duurt het om een ​​ontwerpsysteem te bouwen?

Er zijn geen verkeerde vragen en ik was blij om elke keer te beantwoorden. Telkens wanneer ik deze vraag hoor, heb ik echter het gevoel dat het op een dieper probleem wijst: ontwerpsystemen worden nog steeds verkeerd begrepen en verward met een oude aanpak voor het bouwen van een stijlgids.

The Zombie Style Guide Legacy

Vroeger zou een ongelukkig lid van het design- of front-end ontwikkelteam worden vertrouwd met de taak om alle door het team goedgekeurde conventies te documenteren. Kleurenpaletten, tekststijlen, codestandaarden, soms zelfs UI-patronen.

Klinkt als een ontwerpsysteem? Je hebt gelijk. Het klinkt als een ontwerpsysteem, maar dat is het niet.

Deze oude benadering van het bouwen van een stijlgids was gericht op het produceren van een artefact. Het zou een afgeleide zijn van een documentatieproces. En elke keer ...

Voordat de stijlgids klaar was, veranderde deze al in een zombie.

Waarom? Simpelweg omdat de dynamische wereld van productontwikkeling, waar voortdurend veranderingen plaatsvinden, niet goed reageert op statische activa die weken nodig hebben om te bouwen. Terwijl een ontwerp / ontwikkeling-martelaar moeite had om elke conventie te documenteren, veranderden de conventies voortdurend. Het bouwen van een stijlgids was een Sisyphean-taak.

De onmogelijkheid om stijlgidsen te bouwen en te onderhouden, moedigde onze branche aan om het proces van consistentie van ervaring en code te herzien. Voer het ontwerpsysteem in.

Het ontwerpsysteem is een proces

In tegenstelling tot statische stijlgidsen zijn ontwerpsystemen dynamisch. Wat betekent het? De stijlgids is een artefact, het ontwerpsysteem is een proces.

Artefacten zijn statisch, processen zijn dynamisch.

In plaats van één persoon te delegeren om documentatie te maken, plannen we in de wereld van het ontwerpsysteem een ​​nieuwe workflow die alle informatie blijft toevoegen, aftrekken en wijzigen voor het maken van gebruikerservaringen.

In plaats van te denken in termen van de leverdatum, zijn ontwerpteamteams (meestal Design Operations-teams genoemd) van plan organisaties te helpen de interne consistentie van de interface geleidelijk te verbeteren en sneller geweldige projecten op de markt te brengen.

Entropie beheren met een stijlgids en een ontwerpsysteem

Verenigd tegen entropie

Net als bij elk gesloten systeem, blijft de entropie van een digitaal product toenemen, tenzij het opzettelijk wordt beheerd. Elke nieuwe functie, elk nieuw lid van het team, elke nieuwe managementlaag of stakeholder / klantinteractie draagt ​​bij aan de entropie van de ervaring.

Productervaring wordt geleidelijk standaard in chaos.

De groei van de entropie is een constante en kan alleen worden geregeld door constante actie. Daarom is het eindspel voor een Design Operations-team geen statisch artefact, het is een workflow waarin een verenigde organisatie van ontwerpers, ontwikkelaars, PM's en andere teamleden een ontwerpsysteem bouwen voor het maken van gebruikerservaringen.

Nooit eindigend minimum haalbaar product

Vragen over de leverdatum van een ontwerpsysteem lijkt een verborgen veronderstelling te hebben, dat er een moment is waarop het ontwerpsysteem "klaar" is. Het procesmatige karakter van een ontwerpsysteem heft deze veronderstelling op.

Ontwerpsysteem is een proces en is daarom altijd klaar en nooit klaar.

Een ontwerpsysteem blijft in een constante staat van een minimaal levensvatbaar product. Het tijdstip waarop een ontwerpsysteem plotseling waarde wint, bestaat niet. Zodra het ontwerpproces is vastgesteld en overeengekomen, wordt de minimumwaarde bereikt. Bij elke volgende release wordt het ontwerpsysteem krachtiger, maar bereikt het nooit de ultieme waarde. De entropie blijft groeien, de interface blijft veranderen en het ontwerpsysteem moet als een proces zonder einde evolueren.

Begin vaak met een klein schip

Een ontwerpsysteem ontstaat wanneer een organisatie erkent dat toenemende inconsistentie van de UI moet worden opgelost door middel van nieuwe workflows.

De entropie stopt met uitbreiden met de eerste conventie die is overeengekomen en geïmplementeerd door een ontwerporganisatie. In tegenstelling tot een stijlgids kan de waarde van een ontwerpsysteem onmiddellijk worden ervaren. Het ontwerpsysteem begint vrijwel onmiddellijk waarde toe te voegen, zelfs als de eerste conventie slechts een set van 5 primaire kleuren met bijbehorende naamconventie is. Ik zou zelfs betogen dat:

Ontwerpsysteem met één kleur gedefinieerd, correct benoemd, geïmplementeerd en geaccepteerd door een organisatie is beter dan een volledige statische stijlgids.

Waarom? Omdat deze kleur de entropie onmiddellijk vermindert, in tegenstelling tot een statische stijlgids die altijd verouderd blijft en nooit wordt geïmplementeerd.

In plaats van je zorgen te maken over de leverdatum van een ontwerpsysteem, accepteer het procesmatige karakter, begin klein en verzend vaak. Je bent in oorlog met chaos en elke kleine strijd is belangrijk.

Succes.

Wil je zien hoe we ons ontwerpsysteem bouwen? Volg onze sprints van Design Operations:

  • Design Systems Sprint 0: The Silver Bullet of Product Development.
  • Design Systems Sprint 1: The Interface Inventory
  • Ontwerp systeem Sprint 2: één kleurenpalet om ze allemaal te regeren
  • Ontwerpsysteem Sprint 3: beheer van de basisprincipes
  • Ontwerpsysteem Sprint 4: ontwerpprincipes
  • Ontwerpsysteem Sprint 5: typografie beheren
  • Ontwerpsysteem Sprint 6: de snelste pictogrammen op aarde

En hier is een breder perspectief op ontwerpsystemen:

Ontwerpsystemen zijn een taal. En dit verandert de softwareontwikkeling voor altijd.

Doe mee: https://www.uxpin.com/design-systems-early-access