Archive

Archive for the ‘Usability’ Category

A clear objective is no silver bullet

I’ve many times, as so many others, stressed the importance of clear and shared objectives, but is that enough?

Just because you and everyone else know the objective does not mean you share the same view on how you measure if the objective has been reached and what is key to reach the objective. I believe that the measurement and and the main road is as important. The high focus on just setting the objective(s) is simply not enough. If the group does not share the same view on how success is measured and what is important in order to reach the objectives, I believe there will not be a factual common objective within that group.

Categories: Agile, planning, Usability Tags:

Usability test in a non lab environment?

2010/06/09 1 comment

There are so many ways you can test usability and perform usability studies. I guess there is no final solution to how you should test your system: you probably need many tools and many types of studies but last week, we tested a study outside the lab environment.

A good thing about AB-testing and tools which record users while using the system is that you don’t test stuff in a lab environment. Normally, when you interview users you set up a meeting, invite them to a silent room and turn off the phones. The user can then test the system without being disturbed from the outside. But this is not how he will use the system. Then, the phones will be ringing and the deadline has been missed. This is when you see the tripple clicks.

With automated systems, you can see the more realistic usage but then you miss out on the face to face communication in the study. You cannot ask for details and sense the feelings from the participants.

So, in an effort to combine these types of studies, we performed a usability study in the environment in which our users reside. In a home, with kids running around. This will not be the sole test but will be one part of our usability studies.

But does the situation matter? Of course it does! As Dan Ariely found in this study, we make different choices and hold different values depending on the situation.

Categories: Usability

Creating a mindmap specification

2010/04/30 3 comments

In one of my projects, one of the lead developers asked me for a flow chart, describing the things we’re building. Far from the scrum product backlog, yes, but I decided to give it a try.

I downloaded XMind, a free software with a PRO version with really useful functions, but since I’m just testing the concept as a product owner, I decided to test the free version.

The result, many hours later, is a number of connected flow charts which all looks something like this:

flowchart

I started with setting up the basic flow chart, and identified the main steps. All these main steps were given their own page in the workflow workbook and then I started drilling down. I looked at all steps and identified which functions I wanted to be available from that step and if there were any special scenarios. To help me out, I have the work from our user interface designer, so all I had to do was translate his work into this flowchart and identify these special scenarios. Well, “all I had to do” is perhaps to simplify the task. I will not hide that it was hard and sometimes gruesome work. For each step I covered, I identified more special cases which I need to find solutions for.

But after a while I got to really like this approach. I focused on one step at the time. Took a good look at that step and tried to think about if I’d really seen all the ways to which one could come to that step and I tried so see which steps were possible from there. The nice little note functionality made it possible to add all those special scenarios and questions.

In a couple of hours I had documented all those discussions we’d had in the project group and I would say that what we have is a number of user stories, but in another format. I can better see the links between stories, and it’s easier to track what the story applies to, without having to write too many X:s under “As a X” if I’d used the user story format.

Also, the diagram does something that user story cards don’t: it puts the story in a context. Yes, a user story does say why we do the story, but it does not show what happens next and what we take for granted has happened before.

So, what about the output? There is a HTML export function which exports not only the image but also the comments and pictures.

WHat about the next step? the next step is to see if the developers like it or not. And if they do, we have to find a way to build using this. But the first step is to see if this is the way to go. What do you think?

Categories: Agile, Modelling, planning, scrum, Usability Tags:

The non responsive UI – a nightmare for users and testers

If there is something I cannot tolerate as a computer, it’s a non responsive UI.

I’m currently updating my IPod music list and I’m so disappointed with Apple that they still haven’t fixed the responsiveness of the UI. If I click a song in the list, it takes seconds before ITunes starts playing the new song.

My least favorite program is in a class of itself, as always. When I select an e-mail in the Inbox it can take many long seconds before the right message is displayed in the preview. This has sometimes resulted in missed information and always a lot of frustration.

As a tester, the non responsive UI is also a big problem. I click something. Nothing happens. So, I click again. Something happens. Is that because I clicked once or twice?

When you’re buying new software for your staff, don’t be satisfied with a PowerPoint presentation, test the UI yourself. And that does not mean the salesperson showing what he wants to show with the data he wants to display. If you have a product list with 100.000 products, make sure you test the search functionality with that data. And make sure that you are handling the computer. Salespeople know their software, know where the loopholes are. But he won’t be there when the guys can’t complete their tasks because the software is malfunctioning.

We can all blame the software industry for sloppy work in this area but as long as the people buying the stuff does not demand this as much as they demand functions which they rarely use, why should things improve?

