t’s daunting to come up with a topic of interest to a large group of readers?and then to write about it well. I know it’s impossible to please everyone, but still, when I write, I do my best to be interesting and relevant to as many people as possible. Unfortunately, most organizations don’t take the same view when it comes to specifying software.
We all know how important it is to get the user involved in the design of the software they will eventually use. We all agree on that point, right? After all, it’s been rammed down our throats over and over for the past 15 years or so. And besides that, it makes good sense. So why aren’t we doing it?
When I stop to tally the number of projects I’ve seen over the last couple of years where nobody has included the user in the project, I am horrified. The excuses are all bloody stupid, and none of them even come close to assuaging the huge risk of not doing so.
Repeat (in a whiny voice): “But our customers are the marketing department,” or “Of course we know what they need?we’ve spoken to their managers” or, my favorite, “We have too many different types of users, and it’d cost too much to get them all up here.”
Let me state the equation simply: If your end user isn’t part of the development project, then you’re doomed to failure. Don’t whine and try to tell yourself that you delivered your software for an unknown user and therefore the project was successful. Writing software is only half the battle; writing useful software that provides positive returns on investment is the other half. And though it may not seem so to you, in the big picture, the latter half is the important one.
Of course, it is possible to create successful software without ever having spoken to the user?but it’s extremely unlikely.
User-centric Design
Development authority Larry Constantine pushes a technique called user-centric design (UCD), in which user interface designers work closely with the users designing many prototypes for each screen, allowing the users to choose their favorites. End users can design the workflow and any other relevant aspect of the application.
There are a lot of arguments that can be leveled against Constantine’s approach. If you try to fit UCD into the waterfall programming process, you’ll immediately notice some issues. First of all, what is UCD? Is it design, as the name suggests? Possibly it is designing the user interface, which is then being used to drive the design of the rest of the system. But it’s also a way to gather requirements, as the user is telling us what they want to see in the system, and we’re using that information to drive the rest of the process. So, what is it?design or requirements?
The answer, of course, is that it’s both, and because of that it’s doubly useful. Constantine’s idea is that user feedback and interaction should be the core of the development process, and he has had great success with this approach in the U.S. There are even adherents where I live in New Zealand (I’ve worked with some of them).
Think of UCD not as a step in the waterfall but as a “process pattern.” According to Scott Ambler, author of two books on process patterns (and several others on agile programming techniques), “a process pattern is a pattern which describes a proven, successful approach and/or series of actions for developing software.” Process patterns can be overlaid on any process, be it the Rational Unified Process, Extreme Programming, or RAD.
I don’t think UCD is powerful enough to drive all classes of development project. But, if you’re writing an application that’s user-centric, you should investigate the philosophy a little further?there are many references on the Web and you’re bound to create a more usable application having studied it.
The important point that I want to make about UCD is its central tenet: You must talk to users and listen to what they have to say; they must have input. Even if you’re not creating a user-centric application, you need to identify the users of the application and get them involved. If the “users” are not people but other processes, try to find the authors of those processes and ask them what they need from your software. Users aren’t always human, but it’s your job to find them?whoever or whatever they are?and find out what they really need. Most systems (if not all) have users, and even if they’re not the primary driver, their input will enrich the results of the project.
When you start talking to your customers you will discover that they all have different views of what your system should be and what it should look like. Their views will be messy, inconsistent, and confusing. But that’s human, and it’s OK. You’ll sort it out, survive, and have a better system at the end of it.
You won’t be able to please everyone, but at least you’ll know that you’re going to please someone.
