This is the first of a three-part series on how we have employed wireframing processes in some of our Agile projects. This first part covers how wireframes can be employed as a specification tool, part two goes over how much detail is appropriate for our needs, and part three discusses what else you may need in your Agile project beyond a set of pretty wireframes.
Introduction
Wireframes are used to design (and define) the form and function of an application, usually a web application or smartphone app in our case. In our experience, they have proved to be a valuable tool in an Agile development environment because they facilitate strong communications between the project team and they encourage iteration. They have also served another very useful purpose in our projects because they have reduced the volume of written specifications required and improved the overall clarity and operation of the application for both the customer and the development team.
"[Wireframes] facilitate strong communications between the project team and encourage iteration."
A tool for the agile toolkit
At Sandfield, Agile means using a number of tools and techniques to define scope and to fully engage all of the stakeholders in the software delivery process. These techniques aren’t homogeneous and they alter between and throughout projects. Wireframes are a tool that we use on web application and smartphone app projects because we think they are an efficient and cost-effective means of documenting form and function to the team.
The type of documentation and the level of detail is always a balancing act on an agile project. The general tenet is that documentation should be “just good enough” to deliver working software and it should be produced in a collaborative manner. Traditional requirements and specification documents are difficult to collaborate on and are not the most engaging of mediums to work in. They also tend to get out of date very quickly, regardless of whether the project is agile in nature or a more traditional waterfall project.
The wireframing process
For web applications, we have found that a wireframing process delivers considerable benefits. The initial stages of wireframing requires close collaboration with stakeholders and can be done using informal and low-cost agile modelling techniques such as whiteboard sessions. This gets the team engaged in robust discussion and focusses on what the application needs to do (concentrating on the function, not the form).
From here, we then refine a few key wireframes (at a suitable level of detail) which are then the basis of further discussion and collaboration to refine the function (what it does) and to start moving into the form (how it looks). This also encourages iteration and because low-cost techniques are being used, emotional attachment to designs is reduced and there is less resistance to scrap a design and start again if it doesn’t work. We ensure that common design elements and templates are approved so that these can be the basis for future wireframes. This then allows us to produce wireframes throughout the software delivery rather than needing to do all of them up front. Again, this fits in with agile deliveries where the detailed design is done by the development team and stakeholders throughout the project. This also means we don’t design pages we don’t end up building because wireframe design and refinement generally occurs just before the page is developed.
How wireframes have worked for us
"Wireframes are easier to discuss and refine because stakeholders can visualise the form and function."
Wireframes can also be used to communicate the dynamics of how a website or app works, not just what specific pages look like. Doing so ensures that the stakeholders and development teams both understand key usability aspects of the application. This can be achieved with specific wireframes e.g. showing a modal dialog or with simple annotations on the designs. Most wireframing products also support wireframe linking so a usable model can be prepared to show transitions from page-to-page in the application when the user performs certain actions such as clicking/tapping controls. This provides additional context to all concerned and this visual method is much faster and cost-effective to prepare than attempting to document that type of detail in a design specification document.
We have found that the adage that a picture is worth a thousand words really is true when using wireframes as a means of documenting design detail in a web application. Not only are they easier to collaborate on (especially in the earlier stages where the tools used can be very simplistic) but they are also easier to discuss and refine because stakeholders can visualise the form and function and have meaningful discussions about it easier than reviewing a wordy document. We have found that this has increased accuracy in both form and function definition and in ensuring key business processes and rules are captured and implemented correctly. The wireframes themselves are also agile in nature in that they are produced at an appropriate level of detail and once working software is delivered their role is fundamentally completed and there is no need to keep them up-to-date. Once a web page has been built, it is usually easier just to make minor tune-ups to the web page if required rather than continuing to refine the wireframe.
How Much Detail?
So far I’ve only discussed the fidelity levels of wireframes in general terms e.g. “appropriate”. In part 2, I’ll go on to discuss the levels of detail that you can use in your wireframing processes on an Agile project.
