Lättrörlig utvecklingsmetodik och kontinuerliga leveranser gör att vi idag snabbt kan börja leverera affärsvärde i mjukvaruprojekt. Trots detta prioriteras fortfarande ofta användarupplevelsen ned i det tidiga skedet av utvecklingen. I värsta fall reduceras UX-arbetet till att handla om att styla en projektion av en normaliserad one-size-fits-all-datamodell.
En bra användarupplevelse är starkt kopplad till mjukvarans potential att skapa affärsvärde och är ingenting man kan lägga på i efterhand – tvärtom behöver mjukvaruarkitekturen stödja en mångfacetterad och föränderlig UX redan från dag ett.
I denna artikel delar Citeruskonsulterna Maria Wikforss och Håkan Jonson med sig av sina tankar kring att skapa förutsättningar för ett bra UX-arbete redan på arkitekturnivå i mjukvaran med hjälp av domändriven design och event sourcing.
Bakgrund
Vad som utgör en bra användarupplevelse är inte konstant. Det som vi tycker fungerar bra, är ändamålsenligt och tilltalande idag, behöver inte vara detsamma imorgon. En hög konverteringsgrad nu, betyder inte automatiskt en hög konverteringsgrad i framtiden.
Ett växande antal typer av mobila enheter, med sina respektive användningsområden, och en mängd användartyper, med sina respektive förutsättningar och förväntningar, räcker inte att ha i åtanke längre. Vi behöver också förhålla oss till att allt vi tror att vi vet förändras. Hela tiden. I rasande fart.
Att kontinuerligt kunna lägga till, dra ifrån, förbättra, förändra och utöka funktionalitet och finesser i mjukvaran vi utvecklar måste vara smidigt. Likaså att göra nya oväntade tvärsnitt i datan och hålla reda på, och enkelt kunna visa, historik och förlopp som ägt rum. Vi måste helt enkelt kunna agera på förändrade förhållanden, ny kunskap eller nya insikter om vad mjukvaran ska stödja för användningsfall för att vara konkurrenskraftiga idag.
I detta syfte är det inte tillräckligt kraftfullt att det går att ändra stylingen i användargränssnittet på ett smidigt sätt. Det är självklart bra, men användbarheten och upplevelsen styrs inte bara av presentationen i sig, utan av vad vi presenterar, vilken information vi väger samman och när vi visar den.
Typisk scenario
Idag stöter man ofta på system som arkitekturellt vilar på en datamodell normaliserad efter viss nyckelfunktionalitet. Kanske har man sedan utökat denna för att stödja en handfull specialfall eller avvikelser. Typiskt persisteras modellen i en relationsdatabas som sedan kompletteras med diverse index för att snabba upp de vanligast läsfallen. Som tidigare diskuterats är användarupplevelsen ofta en ren konsekvens av denna underliggande struktur, med allt vad en gemensam läs- och skrivmodell innebär.
Figur 1: arkitektur med en gemensam läs- och skrivmodell som speglas ut till gränssnittet.
Efterhand som system mognar och växer förändras funktionella och icke-funktionella krav. Användargrupper kommer till eller faller bort och funktionalitet och fokus förändras. Nya affärsperspektiv eller visioner gör att de initialt så viktiga optimeringarna kanske inte längre är lika avgörande. Den tidigare så effektiva normaliserade modellen börjar nu istället bli en belastning; introduktion av ny funktionalitet slår mot prestanda, data måste kompletteras med hjälp av batch-uppdateringar och i vissa fall kanske till och med datamodellen försvårar implementation av ny funktionalitet.
Hur kan vi anpassa mjukvaruarkitekturen för att kunna jobba med moderna krav på lättrörlig UX, där vi måste kunna ändra och förnya oss ofta, utan att behöva brottas med att modellera om hela systemet stup-i-kvarten? Eller ännu värre, låta detta sätta stopp för att skapa bra UX.
Ett annat sätt att tänka
Inom domändriven design (DDD) talar man om användandet av flera modeller som är skräddarsydda för olika delar av ett system eller problemområde. Här finns det med andra ord inget självändamål i en one-size-fits-all-approach. Tvärtom är det inte ens speciellt önskvärt.
Introduktion av flera modeller innebär dock ofta införandet av redundans. Kanske existerar viss data i flera modeller och kanske har de till och med liknande kontextuell betydelse. Detta innebär dock sällan problem i modellen. Dessvärre finns det en utbredd uppfattning om att redundans i databasen – och i synnerhet i en relationsdatabas – är allt annat än önskvärt, vilket också må vara sant, så länge du jobbar med en normaliserad one-size-fits-all-modell. Från ett UX-perspektiv är dock redundans ofta något positivt; redundans kan till exempel användas för att understryka koncept kring navigering eller komplexa relationer. Redundans används också flitigt för att skapa gränssnitt som passar alla kognitiva typer – och således alla typer av användare – då vissa människor i första hand ser spatiala mönster, andra färger, former, siffror, etc. Bortsett från den diskrepans som råder kring begreppet redundans, och de kommunikationsproblem detta kan ge upphov till, visar det sig att redundans inte nödvändigtvis behöver ses som ett problem i modellen.
För att undvika inlåsning i en statisk läs- och skrivmodell, normaliserad för en kravbild som kanske inte längre är giltig, kan man med hjälp av event sourcing se samtliga förändringar i systemet som en sekvens av händelser.
Typisk systemfunktionalitet innebär ofta någon typ av tillståndsförändring i systemet; ett värde – och således ett fält i databasen – uppdateras som konsekvens av någon input i gränssnittet eller affärslogisk operation. I en traditionell modell innebär detta en pågående historierevisionism; aktuellt tillstånd är alltid sanning och denna är alltid relaterad till endast en punkt i tiden. Med event sourcing representeras istället funktionalitet som en eller flera händelser som ett objekt reagerar på; ett synsätt som får en del intressanta konsekvenser.
Om aktuellt tillstånd aggregeras upp från en sekvens med händelser, relaterat till en godtycklig punkt i tiden, finns det således möjlighet att försätta systemet i gårdagens läge – eller i det läge som för 6 månader sedan tycks ha orsakat det där allvarliga felet. På samma sätt som saldot på ditt bankonto är summan av alla positiva och negativa transaktioner relaterat till en punkt i tiden är systemtillståndet det av alla händelser.
Figur 2: multipla läsmodeller aggregerade från en sekvens av händelser.
Modellering av tid, utan att explicit spåra ett objekts livscykel, är bara en fördel med event sourcing. I motsats till en normaliserad one-size-fits-all-modell inbjuder event sourcing till att spara händelser i de-normaliserad form; det finns i praktiken ingen poäng med normalisering då händelserna i sig inte har någon inneboende information om hur de relaterar till andra händelser, utan det är först då man placerar dessa på en tidslinje som hela bilden framträder.
Multipla modeller – där varje modell har sitt respektive syfte – vars tillstånd aggregeras upp från en (del)mängd av de-normaliserade händelser tar udden av redundansproblematiken; urvalsprocessen blir en fråga om vilka händelser som läses upp snarare om hur data är representerad i dessa. Att läsa samma händelse flera gånger beroende på vilken affärslogisk modell som ska representeras känns helt självklart.
Lean på köpet
Detta medför också ett nytt sätt att jobba mellan mjukvaruarkitekt, utvecklare och UX:are. Genom att lägga grunden till mjukvarans arkitektur tillsammans kan man skapa förutsättningar för att arbeta tvärfunktionellt på riktigt under hela projektets livslängd.
Förutom att det är otroligt givande att jobba i team och samarbeta iterativt kring arkitekturen och UX, så är det också bra för att skapa mer pragmatiska lösningar där vi gör rätt kompromisser och prioriteringar mellan UX, arkitektur och utvecklingstid.
När samarbetet är tätt, ofta och nära så kan man dessutom minimera mängden leveranser sinsemellan och annan “muda” (slöseri) i teamet, vilket går i linje med det agila tänket och Lean UX-rörelsen. En ökad förståelse för varandras perspektiv ger också ökade möjligheter hitta nya, oväntade lösningar på problem och få till ett kreativt teamarbete.
Sammanfattning
Genom att använda event sourcing, i kombination med skräddarsydda läsmodeller för viktig funktionalitet eller användarscenarion, har du en arkitektur som är väl förberedd för framtida gränssnittskrav och förändrat affärsperspektiv. Det blir lättare att skräddarsy användarupplevelsen för olika enheter, scenarion och ständigt uppskruvade förväntningar. Och till på köpet har man en arkitektur med ypperliga förutsättningar för att skapa enastående UX – utan att behöva kompromissa på datamodellen.
Referenser och lästips
http://martinfowler.com/eaaDev/EventSourcing.html
http://codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/
http://www.infoq.com/presentations/model-to-work-evans
Jeff Gothelf (& Josh Seiden, editor) (2013) Lean UX Applying Lean Principles to Improve User Experience, O’Reilly Media Inc.