Den som öppnar ett designverktyg möts numera av förslag på färgpaletter, automatisk grid-layout och komponenter som känner igen sin egen kontext. Det som tidigare krävde ett möte och en diskussion kan nu hanteras av en funktion inbakad i själva ritbordet.
Förändringen har inte kommit över en natt. Men den har förändrat hur beslut fördelas i ett projekt, och vem som får ordet när en detalj ska fastställas.
Verktyg som föreslår i stället för att bara rita
Tidigare generationer av designprogram höll sig till att låta formgivaren dra linjer och välja kulörer. Verktyget lyssnade, men tog aldrig initiativ.
I dag har samma verktyg en egen uppfattning. De kan föreslå kontrast, kontrollera tillgänglighet, föreslå alternativ färgsättning eller anpassa typsnitt efter skärmstorlek. Funktionen kallas ofta intelligent assistans, men i praktiken innebär det att verktyget styr mer än det styrs.
För den som arbetar ensam kan det vara en hjälp. För team betyder det att beslut ofta landar innan någon annan hinner se alternativet.
Mindre tid i möte, mer tid i gränssnitt
När designverktyget kan ge återkoppling direkt minskar behovet av avstämningar. I stället för att boka in ett möte för att diskutera färgkontrast får formgivaren svaret medan arbetet pågår.
Det frigör tid. Men det betyder också att beslut som tidigare togs i grupp nu tas av den som för musen. Rollfördelningen förskjuts.
Den som skriver kod eller förvaltar varumärket får allt oftare se ett färdigt förslag först när designen redan är etablerad i verktyget. Diskussionen flyttas från idéfas till godkännande.
Vad som automatiseras styr vad som diskuteras
De funktioner som byggs in i verktygen bestämmer vilka frågor som alls hinner upp till ytan. Är kontrasten grön enligt standarden blir den sällan ifrågasatt. Är ett avstånd räknat automatiskt ur ett grid blir det inte heller föremål för debatt.
Det som däremot inte kan räknas ut – tonalitet, hierarki, känsla – det stannar kvar som öppna frågor. Och eftersom tiden är begränsad hamnar fokus där det inte redan finns ett svar.
Resultatet är att de beslut som är svårast att formalisera tar störst plats i dialogen, medan allt annat avgörs tyst av algoritmen.
Standarder byggs in och blir osynliga
När WCAG-regler programmeras in i ett gränssnitt blir tillgänglighet mindre synlig som arbetssteg. Det är inte längre något man kontrollerar, utan något verktyget redan har gjort.
Samma sak gäller responsivitet, mellanrum och grid. De standarder som definieras tidigt i projektet byggs in i komponenter och mallar. Därefter hanteras de inte längre aktivt.
Det ger en trygghet. Men det döljer också de val som faktiskt görs. En komponent som alltid renderar samma marginal gör det oavsett om marginalen passar i det nya sammanhanget eller inte.
Samarbete kräver fortfarande ord
Trots att verktygen kan mycket själva behöver människorna i projektet fortfarande prata med varandra. Ingen algoritm kan förklara varför en viss knapp ska synas mer än en annan, eller varför logotypen ska sitta högre upp.
De samtalen kräver ett gemensamt språk och en förståelse för vad som ska värderas högst. Verktyget kan inte avgöra vilken känsla ett interface ska förmedla, eller vilken hierarki som stödjer affären bäst.
När besluten automatiseras finns det risk att det språket förtvinar. Om ingen behöver motivera sina val högt blir det svårare att lära sig göra det.
Rollerna behöver skrivas om
I takt med att verktyget tar över delar av designarbetet förändras vad det innebär att vara formgivare, utvecklare eller projektledare. Den som tidigare ansvarade för att kontrollera kontrast kan nu fokusera på annat. Men vad det andra är behöver definieras.
Många byråer och team skriver just nu om sina arbetsprocesser. I stället för att låta verktyget diktera flödet försöker de formulera vad som fortfarande kräver mänsklig bedömning.
Det handlar inte om att motstå automatisering, utan om att välja vad som ska automatiseras och vad som ska hållas öppet för diskussion.
Verktyg gör inte beslut, de bara flyttar dem
En funktion som automatiskt justerar textstorlek tar fortfarande ett beslut. Det beslutet fattades bara tidigare, när funktionen programmerades, av någon annan än den som använder verktyget nu.
Det innebär att designbeslut i allt högre grad tas av dem som bygger verktygen, inte av dem som använder dem. Reglerna kodas in, och användaren ärver dem.
För den som vill ha kontroll innebär det att valet av verktyg blir allt viktigare. Vilket verktyg man väljer avgör vilka beslut man får ta själv, och vilka som redan är tagna.
Dokumentation blir viktigare när beslut döljs
När en färg väljs manuellt finns det ofta en anteckning i marginalen om varför. När samma färg väljs automatiskt av ett system försvinner förklaringen.
Dokumentationen behöver därför flyttas från designfilen till systemet. Det räcker inte att visa vad som gjorts, man måste också förklara varför det gjordes så och vilka premisser som gällde.
En del team löser det genom att bygga in kommentarer direkt i sina komponenter. Andra upprättar designprinciper som lever utanför verktyget och följer med genom hela projektet.
- Definiera vad som får automatiseras – välj medvetet vilka beslut verktyget ska ta och vilka som kräver manuell bedömning.
- Dokumentera reglerna – förklara varför en funktion finns och vad den optimerar för.
- Granska regelbundet – se till att automatiken fortfarande stödjer projektets mål, inte bara reproducerar gamla val.
- Behåll samtalet – se till att team fortfarande diskuterar designval, även när verktyget föreslår svar.
Praktiken varierar mellan byråer
Vissa aktörer väljer att bygga sina egna system där varje automatiserad funktion är definierad internt. Det kräver tid, men ger full kontroll över vilka beslut som delegeras till verktyget.
Andra använder färdiga plattformar och anpassar sin process till vad verktyget erbjuder. Det går snabbare, men innebär att beslutslogiken ärvs från externa utvecklare.
Rawdesigns arbetar med designsystem där automatiseringen byggs upp stegvis, utifrån projektets behov snarare än verktygets standardfunktioner. Det gör att teamet kan välja vilka beslut som ska tas i mötet och vilka som kan hanteras direkt i gränssnittet.
Transparens som motsats till automatik
Ju mer verktyget gör åt oss, desto viktigare blir det att förstå vad det gör. Transparens handlar inte om att se koden, utan om att förstå logiken.
Ett verktyg som automatiskt sätter avstånd bör kunna förklara vilken regel det följer. En funktion som justerar färg bör kunna visa vilken standard den utgår från.
Utan den öppenheten blir designen en black box. Det ser bra ut, men ingen vet varför.