Right there in the center of my boilerplate for design proposals is a section that I glare at with more resentment each time I complete it. It’s called “Deliverables,” and it’s there because clients expect it: a list of things I’ll deliver for the amount of money that I specify further down in the document. Essentially, it distills a design project down to a goods-and-services agreement: you pay me a bunch of money and I’ll give you this collection of stuff. But that isn’t what I signed up for as a designer. Frankly, I don’t give a damn about deliverables. And neither should you.
(Image: Snoggle Media)
Case in point: for months now, I’ve worked consistently with a particular client for whom I do almost no work on actual design artifacts (wireframes, prototypes, etc.). Rather, I hold frequent calls with the main designer and developer to go over what they’ve done with the product (i.e. poke holes in it) and what they should do next (i.e. help prioritize). Some days, they hand me wireframes; sometimes, a set of comps; other days, live pages. Whatever the artifact, our purpose is always to assess what we have now versus where we need to get to. We never talk about the medium in which these design ideas will be implemented; we focus strictly on the end result, the vision of which we established long ago and continually refer to. And in working this way, we’ve been able to solve countless significant problems and dramatically improve the client’s website and products.
It’s not about deliverables. It’s about results.
Understanding why this works depends on understanding the real role of the designer and the deliverables they create.
What designers are hired to do — the reason why companies seek out designers in the first place — is what my friend Christina Wodtke calls “The Big Think”: we’re hired to solve problems and develop strategies, determining what needs to be achieved and making design decisions that help to achieve it. But because companies have a compulsive need to quantify The Big Think, designers end up getting paid to create cold hard deliverables. Our very worth, in fact, is tied intrinsically to how well and how quickly we deliver the stuff. Heck, we’re often even judged by how good that stuff looks, even when much of it goes unseen by a single user.
Is this how it should be done? Absolutely not.
Hiring a designer to create wireframes is like hiring a carpenter to swing a hammer. We all know that the hammer-swinging is not what matters: it’s the table, the cabinet, the deck. Clients don’t hire us to wield hammers, but to create fine furniture. It’s not the process they need or the tools, but the end result.
In theory, companies understand this. In practice, not so much. They cling to the deliverables.
The purpose of a design artifact, whether a wireframe, prototype or sketch, is to illustrate our thinking. Pure and simple. It’s part of the thinking process. It’s also, according to some, a record to look back on later to aid when reconsidering decisions, tweaking the design and so on. But let’s be honest: people rarely look back at these documents once the design grows legs and starts walking on its own. More often than not, significant changes result in new wireframes, and minor tweaks are made on coded screens, not back in the deliverables that we were paid so much to create.
(Image: HikingArtist.com)
Most of the time, design artifacts are throwaway documents. A design can and will change in a thousand little ways after these documents are supposed to be “complete.” In terms of allocating time and budget, design artifacts can be downright wasteful. They can even get in the way; designers could get attached to ideas as they transition to functioning screens, precisely when they need to be most flexible. Every design is speculation until it’s built.
Like it or not — and some of you will surely disagree — we can survive with fewer deliverables. Of course, what this looks like depends on how you work.
Interestingly, only one of these parts involves complicated design artifacts. The vision is merely a statement that describes the purpose and desired outcome. Requirements are but a list. Success metrics? Another list. The only part that involves more than a simple, concise summary is the design itself. And nothing requires that process to involve layer upon layer of wireframes, prototypes and comps before going to code. (More on how to change this in a minute.)
(Image: lucamascaro)
Comps, of course, are a must when graphics are involved; in addition to necessarily being the source of the graphic files to be used in the actual design, they define the visual language, the specifics of layout, spacing, typography, etc. Creating wireframes, on the other hand, as quick as it is compared to creating coded screens, can take much longer than going from sketch to code. So, consider cutting the load down to what’s most essential and useful: the interaction model.
In other words, you don’t have to create wireframes and comps for every idea or every screen; just for the toughest screens, the ones that define the most crucial interaction paradigms. Use them to iron out the model, not every last detail.
It’s time for more design and less stuff. Consider the revised process below.
Forget the lengthy strategy documentation. Forget the deck of wireframes. Just short summaries (long enough to get the point across, but short enough to be able to do quickly), sketches and comps, limited to the things that need to be brought to a boil in Photoshop. Skimping on the deliverables can save a lot of time.
Set the expectation from the beginning that you will work with stakeholders collaboratively. They will help you think through the design at every step. You will not be a wireframe monkey. Rather, you’ll focus on The Big Think. And you’ll do it together. If the client is unwilling or unable to spend time and energy on the design as you develop it, find another client. A client who is too busy to get involved in the process is a client who doesn’t care about their customers.
Collaboration is essential to great design. No one person can think of everything or always have the best ideas for every aspect of a product. It takes a group to make this happen. This might require you to occasionally browbeat the client into being available for frequent discussions on new and developing ideas, but the result will be infinitely better. And with the added input, you can focus less on stacks of deliverables and more on converting rough ideas into comps, prototypes and/or functioning pages that give undeniable weight to those ideas.
In practical terms, this means working closely and constantly with the visual designers and developers (assuming you’re not doing this work yourself). And it means frequently reviewing what’s being done and discussing at a deep level and at every step how to make improvements. It means talking through every detail and making sure someone has the job of being the resident skeptic, questioning every idea and decision in the interest of pushing the design further.
(Image: Snoggle Media)
Case in point: for months now, I’ve worked consistently with a particular client for whom I do almost no work on actual design artifacts (wireframes, prototypes, etc.). Rather, I hold frequent calls with the main designer and developer to go over what they’ve done with the product (i.e. poke holes in it) and what they should do next (i.e. help prioritize). Some days, they hand me wireframes; sometimes, a set of comps; other days, live pages. Whatever the artifact, our purpose is always to assess what we have now versus where we need to get to. We never talk about the medium in which these design ideas will be implemented; we focus strictly on the end result, the vision of which we established long ago and continually refer to. And in working this way, we’ve been able to solve countless significant problems and dramatically improve the client’s website and products.
It’s not about deliverables. It’s about results.
Understanding why this works depends on understanding the real role of the designer and the deliverables they create.
A Designer’s Work
First, consider the role of a designer compared to what we actually spend most of our time doing.What designers are hired to do — the reason why companies seek out designers in the first place — is what my friend Christina Wodtke calls “The Big Think”: we’re hired to solve problems and develop strategies, determining what needs to be achieved and making design decisions that help to achieve it. But because companies have a compulsive need to quantify The Big Think, designers end up getting paid to create cold hard deliverables. Our very worth, in fact, is tied intrinsically to how well and how quickly we deliver the stuff. Heck, we’re often even judged by how good that stuff looks, even when much of it goes unseen by a single user.
Is this how it should be done? Absolutely not.
Hiring a designer to create wireframes is like hiring a carpenter to swing a hammer. We all know that the hammer-swinging is not what matters: it’s the table, the cabinet, the deck. Clients don’t hire us to wield hammers, but to create fine furniture. It’s not the process they need or the tools, but the end result.
In theory, companies understand this. In practice, not so much. They cling to the deliverables.
The Essence of Deliverables
So let’s look at what a design deliverable really is.The purpose of a design artifact, whether a wireframe, prototype or sketch, is to illustrate our thinking. Pure and simple. It’s part of the thinking process. It’s also, according to some, a record to look back on later to aid when reconsidering decisions, tweaking the design and so on. But let’s be honest: people rarely look back at these documents once the design grows legs and starts walking on its own. More often than not, significant changes result in new wireframes, and minor tweaks are made on coded screens, not back in the deliverables that we were paid so much to create.
(Image: HikingArtist.com)
Most of the time, design artifacts are throwaway documents. A design can and will change in a thousand little ways after these documents are supposed to be “complete.” In terms of allocating time and budget, design artifacts can be downright wasteful. They can even get in the way; designers could get attached to ideas as they transition to functioning screens, precisely when they need to be most flexible. Every design is speculation until it’s built.
Like it or not — and some of you will surely disagree — we can survive with fewer deliverables. Of course, what this looks like depends on how you work.
Breaking the Deliverables Habit
The most important parts of any design project are the vision of the end result, the requirements for it, the design itself, and a way to measure its success.Interestingly, only one of these parts involves complicated design artifacts. The vision is merely a statement that describes the purpose and desired outcome. Requirements are but a list. Success metrics? Another list. The only part that involves more than a simple, concise summary is the design itself. And nothing requires that process to involve layer upon layer of wireframes, prototypes and comps before going to code. (More on how to change this in a minute.)
(Image: lucamascaro)
Comps, of course, are a must when graphics are involved; in addition to necessarily being the source of the graphic files to be used in the actual design, they define the visual language, the specifics of layout, spacing, typography, etc. Creating wireframes, on the other hand, as quick as it is compared to creating coded screens, can take much longer than going from sketch to code. So, consider cutting the load down to what’s most essential and useful: the interaction model.
In other words, you don’t have to create wireframes and comps for every idea or every screen; just for the toughest screens, the ones that define the most crucial interaction paradigms. Use them to iron out the model, not every last detail.
It’s time for more design and less stuff. Consider the revised process below.
1. Strategy Document
Distill your research on users and the business down to a short vision statement on what the user’s experience should be like. Add to this a list of design criteria (specific guidelines or principles for the design), as well as success metrics (how you will know that the design is achieving your goals). You should be able to do all of this within just a couple of pages; and keeping it short will help to ensure that everyone reads it.2. Activity Requirements
Write a list of tasks that users should be able to perform, and functions that the system should perform that will benefit users. Prioritize the ones that will appear on the screen.3. Sketch
To apply the design criteria and meet (or exceed!) the requirements, sketch a dozen or so ideas — in Keynote, on paper or on a whiteboard — and then take pictures of the sketches. Sketch the toughest, most complicated and most representative screens first. These will frequently determine the interaction model for most of the design.4. Comp and Code
If you’re not doing the visual design yourself, collaborate with the graphic designer to iron out the details of the most representative screens and any other screens that require graphics. At the same time, collaborate with the developers to identify issues and areas for improvement throughout the process.Forget the lengthy strategy documentation. Forget the deck of wireframes. Just short summaries (long enough to get the point across, but short enough to be able to do quickly), sketches and comps, limited to the things that need to be brought to a boil in Photoshop. Skimping on the deliverables can save a lot of time.
Untying Deliverables From Project Fees
Of course, sufficing with this shorter list of artifacts and untying deliverables from your fees require a change to the design process. In short, we need to shift the emphasis from documentation to collaboration.Set the expectation from the beginning that you will work with stakeholders collaboratively. They will help you think through the design at every step. You will not be a wireframe monkey. Rather, you’ll focus on The Big Think. And you’ll do it together. If the client is unwilling or unable to spend time and energy on the design as you develop it, find another client. A client who is too busy to get involved in the process is a client who doesn’t care about their customers.
Collaboration is essential to great design. No one person can think of everything or always have the best ideas for every aspect of a product. It takes a group to make this happen. This might require you to occasionally browbeat the client into being available for frequent discussions on new and developing ideas, but the result will be infinitely better. And with the added input, you can focus less on stacks of deliverables and more on converting rough ideas into comps, prototypes and/or functioning pages that give undeniable weight to those ideas.
In practical terms, this means working closely and constantly with the visual designers and developers (assuming you’re not doing this work yourself). And it means frequently reviewing what’s being done and discussing at a deep level and at every step how to make improvements. It means talking through every detail and making sure someone has the job of being the resident skeptic, questioning every idea and decision in the interest of pushing the design further.
No comments:
Post a Comment