Once upon a time, I worked with a designer who refused to use any tool except Illustrator. Everything got made in Illustrator, whether he was building a visual design mockup, a task flow, or a discussion guide for a user research session (seriously). All of his deliverables were gorgeous.
He was also the slowest designer in history. Every single thing he did took five times as long as it would have taken anybody else, and much of it wasn’t very usable or useful. Pretty, though.
While the visual interface, if your product has one, is an important part of the user experience, it’s not the entire user experience. And that means that the deliverables designers create to demonstrate a visual interface are not the only deliverables they need to make.
So, if designers aren’t going to just produce pixel perfect Photoshop or Illustrator files, what sort of deliverables should they be creating? That’s easy. They should make whatever they need to communicate the thing that needs to be communicated to the audience to whom they’re communicating it.
Let’s get a little more specific. First, you have to understand the role that design deliverables play in the product development process. Designers, the good ones anyway, help to craft the experiences that users will have with a product, but they are rarely the ones to build the end product. Of course, there are designers who also code or build things, but even when this is true, there are typically other people on teams who also need to build things that the designer has specified. This means that the designer needs to create some set of documents or artifacts showing other people what to build.
But those aren’t the only deliverables that designers create.
In fact, designers make artifacts for three general reasons:
Deliverables for Creation
The first type of artifact or deliverable that designers use are those that are helpful during the creation and ideation phase of design. These are tools that designers use by themselves or with small groups of people working together in order to get ideas out of their heads and into the physical world.
These sorts of deliverables might include things like sketches, ideas written on sticky notes, affinity maps, or dozens of other works in progress. In fact, many of the exercises in my upcoming book, Build Better Products (Rosenfeld Media ‘16), produce these sorts of deliverables — often bunches of sticky notes presented in some sort of framework.
These deliverables are great for communicating within a small team and making sure that everybody is talking about the same thing.
Ideally, these are done roughly and quickly, since they’re essentially temporary and meant to facilitate a meeting or work something out in a group. In fact, they’re hardly deliverables, at all. You might prefer to call them artifacts of the design process, if that’s what you’re into.
When done right, these artifacts are incredibly useful to the people creating them and completely useless for communicating anything to anybody who wasn’t there when they were made.
Even when what you’re creating is a visual design, the early stages of working out that design can be done quickly with the goal of iterating through lots of ideas to find the one you want to move forward with. Many visual designers start with mood boards or collections of colors and examples of typography and imagery in order to narrow down the exact look and feel they want to achieve. Again, these don’t tend to be that helpful to anybody who isn’t the designer or at least extremely familiar with the visual design process.
That’s fine. Artifacts that help the creation process are not meant to be used for communication to other people after the fact. There are entirely different deliverables for those.
Deliverables for Communication
Designers have to communicate their ideas to other people. Frequently, they have multiple audiences for that communication. For example, they may have to communicate designs or concepts to engineers who are going to build the product. They may have to communicate new feature ideas or directions to customers in order to get feedback. They may have to present things to managers or execs within the company.
Each of these different audiences can require different types of deliverables. In fact, any given audience might require different types of deliverables depending on the purpose of the communication.
Some executives simply can’t stand seeing any designs that aren’t complete, pixel perfect, and fully interactive. Others might be fine with an early sketch or even a task flow. Depending on what the engineers are building, they might prefer a well constructed task flow and a set of detailed user stories rather than a static Photoshop mockup. At other times, they might need a detailed visual design specification.
Deliverables for communication are a type of product in themselves. You need to understand who the intended audience is and what you want to communicate to them.
However, these deliverables do tend to be higher fidelity than deliverables that are only intended to help the designer create things. Because they are meant to communicate complicated ideas to people who may not have had anything to do with their creation, they have to be easier to understand than the type that are used merely to help a team think about the product together.
Deliverables for Validation
Another type of deliverable is used for validation. For example, a designer might produce a mockup or interactive prototype for the purpose of usability testing or to get feedback from a customer on a particular direction the team is thinking of going.
As with the deliverables for communication, what you produce here is going to depend on your audience. Some customers may be comfortable with low fidelity sketches or static pictures of features, but in general, these are going to be the most detailed deliverables a designer creates.
There are good reasons for this. When you’re usability testing a prototype, you can get much more realistic feedback from a prototype that behaves like the final product. If you’re trying to get feedback from a customer about a possible feature, there’s an excellent chance that the customer doesn’t have nearly as much information about the product as you do, so showing a more realistic example will help them to assess whether it’s an interesting feature.
Of course, the type of deliverable that you share here will also depends on what your goal is. Are you interested in getting usability feedback? You probably want an interactive prototype. Do you want to get customers excited about an upcoming feature? A high fidelity mockup might be better.
In general though, when sharing with outside people, avoid very high level sketches and concepts or boxes and arrows, since outsiders will have a difficult time understanding what they’re looking at.
Why On Earth Does This Matter?
Ok, that was a lot of time spent talking about things that designers make, and you may be wondering why it’s useful. It’s not just designers that create artifacts and deliverables. Everybody on your team creates them, all the time. You probably create documents, decks, spreadsheets, emails, and a dozen other types of documents every day.
Many teams have trouble communicating because they create the wrong types of artifacts for the job they’re trying to do. Thinking about what you’re trying to communicate and to whom will help you determine the correct level of specificity required from a deliverable.
Being thoughtful about this can save you a huge amount of time — both because it keeps you from creating overly detailed deliverables and because it prevents a lot of confusion that can happen when you share the wrong level of deliverable with a team member or customer.
Let me give you an example. Let’s say you’ve just had a meeting with your team where you’ve been sketching possible feature ideas on a board. Maybe you’ve gotten to the point where you all agree on a direction and even sketched some wireflows. In order to make sure that everybody remembers what you decided, you take a picture of the whiteboard and attach it to the story in your issue tracker.
Now imagine that a new engineer has just joined the team, and they weren’t in the meeting where you had that discussion. How useful will that picture be? Or, imagine that you share it with a customer who requested a similar feature in order to get feedback. Do you expect that the customer will be able to give you any sort of useful information about what you’re sharing? Very unlikely.
On the extreme other end, let’s say that you decide that you need to make a change to your app to allow users to opt out of certain notifications, and you need to share the specifics with the engineers who will be building it. Do you really need a fully prototyped, pixel perfect version of the feature? Or would a quick task flow and a sketch showing the changes be more useful to the engineer who is implementing the change?
Instead of always creating the exact same deliverables or whatever’s easiest — photos of whiteboards, powerpoint decks, Photoshop mockups — think about the audience for the deliverable and what you’re trying to communicate. And make sure that everybody on your team does, as well.
A Deliverables Framework
When you’re deciding on what sort of deliverable to create, you need to consider the following:
- who is your audience?
- what are you trying to communicate?
- what sort of action do you want them to be able to take?
Honestly, the best way to find the right deliverables with your team is to sit down with them and understand how they work, and then experiment with different levels of fidelity. If they want something with significantly more detail than you think is justified, talk to them to understand why.
Are they trying to avoid a problem they’ve had in the past? Are they uncomfortable making decisions? Are they new and lacking any of the background? Are you just really bad at judging how much direction someone might need? All of these are possible. In other words, treat your deliverables like a design problem and your coworkers or customers as the users of those deliverables.
Once you understand your user and what you want to communicate to them, you need to have a firm idea of what sort of action you’re expecting from them. Are they supposed to implement a feature? Give usability feedback? Help you flesh out a concept? Estimate the amount of work something would take? Greenlight a new project? You should always give people what they need in order to give you the sort of feedback that you want.
In other words, don’t expect people to give you usability feedback on a high level sketch. There simply isn’t enough information there to respond. On the other hand, a developer shouldn’t need a fully functional prototype with complete visual design to start working on building a feature.
Once you know who you’re communicating with and what you’d like to get back, you need to pick the right deliverable. Deliverables can come in a dizzying array of styles. Let’s look at a framework for deciding which is right for what you need to do.
The first question you need to ask about your deliverable is whether it needs some visual component. In other words, can it be described easily in words or a story? Or does it need a conceptual model? A sketch? A full visual mockup? This depends on what it’s conveying, of course.
Many things benefit from being shown visually. For example, explaining the layout of a page or the context of use for a product can be done much better with images than with words.
However, other things, like how often an email gets sent or which pricing plans to offer to different types of customers might be better shown in something like a spreadsheet or user story. When you’re communicating something, don’t just fall back on whatever you’re used to. Ask yourself, “could this be communicated better with an image or with a story?”
If you do need something visual in your deliverables, the next question you need to ask is how high fidelity does it need to be.
You should be careful here. While high fidelity visual designs can make users or team members feel more like a product is “real,” having a very finished looking prototype can get you worse feedback on your idea. When confronted with pretty, finished looking mockups, people tend to focus on the look of them rather than whether they’re useful or usable. A gorgeous demo looks like a fait accompli, and you’ll rarely get good input other than surface level visual comments.
You also need to decide how interactive your deliverable should be.
Again, how interactive something needs to be depends on the sort of feedback you want. You’ll get significantly better usability feedback on an interactive prototype than you will on a sketch or a static mockup. People who can play with something that feels like a real product won’t have to imagine nearly as much as they would if they were looking at a set of user stories. That said, interactive prototypes take time to build, and sometimes you don’t need that level of feedback.
The last thing to consider when creating a deliverable of any sort is how maintainable it needs to be. Everybody forgets to take this into account, and it’s exactly the sort of thing that will cause you problems six months from now.
Imagine that you’re creating a set of personas. A huge number of teams seem to think that personas should be turned into posters that can be printed out and displayed around the office. That’s fine. It can make them very high visibility.
However, imagine that three months from now you realize something that needs to change about the persona. How do you do that? You’d have to remake all the posters. That’s not terrible for things that are fairly simple and aren’t likely to change constantly. But if you’re building a product prototype for usability testing, being able to quickly and constantly make changes as the product changes and features get added will save you an enormous amount of time in the long run. If you’re building an interactive demo to show to high level execs in order to get funding for a project, on the other hand, being able to update that demo later is significantly less important.
The most important thing to remember in all of this is that deliverables, like everything else in the product development process, are not one size fits all. All the deliverables you create have a purpose and a user. Understand those before you make anything at all.
Originally published at www.usersknow.com.