Wireframes Taking the Fall for Process Pitfalls: Part 1
Originally written in 2013
Wireframes: That one tangible thing the client sees before their site gets built. At many places I’ve worked, each department focuses on a certain step of the process. In the eyes of our clients and the project manager, the wireframes are the one consistent as the project goes from Strategy to Design to Development to Testing. Because wireframes are the first point where clients can start to see the strategy develop, and also what developers and designers use to start their work, it becomes a tricky document to keep coherent and consistent.
In my workplace, we strive to make sure that the communication, use, and comprehension of a project’s wireframes stay consistent throughout the entire life of the project. This is no simple task due to the varied perspectives that come into play.
As you will see, it’s important to understand all of the possible misconceptions and different views when it comes to wireframes as each misconception trickles down to cause issues further down the road, both internally and externally with the client. From a UX Strategist Point of view this series will touch on the potential pitfalls of each department, and how my team and I combat them.
Today we’ll focus on the first departments that are introduced to a client: Sales and Project Management.
Possible Sales Pitfalls:
Sales is the first interaction with the client and selling important research and the discovery phase can often be challenging. As a result, its easy to point to wireframes as the end product of discovery. The problem with this? Wireframes are NOT discovery. Wireframes are design informed by discovery. In order to create the strongest and most compelling set of wireframes, the discovery phase is necessary.
Possible Project Management Pitfalls:
Project managers have the difficult job of matching the expectations set up at the point of sales and some of these expectations may be hard to reach. The client may have tossed ideas back and forth in previous meetings and is now waiting for those ideas to appear in wireframes, as promised by the sales team.
Project managers must balance advocating for the client and advocating for the business. The design team must now work to show wireframes as soon as possible. The UX designer now has to try and pull requirements out of client through wireframes because it’s the only tool they feel comfortable with.
Wireframes have now gone from a deliverable to a communication tool.
Resetting Expectations:
UX strategists/designers/themers, whatever you want to call us, we are not mind readers. (If you have successfully figured this out, by all means let us know!) To manage expectations, its a must to involve the client in the Discovery process as much as possible by including them in activities that will identify needs, goals, and audiences.
Discovery activities may include business stakeholder interviews, end-user interviews, sketch prototyping, analytics reviews, competitive benchmarking, and more. Based on the results of these activities, we strive to achieve a general consensus on goals and an overarching strategy based on high-level features to meet them.
Goals and features are also prioritized based on stakeholder and user feedback. The client and the entire project team have access to a documented roadmap of including the established goals and features. The wireframes are no longer a requirement pulling activity, they are a blueprint for the site that the Design team can use to start flushing out smaller details.
The roadmap is the deliverable from Discovery. Sometimes we bring the discovery phase into the sales process, starting with stakeholder interviews. This allows our whole team to interact with the potential client early on, and for the client to have insight into our research strategy.
We sell this thirst for knowledge, a well thought out road map (business plan), and wireframes to our clients. We are no longer an implementation shop — we are a strategic partner that understands our client!
