In the age of information overload, no one wants to read through text-heavy requirements documentation. I’ve adopted a strategy of “show don’t tell” which requires less stakeholder effort while improving the quality of feedback and participation in the analysis effort. The cornerstone of this strategy is the wireframe – a universal communications tool that illustrates the user experience while providing implementation details that streamline the transition into the development effort. Each wireframe is a rough sketch of a page in the system, along with an overall description of the page and numbered annotations describing how each component of the page will work. The annotations are a great place to capture rules for validation, dependencies, etc. A site map should accompany the wireframes, which establishes the site’s basic hierarchy. This provides context and helps the viewer understand how the wireframes fit together. Before wireframing any project, the analysis team should have a level of confidence in the overall stability of high-level project goals and requirements, as well as a shared understanding of the basic system architecture. Obviously, requirements are somewhat fluid by nature and some uncertainties will remain at this stage in the project – but the key to reducing costly amounts of re-work is to minimize these uncertainties to the fullest extent possible by talking through the approach with team members. I’ve found that wireframes engage the customer far more effectively than long lists of “The system shall…” statements. However, no single requirements artifact is perfect. Wireframes can be somewhat dangerous because:
- they can make false promises about layout or system functionality if they are not reviewed with a fine-toothed comb;
- if they are initiated too early in the analysis phase (very fluid requirements at this point), it will take a significant amount of time to incorporate major changes;
- they can interfere with the creative talents of the design team if they are over-engineered or stylized; and
- they will eventually reach a point of diminishing returns, once stakeholders have an overall “feel” for the system but want to incorporate small changes that don’t need visual representation (tools such as JIRA are useful for capturing requirement changes at this stage in the game).
However, wireframes can be extremely valuable because:
- they provide a somewhat stable UI concept at the outset of the development phase, significantly minimizing rework due to stakeholder misunderstanding of how the requirements translate into user interface components such as radio buttons, checkboxes, etc.;
- they help illustrate requirement dependencies and the impact of those dependencies on the level of effort required to accommodate certain types of change requests;
- the review process is much easier for stakeholders, and timeliness/quality of feedback is enhanced;
- in conjunction with workflow diagramming, they can clarify the scope of complex process requirements amongst all stakeholders;
- in conjunction with annotated specifications, they can expand on the inner workings of the system which may not translate visually (such as linking validation to specific UI elements);
- they often uncover potential gaps in process concepts early in the lifecycle; an
- they often uncover usability issues that are inherent to the stated requirements, allowing for those requirements to potentially be adjusted to optimize the way they are implemented.
I’d love to get some feedback on this, particularly in terms of pros and cons I may have missed.