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.