Saving Time and Money with Wireframes

One of the most difficult parts of defining requirements is gathering stakeholder alignment. The investors have a vision in their heads of how amazing some feature or product should be, but they don’t understand the technical implications of what they want. The tech lead knows how things need to work, but isn’t able to focus on user-friendliness. The product owner wants everything to work within the budget and may not anticipate certain edge cases or nuances in the request. Having a requirement documentation process in place and defining tasks in trello or jira can help to keep things in synch, but those only go so far in fostering stakeholder alignment and clear communication.

Wireframes, mockups, screens, proofs; they go by many names. Wireframes are intended to call out key moments and interactions in software design in order to provide clarity into how something should look, feel, and function. Much like blueprints for a home, wireframes offer a chance to see how everything will fit together to form a unified product, feature, or service before development begins. We’ll talk more about what wireframes look like and the categories that exist later. For now, just know that they serve as glimpses of “what could be” and are easy to iterate on quickly.

Wireframes can give stakeholders a common artifact to gather around, assess, and refer to while ultimately guiding the requirements definition process in a more thorough and efficient way. Developers are able to visualize what needs to be built and have opportunities to raise concerns or ask questions before estimating time & effort. Exceptions, misunderstandings, and edge cases can be identified early on in the process and allow for a bulletproof solution to be designed before development begins. It may seem like a no brainer to spend time iterating on wireframes, especially when kicking off a new project, but it’s not as common as you might think. I’ve seen projects get needlessly stretched out and weeks of effort gone to waste all because of unfinished requirements that weren't validated by wireframes or agreed upon by stakeholders.

A Tale of Two Projects

Imagine your team is told that they need to roll a new feature out in the next month. Stakeholders meet and agree upon requirements within the first week, and by the beginning of week two the development team is hard at work, requirements in hand. At the end of the second week an email is sent out by a stakeholder requesting 2 or 3 small changes to the feature, which the development team admits are inconvenient but doable. Work continues as expected. Midway through week three stakeholders attend a demo of the new feature, almost ready to implement, with another week scheduled for polishing and refinements. The tech lead on the project doesn’t like showing unfinished work and getting in arguments over things that obviously need more attention...

The demo starts off smoothly enough, but before long arguments start springing up and tensions begin to rise. False assumptions come to light, obvious inclusions weren't so obvious to some, and unanticipated edge cases bring the whole design into question. Over the next two hours (the meeting was supposed to take no more than 30 minutes), it becomes more and more clear that serious changes need to be made to the implementation, usability, functionality, and scope of the feature. Drastic measures need to be taken in order to launch on time, which at this point is looking unlikely. Meetings are scheduled, hours of overtime worked, days or weeks worth of work thrown out, and the go-live date is pushed back another two weeks. Eventually the feature is delivered to spec, though late and over budget. I doubt I’m describing any projects you’ve ever been on. Maybe a parody that you’ve seen on Silicon Valley.

So what went wrong and who should be blamed? The requirements were never validated, stakeholders weren’t aligned on their vision, and development started prematurely. Can wireframing really mitigate these issues?

Let’s take the same feature request and timeframe. Over the first week a designer is involved in the requirements definition process, producing low fidelity wireframes, sketches and, whiteboard doodles to hone in on some of those unanticipated issues. By late in the week the requirements are nearly complete and the designer begins creating high fidelity wireframes. By the beginning of week two, the designer has finished the higher fidelity screens and discusses them with the stakeholders. Some things are clearly missing or seem inadequate, though much of what was discussed the week prior is worth keeping. The team proceeds to brainstorm, whiteboard, and problem solve for another hour or so. The designer takes the rest of the day to iterate and apply design feedback, and a second meeting is scheduled for early the next day.

This cycle of frequent communication and iteration results in a solid set of high fidelity wireframes, detailed design specifications, stakeholder alignment, clear developer expectations, and thoroughly defined requirements. Midway through week two, the tech lead (who has also been a part of all of these conversations) begins work with his team, referencing the artifacts from the discovery process along with occasionally contacting the designer for clarification or ideas as needed. Throughout development the team continues to meet regularly to review progress, assess needs, and refine requirements as needed. The biggest issues were brought to light early on, and even though smaller concerns come up over the third and fourth weeks, they’re quickly folded into the existing design system. Finally by the end of week 4, the feature goes live on time and within the budget. Naturally, our team decides to celebrate at happy hour together, because why not?

Using the Right Tool

Wireframing is a tool, a means for communication, and an effective method for clarifying and refining requirements within a team. In the example above, our team was able to anticipate issues in the feature request, get a head start on the design process, communicate more effectively to the development team, iterate more quickly, and synchronize disparate opinions with the help of wireframes. Issues arise when the right tool is used for the wrong job. Most can’t afford to wait to see it running in their browser to say “that’s not what I had in mind.”

