Det grymma med att vara på en bred utvecklarkonferens som Øredev är ju att det är lätt att gå lite utanför den vanliga fåran, där man brukar vara.
Jag har gått på några UX presentationer idag som varit rätt bra. Om man ska vara riktigt generös med tolkningen av användare så var jag på en igår också på temat “API the hidden UI”. Tanken är att den som kommer använda ditt API också är någon form av användare, en stor skillnad är dock att ett GUI kan ändras efter att det börjat användas, ett API kan däremot inte ändras utan att saker verkligen går sönder för användare. I princip kan man säga (ok, lite hårddraget) att man bara har en chans att göra API:t rätt. När det publicerats är det användarna som äger det. Inte själva implementationen, men du kan inte ändra hur som helst längre.
Flera av lärdomarna där har jag hört upprepas idag på mer traditionella UX presentationer t ex:
- När man får förfrågningar om nya funktioner får man det oftast i form av ett halvfärdigt lösningsförslag. Försök att fokusera på det underliggande problemet istället. En princip som kan användas är att det inte ska bli bättre bara för en användare utan för många. Beställaren ska kunna motivera varför, för vilka den löser vilket problem.
- Använd konventioner som är utbredda. Analogt med att användare spenderar mest tid på andra webbplatser än din egen, så spenderar API-användare mest tid med andra API:er än ditt. Ett exempel är att en relation mellan brukar benämnas parent-child. Om man i sitt API kallar det för father kommer det bli förvirrande.
Jeff Patton presenterade två klassiska “failure modes” när man utvecklar och jobbar (mindre bra) med UX:
- Man antar att “om jag gillar det så kommer användarna också göra det”
- Man frågar användare direkt vad de vill ha och ger användare skulden om det inte blir bra.
“Don’t capture requirements – build empathy”
När man får in krav: fråga vem det hjälper och vilka problem det löser? Nå roten till problemet. User stores hjälper till att fokusera rätt
UX har lager:
- Aesthetics
- Usability
- Utility
Bygg underifrån (Utility -> Usability). Produkter utan utility dör. Man måste adressera ett verkligt behov.
Jeff menar att det finns fyra vikiga faser under designen, som det krävs disciplin för att inte hoppa över:
- Förstå problemet. Kräver empati och genuin förståelse för användares situattion kräver oftast “skuggning”, att man iakttar användare i deras verkliga miljö
- Identifiera lösningar. Tänk brett och brainstorma.
- Förfina och validera lösningen iterativt.
- Slutligen: Skapa plan för implementationen.
