The biggest lie in software development is phase 2 

Jag tror att första gången jag hörde citatet i titeln var det antingen Jeff Patton eller Jeff Gothelf som yppade det, men det är säkerligen äldre än så.

Jag har egentligen endast jobbat i ett regelrätt vattenfallsprojekt (dvs. hårt strukturerad produktframtagning uppdelad i diskreta enheter) så jag har svårt att uttala mig om hur produktledningsspelet såg ut före den agila rörelsen klev in på banan. Baserat på min lilla erfarenhet, en massa läroböcker samt vetskapen att de flesta tog Winston Royce beskrivning av en trasig modell som en rekommendation, så tänker jag mig att förbättringsarbete pågick inom varje versionsarbete och man lade till funktionalitet för varje funktion. Det som förbättrades var att man eliminerade buggar. Jag tror att fas 2 verkligen fanns, om än bristfälligt.

När bl.a. Agile äntrar banan, en massa år efter Royce essä, ligger fokus på att få till en kontinuerlig feedbackcykel med så kort tid mellan varje steg som möjligt. Detta ger upphov till att det faktiskt kan och får ske förbättring även mellan versioner. Man får en möjlighet att ha en mer kreativ och utforskande process där det är helt okej (nåja) att sikta fel i första versionen för att det går att sikta mer rätt i efterföljande versioner. Man brukar säga att man inte tänkte på UX när det agila manifestet togs fram, men man möjliggjorde ett tätare samarbete mellan designavdelningen och utvecklingsavdelningen som var få förunnat innan dess.

Jag hittade ett par bilder på Internet, som jag inte vet var de kommer ifrån. Den första illustrerar varför man bör iterera.

iteration

Men ett antal år senare försvinner fas 2. När de gamla projektledarna inser att de med agil metodik (inte nödvändigtvis med agilt tänk) kan snabbare leverera funktionalitet, blir utvecklingen rent inkrementell. Man bygger på det man tidigare gjort och kallar det förbättring, fastän man egentligen inte rör redan färdigbyggda funktioner om de inte är uppenbart funktionellt trasiga. Om de inte matchar målgruppen eller marknaden, well, då lägger man till fler funktioner för att råda bot på det problemet. Ju snabbare man jobbar i kortare och kortare sprintar, desto mindre hinns det med någon typ av iterativt arbete varken under tiden eller mellan versioner. Man tappar fullkomligt den egentliga styrningen och kreativiteten.

Den andra bilden visar var bristen ligger i det som vanligtvis går under namnet agile, men definitivt inte är det.

AndersRamsays

Här råder en stor frustration och ilska mellan designers och utvecklare.

Här är vi idag.

Eller rättare sagt igår, för med Lean Startup-metodik i allmänhet och LeanUX i synnerhet, har vi fått ett verktyg som mer matchar agilisternas gamla slagdänga om iterativ och inkrementell utveckling.

Nu gäller det bara att vi lär de gamla projektledarna detta också.

  

Service design vs. User experience

Jag har den senaste tiden läst en mängd blogginlägg som målar upp Service design och User experience design som motparter i någon form av krig. Jag ser dem som kompletterande.

Service design har ett holistiskt angreppssätt, det innebär att man inte bryr sig om vilken typ av gränssnitt man behandlar. Människa – maskin, människa – omgivning, människa – människa, det är helt egalt för en service designer. Inom Service design har man metoder för att dels förstå människors behov och dels strategiskt definiera vad som behöver göras för att förbättra upplevelsen.

User experience design har ett mer snävt angreppsätt. Man fokuserar nästan uteslutande på gränssnittet mellan människor och maskiner, och idag betyder det att det i de allra flesta fall är människans möte med internetbaserade tjänster och applikationer. Inom User experience design har man metoder för att dels förstå människors behov (ex. användarstudier), dels strategiskt definiera vad som behöver göras för att förbättra upplevelsen (ex. effektkartläggning och upplevelsekartläggning) och dels skapa den nya upplevelsen (ex. interaktionsdesign).

sdvsux

Service design har en del sköna insiktsmetoder som User experience designers kan lära av. User experience design har en hel del framställningsmetoder (ex. prototyping) som service designers kan lära av. Service design lider av bristen att inte ta en produkt från idé till färdigt skick och User experience design lider av att inte se helheten.

Hur dessa ämnen kan vara något annat än kompletterande har jag svårt att förstå, om man inte tolkar Service design som bara applicerbart på kundtjänst eller User experience design som bara design utan användarmöten …

  

5 tips för bäst långsiktig användarupplevelse