When beginning on a new project, there are several unknown factors that need to be uncovered and addressed. I’ve often been told “just give me something to react to, and I’ll let you know how close it is to what I think we need.” There’s something about seeing an artifact of what an application, product, or feature could become that brings out creativity and solutions that would otherwise lay dormant. Let’s not forget, more than a pretty picture is needed to guide the process. Wireframes are intended to supplement and clarify requirements, not replace them. When coupled with clear requirements, wireframes can guide the conversation and help stakeholders to visualize the problem and identify innovative solutions, all the while producing practical resources to support development efforts.

While I’m clearly a fan of producing wireframes to aid in the requirements definition process, doing so isn’t a magic bullet. I’ve been on projects where wireframing was intentionally worked into the requirements definition process, but developers were told to begin on features before the wireframes were finalized. There were elements of the designs that were almost there, and our team was told to begin building out the sections that were “definitely not going to change.” A week later the feature had to be completely rethought and rebuilt. This trend continued until the component was rebuilt 4 times, despite the fact that each revision came with the promise that nothing else would change. Needless to say, our dev team wasn’t too happy. Just because a wireframe exists doesn’t mean the designs are finalized, approved, or even any good to begin with.

Wireframes can help to alleviate the strain of defining requirements by giving a target to aim at. The areas of the design that are lacking as well as glimpses of the eventual solution can be seen. Still, feedback needs to be carefully gathered and discussed before revisions can be made. Wireframes are often quickly put together to get something out there to react to, but each iteration should take all of the feedback into consideration to eventually zero in on a solution. Guessing at solutions is not the same as thinking through and solving a problem, no matter how pretty of a picture you wind up with.

Taking the time to work wireframing into the discovery process pays dividends down the line. Hurrying through discovery and requirements definition in order to “get to the real work” only short changes you. While there certainly are times when it’s possible or even beneficial to start coding before the requirements are finalized, your project is almost never going to be the exception. Not to mention you’ll be playing catch up on at least a handful of design details when things inevitably change. Beginning development with a solid set of wireframes in one hand and bulletproof requirement documentation in the other should be the expectation, not the exception. Otherwise your team is aiming at a moving target.

Types of Wireframes

So what counts as a wireframe? There are a handful of kinds, ranging from low fidelity doodles to fully functional prototypes, each with their own purpose.

Sketches

During the discovery process, quick doodles on whiteboards or scratch paper can help to communicate ideas that are hard to put into words - like brainstorming with pictures. These sketches could end up being breakthrough ideas or simply serve to move the conversation forward, but they provide a valuable baseline to rally around as the problem is being defined.

Low Fidelity

Once you’ve defined the problem and progressed to investigating potential solutions it can be helpful to block out general screen layouts to avoid getting hung up on aesthetics. These designs focus on functionality and interactions, and this approach is helpful when you’re trying to determine if a specific pattern or idea will help to solve your problem. Designs in this phase can also be put together and iterated upon very quickly due to their simplistic nature.

High Fidelity

These types of wireframes are usually most valuable after the interaction patterns have been nailed down and the requirements have been fully drafted. They give stakeholders a glimpse of what the end result could really look like, and for many stakeholders this is where issues are easiest to see. It feels more real than anything else that’s been looked at, and people tend have a more visceral response as a result. These designs are still quick to iterate on and often provide valuable insight into nuanced use cases and unanticipated edge cases.

Click Through Prototype

Sometimes it’s not enough to simply see what the design could look like. Prototyping can provide insight into how it actually feels to interact with an idea. This step can become more time consuming with increased complexity, but using high fidelity wireframes to stitch together a click through prototype can be a powerful tool for soliciting feedback and gathering a consensus.

Functional Prototype

Depending on the complexity of the interaction being examined, a functional prototype can be incredibly valuable. Manipulating static images tends to fall short when a complicated or detailed interaction needs to be validated, but a functional prototype can allow stakeholders to quite literally interact with the solution. These prototypes often take more effort to assemble and can sometimes function as prototypes for the development team as well.

Spec Documentation

Tools like Zeplin have made it easier than ever to take high fidelity wireframes and produce detailed spec documentation for your development team. This kind of documentation eliminates guesswork and gives developers exact details to implement the solution as it was designed.

Bonus: User Testing

Wireframes are a powerful tool, but just because your team agrees upon a solution and development goes smoothly doesn’t mean your end users will adopt it. There’s nothing worse than building “the beautiful wrong thing,” just like building a bookshelf only to realize at the end that you actually needed a kitchen table. Any level of wireframe can be tested with users, whether it’s through a quick survey, an hour long one-on-one session, or a day long workshop. If your goal is to refine requirements and solve the right problem, you can’t afford to ignore the people you’re trying to solve the problem for. If you’re interested, you can read more about user testing here.

In Summary

Prioritizing wireframing as a part of the requirements definition process does more than enable stakeholder alignment. It promotes clear communication and problem solving, encourages asking questions and trying new ideas, provides valuable resources for developers and stakeholders alike, optimizes time spent in implementation, and enables validating and challenging assumptions in order to de-risk the project as a whole. If you’re tired of working overtime on projects that run over budget, ship late, and only provide the bare minimum solution, then wireframing might be just the tool you need to course correct.

Thank you for taking the time to read this blog post. Have questions or want to talk to our team? Schedule a meeting HERE.

‍