So. The project planning phase is over. After a week’s worth of making personas, playing innovation games, doing sketches, and putting together a story map, what comes next? It’s time for the team’s developers to dive right in and start coding, while the designers begin working on some fancy, hi-fi design concepts, right?
Wrong. To do that would be to skip a vital step: putting together a detailed wireframe document that captures all of the thinking you have been doing in the project planning phase.
Why Create Wireframes?
It’s a valid question. After all, producing a detailed, accurate wireframe can take a person or pair days, or even an entire week. So what value does a wireframe bring to the process?
A finished wireframe represents a shared consensus between developers and designers and between the team and the client regarding how an application should be structured and how it should function. It takes the scattered information revealed in sketches, conversations, and the story map and condenses it into an annotated, illustrated document, a summary of the team’s findings and thoughts. Having such a document can be a lifesaver six weeks or six months down the road as the team is working on the application. It acts as a reminder and a concrete, thought-out reference for all of the functionality and features that were worked out during the planning phase. When you’re trying to remember how a certain feature or workflow was supposed to be implemented, the wireframes are useful for both the client and the development team alike.
The process of wireframing is also an important step because creating a wireframe causes the team to think through the functionality of the application in an in-depth way before any programming or design happens. This can save money down the road by preventing costly oversights or holes in the application and exposing flaws in the usability or workflow before they are ever built into the application. While wireframes are not a foolproof barrier against issues like these, they certainly help catch and prevent them early on in the process.
For the designer of an application, wireframing is an important opportunity to begin thinking about application architecture, as well as design considerations such as placement and proportion of objects on the screen, without having the overhead of working with a hi-fi design concept in Photoshop or the application itself. Although a wireframe is only an approximation of an application and it is often necessary to fine-tune the design later in the process, as a designer I try to make the layout and proportion of objects and features in the wireframe as close as possible to what they will be in “real life”. When working on design or markup, I only make major departures from the wireframe if there is a good reason (and never before discussing it with my team.)
Who should work on creating the wireframe?
As a blueprint and reference for an application’s architecture and functionality, the wireframe affects everybody on the team as they design and build the application. Because of this, I think the most useful and successful wireframes are created when developers and designers are able to work on them together. Recently, as we were working on a redesign and some added functionality for an existing product, Michael Harrington and I spent almost two weeks pairing on a 25-page set of wireframes for the changes we were about to make. For me, working closely with Michael really illustrated the benefits of having designers and developers involved in this process together. With his advanced knowledge of the application and its programming, Michael was able to clarify points that were fuzzy in my mind and steer us away from making decisions that would be costly or difficult to implement from a programming perspective. Likewise, as somebody whose background is in design and user experience, I was able to address concerns and issues in those areas.
In practice, this pairing approach to wireframes can be done a number of ways. When Michael and I worked together, I did most of the “driving” of the computer, working our thoughts out onscreen using OmniGraffle. However, the keyboard-and-mouse duties could be swapped back and forth too, allowing the developer in the pair to flex (or gain) skill in OmniGraffle. It all depends on the comfort levels of the people involved. For some discussions, we left the computer behind and used our whiteboards or paper sketches instead. One thing we did, which helped our velocity, was to postpone repetitive tasks, such as lining up a row of icons or filling in a table of information. For such tasks we would often hammer out the first element or row together, and then I would come back later alone and fill in the rest of the data. Putting off these tasks allowed us to focus on the real application problems which needed our attention and brain power.
Sometimes, a project’s resources or timeframe makes it impractical for two people to spend a week or more wireframing, and the task falls to one person (frequently, the designer). In these cases, I want to stress how important it is that the person creating the wireframes is in close contact with the rest of the team, pinging for questions and input multiple times a day. In our case at Atomic Object, having an open workspace really helps facilitate this kind of interaction. It is easy to check in with one another when you’re on your way across the office for something, or to quickly glance at your team member’s screen when you are in between tasks.
In this post, I have discussed why I think it is important to include detailed wireframes as part of a project’s development process, and why it is important that everyone be involved in creating those wireframes. In my next post, I hope to discuss some practical tools and techniques for creating useful wireframes. Stay tuned.
One Trackback
[...] my previous post, I discussed why it’s a good idea to create wireframes of an application before building it, [...]