All too often, the iterative process for user experience design conflicts with the typical process followed in IT groups. This has lead many IT groups to ignore the user experience process altogether (or at least parts of it). Some in our industry have blamed the development processes themselves, noting that they contain little or no user experience design phases or steps. So the question remains if the development process itself cannot change, how should user experience design be included?

Before I get into the meat of my recommendations, let’s take a very simplified look at the major differences between the most common development methodologies.

First off, let’s take a look at RUP. Long thought of as the de facto software process (indeed its taught in universities everywhere), Rational relies on the notion of usecases based off of some sort of requirements list. These are then broken down and analyzed to the level of detail required to estimate and plan the project. In other words, document everything and then build – oh, and document along the way, too. Indeed this process is based on documentation. In fact, RUP is really a project-management centered process.

As a counter-example, we have Agile. I’ll admit that I don’t have as much exposure to Agile in any serious way, as virtually none of our clients use it. The best thing I can say about Agile (and others like it, e.g. Scrum, XP) is that it’s based on very little documentation, and has a plan-light approach to development. I have seen, however, that Agile can be extremely difficult to project manage. How do you know when you’re done? I know there are answers to this question, but the fact remains that Agile and project management don’t mix well.

From our position, it’s true that neither process addresses the user experience in any meaningful way. Both RUP and Agile suffer from being too bottom-up – the tiniest cases, the tiniest slivers of work, cannot be held together in a user experience that has value to the user without considering the big picture and what form it should take. It’s like trying to design a car starting with the notion of a wheel – you may well end up with an airplane. After all, airplanes have wheels too. The difference between a car and an airplane, in user interface terms, is the initial model - the overall conceptual structure, the interface system, within which all features, views, and so on are organized to support its use.

So what is the right way to include user experience? Regardless of your penchant for documentation, you need to start with a model. Forget the detail, start top-down initially. Consider what the user’s overall need is. All that’s required from that point forward is the discipline to maintain the model as detail is added and that your functions are not treated as silos across development teams. The model needs to be tested to make sure that the very basic ideas resonate well with users.

The good news is that, with this approach, you’ve spent very little to find out a great deal. With both RUP and Agile you can very well have spent millions before you notice you started off to build a car and ended up with an airplane – but hey, that wheels requirement was indeed met.

If you’re in an organization that is open to alternative processes, I would say take a look at FDD or BDUF. Both of these methodologies are structured in such a way as to be natural to the design process – and they are more or less extensions of Agile and RUP respectively. Both include concepts of a model.

No matter which methodology fits your organization best, the fact of the matter is that the domain of your application, the way the users will use it, and the utility it provides - the experience model - will be the best indicator of usability success. If the model of the system doesn’t work well, nothing else will .

0 Comments on this article