Categories: Business, testing, Usability

The scared user

2009/09/05 6 comments

We’ve all met them, talked to them, tried soothing them. We’ve ducked their phone calls. I’m talking about the scared computer users. The ones who calls you up directly when they don’t know how to do something with the computer, since “you work with computers”. And you think that well, you don’t know anything about Excel formatting and Word printing just even if you work at the IT department. You just want them to try finding out things themselves and wonder why they can’t google stuff or access the online help.

Morten Nielsen describes an example of Computer anxiety on his blog and David Kramer include on his blog a process diagram for self-help for the group.

As a product owner, I often have a persona matching the person who won’t try an alternative by chance or if she does and things don’t turn out as planned never remember what she did. I give her a name and when we discuss UI I ask the guys about her reaction to the functionality.

“Yes, I know that most users know how to select File—>Print, but what about Berit?”

Another persona I use is the first line support guy. The one who gets to answer these questions at the service desk over and over again. Think about the number of users who will call your first line support about a functionality and what each call costs. Not only in time spent by the service desk but also in the health of the service desk folks. 

“What about David, how many extra calls do you think he will get about this and how is he going to explain this?”

If you’re annoyed by your mother calling YET another time about those columns in Word, think about the service desk getting these calls all the time. And not just from your mother but all those scared moms out there.

Categories: Agile, Usability

What controls your decisions?

2009/08/25 2 comments

Dan Ariely with his research makes me wonder a lot about the rationality of decisions. To be frank, he’s made me think that there is nothing like a rational decision.

 

Look at these offerings from The Economist. This is an offering Dan found a couple of years ago, and of course the middle options doesn’t seem to be a well thought idea. Now, The Economist made this add by mistake, but it might not be as stupid as one thinks, especially when the offering is made to people, trying to be rational.

image

Dan asked a number of people what they would choose and what he found was that when people were given these options, non chose the middle option, 84% took the last alternative and 16% took the first option.

But here comes the strangeness of the human mind. If a group was presented just the first and the last option, the third option just attracted 32% while 68% chose the first option. You exclude an option that no one wants and that change how people view the offerings differently.

This should have huge implications on usability. I guess we all know that people are not rational, but remembering that when you specify the alternatives of that dialog box is sometimes not easy. Do listen to the whole presentation and you’ll hear the full story. And thanks to Dan Ariely for again pulling away the blindfolds.

Categories: Business, Usability

Business value of the boring stuff

2009/08/17 1 comment

This weekend, our vacuum cleaner broke down. We both looked devastated on the thing. Not so much for the money (which of course is boring to spend) but for the knowledge that we now would have to spend a lot of time buying a new one.

First, I tried to make an educated, good decision and scanned different communities and sites for the most recommended and best value. But I soon lost interest and found myself surfing on more interesting stuff. That is most things in the universe. I tried looking at one of those cleaning robots but realized that with two floors, one dog and a boy into Lego, this would probably cause more time spent than our gain.

So, I just gave up and went to the store. I went to one of those malls where are multiple stores to choose from, but realized when I got there that it wasn’t worth my time shopping around. So, I picked a store and went inside.

There are an silly amount of options out there, folks. One brand can have five or six different models in your average store. People went around there, testing the things. I just stared. How could I possibly choose?

And then I nearly fell into the trap that most product owners do when they prioritize. They think that something is boring so they go for the cheapest option out there. I almost picked the cheapest one when I realized, Hey, I hate cleaning. Why should I have the worst possible tool when I do the stuff I hate the most? Won’t that make me hate it even more?

The same goes for product owners. They probably don’t think upgrades, logging, error handling and installation features are the stuff of their dreams, so they try to get this as cheap as possible. And then they complain when bugs go unnoticed for months. When regression testing is a hassle, when upgrades takes forever and roll back is not possible.

I didn’t pick the most expensive vacuum cleaners. I took one in the upper level without a bag. I don’t like shopping those bags either. Since I don’t even know the model I’m using, I’m stuck trying to find that just to know that the specific bags are not available then. And they cost a lot of money. With a Golden Retriever you tend to spend a lot of bags.

Well at home, I found that the new thingy made it easier to clean at home. And having a remote in the handle is really a good thing. The dog hair is handled much better and one of the rugs are clean for the first time in five years. Well, I thought it was kind of clean before but now I know.

And one thing more, skipping the bag means that I can see all the stuff I vacuum. No more hiding of dirt. And that is also important in software development. Never hide your garbage for your in house staff. Better that they know about it and help with the cleaning.