Some User-Centered Design techniques are supposed to be conducted during the requirements phase of the software development life-cycle, but in most real-world projects the usability/UX team cannot perform them, usually for reasons like these:

• Requirements are defined by another team (business analysts) and the UX team is not involved in this phase; they usually don’t take part until the design phase.
• The UX team is involved when the project is almost finished (and the interface problems are already pretty severe).

Yes, we know that the UX team should participate since the early stages of the development, but… what can we do when we are faced to given requirements, which are usually incomplete, long lists of technical features, and which have nothing to do with UCD techniques like use cases or user stories?

UX Interpretations

Last June, Greg Lauger explained in his article ‘Matching Requirements with User Experience‘ on Johnny Holland Magazine some techniques used in that kind of situations, and I think that the ‘UX Interpretation‘ approach (he calls it a “collaborative clarification”) is a great idea and could be used as a UCD technique on its own.

For every single requirement (or every important requirement, or every unclear requirement), the UX team would develop the corresponding ‘UX Interpretation’, following this simple structure:

1. Reference to the original requirement.
2. UX interpretation of the requirement.

The UX interpretation could be a use case, a storyboard, a prototype… any technique which described the implications on the interaction of that requirement. After that, the interpretation would be reviewed by other members of the development team.

What would be the purpose and benefits of these interpretations?

• The UX team would work with a more familiar way of describing requirements.
• The interpretations would be the equivalent of “this is what we have understood from the UX point of view”. Consequently, they would be a better reference for discussions with the analysts team than the original requirement. The analysts could then give feedback about the correctness of the interpretation.
• The UX team would show that the requirements are a fundamental aspect of the development, and that the team uses them and cares about them.
• The analysts would have contact with the “UX way” of describing requirements, and they could use that knowledge for following projects.

So… do you think you could have used this technique in some past situation? Or better… Do you think this could be useful in future projects?