A short while ago, product designer Sean Dexter wrote an article entitled “Wireframes are becoming less relevant — and that’s a good thing.” Though wireframes are uniformly accepted as a crucial part of the design process which focus attention on usability instead of aesthetics, Dexter argues this is something we should reconsider. In the past, we used to find that presenting clients with fully-realized designs ended with them fixating on the wrong thing — like the colour or shape of a button, rather than the functionality and flow of a page. By stripping away the design layer, wireframes prevent those discussions from happening at the wrong time. Dexter, however, notes that the static—and undesigned—nature of wireframes betrays the importance of interactivity, animation, colour and design within user experience. A lot of what Sean wrote resonates with us. Wireframes are still an important tool for us, but we recognize their inherent flaws.
How we use wireframes
After we deliver a strategy that outlines a project’s audiences and goals, we deliver a set of wireframes along with a sitemap and moodboards. For us, wireframes are a lo-fi representation of the general content flow and organization of the elements and blocks on a page. We use lorem ipsum text to approximate the amount of copy needed for different sections (controversial, we know). We use draft copy for headings and calls to action as much as possible. Finally, we annotate the wireframes to explain small details or anything that might be difficult to explain in a static wireframe.
We try to keep people focused on what’s on a page and the general flow and order of content. It’s important for us to clarify that this is what it might be, but it might not look exactly like this. There is a lot left to the imagination and to our discretion to adapt this basic concept when the content is written and the design is built out.
Why wireframes are good, and what we don’t want to lose
Content/hierarchy planning
We start out wireframing on brown paper or use UX/wireframing cards. The act of planning out the wireframes is the point where Kobot starts to get serious about the content needs and hierarchy of a website. Wireframes are the first visual manifestation of the website and they focus our discussions into tangible needs. It’s a practical time to ask questions about how to turn our broad goals for a website into specific goals and tactics for single pages and what content we will need to achieve those. The literal drawing — and eventual refining — of wireframes helps us identify any gaps in our content planning.
Wireframes help us plan the page designs
Sketching out visual arrangements of boxes and lines of type is an obvious and necessary step in designing the pages. Without the obligation to obsess over aesthetics, sketching at a coarse fidelity (Sharpie on brown paper) lets us move rapidly. From the discussions they generate to the way they expose critical problems that might not be apparent in a text document, wireframes provide a solid plan for how pages will take shape.
Once we are pleased with the initial sketches, moving from brown paper to a digital application (we use Sketch) is the next step for us. We use a series of symbols and templates to make this process move quickly. Once we are digital, we have another chance to review and refine the wireframes. The digital wireframes allow us to reorder sections of pages and clarify sections through annotations. When we are satisfied with the digital wireframes, they are a crucial roadmap and planning tool to design the visual layer of the website.
The bad things about wireframes
Feedback
While we’ll often get feedback from clients about sitemaps and moodboards, we rarely get any feedback from clients regarding the wireframes. Either this means we’re really good at our job (maybe true), or wireframes are failing as a deliverable.
Our stated goal with wireframes is to express the flow and arrangement of the content and to call out details that we think the client should be aware of. We initially present wireframes in person and walk through them as thoroughly as possible.
Client walkthroughs of the wireframes usually go pretty smoothly, but understanding wireframes can be demanding. In our approach to wireframes, we allow ourselves some flexibility of implementation by being a little vague at this stage. Where this falls down is that wireframes require a certain level of abstract thinking. We need the client to use their imagination and think about applying the moodboards to the wireframes in their mind.
Wireframes are abstract
There’s no way around the fact that a wireframe is not a webpage. They are static screens presented in a flat document that lacks any feeling of how things flow from page to page. We omit the design which, as Dexter points out, completely undercuts the intrinsic impact design has on user experience. Wireframes fail to show the crucial part of “this is how your website is going to work” by suggesting “this is how your website is going to look MINUS the design.” We present wireframes as important despite this huge gap between them and the real experience of a webpage.
We sometimes make assumptions with the wireframes when we’re framing them out. Working at the fidelity we do (lorem ipsum), we often hit barriers when we start to develop the content and design because real content is different. The cost of this is delivering a working website which breaks from what the wireframes look like. These divergences are rarely huge because wireframes are great to root out major problems, but little changes happen, and that affects client expectations.
Not dead yet
Clients seem to get what’s going on in the wireframes in meetings, but when asked to think about the wireframes and provide further notes, it rarely happens. This begs the question as to whether wireframes have value to clients beyond an initial scan of the general flow of pages. Maybe we don’t need to hold wireframes up on as high a pedestal as we do for a deliverable.
Perhaps we need to stop thinking about this being important for the client, and instead note this as a step that’s more important for our internal processes. Maybe the client discussion around wireframes needs to be lighter and less structured. Maybe we need to rethink what we present. We could, instead, possibly bring in a number of designed pages which go further than wireframes that give the client a better, though still abstract, artifact to assess the progress of the project. That way, we’re creating something closer to their expectations and understanding of what a website is that gets the conversation started, but then have the serious conversations over the actual website.
Want to see the whole conversation? Check out the video!
This blog post is based on a recent episode of Ask Kobot Anything, our weekly Instagram Live where we let you ask us, well…anything! Questions or comments about this post, or just want to see something discussed on the show? Email us! Check out our Youtube for more past episodes. And catch Ask Kobot Anything every Friday at 11:30 MST on our Instagram.