Det är egentligen inte så mycket som man behöver komma ihåg som UX:are för att göra ett bra jobb. Enligt mig är det endast de här fem punkterna. 😉

  • Träffa riktiga användare. Jeffrey Liker säger, i boken The Toyota Way: ”In my Toyota interviews, when I asked what distinguishes the Toyota Way from other management approaches, the most common first response was genchi gembutsu [go and see] […] You cannot be sure you really understand any part of any business problem unless you go and see fo yourself firsthand.” Det här torde vara en självklarhet för en UX:are, men vi tenderar att slå på stort och göra kostsamma användarstudier samt inte så ofta. Mitt förslag är att bestämma en dag varje vecka som man ser till att träffa användare på. Detta även fast man kanske inte har något specifikt att ta reda på, det är värt att bara sitta ner och småprata en stund. Gör inte en stor grej av det, gör det normalt.
  • Sluta leverera leverabler, leverera värde. Användarstudier och interaktionsdesign som kontinuerligt kommuniceras till team och kunder ger mycket mer värde än en detaljerad wireframe i ett worddokument. Följ Build-Measure-Learn-loopen från Lean Startup kontinuerligt för att alltid vara säker på att du är på rätt spår istället för bara verifiera med team/kunder och validera med användare när produkten är ”klar”. Du bör alltid se din produkt som en hypotes som behöver valideras så fort som möjligt för att minimera slöseri med tid och resurser. Att bygga en Minimum Viable Product som sedan kan slängas om man inser att man bygger på fel produkt, det är vad som ger förståelse och hjälper till att sikta rätt i nästa iteration. Som Eric Ries argumenterar: ”Success is not delivering a feature; success is learning how to solve the customer’s problem”.
  • Släpp sargen och skissa bums. Vi strävar efter så korta feedbackloopar som möjligt. Ju snabbare idéer visualiseras desto fortare får du feedback. Så, använd penna och papper. Håll dig borta ifrån trögjobbade Adobe-produkter. Eller som agila manifestet säger, ”Enkelhet – konsten att maximera mängden arbete som inte görs – är grundläggande.” Försök att alltid vara transparent gentemot din omgivning. Sätt kontinuerligt dina skisser på en vägg så kan du lättare få feedback. Isen är hal, men du kan göra det!
  • Samarbeta, samarbeta, samarbeta!!! Skapa möjligheter till samarbete överallt och hela tiden. Även fast det kanske inte känns så, så kommer detta göra dig snabbare och låta dig gå djupare på designen, samtidigt. Våga riva väggarna till din silo. Att pardesigna med utvecklare, att ta med dem och produktägaren på användarstudier, att involvera hela teamet i en design studio-session, m.m. Möjligheterna är många och de ger alltid mervärde.
  • Förbättra kontinuerligt. För att veta att vi alltid gör rätt sak, så måste vi kontinerligt kämpa, både för en bra process (exempelvis att se till att träffa användare frekvent) och för en bra design. Vi måste hela tiden utvärdera vad vi gör och anpassa oss. Vårt verktyg för detta kan vara att ha ett process-retrospektiv varje vecka (och agera på problem som dyker upp där). Som UX:are har vi en stor verktygslåda, men varje verktyg måste anpassas och slipas för att vara optimalt.

Se, det var väl inte så svårt. Nu är det din tur.

  

Behövs vi UXare?

Jadå, vi behövs, det är utan tvekan. Det är få IT-system, produkter eller tjänster som inte gör användarna frustrerade. Men förstår företagen det? Ibland känns det verkligen inte så.

Dataföreningens tidning Framtid & Karriär har gjort en behovsanalys ur företagens synvinkel och det ser ju lovande ut. :)

  

5 användare borde vara tillräckligt för alla

Den där grafen ni vet, som Jakob Nielsen kläckte ur sig runt 1993, om att 5 användare är tillräckligt många att testa med. Den stämmer ganska bra, tycker jag. :)

fem

Jag börjar få ganska många års erfarenhet av användningstestning och om målgruppen är hyggligt homogen så börjar jag efter 3 test se samma problem dyka upp. När jag är uppe i 6-7 test så är det helt klart så att jag har fått mycket bra koll på läget. Det blir också tydligt då om målgruppen faktiskt är heterogen och vilka undergrupperingar det rör sig om. Efter 4-5 möten med användare i en subgrupp så vet jag om den gruppen är homogen.

Det är faktiskt ganska coolt.

  

Användarstudier med barn

Jag har inte haft en blogg sedan urminnestider, närmare bestämt sedan september 2008. I den här bloggen kommer jag att behandla agilt och ux, både högt och lågt. Det blir nog mest lågt, korta kommentarer, länkar och tips. Men jag tänkte börja högt, genom att återpublicera det sista blogginlägget i förra bloggen. Då körde jag på engelska, så ni får stå ut. Det här handlar om lillgamla barn.

Martin


