Unfortunately, most organisations don’t have 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 have to work with -- don’t we?
Well, we should. It’s been rammed down our throats enough for the past 15 years or so and it makes good sense, so we should all know what to do. So why aren’t we doing it? The number of projects I’ve seen over the last couple of years where nobody has included the user in the project just horrifies me. The excuses are all bloody stupid too, and none of them are even close to assuaging the huge risk that is the result of not doing so.
Repeat (in a whiney voice) “But our customers are the marketing department”, or “Of course we know what they need, we’ve spoken to their managers” or, my favourite, “We have too many different types of user, and it’d cost too much to get them all up here”.
Let me just repeat, for the hard of hearing or the terminally stupid, if your end user isn’t part of the development project, then you’re doomed to failure. Don’t sit there wingeing, trying to tell me 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 although you may not realise it, it’s the important half.
Of course, it is possible to create successful software without ever having spoken to the user -- but it’s extremely unlikely.
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 favourites. They also allow the users to design the workflow and any other relevant aspect.
Whilst there are a lot of arguments that can be levelled against Constantine’s approach, most of them can be resolved through the use of this approach as a "process pattern" – a useful technique that can be overlaid on any process, be it RUP, XP or RAD.
If you try to fit UCD into the waterfall method, however, 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 after all, and that is 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?
Of course it’s both, and because of that it’s doubly useful. Constantine’s idea is that this should provide the core of the development process, and he has had great success with this approach in the US, and there are even adherents here in New Zealand (I’ve worked with some of them).
I don’t think UCD is powerful enough to drive a lot of development projects. But, if you’re writing an application that’s user-centric, you should have a good look at it – there are plenty of references on the web.
Even if you’re not creating a user-centric application, you should consider getting the users involved. Most systems have users, even if they’re not the primary driver, therefore most development projects require their input and will be enriched by it.
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 okay. You’ll 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.
As for me, I hope to interest please a few readers -- and myself, of course.