Vanliga frågor om UX

Till och börja med skulle jag säga att ta bort godtyckligheten i språket du använder i dina krav. Du behöver specificera dina krav som gör det lättare att mäta på om kravet har uppfyllts eller inte. Det gäller att försöka bryta ner kravet så det blir mer specifikt, så att man faktiskt kan mäta i det som man vill försöka uppnå.

Just när det kommer till användbarhetsfrågor så pratar vi ganska ofta om hur stor andel av alla anvdändare i en viss typ ska slutföra ett flöde successivt över löpande tid.

När det kommer till design och grafiska profiler och liknande, det är alltid beroende på vad vi har för företag och vad de har för grafisk profil, hur man vill att menyalternativ ska displayas, vilka färger och former vi använder. Men kan vi inte mäta på det så blir det också väldigt svårt att veta, är det ett bra skrivet eller ett väl uppfyllt krav eller inte?

Jag vill tolka det som att du har ställt frågan utifrån funktionella krav, det vill säga en funktion ska exekveras, ett flöde ska slutföras. Och då blir det också så klart mätbarheten på hur många som slutför det, var i processen de trillar av, varför, och kunna kolla på det på det sättet. Redan på kravnivå så skriver vi det. Det ställer saker och ting på sin spets i kravhanteringen också. Varför skriver vi det här kravet? Varför är det viktigt att ha den här funktionen? Hur många kommer att använda den? Vad är kriterierna?

Jag tycker det är en väldigt relevant fråga. Jag tror många jobbar väldigt olika där. Jag personligen tycker att det är jättebra att vara väldigt involverad, att man får en känsla av att vi jobbar allihopa samma team, vi har samma backlogg. Jag som UX:are kan också vara med och påverka, skriva PBI:er eller att vara med och lägga in skisser och annat så att man kan göra så bra grundarbete som möjligt sen för utvecklarna att ta vid. Så jag tycker för personlig del att det är väldigt nyttigt för mig att få vara en del av det och hade nog känt mig lite bortkopplad från det slutgiltiga, det som fortsätter efteråt, efter mitt så kallade arbete.

Jag håller med. Och jag tycker också att design - första skissen, första konceptet, att den första iterationen av designen är egentligen en första förädling av ett krav. Så per definition så måste man ju samarbeta om man vill ha de bästa möjliga funktionella kraven, det vill säga designen på sina funktionella krav, tidigt. Mellan designorganet och den som prioriterar och definierar kraven och bryter ner dem. För gör vi inte det så är risken att vi prioriterar upp krav som är omöjliga att designa.

Så jag skulle vilja säga, tidigt i fasen när ett krav skrivs in i ett Jira eller ett DevOps eller ett annat sånt kravhanteringsverktyg, så bör en designer, en produktägare/kravare, en arkitekt vara med i det första steget och prioritera och definiera det tidigt.

Jag tycker det beror på lite grand på hur stort är projektet? Hur många är vi teamet? Hur lång är en sprint? Hur kritiskt är kravet?

För jag upplever att om vi har en designskiss färdig innan utvecklarna tar vid så brukar de må mycket bättre av det. Vanligtvis, det jag stöter på oftast, det är utvecklare som beklagar sig över att vi gör förändringar sent, så att de måste skriva om kod sent. Och det är ju på både gott och ont. Vi blir ju mer flexibla om det funkar. Så jag förespråkar alltid att det ska funka, att man får det att funka, snarare än att man låser en design jättetidigt och så går det en viss kalendertid innan det tas tag och utvecklas. För där löper vi i stället risken att vår design blir utdaterad och inte så bra som den hade kunnat bli. Så det måste finnas en balans däremellan. Men jag skulle inte säga, eller rekommendera, samma sprint om det inte är absolut nödvändigt för vissa enskilda sistaminutengrejer som alltid kommer in. För har vi samma sprintförändringar så skapar det ganska mycket instabilitet i outputen till teamet och de blir mer osäkra. Det är alltid bra att veta vad du ska göra i alla fall de kommande två eller tre veckorna. Och det bör man ju kunna nå i de allra flesta fall.