A common way of separating users with the intent of forming different target groups for usability testing is to use age as a variable. The problem is that this is of course a tricky variable to use. Usually, we aim to define end-user populations as homogeneously as possible, since it is then easier to do user testing and optimize user interface design. This approach is good as long as the product is intended for professional use, by users who are between 18 and 50 years old. This approach was good enough twenty years ago when most computer programs had that target group. Today the situation has changed. Target user populations have become heterogeneous, with people of all ages using computers more or less on a daily basis and more or less successfully. Two outliers in this distribution are children and the elderly. Digital natives are a large user group and the computer literates has become twenty years older as well.

During these two periods, adolescence and senescence, the changes on a cognitive level and the differences between individuals are great. The former period we call development and the latter, for lack of a better word, decline. For example, you have probably heard about both precocious kids and late bloomers. A uniform age group is not applicable, hence it is important to have usability professionals taking a deeper look at user group compositions when developing for the youngsters and elder people of today.

I once carried out several projects involving both these outliers and became very intrigued by developmental psychology, especially the parts focusing on children. This article will focus on the theories behind and will try to give you some heads-up before you conduct usability testing with children.


© MrsGooding

One theory of cognitive development of children, which seems to be the most common, is the one of Jean Piaget. He divides childhood into four development stages; sensori-motor period (infants), preoperational period (2-7 years), concrete operational stage (7-11 years) and formal operational stage (11 years and up). Although the timing may vary, the sequence of the stages does not, thus this theory is a good base for differentiating target groups of children. The characteristics of the preoperational period is a development of an inner representation of external objects. The thought processes of the child are then linked to the most prominent features of an object or a situation. The concrete operational stage is characterised by logical and purposive thinking, although the operations are always connected to the actual situation. In the formal operational period the children disengage from the concrete situation and become able to perform systematic analysis on an abstract level.

Apart from standard interview techniques such as commencing the interview with smalltalk, there are some issues to take into consideration when interviewing children that I learned during the aforementioned projects. One such thing is considering the attention span of the child. A session with young children demands a flexible setup of the evaluation. The child should be able to explore the product almost on their own instead of following a set of tasks. They are often motivated by making adults happy, hence let them show what they have found in the product and increase their motivation by encouraging them. For example, say ”Wow, did you do all that by yourself?” or ”Is that how it works! Thank you for telling me!”. Furthermore, avoid placing the child in front of the interviewer, place the child in front of the product with the interviewer acting as support on the side. In one of the projects, four male interviewers in their early twenties sat down in front of an eight-year-old girl and were surprised when she didn’t want to cooperate in the evaluation. Apart from steering clear of these kinds of situations, it is a good idea to have younger children evaluating in pairs where they can encourage each other and share ideas. It is also easier for them to speak about the product with a peer than with an adult.

This shyness towards adults is most visible in the preoperational stage. Hence, children in this stage can also have problems with expressing their feelings for the product in words, especially in front of a grown-up. Observe their behaviour, sighs, smiles or if they simply disappear under the table (which occured a lot with some children). Also, try to avoid asking the children if they wish to play a game or perform a task as this will give them the option to say no. Instead, say ”Now, I would want you to…” or ”It is time that we…”. This is easier to do with children in the concrete operational stage.

Children in the concrete operational stage have a high tolerance for complex interfaces. They employ pattern-based problem solving, ”push twice on the left button and three times on the right button to reach the gold” comes natural as long as it benefits them. They are starting to understand how to critically review the task given to them. They will be able to answer questions regarding the task and try new approaches with joy, but they are very aware that they are being observed. The previously mentioned eight-year-old asked the interviewers, in a latter session, why they wanted her and not her sister to evaluate the product. When the session ended it seemed as if she only criticised the method and did not care about the product. Later on, her teacher collected some drawings of hers containing references to the product and it was accompanied with a sun and a couple of green trees. Some children would like to answer questions orally and other in writing, but remember not to neglect those who want to express themselves with pictures.

In the formal operational stage, children might be able to think aloud while they are performing a task. However, what has to be taken into consideration is that these pre-teens or teens are not geniuses that can adapt to every complex situation. The possibly bad performance of the teens are caused by mainly three factors; inadequate ability to read, bad research strategies and a relatively low level of patience. There are simply a lot of other things happening in their world at that particular moment that we unfortunately have to contemplate.

On the other hand, most children tend to be smarter than you would give them credit for. One eleven-year-old girl demonstrated her own Klik & Play-made programs to the interviewer and explained how she could make the product in question smarter. The outcome was, needless to say, very appreciated by both parties. Children understand the concept of usability. Most children in the two operational stages can spot the difference between fun and efficient. They are as motivated by reaching their goals as adults are, and they really do not like when a product is not working.


I början av 2014 höll jag en presentation om mina erfarenheter med användarstudier med barn. Här är mina slides, håll tillgodo.