I recently tuned into the podcast on IT Conversations, hosted by Phil Windley, and featuring David Platt, .NET programmer and author of the new book "Why Software Sucks". In the podcast, Platt adds some new light to problems of user-facing software (as opposed to programmer-facing software). Much of what he has to say has already been covered in Alan Cooper's unforgettable book, "About Face".
So what makes some software suck? Software is supposed to make our lives and jobs easier to accomplish. When software makes it difficult for a user to do things, or forces the user to remember things, or demands that the user do a complex dance with her keyboard and mouse, then that software sucks unequivocally.
But if you visit the computer lab and ask the programmers what makes software suck, they will have a totally different perspective. Code that's hard to read, lack of unit test coverage, tight coupling of objects, redundancy: these are the problems that make software suck.
My opinion is that you can have the most highly refactored code, in all of its object-oriented goodness, and the software can still suck. My fear is that there are many devotees of Martin Fowler and Uncle Bob, who in their own minds believe they are writing great software, but realize only after it has been foisted on the end user that it actually sucks.
When I tried to de-suckify a feature in the web application we recently released, I was often met with fierce resistance from programmers, whereas the business analysts were very open to new ideas on how to make the software more user-friendly. One example was when we were required to build an interface whereby a loan representative could transfer the responsibility for a loan application to another loan rep. In our lingo, this is called "pushing a loan". The original specification required that the end user would enter the name of the receiving loan rep or their office then run a search against the database. I believed that this method would be error-prone and that there ought to be any easier way. I sat down with the business analyst in charge of this new feature and asked her "What do people use this for 90% of the time?" She stated that most often, people would push the loan to someone else within their own loan office. So I asked how she would like it if, when the user first selects the feature, he is presented immediately with a list of the loan reps from his own office, and that this list would precede the search function on the page. The business analyst thought this was an excellent alternative, and she went to draw up the new plans. Back in the development lab, things ran afoul because "everyone knows" that the search function "has" to be the first thing on the page. This was going to "break the convention" of the look and feel of the rest of the web application, and this self-imposed directive should take priority over giving the user what they truly want. Also, this alternative was going to require extra programming that we had not originally planned. I stood my ground on the customer's behalf, and ultimately we all did agree on this alternative presentation of the UI. But this incident illustrates that sometimes even software developers who are in good communication with the end user will fail to have the end-user's best interest as their top priority.
In our development shop, we developers would often lapse into the flawed mentality of "the customer's always right", and I have been just as guilty as others on this. The customer would dictate the requirements and the developers' task was to merely implement whatever they came up with. Occasionally, the customer would ask for something so goofy that we developers would have to put our foot down and everyone would go back to the drawing board. Such are the risks of assigning the responsibility of software design to the customer, in this case the business analysts. The business indeed knows best what the business needs, but is typically not the best choice in deciding how to get there. The developer has the knowledge to create whatever a specification calls for, but his knowledge of the business need is often very shallow. This leaves a disconnect between the customer and the developer. This disconnect was partially alleviated by the agile process we used, during the breakout sessions. These sessions are great at defining the business need at a high level that could be understood by both business analysts and developers. These session are not so good at defining the user interface. And user acceptance is all about the interface.
In Cooper's book, "The Inmates are Running the Asylum", he introduces the concept of the "interaction designer", a person who's job is to define the user interface and overall orchestration for a software project. In software development circles, the "architect" is more like the lead programmer who has view of the entire system as a whole, including database structures, development frameworks, and the code base. Cooper's interaction designer is more like an architect in the real world, and they are not so concerned about the mechanics of making it happen as they are with getting it absolutely right with the customer. Programmers don't necessarily make good interaction designers, because of their intense focus on the "how" of creating software, they lose sight of the "what". The interaction designer is not so concerned that the chosen framework doesn't directly support a certain feature, they are focused on the end product, and have the artistic license to devise the product so that it works intuitively and flawlessly for the end user.
In Platt's interview, he does not acknowledge many of his observations that have already been articulated at length by Cooper. He does offer a few helpful tips for both end users and developers. His tips for developers include:
1) Make sure the project includes a "virgin" - that is, someone who is knowledgeable in software development but comes to the table with a clean slate, unaware of the software currently under development. This fresh perspective will cause new ideas to bloom outside of the box of groupthink that evolves within a development team.
2) Be willing to break with convention. Doing things the way they've always been done is no longer good enough. If you can't find the right GUI widget from your class library, get a better class library or build it yourself.
3) Don't let edge cases complicate the mainstream. Programmers tend to write software that is mathematically correct, when they should be focused on making the actions and decisions most often taken by the end-user the top priority. Platt says that it should be easy for the user to do things that are "good, smart and safe" and difficult for users to do things that are "bad, stupid and dangerous". Platt also demonstrates that it's faster and easier to track a UPS delivery by searching the UPS tracking number in Google than it is in UPS' own web site. In Cooper's "About Face", he makes the absurd analogy of putting the eject button right next to the radio switch in the pilot's cockpit.
4) Instrument the user experience. Today's software allows you to be able to report on the user's experience, so you should monitor how the user uses the software and then use that information to improve the software for the user's actual needs instead of their stated needs. If your software is a web application, the simplest thing you can do is monitor the web server logs, but you can even do more than that.
One of the problems I see with judging software usability is that it relies on subjective experience. There is no one good metric to determine how much a piece of software sucks or doesn't suck. Aesthetic appeal is the first thing that hits the eye, but the lasting impression is the ease of interaction. For instance, my T-Mobile service lets me pay my bill over the phone, and I don't even have to push a single button; its voice commands are intuitive, succinct and accurate, and I have even paid the bill while driving.
I'll have more to say about these issues on future blogs.