Wie jullie merk uitvoert, werkt hier niet

Het meeste wat er over designsystemen wordt geschreven, gaat uit van één soort gebruiker. Die zit ergens in dezelfde organisatie, heeft toegang tot Figma, kan de Storybook openen, en als iets onduidelijk is stelt hij de vraag in Slack en heeft hij voor de lunch antwoord. Het systeem is een gedeelde afspraak tussen mensen die een werkplek delen.

Ik bouw merksystemen voor een andere situatie. Bedrijven waarvan het merk vrijwel volledig wordt uitgevoerd door mensen buiten de organisatie. De onderdelen zijn dezelfde die je zou verwachten: een vaste tekstschaal, exacte kleurwaarden, een stramien, regels voor hoe het logo zich gedraagt. Wat verschilt is wie het systeem in handen krijgt, en dat blijkt bijna elke beslissing eronder te veranderen.

Stel die uitvoerders je even voor. Een belettering die veertig opleggers moet doen. Een drukker die verpakking produceert in een ander land. Een freelancer die de marketingcoördinator vorige week heeft gevonden. Een bureau dat twee jaar na de oplevering wordt ingehuurd door een dochteronderneming. Geen van hen leest documentatie. Geen van hen gebruikt ontwerpsoftware. De meesten spreken nooit iemand die aan het systeem heeft gewerkt, en tegen de tijd dat hun werk in de wereld staat, is de beslissing die het vorm gaf maanden eerder genomen door iemand die inmiddels weg is.

Ik beproef dit al een tijd op mijn eigen uitgeversnetwerk voordat ik de aanpak verkoop: vijftien B2B-titels op één codebase en één set merkdefinities. Dat is een bruikbare proefopstelling, juist omdat elke zwakke plek zich vijftien keer laat zien in plaats van één keer.

Als je systeem ervan afhangt dat je de mensen die het gebruiken kunt bereiken, dan heb je geen systeem gebouwd maar een proces. Dat verschil is makkelijk te missen zolang iedereen bereikbaar is.

Het bestand moet overleven in handen van iemand die er niets om geeft

Een autobelettering die een rij opdrachten afwerkt, opent de map die je hebt gestuurd, ziet iets wat op een logo lijkt, en gebruikt dat. Hij is niet slordig. Hij heeft een bay geboekt, een bus die staat te wachten en vier andere klussen die dag. Het bestand werkt of het werkt niet.

Dat is het argument tegen een map met twaalf varianten en een pdf die uitlegt wanneer je welke pakt. De map garandeert dat iemand het verkeerde bestand kiest, en de pdf garandeert niets, want die wordt niet geopend. Wat beter werkt is een kleiner aantal bestanden waarvan de naam de verkeerde keuze lastig maakt, en waarvan de opbouw verkeerd gebruik zichtbaar verkeerd maakt in plaats van stilletjes verkeerd.

Ik ben bestandsnamen gaan behandelen als onderdeel van de specificatie in plaats van als opruimwerk. Een bestand dat logo-definitief-2.png heet, wordt voor alles gebruikt. Een bestand dat logo-horizontaal-druk-cmyk.eps heet, wordt voor drukwerk gebruikt, en wie het voor een scherm nodig heeft, merkt dat dit niet het bestand is.

Dit is niet elegant. Het lijkt meer op het labelen van een meterkast dan op het schrijven van documentatie, en het werkt om dezelfde reden.

Een regel die in een document staat, is geen regel

In een productsysteem wordt een regel over minimale vrije ruimte afgedwongen door het component zelf. De ontwikkelaar kan hem niet makkelijk overtreden, omdat de marge onderdeel is van het ding dat hij importeert. De regel en het bestand zijn hetzelfde object.

Buiten die omgeving vallen regel en bestand meteen uit elkaar. Je schrijft op dat het logo vrije ruimte nodig heeft ter hoogte van de binnenvorm van de letter. Die instructie blijft in het document staan, en het bestand reist alleen verder naar iemand die het tegen de rand van een visitekaartje plakt, omdat het daar past.

Wat ik nu doe is de regel niet meer beschrijven maar in het bestand bouwen. Vrije ruimte wordt transparant canvas rondom het merkteken, zodat het bestand tegen een rand plakken alsnog de juiste marge oplevert. Minimale grootte wordt een beslissing over welke variant überhaupt bestaat, zodat de versie die onder een bepaalde schaal breekt niet tussen de opgeleverde bestanden zit.

Je levert er flexibiliteit mee in. Wie het systeem begrijpt en het merkteken om een goede reden strak wil plaatsen, moet nu om jouw canvas heen werken. Die ruil is het waard op het moment dat vrijwel iedereen die het bestand aanraakt de regels niet kent.