Så med andra ord, inte samma dag som det ska utvecklas, men inte heller fyra månder i förväg innan det ska utvecklas.

Den här frågan är ständigt återkommande i regulatoriska sammanhang när vi har datalagring i EU, utanför EU och när det är en hög dataintegritet som behövs. Historiskt sett har jag haft ganska stor framgång genom att bara ringa eller kontakta utvecklaren av det verktyget som jag vill använda, för jag kan inte sitta här och säga att ”använd det här verktyget”. Det kanske inte är rätt verktyg för dig, men har du hittat ett verktyg som är bra, som du vill använda, som du inte är säker på hur dataintegriteten sköts. Skicka ett mejl till dem och ställ frågan precis så du har gjort, att ”jag jobbar på en myndighet i Sverige, jag får inte använda ditt verktyg men jag skulle jättegärna vilja göra det. Kan du hjälpa mig? Eller kan du se till att mitt data lagras på en server inom EU?” Och de flesta har varit ganska tillmötesgående på det.

Jag har tyvärr inte något jätterakt svar på den frågan faktiskt nu så där. Men det finns ju, vet jag, ett företag som heter UXtweak som är baserat i Slovakien, men jag har ingen aning om var deras servrar finns.

Men det kanske finns också andra sätt att dela informationen på, för de flesta verktyg som du använder kan du säkert lagra lokalt i stället för att lagra det på deras server och dela det genom delningstjänster som ni redan använder. Så att du kan få feedback från användare eller skicka ut enkätundersökningar som inte lagras på molnet, utan där du får svaren direkt sammanställda.

Välkommen till livet som designer. Det finns inget good enough i vår hjärna :) Och därför är det också viktigt att man sätter kriterier för det på någonting som är mätbart, som du kan avgöra som inte bara är godtyckligt, som inte är din upplevelse om att ”det här är inte bra nog” eller ”det här måste vi göra om. 

Du blir liksom aldrig färdig. Antingen är pengarna är slut, och det brukar det väl vara liksom. ”Nej, nu kan vi inte designa mer.” Och då är det dåliga förutsättningar. Men helst av allt vill vi komma till att vi bestämmer ”nej, men vi släpper det här, vi designar inte vidare på det för att vi har fått den effekten av den här designen eller den funktionen som vi hade förväntat oss från början.

Sen kan man ha ett huvudmål och delmål på vägen, så en roadmap mot det som är det slutgiltiga målet. Och man får tänka så att, okej, nu har vi en tidsram. Vi behöver ha kommit i mål med vissa av de här sakerna fram till den här tiden. Vi kanske har en helhetslösning så får vi ta ett omtag på det och göra det till nästa iteration beroende på vad man har för projekt. Så man kan bygga upp en roadmap så man kanske får ibland säga att, okej, nu var vi kanske inte helt i mål med det vi ville göra med allt, men vi behöver ändå sätta ett litet nedslag i att vi måste ändå ha någon form utav deadline. Och sen så får vi göra om det och iterera allting en gång till.

Men precis, sätta delmål, för det är lite grann som att säga så här ”jag ska jobba tills jag är rik” utan att säga hur mycket pengar man ska ha tjänat innan man slutar jobba. Du kan ju fortsätta och fortsätta och fortsätta. Det finns ingen bortre gräns för det. Så avgränsa med någonting som ni kan ta på, som ni kan känna att alla tillsammans att ”det här är good enough, det här är vår definition av good enough”. För sannolikheten är att ingen har samma definition av good enough förräns ni har pratat om det.

Det här kommer säkert många tycka ”men gud vad trist”, men jag älskar Swish-appen.

Nej, men alltså allting som har med bankärenden att göra som är alltifrån att bara skanna min pappersfaktura, om man nu, God forbid, får en sån i brevlådan någon gång. Jag tänker bara tillbaka på när jag bar yngre och jag var skyldig dig pengar.

