Most UX designers create different deliverables for a project. They make ones for user research and ones for design. Wireframes & mockups are the most powerful deliverables UX designers can make.
They’re the most important deliverables for the following reasons:
- They’re easy for clients to understand.
- They communicate vision and expectations.
- They inform the user interface.
- They are the most actionable.
- They create the most change & impact.
- They allow for easy discussion & collaboration.
- They track the progress you’re making.
It’s a waste when designers spend so much time and effort focusing on other deliverables. You should spend most of your time on wireframes and mockups.
It’s useful to do user research, but not user research deliverables. At the end of the day, only a few people will give your user research deliverables much attention. No real change or impact happens because they are not actionable. In other words, they don’t offer a practical solution to the problem.
If you want to solve a design problem and communicate the solution, wireframes and mockups are the way to go. They set a vision, inspire change and clarify understanding. No other deliverable does that as effective.
Wireframes
Wireframes are like blueprints in architecture. The purpose is to communicate the order, structure, layout, navigation and organization of content. It’s not to communicate visual design aspects such as imagery, color, and typography. For that reason, they are often done in black and white. The emphasis of wireframes is more on content than form. Designers always do these before mockups.
Mockups
Mockups communicate the visual design aspects that wireframes don’t. These include imagery, color, and typography. They give you a sense of what the design will look like pixel-for-pixel before it’s brought to life. The emphasis of mockups is more on form than content. When the mockups are complete, they go to code and development to bring them to life.
Form + Content = Design
Design is the synthesis of form and content. Wireframes bring together the content while mockups bring together the form. Together they are the potent package of design. Every designer should know how to create both. Evolving a design from wireframe to mockup is a beautiful sight to see. It’s not just a sign that you’re progressing on a project, it’s a sign that you’re progressing as a UX designer.
I agree with you anthony, but think there’s something missing.
What about including prototypes prior (paper prototypes) or after the wireframing stage. (html + jquery, axure, fireworks, etc.)
You mentioned about clarifying deliverables. Prototyping helps people understand how you believe something is going to work.
A static image may not help translate your vision as something that is interactive for the client to play with.
Hi Joshua,
Paper prototypes might work internally, but when you are dealing with a client you need to motivate them and show them something that resembles their product. The problem with Axure and clickable prototypes is that they take too long to make and provide little to no benefit. It’s an extra step that designers have to do after they design their static images.
Most clients have some understanding of how different UI components work, so telling them that a button functions like this, or a link takes you here is not really necessary. All of that can be communicated in a static image with annotations. It may be cool to play with, but you have to always keep in mind efficiency and effectiveness in what you’re doing.
I have to agree with this. However, I have had several clients who for whatever reason were unable to visualize interactive widgets or even simple dialog boxes without seeing them “execute” on click.
For this reason I still rely on prototyping as it is more efficient than changing workflows or widgets while coding.
Thanks
We have recently started to use Axure for wireframing with two key objectives:
– keep the visual/cosmetic elements away from iterations\
– focus more on flows and get those iterations done as quickly as possible
We are not yet done, but I am simply amazed at the convenience and speed this approach has delivered. The fact that we don’t have to think about colors and fonts makes the process so much faster to iterate on (quick implementation, effective feedback).
In my previous experience (where and content and form were not segregated), every discussion that was intended for content ended up inadvertently focusing on form.
Thumbs up for setting this up as more and more people and organizations need to be doing this.
Pingback: 35 Excellent Wireframing Resources - Noupe Design Blog
Hi Anthony,
Great post; I agree that some people underestimate the power of wireframes and mockups and I think the 7 reasons you list as to why people should use them are spot on.
However, I also agree with @Joshua Lay on the need of prototypes as well. But this is not to say that creating something that is interactive is needed for each and every page of each and every project. That would take up a lot of valuable time. Prototype necessary areas or elements.
If you are creating a simple website where explaining the interactions to clients is sufficient, you likely do not need to move into prototyping. However, if you are creating complex websites or web applications that may be difficult to understand in terms of text explanations, using tools like Axure, ProtoShare, or straight HTML to illustrate functionality help clients understand what you are talking about and help save headaches further down the road. Taking the time to simulate those interactions may very well be more efficient than assuming the client understands what you are referring to.
It all boils down to your needs as the designer and your client’s needs in terms of technical knowledge and project complexity.
Cheers,
Andrea
(disclosure: I work at ProtoShare)
Hi,
Some good points were mentioned already. The thing is that you don’t necessarily have to choose between wireframing and prototyping, you can mix both things. You can end up having different fidelity degrees when presenting something to your client, this might not be bad at all.
Of course you’re right when you say many clients have a basic understanding about how some common UI components work. Don’t waste time in it. Anyway, when moving to more complex environments, being able to show how something exactly works will save you a lot of time, work and stress.
Another things I often hear is that “it takes too much time to create a prototype”. We put a big effort in saving this obstacle and we feel we succeded. If you’re interested, give us a try: Justinmind Prototyper.
Cheers,
Dan
@Justinmind
From my experience – long – building a prototype is fundamental but using a tool to do it might not be the best way. Cheap tools like Axure – IMHP – are a waste of time and I can’t afford expensive tools. If you are competent developer usin the final tools to build your prototype might be the best way to go…