Verbodsregels verlopen sneller dan gebodsregels, en niemand merkt het

Een gebodsregel wordt bevestigd elke keer dat iemand hem volgt. Gebruik deze kleur voor primaire knoppen, en elk juist gebruik maakt het volgende juiste gebruik waarschijnlijker, omdat het patroon zichtbaar wordt in het product.

Een verbodsregel heeft die terugkoppeling niet. Plaats het merkteken niet op een foto. Overtreedt iemand dat, dan gebeurt er niets. Geen foutmelding, geen mislukte build, geen klacht. De overtreding gaat de deur uit, ziet er op zichzelf acceptabel uit, en wordt een voorbeeld voor de volgende die zoekt hoe het merk wordt toegepast.

Die scheefgroei stapelt. Na twee jaar niet-afgedwongen verbodsregels heb je geen systeem met een paar uitzonderingen. Je hebt een systeem waarin de uitzonderingen in de meerderheid zijn, en waarin de oorspronkelijke specificatie leest als een verslag van iets wat ooit waar was.

Ik heb hier geen goede algemene oplossing voor. Wat helpt is het aantal verbodsregels terugbrengen tot de twee of drie die er echt toe doen, en ze opschrijven waar het bestand staat in plaats van in een apart document. Een regel die je niet kunt afdwingen is het opschrijven waard zolang je accepteert dat zijn functie is om achteraf een discussie te beslechten. Dat is een echte functie, maar een veel kleinere dan de meeste huisstijlhandboeken aannemen.

Distributie is een groter probleem dan specificatie

Productteams lossen distributie één keer op. Er is een pakket, een register, een versienummer en een manier om de actuele versie op te halen.

Voor een externe keten bestaat dat equivalent niet, en de meeste pogingen om er een te bouwen mislukken om redenen die niets met de kwaliteit van het systeem te maken hebben. Een gedeelde schijf vraagt toegangsbeheer dat niemand bijhoudt. Een pdf wordt doorgestuurd en wordt vier jaar lang de geldende versie op iemands bureaublad. Een portaal met een login is een portaal dat een drukker niet gebruikt, want hij maakt geen account aan voor een klus waarvoor hij dinsdag is betaald.

Waar ik op ben uitgekomen is één url, zonder inlog, op het eigen domein van de klant, met de actuele specificatie en de actuele bestanden erop. Een nieuwe leverancier krijgt een link in plaats van een uitleg. Dat is in elk opzicht een zwakker mechanisme dan een pakketregister, behalve in het enige opzicht dat telt: mensen gebruiken het.

Dezelfde redenering geldt voor alles wat je publiceert voor mensen buiten de organisatie. Ik heb onlangs een set constructietekeningen verplaatst van een pagina met een drempel naar een kale url die het bestand direct teruggeeft, zonder formulier en zonder account. De enige mensen die ze zouden openen waren leveranciers met een klus voor zich, en elke stap tussen de link en het bestand is een stap waarop ze afhaken en pakken wat ze al hadden.

Er zitten echte kosten aan. Wat zonder inlog wordt gepubliceerd is openbaar, en dat beperkt wat erin kan. Prijzen, strategie en alles wat commercieel gevoelig is blijven eruit. Wat overblijft is het deel dat leveranciers nodig hebben, en dat blijkt vrijwel alles te zijn wat ze nodig hebben.

Er is geen terugdraaiknop

Dit is de beperking die ik er het langst over deed om te doorgronden, en het is de beperking die dit werk het meest scheidt van software.

Als een component met een fout de deur uit gaat, herstel je hem en deploy je opnieuw. Bestaande gebruikers pakken de wijziging op bij hun volgende build. De foute versie leeft dagen.

Als een oplage van veertigduizend dozen met de verkeerde kleurwaarde de deur uit gaat, bestaan die dozen. Ze zijn twee jaar in omloop. De prepress-afdeling van de leverancier heeft het bestand gearchiveerd en gebruikt het opnieuw bij de herdruk, en wanneer die herdruk wordt besteld door iemand nieuw met de opdracht het gelijk te houden aan de vorige, plant de fout zich voort in plaats van dat hij verdwijnt.

Alles wat daarvóór komt verandert daardoor. Validatie kan niet stapsgewijs zoals bij software, omdat er geen goedkope herhaling is. De kleur moet kloppen voordat er iets wordt verstuurd, wat betekent dat de specificatie exact moet zijn voordat hij bruikbaar is, wat betekent dat het werk vooraan ligt op een manier die ouderwets aanvoelt en niet onderhandelbaar is.

Een korte controle die je deze week kunt doen