Då fick vi antingen ta ut cash och så fick man sitta och växla med varandra för det var ju aldrig liksom bara en ren hundralapp, utan det var alltid 47 spänn eller något sånt där löjligt. Eller så fick jag be om ditt kontonummer och så fick jag lägga in det med min bankdosa som mottagare. Det var så jobbigt. Eller liksom då levde man ju med det, men när Swish kom …

De har ju också kommit med lite små och nya funktioner. Man kan skicka ett litet giftcard och så lite så här. Jag använder den tjänsten så ofta så den har blivit en sån stor del av min vardag och jag uppskattar den extremt mycket verkligen.

Men jag tror att det här är ju bara tecken på att alla de här iterationerna av vardagliga problem och det jobbet vi som UX-designers till vardags gör, är svinviktigt utan att vi sitter och reflekterar över det. För vi tar rent ut sagt inte så där superstora kliv längre, utan det är små kliv men de tas frekvent, så vi ser liksom inte förändringen.

Ett annat exempel i närtid är när Apple introducerade ”du har glömt dina airpods hemma, åk tillbaka”, det har jag fått ganska mycket hjälp av. Liksom ”ja, just det, de ligger i fel jacka”. Så har man inte lämnat dem hemma och åkt till jobbet utan dem. För det hade jag en benägenhet att göra mycket. Och det dök upp oannonsserat som en sån här ”dina hörlurar lämnades kvar hemma”. Det var ingenting jag nödvändigtvis tänkte på tidigare, utan det var bara en sån här sensationell uppenbar feature som dök upp. Och det var ju bara ett halvår sen eller någonting sånt som den kom.

Pengar. Tid och pengar. Bortsett från dem så upplever jag att vi nöjer oss i designarbetet med magkänslobaserade val. Och det skapar ju ganska dåliga förutsättningar för att vi ska kunna fortsätta. Det blir som vi precis pratade om, när är det bra nog? Jag upplever att vi väldigt ofta för tidigt nöjer oss att det får bara nog, vi måste gå vidare, utan att vi har någonting påtagligt och någonting mätbart att lägga på det. Så det blir lite svårt att säga att ”är det verkligen bra nog?” Det är det oftast inte. Och det sätter ju också en kultur någonstans, att vi accepterar medioker design. Så de förutsättningarna, det är väldigt svårt att vända på det.

Jag upplever också att tycker att förarbetet inte är lika viktigt. Att det är tradition eller ett gammalt sätt att arbeta, just det här med utveckling och man ska knacka kod och det är det som får jobbet gjort. Men jag kan dock känna, och bygga på det du sa nu, att bara ren förståelse kring UX- och designarbete är ju lite bristande.  Just det här med att man får inte tillräckligt mycket tid eller förståelsen att ”jag behöver gå igenom vissa stadier i den här processen för att kunna uppnå ett trovärdigt resultat.

Ja, precis, för jag upplever nog någonstans att världen har nått den första toppen på Dunning-Kruger-kurvan gällande UX. Alla tror att de kan allting när de bara har börjat skrapa på ytan. Och så tar man in en inspirationsföreläsare och så gör man en satsning på ett projekt och så har man lärt sig lite grann, så tillämpar man det överallt. Men du har aldrig brutit ner det på grunden. Du förstår faktiskt inte på djupet vad konsekvenserna är, de negativa konsekvenserna av dåligt arbete. Så mycket av mitt arbete de senaste fyra, fem åren har ju handlat om att verkligen … nästa ta till med hot skulle jag säga. ”Det här är det negativa som kan hända om ni inte tar det här på allvar. Så här illa kan det gå. Man tar beslut som är magkänslobaserade helt enkelt. ”Men vi kan inte, vi har inte råd, vi har inte tid.” Jag köper det, men gör då maximerat det du kan under den perioden eller gör inte för mycket så att allting du gör blir skit. Välj striderna lite bättre. Eller hör med en affärsutvecklande nivå, affärsplanering och UX-strateginivå att göra det. Det finns ju en anledning till varför det är så många som suktar efter den här kompetensen i dag, för de har börjat fatta att det är viktigt men inte riktigt förstått vilka fallgropar man ska utnyttja.

För att dokumentera research, observationer eller intervjuer använder vi ofta Adobe-programmen.

