Tag Archives: usability

Dyr lärdom från PUST: hur undvika nya IT-fiaskon?

Posted on by

2010-2011 gjorde RPS en bra grej. De byggde ett system (Pust Java) som gjorde polisen mer effektiv. Poliserna fick datorer i sina bilar och kunde direkt registrera brott. Därmed behövde de inte åka in till stationen för att avrapportera lika ofta som med gamla systemet. Systemet var skräddarsytt för att ge hög användarnytta, och projektet blev en framgång. Pust Java blev finalist i CIO awards “project of the year 2011” och DN skrev en helsida “Polisen rapporterar betydligt snabbare med ny metod“. Systemet var inte perfekt, men en bra start. Poliserna sa att det var bättre än vad de hade innan, och folk var optimistiska inför systemets framtid.

Sedan hände något tragiskt. Istället för att vidareutveckla och kontinuerligt förbättra systemet, så valde ledningen att skapa ett nytt system från grunden (Pust Siebel) med undermålig teknik. Det blev ett fiasko. Ursinniga poliser klagade på att en avrapportering kunde ta flera timmar – “Pust Siebel gör en helt frustrerad och på gränsen till vansinnig!” – och saknade det gamla systemet. RPS hamnade i ett mediadrev. En poliskälla uppskattade samhällskostnaden till 10 miljarder kr!

Efter massiv kritik från både media, poliser, skyddsombudsmän och oberoende aktörer med insyn i projektet, beslutade RPS att lägga ner Pust Siebel.  Nu är det allt fler som förespråkar att Pust Java återinförs

Varför spenderar en myndighet hundratals miljoner på att bygga något bra, för att sedan spendera ytterligare hundratals miljoner på att byta ut det mot något dåligt? Ännu värre: varför gör man detta trots att hela IT-avdelningen visste, och högljutt påpekade från början, att det nya systemet skulle bli sämre?

Syftet med denna artikel är att belysa och sprida lärdomarna, så andra företag och myndigheter slipper göra om liknande dyra misstag.

read more »

Designprinciper

Posted on by

Jag läste en artikel om User Experience (användarens upplevelse av en produkt) häromdagen. En person hade kommenterat texten med den väldigt vanliga kommentaren om UX. Han sa att “allt vi behöver göra är att låtsas vara en användare och utvärdera vad vi har byggt ur den synvinkeln”. Detta håller jag tyvärr inte med om. Vi är alltför partiska som produktdesigners och utvecklare, vi känner till för mycket om hur produkten fungerar. Dessutom tillhör vi troligast inte den avsedda målgruppen, vi kommer inte att använda produkten i en faktisk situation för att lösa ett faktiskt behov, så det kommer bli mycket svårt för oss att låtsas tillräckligt.

Men vad vi kan göra är att luta oss tillbaka på forskningsresultat som kan appliceras på de allra flesta människor och därmed de flesta av våra användare. Dessa resultat kallas designprinciper och med deras hjälp kan vi lyfta vår produkt upp till en bättre nivå. Detta är det minsta du kan och bör göra för dina användare. read more »

Modal Windows Considered Harmful

Posted on by

On the Wicket user’s mailing list there was a question about modal windows and it set me off. Since my excellent wisdom 😉 is larger than just modal windows and Wicket, I thought that it would be of interest to all of you, dear readers.

I have discovered that the modal windows that was gone when web applications started to spread, are starting to come back. And they are bad, even if they are not as bad as the goto statement that was accused the same way as I just did: harmful.

A modal window is something that pops up in the face of the user, screaming its importance by not letting the user touch anything else until the modal window had its way.

We have a back office application written in Swing that use modal windows a lot and it is just getting worse by each feature added.

Modal windows are really a last resort and should not be used at all, if you can avoid it. What I have seen is that they tend to grow in functionality over time and suddenly you are faced with the question: "should I put a modal window here, oh, I am already in a modal window".

(Ranting further), modal windows are primarily for non-expert users that need guidance when you wish to be certain that they know the implications of what they do.

There should be nothing but some information and a yes/no question.

If the users are pushing you around demanding modal windows and customer is always right, so what to do? I suggest take a step back and present a complete new style of interaction that would give users a much better flow in the interaction than now.