Wil je dit op je eigen systeem toetsen in plaats van mijn woord ervoor aan te nemen, dan zijn vijf vragen genoeg. Dit is de controle die ik gebruik en hij kost ongeveer een uur.

1. Pak je vijf meest gebruikte bestanden. Hoeveel versies bestaan er van elk?

Tel wat een leverancier zou vinden als je hem vandaag de map stuurt. Is het antwoord voor het logo negen, dan zijn er acht verkeerde keuzes beschikbaar. Breng het terug tot de verkeerde keuze moeite kost.

2. Neem één regel uit je documentatie. Zit hij in het bestand?

Minimale vrije ruimte, minimale grootte, toegestane achtergronden. Bestaat de regel alleen als zin, dan wordt hij overtreden door iedereen die de zin nooit leest, en dat zijn de meesten. Vraag je af wat er nodig is om hem in het bestand te bouwen.

3. Tel je verbodsregels. Vraag daarna wie een overtreding zou opmerken.

Is het eerlijke antwoord niemand, dan is die regel de vastlegging van een bedoeling en geen beperking. Houd hem als je hem nodig hebt om discussies te beslechten. Reken hem niet mee als handhaving.

4. Klok de weg van link naar bestand.

Open je distributie in een privévenster zonder sessie. Tel de stappen tot een bruikbare download. Elke login, elk formulierveld en elke map is een stap waarop iemand met een klus afhaakt en pakt wat hij al had.

5. Kijk naar je afspraken, niet alleen naar je bestanden.

Zoek elke bepaling die jou tot verplichte deelnemer maakt aan iets wat je hebt omschreven als overdraagbaar. Die bepaling vertelt de waarheid over het systeem, en de omschrijving niet.

Wat dit betekent voor systemen met bereikbare gebruikers

Ik betoog niet dat productdesignsystemen deze beperkingen moeten overnemen. De meeste ervan gelden daar niet, en bouwen voor een onbereikbaar publiek terwijl je publiek bereikbaar is, is verspilling.

De bruikbare vraag is een andere. Als je het vermogen om je gebruikers te bereiken zou wegnemen, hoeveel van je systeem zou dan nog werken?

Niet de delen die afhangen van inwerken. Niet de delen die afhangen van iemand die een afwijking opmerkt tijdens een review. Niet de delen die in een pagina staan die een nieuwe medewerker moet lezen. Wat overblijft is het deel dat echt is vastgelegd: beperkingen die in de bestanden zitten, namen die de verkeerde keuze onwaarschijnlijk maken, en definities waar een machine of een vreemde naar kan handelen zonder interpretatie.

Die rest is het systeem. De rest is een proces dat toevallig werkt omdat de mensen die het draaien er nog zijn.

Er is een versie van deze test die je op je eigen afspraken kunt toepassen in plaats van op je bestanden, en die is ongemakkelijk. In mijn voorwaarden stond dat de opdrachtgever de onderliggende constructie niet mocht wijzigen zonder mij erbij te betrekken. Ik heb die bepaling geschreven in de overtuiging dat hij de integriteit van het werk beschermde, en lange tijd las hij redelijk. Wat hij in werkelijkheid deed was mij tot permanente afhankelijkheid maken van een systeem dat ik als volledig overdraagbaar had omschreven. Daarmee was de overdracht voorwaardelijk en de omschrijving niet juist.

Ik heb hem eruit gehaald. Na volledige betaling kan de opdrachtgever de constructie zelf wijzigen of aan iemand anders geven, zonder te vragen. De richtlijnen zijn nu advies en geen toestemming. Houdt het systeem alleen stand zolang ik bereikbaar ben, dan was wat ik bouwde nooit een systeem, en dat ontdekken via een contractbepaling is goedkoper dan het ontdekken via een klant die verder is getrokken.

Drie dingen om mee te nemen

Beperkingen die in documentatie staan zijn suggesties. Beperkingen die in het bestand zitten zijn beperkingen, en het verschil wordt pas zichtbaar wanneer degene die het bestand vasthoudt nooit van je heeft gehoord.

Verbodsregels verlopen zonder het aan te kondigen, omdat er niets misgaat wanneer ze worden overtreden. Houd er weinig en zet ze waar het bestand staat.

Distributie wint van specificatie. Een zwakker systeem dat mensen daadwerkelijk bereiken, wint het elke keer van een beter systeem achter een login.

Ik zou graag weten of dit ook opgaat voor teams die volledig intern werken. Mijn vermoeden is dat de onbereikbare-gebruikertest in de meeste organisaties ongemakkelijk uitpakt, en dat veel van wat voor een systeem doorgaat een proces is met goede opkomst. Doe je die vijf vragen op je eigen systeem, dan hoor ik graag wat er breekt.