För grupparbeten eller annat så finns digitala whiteboards som Miro eller annat som är rätt bra att ha i ett team.

För att visualisera prototyper eller skissa så gärna antingen Sketch eller Figma.

Men även penna, papper, whiteboards, kommunikation och enkäter fungerar toppen. Det finns ingen anledning att använda avancerade verktyg om det inte behövs.

Det där är ett dubbeleggat svärd. Vad jag anser om att skriva om defaultbeteenden generellt sett är att om det finns en anledning att skriva om ett defaultbeteende, så är anledningen troligtvis att det defaultbeteendet inte är så bra från början. Jag förespråkar aldrig att skriva om någonting utan att ha ett syfte. Så det måste finnas ett syfte. Så vi utgår ifrån att vi har någon situation där ett defaultbeteende i antingen en webbläsare eller en mobiltelefon eller hur infrastrukturer beter sig är bristfälligt och dåligt och det behöver göras bättre, för att vi tror att det att göra det bättre. Att investera i den tiden och energin kommer att ge mer nytta tillbaka än vad det kostar och smakar. Utgår vi från det läget så ser jag inget problem med det. Jag förstår att en utvecklare inte vill göra det eller att det blir stökigt och kanske känns som onödigt arbete, men om vi konstaterar att det inte är onödigt arbete, kör på, gör det, för då blir det oftast bättre för att du har tänkt igenom det. Men att skriva om det bara för att någon har en idé, att ”jag tycker att det vore bättre så här” eller ”det där är inte snyggt”, det finns ju ingen som helst mening med. Ingen affärsmässig vinning på det och det är totalt ogrundat, så då skulle jag nog vilja säga, stå på dig och kräv anledning till varför och med betoning på kräv. Kräv anledning till varför vi ska ändra någonting som används överallt, som är kompatibelt framåt, bakåt, åt alla håll och kanter. Det blir lättare att underhålla. Det blir lättare att supportera på alla sätt så småningom. När det kommer en ny webbläsarfunktion så kommer defaultbeteendet troligtvis funka i nästa version om du kodar därefter. Men en anpassning måste fixas oftast. Så … ja, som sagt, kräv svar på varför. Men var inte helt och hållet emot det när du väl får insikten i att ”okej, det kanske blir bättre om vi skriver om det”.

Och sen så kanske det är beroende på hur stor skillnad det blir på det nya. Ett defaultbeteende är ju säkert någonting som väldigt många är bekanta med också. Så man vill ju kanske inte förändra för mycket så att användaren ska bli helt ”men vänta nu, vad händer nu, det här brukar ju inte hända här”.

Så utgå från vad användarna behöver och utifrån vad affären behöver och kom fram till någonting däremellan.

Förespråkar absolut learning by doing. Men jättebra ifall man har någon med sig som är erfaren, som man alltid kan bolla med. Utbildning versus verklighet, det är inte riktigt samma sak. Så att då är det jätteskönt att med någon, mentor typ, som man kan ta lite rygg på. Jag menar, man är ju supertaggad när man är helt färsk. I alla fall var jag det. ”Nu ska jag ut och jobba. Nu ska jag liksom …” Så. Så att det är viktigt också att man får förtroende där man jobbar, att kunna visa vad man kan.

