Vi måste börja prata om UX-skulden

av | Apr 17, 2018

Mia Henriksson arbetar som UX:are på Purple Scout. I den här artikeln resonerar hon kring UX-skulden. Vad den innebär, hur den skiljer sig åt från den tekniska skulden, hur man hanterar UX-skulden i ett agilt projekt och vilka i teamet som egentligen behöver ta ansvar för den.

Inom mjukvaruutveckling pratas det ofta om teknisk skuld, men många gånger glöms det förbättringsarbete som behövs inom användargränssnitten av. Även inom UX borde vi börja prata om skuld. För också här måste vi inse att det sällan blir perfekt på första försöket och att kostnaden för merarbete inte sällan kan komma att växa längre fram. Ofta skapas det onödig irritation hos användaren när hon vant sig vid ett visst sätt att arbeta och blir tvungen att lära om.

Okej, då har vi konstaterat att det faktiskt finns en UX-skuld, hur ska vi förhålla oss till den?

Sex sätt att hantera UX-skuld:

  1. Gör UX-förbättringar till en naturlig del av det agila arbetet.
  2. Utrymme behöver finnas för att både se över resultat av analytics, A/B-tester, samtal med användarna osv. och också för att hantera förbättringar som kommer fram ur dem.
  3. Hela teamet ska involveras i UX-arbetet och alla bör diskutera igenom och försöka uppnå förståelse för hur UX-skulden har en negativ inverkan på användarens och/eller utvecklarnas och UX-arnas produktivitet.
  4. Gör det till en vana att involvera UX då en sida eller komponent ska uppdateras, och gör UX-förändringar samtidigt. Diskutera hur den UX-skuld som lyfts upp ska hanteras.
  5. Stora justeringar och refaktoriseringar hanteras som andra förfrågningar och tas med i backloggen. Se till att det finns förståelse för dessa och vad det innebär för det fortsatta arbetet.
  6. Inför acceptanskrav för användarfall och tester, det underlättar att påvisa UX-skuld.

Teknisk skuld – ett vedertaget uttryck

Teknisk skuld är kostnaden för merarbete längre fram, på grund av arbetet som skett tidigare. Ogjort, slarvigt eller dåligt utfört arbete gör att utvecklingen går allt långsammare. Det kan också vara så att projektet vuxit sig större eller förändrats så att det som gjorts inte längre är den bästa lösningen. Tekniken måste hänga med, och kod måste hela tiden förbättras.

Agila arbetssätt har lärt oss att avsätta viss tid för att kunna refaktorisera och göra förbättringar. En duktig produktägare förstår att det inte blir perfekt på en gång och att det behöver finnas utrymme för att eliminera teknisk skuld under utvecklingstiden. En duktig utvecklare ser till att alltid lämna kod i bättre skick än hon finner den. Det är en grundregel för att jobba löpande med teknisk skuld och för att undvika större avbrott i ett senare skede.

UX-skuld – behöver bli ett vedertaget uttryck

Skuld, både teknisk och UX-, kan introduceras oavsiktligt (arkitekturen visade sig vara fel och svår att skala, den överarbetade programmeraren introducerar buggar pga slarv, gränssnittet anpassades inte för de stora datamängder som visade sig komma in, ux-aren hann inte med att tänka på alla fall som kunde uppstå). Den kan också introduceras avsiktlig (genvägar tas och delar av arbete, såsom tester, användarstudier osv. skjuts upp för att hinna klart med releasen).

Varken UX-skuld eller teknisk skuld är buggar, det är inte heller ny funktionalitet. Det är viktigt att tydliggöra att det handlar om förbättringar i den existerande lösningen. När UX-skulden hanteras syns det på ett annat sätt och kan inte gömmas undan som en del av koden. Därför är det extra viktigt att produktägaren förstår och är med på tåget. Om programmeraren anses veta vad som behöver göras med koden för att den ska bli lätthanterlig och vara enkel att bygga vidare på, så behöver UX-are få förtroendet att veta vad som krävs för att få ett behagligt gränssnitt som förenklar användarens tillvaro.

Vi måste börja arbeta med UX-skulden agilt

I agila projekt är det vanligt att backloggen prioriteras om och nya saker tillkommer. Även om vi alltid försöker tänka flera steg framåt när vi jobbar med UX kan nya saker som kommer in på backloggen påverka gränssnittet så att det behöver omarbetas. Agilt arbete innebär att vi inte SKA lägga överdrivet mycket tid på att få varje funktion att bli perfekt, och inom UX-arbetet innebär det ibland att vi blir tvungna att ta genvägar. Vi kanske inte hinner göra tillräckliga användarstudier och/eller -tester och då måste det vara en del av arbetet att tillåtas förbättra lösningarna. Allt eftersom det agila arbetssättet sprids och förbättras har det blivit en självklarhet att UX är en del av det arbetet och ska finnas med genom hela processen. Men nu måste vi få med även gränssnittsförbättringar i det naturliga förbättringsarbetet. När UX är en del av det agila arbetet måste vi alltid lämna utrymme för förbättring och hela tiden sträva efter bättre lösningar.

Vilka ska ta hand om UX-skulden?

Svaret är att hela teamet är ansvariga för att UX-skulden hanteras på ett bra sätt. Dev-teamet bör se UX-förbättring som en del av arbetet och produktägaren behöver förstå hur och varför UX-skulden är viktig att jobba med. Att vi ska leverera värde varje gång brukar vara en bra motivering. Men att leverera värde till användaren varje gång kan vara svårt. I perioder görs mycket backendarbete som användarna inte kan se. Det är ett ypperligt tillfälle att samtidigt ta in issues med UX-refaktorisering. Hur lång tid en UX-refaktorisering tar är inte proportionellt mot hur värdefull den är för användaren. En snabb uppdatering av GUIt kan vara oerhört värdefull för användarna.

All teknisk skuld och all UX-skuld är inte akut att bli av med, men vi lånar tid som får betalas av i framtiden. I gränssnitten lånar vi också ofta tid från användaren i hennes arbete.

Pin It on Pinterest