experience design

Implicit Requirements

Over the last year, I've noticed an interesting benefit of interaction design. By overtly building interaction design into the project lifecycle, not only can a project team ensure a more useful and usable product, but also, interaction design can draw out what I've come call "implicit requirements".

What are implicit requirements?
Implicit requirements are un-documented or otherwise un-thought-of specifications that can be distilled through employing various methods of user-centered design such as user & task flows, wireframing, prototyping, and user testing.

By drawing out implicit requirements, developers, designers and other project stakeholders clarify and refine requirements and build more robust and scalable applications/sites.

An example
While working on a project to completely overhaul the virtual library for an online university, I was given sets of both functional and business requirements. In order to effectively translate these requirements into an interface, I began creating task flows and wireframes.

These activities screeched to a halt when I discovered that certain features and pieces of functionality could not be implemented unless the assumptions inherent in each was drawn out and documented. I brought these items to the attention of the project team to their delight (as a side note one of my favorite things to hear is “I never thought of that”).

As a result, changes were made to the site documentation and ultimately impacted the user experience one the new library went live.

I still don’t get it.
To show you what I mean, I have provided a generic example. Say the business owners tell the developer and the interaction designer that they wanted feature “X”. The developer captures this requirement in her/his functional specification, the Interaction designer (me) begins the process of creating an interface through a variety of methods.

During this phase, the interaction designer realizes that the presence of feature “X” seems to assume the presence of otherwise undocumented feature “A”, business rules “Q” thorough “T” and could go one of 3 directions according to the flexibility of the technology platform.

These last items all fall into the definition of implicit requirements. The project team now has the opportunity of addressing these assumptions before any coding begins and is more likely to provide their a better experience.

Conclusion
Implicit requirements are like gold when it comes to what we do as user-centered professionals. It’s one major way we can justify (and even quantify) the need for user-centered design.

By drawing out and documenting these implicit requirements, developers, designers and other project stakeholders can then clarify and refine requirements and build more robust and scalable applications/sites.

posted by matthewjdoty @ 4/09/2007 03:09:00 PM