The value of wireframing even with incomplete information
The task of wireframing in application development, as I’ve come to know it, should begin after user research has been performed, and a complete set of requirements gathered. But what happens when, for whatever reason, you just don’t have access to user research, or a full set of requirements? What if all you have are some rather unspecific, vague notions of what the user should and should not be able to do? Is wireframing at this juncture useful? I say yes. With incomplete or even almost non existent information about target users and or requirements, wireframes can still be a valuable tool in the interface designers toolkit.
The key to a wireframe’s usefulness is that it is a visual document. Presumably it will be presented to one or more product stakeholders, and they will have the opportunity to review it and comment. Having something visual to respond to is one of the easiest ways to generate ideas, and identify incomplete specifications. A good assumption is that if a product’s requirements are incomplete, someone at the wireframe review will notice the gap by responding in the context of the visual presentation. “Where is the Cancel button? Oh…not in the requirements? Well it’s obvious that on this screen the user will need to be able to cancel, so we have to add that as a requirement.”
In this way, a wireframe can be an ever evolving document, which begins by starting the requirements conversation. Of course ultimately, just prior to feature development, the wireframe should have all of the necessary specifics so that the developers can use it as a guide (along with the relevant user stories).