Och lägga till på det. Det är två saker som jag skulle rekommendera junioirer till att göra alltid. Det första är att aldrig tillåta sig själv att ens tänka, för att inte tala om att uttrycka sig i form av att ”jag har gjort det här i två veckor så nu kan jag det”. Kompetens och kunskap är olika saker. Att kunna applicera kompetens på problem, att veta vilka saker du ska tillämpa, att faktiskt använda det på riktigt, det tar ganska lång tid. Jag har hållit på i över tio års tid. Och jag lär mig nya saker varje dag. När man stänger sig själv i form av att ”jag har gjort en enkätundersökning, jag behöver inte lära mig mer, jag vet hur det funkar”, då har man ju låst in sig själv och låst in sin egen utveckling i någonting som är ganska dåligt. Och det andra i sammanhanget är att förmågan att fråga på rätt sätt. För det finns ju någonting som heter att fråga för mycket också, att vara krävande. Det liksom släcker den här personen eller de här människorna runt omkring som man har, deras vilja att hjälpa till. Så att hitta en bra balans i hur du ställer dina frågor. För frågor måste man ställa. Du måste fortsätta vara frågvis och nyfiken och bara mosa dig igenom alla de här osäkerheterna. Tillåt ingen att säga att ”det där borde du veta” utan att du faktiskt känner att du vet det och har de svaren.  Och en tredje sak som dyker upp i huvudet är nog också att de personerna som man utvecklas med, som är ungefär i samma situation, de är också oftast mer benägna till att besvara frågor eller jobba med varandra. Så har du gamla klasskompisar eller andra juniorer som du jobbar med tillsammans, skapa ett forum där ni regelbundet ställer era frågor till varandra, och tar hjälp av varandra för att lösa problem tillsammans. För det här ”ensam är stark” funkar inte riktigt när man är ny och står inför ganska stora utmaningar. 

Det funkar väl inte ens när man är erfaren.

Nej, men aldrig liksom. Jag har fler erfarenheter av att jag får gå in och lösa problem själv än att jag får gå in och lösa problem med team. Och jag kan sitta här med handen på hjärtat och säga att inte ett enda av de problemen som jag har behövt lösa själv har blivit bra lösta. Så verkligen så här, nej, skapa ett nätverk där du kan ställa frågor, oavsett senioritet och junioritet i nätverket. Så klart är det jättebra att ha sina stöttepelare genom livet, sina coacher, sina absolut bästa gurus och orakel. Skapa en relation med dem där alla typer av frågor är välkomna, att de tar sig tid. 

Det är faktiskt jättebra. Det kan jag verkligen relatera till, det här att man har ett nätverk med vänner eller bara nära bekanta eller … ja, man behöver inte ens känna varandra, men bara så att man kan bolla och lära sig utav varandra. 

Att vara erfaren är inte synonymt med att vara bra, för att världen runt omkring dig ändras. Du var bra på någonting där det var då. Världen runt omkring dig ändrades och du måste också leva med det. Och det är det jag också kommer tillbaka till, att jag har fortfarande inställningen om att jag inte kan saker och därför lär jag mig fortfarande saker. Så vill du fortsätta vara erfaren, vill du fortsätta vara duktigt, bra, expert, grym, då kan du inte stå still för att du kommer att bli omsprungen. Du kommer att ha erfarenhet men den är ouppdaterad. Det är som … Det är jättebra att kunna saker och ha gjort saker och kunna falla tillbaka på att ”vi gjorde på det här sättet då”, men det är inte synonymt med att det är rätt sak att göra nu.

Absolut. Det finns ju hur många olika seminarier man kan gå på, läsa UX-bloggar till exempel med andra smarta människor som skriver om korta ämnen. Jag personligen tycker om att läsa böcker, så jag köper mig gärna någon ny UX-bok när jag ser att det kommer ut någonting spännande, så får jag liksom läsa igenom den och snappa upp någonting nytt. Så att för mig är det … och bara liksom att känna nya kollegor. Man får en ny anställd eller är det ett nytt projekt, alltså redan där att ta sig annan nya uppgifter. Så att jag tror att lite … ja, men ett ständigt sökande. Och det finns rätt mycket att snappa upp runt omkring oss, tycker jag.

Som vanligt med all utveckling, reflektera i form av ”vad gjorde jag? Var det bra? Hur kan jag göra det bättre nästa gång?” Så utvecklar man ju sig själv. Det är inte alltid nödvändigtvis någon annan runt omkring som man ska ta rygg på, utan du får helt enkelt ställa dig bakom dig själv och putta lite.

Och sen är det inte alltid att prata med de som är äldre, men prata med de som är yngre.

För jag menar, de juniora som kommer ut har säkert lärt sig sjukt mycket coola nya metoder eller verktyg eller annat som en själv inte har liksom jobbat med. Ja, men jag är kanske bekväm med mina egna verktyg.