Ontwerpschuld

Ontwerpschuld is de optelsom van de kosten van ontwerpbeslissingen die destijds handig leken, maar het product nu moeilijker te gebruiken en aan te passen maken. Het is het ontwerpequivalent van technische schuld en ontstaat op dezelfde manier: individueel redelijke shortcuts die onder tijdsdruk worden genomen, die op zichzelf niet significant lijken, stapelen zich op tot een interface die inconsistent, verwarrend en duur om aan te passen is.

Het ontstaat via herkenbare mechanismen. Een component wordt licht aangepast voor één scherm in plaats van dat het patroon wordt bijgewerkt, en de variant blijft bestaan. Een functie wordt toegevoegd zonder te overwegen hoe deze in de bestaande structuur past. Een pagina wordt ontworpen door iemand die niet bekend is met de vastgestelde patronen. Een overgenomen product wordt geïntegreerd zonder harmonisatie. Een rebranding wordt toegepast op de meest zichtbare onderdelen en niet op de rest. Elk van deze gevallen maakt het product iets minder coherent dan voorheen.

De kosten zijn reëel maar diffuus, waardoor het probleem jarenlang wordt getolereerd. Gebruikers stuiten op inconsistente patronen en moeten gedrag dat eigenlijk overdraagbaar zou moeten zijn, opnieuw aanleren. Dit verhoogt de cognitieve belasting en het aantal fouten. Ontwerpers besteden tijd aan het kiezen uit verschillende bestaande oplossingen. Ontwikkelaars implementeren variaties in plaats van componenten te hergebruiken. Elke nieuwe functie moet rekening houden met de opgebouwde inconsistentie, waardoor de kosten van veranderingen voortdurend stijgen.

Het onderscheidende kenmerk ten opzichte van technische schuld is de zichtbaarheid. Technische schuld is onzichtbaar voor klanten totdat er een defect optreedt; ontwerpschuld is op elk scherm zichtbaar. Klanten hebben er misschien geen woorden voor, maar ze ervaren een product dat onafgewerkt en inconsistent aanvoelt, en die perceptie beïnvloedt het vertrouwen op manieren die moeilijk aan een specifiek element toe te schrijven zijn.

Sommige ontwerpfouten zijn opzettelijk en verdedigbaar. Het uitbrengen van een ruwe interface om de vraag te toetsen voordat er in verfijning wordt geïnvesteerd, is een redelijke afweging, mits dit wordt vastgelegd en de verplichting wordt erkend. De schadelijke variant is onopgemerkt: inconsistentie die wordt geïntroduceerd zonder dat iemand het merkt, die zich over jaren en teams opstapelt, zonder dat er wordt vastgelegd waarvan is afgeweken of waarom.

Herstel vereist een inventarisatie voordat er actie wordt ondernomen. Door het product te auditeren en vast te stellen waar patronen afwijken, hoeveel varianten er van elk onderdeel bestaan ​​en welke inconsistenties de meestgebruikte processen beïnvloeden, wordt een algemeen gevoel van rommeligheid omgezet in een prioriteitenlijst. De meeste producten bevatten veel meer varianten dan verwacht, en de audit zelf levert vaak het argument voor investeringen.

Prioritering moet gebaseerd zijn op gebruik, niet op ergernis. De inconsistenties die ertoe doen, bevinden zich op de paden die de meeste mensen bewandelen, en een storende afwijking op een zelden bezocht beheerscherm kost veel minder dan een subtiele afwijking in het afrekenproces. Door herstelwerkzaamheden te ordenen op basis van verkeer en commerciële waarde, blijft het werk gekoppeld aan de resultaten en wordt het veelvoorkomende patroon voorkomen waarbij een consolidatieproject zich richt op de inconsistenties die de beoordelende ontwerper het meest irritant vond.

Voorkomen is aanzienlijk goedkoper dan herstellen en is grotendeels een systeemkwestie. Een goed beheerd ontwerpsysteem met duidelijke processen voor bijdragen en afschrijvingen maakt consistentie de norm en afwijking bewust. Ontwerpbeoordeling als vaste procedure spoort afwijkingen op voordat ze worden uitgebracht. En door patroonupdates te behandelen als onderdeel van de ontwikkeling van nieuwe functionaliteiten, in plaats van als aparte verbeteringsprojecten die nooit worden ingepland, wordt voorkomen dat afwijkingen zich aan de bron ophopen.

Omdat herstelwerkzaamheden concurreren met de levering van nieuwe functionaliteiten om dezelfde capaciteit, vereisen ze dezelfde rechtvaardiging als elke andere investering. In de praktijk worden de audit en het herstelplan opgesteld via UX-audit in het kader van dit werk wordt de systematische preventie aangepakt door het ontwerpsysteem dat is opgezet in productontwerpEn de implementatie van patroonconsolidatie moet doorgaans worden ingepland tegelijk met werkzaamheden aan de technische schuld binnen productontwikkeling, aangezien beide vaak dezelfde componenten beïnvloeden.