When a software project requires a great user experience or it fails, we need to rethink how we go about defining and scoping the project. Despite volumes written on how to write better requirements, many organizations continue to use out-dated approaches. This short article discusses the dysfunctions of traditional “requirements gathering” and the bind that this creates for the user experience designer. The adverse consequences can be significant.
Learning how to deal with badly written requirements is part of our job, but they can be a trap for the designer. How can the user experience designer handle the inevitable dysfunction that badly written requirements create in his or her relationship with the business analyst? In this article I’ll offer some practical advice on how to deal with this dysfunction and position the designer as someone who needs to be included early in the project–before requirements are written.
Read the entire article at johnnyholland.org.
