Wireframes Taking the Fall for Process Pitfalls: Part 3 - Development
Originally written in 2013
In this third and final post in my series on wireframes and process pitfalls, I analyze the importance of wireframes as tools for developers on the front and back end.
Possible Development Pitfalls
Wireframes and process pitfalls can go any number of ways in the development stage depending on the developer and their level on involvement with the project. One developer, who starts the job at the close of discovery, might read the wireframes word for word. Another developer might read the wireframes as just a rough outline and perceive the ability to fill in the holes.
Other issues may trickle down from other steps in the process too. When the client approves the wireframes, the wireframes may have been so rough due to a lack of research. The wireframes may have simply been used as a requirements gathering tool.
Now that the client sees more details, they may ask the development team for big changes. The developer works with the client to meet these wishes but fails to understand the effects these changes might have to the overall strategy. Design may have made additional changes to the wireframes and now the development team is working off of a previous revision. What a nightmare!
Development is dependent on the strategic work being laid out and signed off on beforehand. It is imperative that the client’s expectations, the designers strategic suggestions, and the developers directions are all lined up.
How to Make the Developers Happy
Collaboration is the key to making developers happy. Due to the design and strategy teams working together, we avoid contradictory documentation. The developer only has one document to look at. As the visual design is being developed, the wireframes are enriched with interaction details for less thought out portions of the design.
I use Axure which allows us to house the wireframes in a clickable prototype, styles (if we choose), and customized developer notes. This continues the theme of one document. The developer and the client are now looking at the exact same document to avoid any miscommunication.
Taking it one step further, the UX strategist and visual designer bring in the project’s themer during the design phase. This ensures that designs are actually buildable given the budget and timeline of the project. This collaboration brings one more mind to the table to try, one more problem solver, and one more contact to communicate the overall strategy to. Continuing the collaborative theme, we bring in the project’s architect as part of the ideation team. This ensures that the lead developer has both an understanding of the strategy and a say in the best way to implement it from an back-end standpoint.
If done accurately, the wireframes reflect the strategy and design thought, and can be used as a communication tool with the development team and the client. The developer no longer has to participate in guesswork.
Ultimately, when wireframes are used properly, there is no confusion from the client on what their site will look like at the beginning and end of of the project.