Having said that on the list, the following question was fired at me.

"Per,
I see what you’re saying and I have a question.
How would you implement (UI concern) a setting page?
What I mean is, suppose I have a page that shows some statistics.
The statistics can be set by the user.
We implemented a link / button that opens up a modal window to select the
statistics.
How would you do it?"

Oh, that is a good one.

You could make it a modal window. After a while that window (I assume) would get to contain more and more settings. Then all of a sudden, the last setting you added will really make statistics take a very long time. Since the user probably can’t foresee that, you wish to confirm that the user have understood the implications. So you need a modal window that … oops … you are already in a modal window.

The first thing is to think about as an alternative is to start with direct manipulation. Is there any way you could change the settings right when you are looking at the statistics?

Typical example is the familiar "click on column heading to sort table on contents of that column".  Consider drag-n-drop objects if that is natural.

Second is to have the modal window inline on the page in panel. After all, selected settings and the result in the same window feels better than switching to another window, modal or not and then back.

But there may not be room for that. Can you split the settings in groups to inline on several places on the page?

Next thing to consider is to have it on another page and here comes another concern in regarding the concept of settings, life cycle. Do all settings have the same life cycle?

Which ones are per request, per session, per user, per application? Side point? Well, it sure controls presentation since settings with different life cycle should not be presented together.

If the selection of statistics is a very separate activity, maybe it should be on separate page before the page that presents the result? Changing settings would be reached by pressing the back button.

These are my thoughts on alternatives to modal windows jungle:

  • Try direct manipulation,
  • Keep selections visible all the time
  • Resort lastly to a separate page
  • Save modal windows for that yes/no confirmation. You will need it eventually.

Thanks for reading!

Usability will cost you money, ignore or score

Posted on by

As a product owner, you should be highly aware that usability will cost you money, regardless if you ignore it or not.

But let us start with the classical observation made by Anna, a product owner. She knows her product well and has observed that users cope with bugs that make the system "unpredictable". When she asks the users what they think, they say it is annoying but "take it for granted". Hum.

I have heard other, similar stories about users coping with ridicolously bad user interfaces. 

My view is that users will stand on their head if they have to, to get their job done. So they cope with it.

This would fine if it were not for another aspect, they make mistakes due to the low usability. Making mistakes, depending on the system, may kill people (e.g. an X-Ray machine, airplane), or just slow users down.

I find it interesting that users not always complain about, or even mention, how awkward the system is. Instead they blame themselves for not remembering that the Return key is different from the Enter key, to take an example.

So, we can’t trust on getting feedback from the users, despite us doing really bad in the usability department. What shall we do, then?

As a product owner, I am responsible for prioritizing the quality attributes of the product.

As an architect,  I am responsible for delivering those qualitites. Well, it is the team that is responsible and their are no architects in Scrum since all they do is sit in ivory towers and philosophise. Not. People have different skills, don’t forget. Oops, a rant.

You have two options,  either ignore or score. If you ignore it, in the worst case people get killed or your product fails to get market acceptance. No business, no money. But if the risks were that high you wouldn’t even consider ignoring it, right?

It is worse when your users belong to the same organisation and there is hardly any comptetion that can kill you. Worst case, people see you as mediocre. Not!

Even then there is money to make. So consider the other option: score.

To score, you have to commit. It will take time, money and focus or you might as well skip it.

However, the bottom line is that if you look, there is money to find from usability. There may be a yearn for more functions but at some point, you have enough functions to satisfy most of your users need. They may have to use paper and pen in some less frequent cases, but most of the time they will do fine with what the system got.

Against that yearn for functions, you should weigh the possibilty of making the users life easier with less mistakes and better flow in their work. They like flow, too, you know.

So start from where you can go. If the mistakes were less than ten percent of today, how much would that increase the value of the product?

To score that value, where do you find the changes that take your product?

I am no expert in the field, but I know that if you could measure how many mistakes users do, that can be great. Also, you could video tape the users in daily action. The third option is to observe a user’s actions when asked to perform a task. Especially good when your homing in on a specific problem area.

So, what will it be – ignore or score?