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.

Advertisement
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.

What can we learn from coffee?

I’ve previously been posting a thought about using The Ultimate Question to show the value in quality. The Ultimate Question is “Would you recommend X to a friend”?

I believe that slipping quality might not drive current customers away but prevent customers from recommending a product. For example, changing a financial system is a hazzle, so those annoying errors which you learnt to live with might not make you switch, but when your friend starts a new business you cannot recommend the system.

I just read Wired To Care. It just happened that I found the book on Audible and thought, why not? I thought it would be one of those nonsense books (or rather all sense books) which already says what you know, they state the obvious. But this is far from true when it comes to this book. Filled with real stories and examples, it presents the not so obvious cases.Like with the coffee industry in the USA.

You probably have already heard this if you’re from the US, but for a Swedish gal, this was news.

Coffee was a well tasting, high quality product in the 1950’s. And then a chill fell over the coffee fields in Brazil and the price of high quality beans sky rocketed. So, what to do?

Maxwell learnt that customers were not prepared to pay the new price, so what they found was that if they added a tiny percent of lower quality beans, the customers didn’t know the difference and they could lower prices. Wonderful. But the upcoming year, they wanted to cut prices even more, tested a blend with slightly lowered quality and since the customers didn’t mind, they were on a slippery slope. After many years, Maxwell found that they didn’t get any new customers. The young turned away from coffee. But their customer evaluation showed that the customers liked the blend and were not prepared to pay more.

But then came Starbucks. They realized that the old customers had slowly learnt to cope with the failing quality and they were not prepared to pay more. But the new customers hadn’t learnt to handle the change and were baffled by their parents drinking this vile coffee. They were not prepared to pay little for crap.

Thinking that lowering the quality when the customers accept it is probably a bad idea, but it’s easy to walk that path. To think that they don’t mind? Why bother with that pixel? It probably don’t mean anything for the user if the system becomes a couple of seconds slower. It’s all those many, smart decisions which makes that horrible coffee, while someone else with pride can present a prime product and even charge for it.

Do you use the Spoilt Brat Pattern?

2009/06/15 2 comments

One of the reason for why I started working for TUI Nordic was the view of the customer. Not that the customer’s always right but the customer must feel like he’s right.

All too often do people think that their customer is wrong or should blame himself for not being satisfied. He made the wrong choice, picked the budget alternative and still he has the nerve to complain about it. And when he do complain how many strive at making the customer go away/stop complaining instead of making him content. Sometimes it does not cost you anything. More often than not simple words and explanations can make the customer feel that his issues has been noticed and validated. Yes, you feel that your hotel is too far from the beach and that is why you paid less than the others. Do you want me to check if we can upgrade your reservation? That’s an example of what I mean, instead of making the customer feel stupid you can recognize his problem and find solutions.

And the same goes for development teams. You have a feature developed and when you deliver you find that the customer is not satisfied. In some cases they tell you that you got it all wrong, load and clear. In other cases they don’t use the functions. In both cases there can be frustration that you didn’t understand them but I guess there is also a sense of guilt. Perhaps they helped during specification and testing but it wasn’t until production they realized the problem. So what do you do?

Many turn to the Spoilt Brat Pattern.

Before I got Peter, I used to hate spoilt children. I still hate it, but now I have a better understanding. So, what is a spoilt brat? That’s the kid who gets what he screams about and he’s still not happy. He complains, screams that you got him the wrong one or that he just want something new now.

If you as an adult apply the Spoilt Brat Pattern you turn to the child and say “Hey, you asked for that one. You got it now, so don’t be so spoiled and be happy about what you have. Think about the poor kids in X, they would be thrilled about that one. It’s no fun giving you stuff, because you’re never pleased.”

Spot on, isn’t it. Hm. In software development this would sound like “Hey, we built it like the specification and you did approve to this during testing. Now you have what you wanted. Think about the guys in finance, they have been waiting for their features for a month now. Why should we develop things for you, you’re never pleased with anything.”

Well, yesterday an incident got me thinking. My son Peter really wanted a scooter after testing one at his cousin and a month ago, we went out and got one. I went to a toy store and there it was, blue and Peter approved of it. It wasn’t quite like the one his cousin had but there were no others like that one in the store, so we got this blue one. It looked something like this:

At home, Peter started using the scooter but soon, I realized he wasn’t pleased with it. And he stopped using it. I couldn’t understand why. So, yesterday we started talking about in a store. He saw another scooter and he gloated. So, I asked why he didn’t use his own scooter. This one was just the same, or?

                

But, he finally confessed, you cannot slide with his. Stupid mom as I am I stated that they were the same. No, said Peter. Mine has three wheels, so I can’t slide it when I brake. If I were a better mom I would probably hinder my son from sliding at age four, but instead I realized our mistake. Peter hadn’t understood that the third wheel would hinder him from making that daring stuff he wanted to do and I hadn’t even bothered to learn the difference between the two types of scooters.

If I had played the Spoilt Brat Pattern on Peter, I would have just said that he should be happy about his scooter. But instead I got him the right one instead and gave the other one to another child, whose parents wouldn’t afford one and who won’t do any sliding. Both Peter and I made a mistake by picking out the three-wheeled scooter in the first place and forcing him to use it would be of no good to anyone of us. But, and this is a big but; hadn’t he acknowledged that he himself made the original choice, this story would have had another ending.

So, next time your users are not happy about the features you’ve built, think if you’ve built them the three-wheeled scooter they didn’t really have any use for and try to fix the problem.

Cultural differences on how you perceive web page loading time

One of the things my new (well, I’ve been working for TUI for over four months now…) boss cautioned me was not to listen too much to a single opinion. And this is something he often returns to: not to take for granted that the person with the highest salary or voice knows best or should be the one making the decisions. Having discussed and have had opinions about working in a lean environment for four years, it’s challenging but more important so intellectual stimulating to at last work for a leader who asks the four why’s when you state something. It makes me really evolve and make so much better decisions.

Because we take for granted that our perception and ideas or general to everyone but I cannot cease to be amazed how untrue this is in the most unthinkable situations.

This weekend, I’ve read Global Information Systems: The Implications of Culture for IS Management, a book which include a number of research papers on culture in IS Management. (No, I did not read all papers and the ones I read, I read them as a normal reader and not a researcher.)

There where many interesting articles but the one that really got me thinking was a study about web page loading. I’ve never thought of this before but since the conception of time differs between people and cultures, the web page loading time is perceived differently in different cultures. It’s not like some cultures like slow pages but more that 1 second is perceived so differently. The cultural differences even amazed the scientists who never thought they would find such a strong statistical correlation. Probably because time is such a basic concept in our minds that we cannot for see that it can be different for someone else. So, which of your perceptions do you take for granted are shared by all your clients and users?