This Software Sucks! – Say Users

And the winner of the I wish I wrote that award is Scott Berkun.

You need to read Scott Berkun’s Essay # 46 – Why software sucks (and what to do about it). His content is great, his style is easy and fun, and he has good insights. If his other essays are this good, he’ll go in the same bucket as Joel Spoelsky and Paul Graham for us. You should also know that he has a best selling* book at Amazon, The Art of Project Management. Soon to be on our bookshelf, what about yours?

[*At the time of writing, the sales rank is 1804, which anecdotally translates to about 6 copies a day]

What does a user mean when they say the software sucks?

Berkun provides a translation table for what users really mean:

• This doesn’t do what I need
• I can’t figure out how to do what I need
• This is unnecessarily frustrating and complex
• This breaks all the time
• It’s so ugly I want to vomit just so I have something prettier to look at
• It doesn’t map to my understanding of the universe
• I’m thinking about the tool, instead of my work

Our thoughts on how to prevent each form of suckitude

As Berkun points out, we don’t set out to write bad software. Here’s how we can avoid some of the different mistakes.

This doesn’t do what I need

Requirements elicitation is a lot more than asking users what they want. The apocryphal Henry Ford quote touches a nerve.

If I had asked people what they wanted, they would have said ‘faster horses’.

As the enthiosys blog points out, Henry Ford would have certainly followed up that feedback with the question ‘Why?‘. We’ve written tips on gathering requirements, and gone into interviewing and brainstorming in additional detail. Eliciting the right requirements is the first step towards preventing this problem. Elicitation is more than just asking people what they want.
When gathering requirements, it’s important to first understand what the problems or opportunities are, and then transform those market requirements into product requirements by determining which problems to solve with software, and which to solve in other ways. Once we identify those problems, we have to prioritize them, and in the first release of the software, make sure we implement the most important requirements first.

I can’t figure out how to do what I need

and

This is unnecessarily frustrating and complex too

These are two sides of the same coin.

We talk about Kathy Sierra’s Kick-ass curve in our post, Getting past the suck threshold. Users are below the suck threshold until they develop competence and then mastery with the software. The amount of time it takes to cross the threshold is proportional to the suckiness of the software. Berkun points out that the value and cost of the software also play a factor in the investment users are willing to make. The grace period people will give to software is a function of how often they plan to use it, and how much time or money using it will save them.

Photoshop has a very high threshold, but is incredibly valuable to people who use it regularly. Watch out Adobe if someone figures out how to package that much power with a lower suck threshold. Gimp is trying, but not there yet. Paint.NET has a much shorter (steeper?) learning curve, but also far fewer capabilities.

We point ourselves in the right direction by making sure that we capture use cases both for novice and expert users. This helps when writing the functional requirements to support the use cases. It allows us to make concious decisions about which features to prioritize highest. If our novice users stop using the software before they cross the threshold, where do we get our expert users?

This breaks all the time

Wow, ok. Buggy software is bad. Crashing buggy software that causes us to lose our work is worse. Don’t even talk to us about software that causes other programs to fail, or corrupts the system.

Testing as an integrated part of the software development process is critical to preventing the release of bugs into the field. We have an introduction to a series of posts on software testing. In short, we should automate our testing, incorporate it into the development process, and establish a team criteria of always maintaining release-ready software. Check out our other posts in the software testing category to see where improvements are possible and valuable.

It’s so ugly I want to vomit just so I have something prettier to look at

and

It doesn’t map to my understanding of the universe
Harsh. True.

What’s the worst phrase to say to a UX specialist? “Sex it up a bit.” Although we do UI design work, and study it as much as we can, we would point you to some of the real experts for great insight. Check out the User Experience (UX) section in our sidebar for links to the best folks we know who are writing about this today. There are also some good book references in Berkun’s post (we already own 2 of the 6 – hooray! us).

Information architecture (IA) is a galaxy in the UX universe. IA is all about structuring and presenting information in a way that is intuitive, navigable, absorbable and comforting. Not ‘beige walls are soothing’ comforting – think ‘opposite of stressful’. One of the biggest mistakes developers tend to make when creating user interfaces is exposing the internal representation of data to the user.

It makes perfect sense – the developers have to think about the internal representation and schema – they write it, rewrite it, optimize it. It makes perfect sense to the developers. The users think in their own domain. We have to design interfaces for those users, and present information in their frame of reference.

Why would a user interface require me to enter my first and last names into separate fields? I think of my name as “Scott Sehlhorst”, with one space and two haches. It doesn’t take a lot of work to parse that into two names for the software to manage under the hood.

Different (software) mp3 players force us to think about our music libraries in different ways. They may force us to use their taxonomy for grouping of music, or require us to know which folders on the hard drive hold our songs. Some days we want to listen to “Jazz something, let me see what looks good” and some days we’re useless until we hear Hendrix’s Star Spangled Banner. Good IA will make it intuitive for us.

I’m thinking about the tool, instead of my work

This one is another manifestation of the I can’t figure out how to do what I need example. “I’m spending so much time trying to understand this software that I can’t get anything done” is slightly less bad than “I don’t understand this – I quit.” But it’s the same fundamental problem (and solution) – just manifesting in a different suck-factor.

Conclusion

Even if we do all of this stuff right, we can’t assure that the software won’t suck any more than we can assure innovation. But if we do it wrong, our software will suck.