The overwhelming majority of users we deal with are non-technical and visual learners. As a result, requirements documents that are heavy on narrative are a poor conduit to understanding the way in which users will interact with a proposed application. By visually manifesting the application prior to development, wireframes put everyone in the best position to win.
Here’s my anecdotal allegory of the problem with requirements documents. When distributing a requirements document, if there are six business users in the room there are probably four that have read the document and two that understand it. Of the two who have understood the document, each of them is imagining a different application in their mind’s eye. It’s not their fault. This stuff isn’t what they do for living and when they become involved it’s on top of their normal day job.
Wireframes replace the written word with visual manifestations of the screens/pages. From a users perspective (an even from our respective) they are significantly easier to understand than dozens of pages of narrative. Software developers and business users live in different worlds and often think very differently. Wireframes help to bridge that gap through pictures that represent a common understanding of functionality. Because wireframes are a visual representation of the application, everyone in the room leaves with the same understanding of what will be developed.
Wireframes should be developed either alongside requirements documents or in lieu of them. They should also be developed deeply and completely to the point where the development team can state at the end of the wireframing sessions:
“This is what we are building – no more and no less. If we are forgetting a feature and it needs to be added later it will likely effect the schedule and budget.”
From my experience, when the wireframing sessions are done well and are complete, change orders are almost never disputed. Don’t get the wrong idea, however, that wireframes result in everyone living happily ever after. Change orders, regardless of whether disputed or not, still frequently cause frustration and require negotiations with scope, schedule, and/or budget.
It’s amazing how often what seems to make sense in thought and speech requires modification once manifested on screen. Wireframes help to alleviate, but not eliminate, this affect. Needless to say, virtually every project succumbs to Humphrey’s Requirements Uncertainty Principle which states:
“For a new software system, the requirements will not be completely known until after the users have used it.”
Wireframes also help to uncover hidden business rules. We all take what we know as professionals for granted and sometimes inadvertently omit information from those with less experience than ourselves. When the development team is discussing the need for each page, workflow, control, validation rule, et al it’s a natural process to hit upon each of the business reasons and processes and discuss them in detail.
Wireframing also helps with estimating projects. I’ve mentioned in previous posts about the inherent problem with estimating software projects. A good example of how badly human beings are at estimating is a statistic from “Demystifying the Black Art of Estimation” by Steve McConnell that most estimates are actually 30% of the actual level of effort. With that kind of epidemic of over-optimism, the clearer we, and the business users, can visualize the application – the better.
Once the wireframes are developed, a finer grained estimate is possible than prior to the wireframes. Each page and feature is able to be enumerated, sized and prioritized. Any prior estimates should be validated against the new information provided by the wireframes.
Wireframing the application doesn’t eliminate documentation. Things like complex business processes still need to be codified.
Wireframes, however, do a better job than requirements documents at articulating for what purposes users need to use a system and the most efficient way in which to use it.
Posts
