EDITOR’S NOTE: This blog post is the third in a continuing series about the importance of a requirements engineering process. If you’re considering an eCommerce project at your company, you’ll want to watch this space. The posts in this series will help explain how having a solid process in place saves time, work, and money. It also turns clients into partners and when that happens, everybody wins. Enjoy this post, and be sure to stay tuned for the fourth and final one of the series.
In the first blog post of this series, we introduced you to the requirements engineering process. Among other things, we provided an overview of the steps it involves, explained its benefits, and mentioned the four key deliverables that should come out of the process. The second post in the series focused on one of those deliverables: the functional specifications document (or FSD, for short). This third post in the series picks up right where the second post left off, because once the FSD is complete, it’s time to start thinking about the next big deliverable in the engineering process: wireframes. In fact, a well-written FSD is something that the user-experience designer (or UX designer) will refer to throughout the wireframing process.
If you’re not involved in web development and design on a day-in, day-out basis, the concept of a wireframe can be a challenge to grasp. We like to compare a site wireframe to an architectural drawing – a blueprint. Just as a contractor would never build a house without having a blueprint on hand, a web designer wouldn’t dream of designing a website without looking at wireframes. They’re that important.
The wireframe provides the answer to the question of “what’s included on each page or layout?” or “what can the user do here?”. More importantly, the wireframe provides a guideline for the developer to see what they’re going to be building. The wireframing process is the first step in building what will become the user experience of the website, but it also serves to expose missing concepts or gaps in the functional specification document. The two items serve to inform each other – all the “actions” that will be planned and mapped out in the wireframe should be covered in the functional specification document.
Keep in mind that this isn’t the stage where you talk about specific design elements, images, colors, fonts, or language. All of those things will come later, in the design and build phase. If we can return to the blueprint analogy for a moment, this makes even more sense: How can you decide what kind of furnishings you want in your house if you don’t even know the room dimensions or how it will flow?
Wireframing begins with a solid foundation of research and exploration. It’s crucial to know who the client is, what they do, and what they need to accomplish with their eCommerce or web design project. Additional information including data on site traffic, analytics and other business reporting can also be helpful.
The research and data that can be provided is helpful to reduce the number of assumptions that a UX designer will have to make when the wireframing process begins. In addition, having that information up front frequently reduces the amount of time in the wireframing process due to a general reduction in feedback.
Once research and exploration are complete, it’s on to brainstorming and sketching. A lot of people mistakenly assume that web designers go straight to the computer. But the good ones will reach for the markers and paper or white board first. They’ll sketch out all of their wireframe ideas so they can hone in on the best ones, always focusing on the user experience. They’ll think about where things will be placed within a website, and why. The best ideas don’t come from just one mind, so it’s important for the entire web team to bounce their ideas off each other. This kind of collaborative approach helps people uncover issues and come up with solutions that they might not have arrived at if they were working alone.
With brainstorming and sketching done, now it’s time to move to the computer. Sticking to some basic “best practices” will ensure this part of wireframing goes smoothly. Here are a few that are extremely helpful:
- Use a grid. A wireframing grid (or guidelines) keeps everyone on track and focused on the project goals. It also ensures a clean, simple layout, because people’s eyes naturally love symmetry.
- Avoid color. As we mentioned at the beginning of this post, wireframing is all about the user experience. Color is a powerful piece of any design, of course, but the design phase comes later. And because color is so subjective and personal, it can also be extremely distracting when it’s used in wireframes. For that reason, it’s best to stick to black and white, or gradients of black and white.
- Stick to classic fonts. Just as color can be distracting, so can typography. In the wireframing process, classic, clean, san-serif fonts are your friend. The user experience, not the font, should be the focal point of the wireframe. Experienced UX designers will take great care to avoid fancy, unique, or distinctive typography specific to the client they’re working with, simply because those kinds of fonts will be too distracting.
- Selectively use images. Just as color is a powerful design tool, so is imagery. Including lots of images in a wireframe is an easy way for the conversation to divert from its intended goal. For this reason it is best to use placeholder boxes to illustrate where an image might be. If including an image makes sense in order to get an idea across, then proceed with caution and do so with a clear purpose.
So how many wireframes are in a typical eCommerce or web design project? The short answer is that there’s no such thing as a typical project. That’s because a well-designed website should communicate your company’s unique culture, business model, products, and goals. If all you need is a single landing page or a simple blog, you’re probably looking at one to three pages of wireframes. But if you’re building a really complex website that involves multiple user groups or a huge catalog of products and tasks, you could easily be looking at 20 pages (or more) of wireframes.
The last thing to happen in the wireframing process is the presentation to the client (and there are often many rounds of presentations). If you happen to be that client, ask yourself these questions as the presentation takes place:
The last thing to happen in the wireframing process is the presentation to the client (and there are often many rounds of presentations). If you happen to be that client, ask yourself these questions as the presentation takes place:
- Are the designers walking you through the actual user experience that the wireframes illustrate?
- Are the people who are presenting to you explaining what they did and showing you how it supports your needs?
- Do they gently redirect you to focus on the user experience if you get ahead of yourself and start asking about design?
- Are the processes that I want the user to take fully covered?
If you can answer “yes” to all four, then you – and your wireframes – are in good hands. You’ll be ready to begin the design/build phase.
Is wireframing and all of the work that goes into it time-intensive? You bet. But here’s the thing – it’s time well spent. Because you discuss, define, and agree on the user experience up front, you can get right down to the creative stuff in the build and design phase. Developers will also be able to consult the wireframes if they have questions down the road. If you skip wireframing and jump straight to design, you risk missing some very important user and functionality issues. These will pop up so late in the game that they could cause costly delays and require significant amounts of functionality work that you didn’t originally plan on.
Speaking of planning, we’ll be discussing it in our fourth and final blog post of this series. Specifically, we’ll be looking at the project plan. Like wireframes, it’s one of the key deliverables in the engineering process.
