Have you ever heard a client, product owner, or stakeholder praise wireframes? Do you, as a designer, love spending hours creating or updating your own wireframes? No, me neither. For years we've tried to maintain the metaphor of the wireframe as part of our web design process. It's time to give up the ghost and finally let wireframes die.
Since its beginning, the wireframe has been used to outline content placement, order components on the page and describe interactions in excruciating detail. In a traditional waterfall model, wireframes are one of the initial pieces of documentation that inform not only structure, but also content, design and development. The lines can be a bit blurry as to who creates them. Wireframes are more commonly created by an information architect who fine tunes the relationship between information, content and categories or a designer who focuses on visual relationships and aesthetics. In a typical process wireframes are created and given to a designer to make them "pretty". The prettified wireframes then pass to the developers to make them work.
This one-way communication methodology is where many problems in communication start to bubble up. Teammates further down the waterfall feel like they've been limited in the decisions they make moving forward. Wireframes amount to a paint-by-numbers system in which the designer uses their preferred design tool to essentially paint over the wireframe, limiting their ability to problem solve.
Wireframes often provide too much information, too early. A series of annotated wireframes are some of the first things a stakeholder is shown for sign off. This creates a lock-in for designers and developers as they begin their work and limits them in exercising their creativity. In being static, wireframes are incapable of demonstrating interactions and instead attempt to describe them, heavily.
Obviously, depending on the complexity and scope of a project, wireframes need to be heavily annotated and documented as part of a functional specification so those further down the waterfall know what is intended. But people don't read documentation. Trying to describe the functionality of complex interactions is difficult. Designers and developers interpret annotations, sometimes correctly, sometimes not.
After a wireframe is passed downstream to the designers, they pass the wireframe and their mockups to the developers. The developers receive a large packet of documentation. By this time, the first round of wireframes that have made it to the developers, have already started to be changed. The wireframes become out of date quickly, which creates a constant cycle of never-ending revisions where those further down the waterfall become more out of sync with those at the beginning.
Consider rapid prototyping as an alternative to improve communication across multiple disciplines. There are four primary tenets to rapid prototyping:
Any process should be agile. Simple guidelines for a rapid prototyping process can be broken down into four steps that should happen concurrently:
The primary concepts behind rapid prototyping help to tear down silos, foster cross-discipline collaboration and provide all members of your team the opportunity to participate in the design process. Rapid prototypes allow the team to explore and validate a design idea, its interactions and communicate the results to others while reducing waste and time-to-market. It's a useful tool in any team's toolbox that provides a more powerful way to explore and communicate design solutions.
Words: Bermon Painter