The Big Think: Breaking The Deliverables Habit

Advertisement

Right there in the center of my boilerplate for user experience strategy and 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 UX 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 UX strategist. Frankly, I don’t give a damn about deliverables. And neither should you.

1
(Image: Snoggle Media2)

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 UX Strategist’s Work

First, consider the role of a UX professional compared to what we actually spend most of our time doing.

What we are hired to do — the reason why companies seek out UX’ers 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, UX’ers 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 UX professional 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 UX 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.

3
(Image: HikingArtist.com4)

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, artifacts resulting from UX initiatives can be downright wasteful. They can even get in the way; designers (UX or otherwise) can 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 UX 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.)

5
(Image: lucamascaro6)

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 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 UX strategy 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 strategy and 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 work. 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.

Break The Habit

By focusing on The Big Think, the deliverables will matter less. And for a UX professional, focusing on effective and well-considered products is a whole lot more rewarding than dwelling on the step by step of deliverables. On your next time out, consider breaking the deliverables habit. Go from idea to code in as few steps as possible. Hefty amounts of collaboration can cure the sickly feeling that you’re an overpaid wireframer, empowering you to define strategies you know are killer work.

(al)

Footnotes

  1. 1 http://www.flickr.com/photos/snogglemedia/6254591338/sizes/z/in/photostream/
  2. 2 http://www.flickr.com/photos/snogglemedia/6254591338/sizes/z/in/photostream/
  3. 3 http://www.flickr.com/photos/32066106@N06/4885853065/
  4. 4 http://www.flickr.com/photos/32066106@N06/4885853065/
  5. 5 http://www.flickr.com/photos/lucamascaro/4811714916/sizes/l/in/photostream/
  6. 6 http://www.flickr.com/photos/lucamascaro/4811714916/sizes/l/in/photostream/

↑ Back to topShare on Twitter

Robert Hoekman, Jr, is the author of Designing the Obvious, Designing the Moment, and Web Anatomy, and is the founder of Miskeeto. He has worked with Adobe, Dodge, American Heart Association, Automattic, and countless others, and has spoken at industry events worldwide, including SXSW and Web App Summit.

Advertising
  1. 1

    I have to disagree with you on this article. I agree that focusing only on the end result and not at all on the way to get there is a recipe for disaster. The solution, however, is not to get rid of deliverables. Instead, include the PROCESS in the set of deliverables.

    For any project we do, we include a Discovery Document (which includes top-level strategy, creative strategy, content strategy, content organization, technical specifications, and wireframes) as a deliverable in the process. We count comps as deliverables. And naturally the end result is a deliverable. We also include revisions to each of these steps as deliverables. More importantly, we include deliverables for which the CLIENT is responsible (including asset delivery, feedback on each round, and so on).

    For us, “deliverables” means “what each party will deliver to the other” throughout the entire project, not just at the end. This encourages collaboration throughout the project while still giving everyone tangible items that they can expect (and when to expect them). I’ve found that using this process, you get the best of both worlds.

    10
    • 2

      Actually, re-reading your article, my first comment doesn’t address the point of your article.

      The end result IS the main thing, but how you get there is important too. I strongly disagree that hiring a designer to do wireframes is like hiring a carpenter to swing a hammer. A more appropriate simile is hiring a designer to do wireframes is like hiring an architect to do blueprints. Yes, they are a step along the way, but they are an important step and are part of “The Big Think”, as you say.

      What you end up outlining (strategy doc, activity requirements, sketch, comp & code) sounds like a set of deliverables to me, and a good one at that.

      I guess I’ve just found that in my experience, documentation and collaboration are not mutually exclusive. Documentation simply exists to make tangible the results of collaboration and “The Big Think”

      12
      • 3

        Robert Hoekman, Jr

        November 22, 2011 11:12 am

        Eric: my list is most definitely a collection of deliverables. My point is not to get rid of them, it’s to decrease them. I’ve been on way too many projects where every single screen is wireframed, no matter how trivial or how identical it might be to another screen. I’m suggesting we cut these down to the ones that describe the basic model and address most of the interaction types to be applied, and then focus on comps and living pages to inon out the details, because this is where the problems are most glaring, and where we have the best opportunity to address them.

        To your point about counting revisions as deliverables, I would never advocate this approach. I know that many agencies, in particular, do this — they charge for design work and then include a limited number of revisions to each wireframe (often 3). This approach reeks of the old “I’ll go off into a cave and design something and then you’ll either agree with it or not” approach. When I work with clients, I work with them every day, in constant communication. I sketch something, post it, and start on something else while the client responds. We iterate many, many times until we land on the solution we all believe is the right one. This is about agreeing on time, not on a number of revisions, and it depends on do a great job early on of making sure everyone agrees on the vision and design criteria.

        I hope that helps clarify.

        6
    • 4

      I agree with Eric, I like what Robert has to say in that a designer should be held mostly to an end, regardless of the means used to get there. So long as that end meets all of the goals set by the project. However, I think the deliverables that we set for a project aide both parties not only in the ways that Eric describes in his comment but also in terms of what the project does not include.

      For me, setting out the list of what will be delivered for both parties is a great tool in preventing feature creep or making sure both sides respect the scope of the project at hand. This may be more prevalent in projects where the designer is responsible for the entire end result (a live web site or product) than if they are just involved in “The Big Think”.

      0
      • 5

        Robert Hoekman, Jr

        November 22, 2011 11:19 am

        That’s a common and reasonable approach when you’re building out the thing you’re designing, but yeah, I’m not really talking about that kind of project. While I collaborate *heavily* with clients’ designers and developers throughout the strategy and design process, I don’t write code for them. I concede that this may mean I have an easier time with outlining proposals.

        Part of a strategy gig is to *define* the feature set, so feature creep isn’t something I have a problem with. My biggest struggles are usually in getting everyone to remember to vet their ideas against the vision and strategy once it’s defined.

        2
  2. 6

    Interesting view on efficiency/documentation. I would agree that maintaining wireframes, comps, etc. across multiple releases and the project (system) lifecycle introduces *many* hours of work.

    On the other hand, if you’re building something that’s expected to live and be maintained for any period of time, you want to build for the eventuality that you won’t always be there to update it. Having a clear style guide deliverable that contains information about layout spacing, typography, colors, etc. is important for maintaining a consistent look, feel and finish after you’ve moved on.

    1
    • 7

      Robert Hoekman, Jr

      November 22, 2011 11:27 am

      “Having a clear style guide deliverable that contains information about layout spacing, typography, colors, etc. is important for maintaining a consistent look, feel and finish after you’ve moved on.”

      Most definitely. But this is more a job for a graphic designer than for a UX strategist. I realize that many people do both, however, so I do see how there could be a natural contradiction in the idea of decreasing deliverables while still leaving solid guidelines in place. On strategy gigs, my main leave-behind is the strategy doc itself, which communicates the vision, design criteria, success metrics, etc, that should be used long-term to vet and validate design decisions.

      There are a million ways to design something to meet the same goal. In strategy work, the goal is the important part; the details of the design come later. I collaborate heavily with clients on those details, but The Big Think is about vision and a set of sketches or similar to offer direction.

      Part of the distinction may be in how you view the purpose of wireframes. I use them to communicate priority and message and hierarchy and such. I do *not* use them to communicate exact details. I would never hand a paint-by-numbers set of wireframes to a graphic designer. To do so would be a great discredit of his or her contribution to the project. I get ideas across in wireframes, and then collaborate on the details with the graphic designers and devs, who all have far more expertise on those aspects of a design than I do.

      0
  3. 8

    If you work as a freelancer collaborating directly with stakeholders on a very small project, you make somewhat of a fair point. However, if working on a part of a much larger team, with Information Architects, Business Analysts, User Research Groups, External Partners, Experience Designers, Visual Designers, Front End Developers ( . . .) it is sometimes very hard to get everyone on the same meeting and bounce ideas. Especially if you work in any type of a waterfall project environment, where work is completed in stages and passed down the assembly line, it is very important to have everything documented clearly. This is why it is very important to have every detail and interaction documented, so that various people don’t encounter uncertainties down the line.

    1
    • 9

      Robert Hoekman, Jr

      November 22, 2011 11:35 am

      I would never advocate a waterfall process. It’s far too problematic. A million things can and will change as projects move from ideas to sketches, from comps to code. The person holding the UX vision and strategy in mind should be involved at every step. “UX” is not a piece of a project, it’s the whole project. Every single thing that gets done, every decision that gets made (and *not* made, for that matter), affects the user’s experience. There’s simply no way to plug “UX” into a Gantt chart and expect a successful product.

      Don’t let your documentation speak for you. As your designs head down the path from sketch to code, do the speaking yourself. Be there. Be involved.

      7
      • 10

        ““UX” is not a piece of a project, it’s the whole project. Every single thing that gets done, every decision that gets made (and *not* made, for that matter), affects the user’s experience. There’s simply no way to plug “UX” into a Gantt chart and expect a successful product.”

        Love that. Excellent article.

        0
      • 11

        Just to clarify, there are numerous variations of the waterfall approach and in most the requirement gathering, design and develop stages overlap. Combining the waterfall and agile approach compromises our different views by utilizing best of the both worlds:

        “With enough requirements and supporting documentation to eliminate risks posed by distributed teams and turnover of team members, but enough collaboration and iteration to respond to changes in a relatively nimble way.

        For example, a project may follow a waterfall model but include an overlap in phases so that there are key collaboration points from team to team. This allows potential changes to surface earlier in each phase. This may also include an early release (such as a beta release to a particular user group) with a shorter iteration cycle. Feedback from that release can then be incorporated before the full deployment of the new site.”

        Russ Unger, A Project Guide to UX Design, 2009

        0
  4. 12

    I agree with Jason and Eric. Deliverables do a number of things for the client, the first and perhaps most important for the designer is that deliverables layout exactly what the designer is going to produce. Your idea and the client’s idea of the end result can often times be vastly opposite. You don’t want to find yourself doing more work than your bid contains. Perhaps your idea of the end result is simply a compelling homepage, however the clients idea of the end result is a homepage, about page, contact page etc… This makes for a sticky situation when you deem the project complete.

    Secondly, deliverables help the client to quantify your cost. For example, if you work with large corporations, your bid has to climb the food chain, eventually it’ll land on the desk of senior level management. The job of this person is to quantify your end result in comparison to the department budget. In order to create a compelling case to give you a piece of the budget they need to know how much you’re going to do for the cost. A concise deliverable run-down gives them what they need to approve the spend. Many times the final say comes from the financing department and believe me, they don’t care about the end result, they are all about the numbers and perceived value.

    Finally, again with larger corporations, your deliverable list in relation to your cost gives them an idea of the cost of your services for the future. For example, you create a homepage, about page and contact page. You charge the client a total of $3000.00 for this work. The client now has the understanding that each page you design is a total of $1000.00 in cost. Further down the line this client may want a landing page or micro campaign, they can look at your deliverables from the first project and get an understanding of the cost involved with their latest endeavor. When they come to you for the bid they often times have already gotten the general cost passed through the company and are ready to sign the contract and move.

    I like to keep surprises to a minimum with my clients. The more black and white I am with my bid and deliverables the more black and white they are with their budget and the quicker I get paid. It adds up to a better relationship between myself and the client and I get more return work this way than I do by generating a random bid based on undetermined deliverables.

    0
  5. 13

    I like the theory of this article, but I don’t think it’s practical. One major problem area for any project is scope drift, and the ability to set expectations. This protects both the client and the designer/firm. Deliverables are the quantifiable milestones that let each party know that a portion of the project is done.

    Using the house analogy, can you imagine your home builder saying, “Ok I’m not going to tell you specifically what you are going to get with the house, but I do have this visions statement that declares it will be big, spacious, and have a great view. Here are a few sketches that we may or may not go with.”

    As a business owner, I wouldn’t hire any firm under contract that didn’t tell me specifically what they were going to accomplish, it’s leaving my butt out there to be burned. As a designer, the same thing is happening. In the end if the client decides to go a different direction, runs out of money, whatever, they can simply claim that you didn’t complete what they understood the project to have been. “I thought you were including a shopping cart?”

    Ultimately in an ideal world people will just pay designers and trust them to carry out all their wildest fantasies, but in reality this approach, in my opinion, is setting people up for failure and heartache on both sides of the fence.

    2
    • 14

      Robert Hoekman, Jr

      November 22, 2011 11:44 am

      It sounds like you and I handle different aspects of product development. When people hire me, it’s for the very reasons you are dismissing here: to establish vision, design criteria, and direction. I don’t build, I define, and then collaborate with the builders. As I said in an earlier reply, it’s hard to have a scope-creep problem when it’s your job to define the scope in the first place.

      I agree that no one would hire a home-builder to do what you listed, but that’s because it’s not a home-builder’s job to figure out what the customer wants and how to make it happen. Granted, I’ve never bought a house or taken part in building one, but I believe that job belongs to the realtor, no? Applying your analogy, you and I have very different roles. Does that help clear up the confusion?

      0
      • 15

        That makes sense. It would be nice to see the role you are referring to more clearly defined in the article, it might help focus it a bit more. It sounds like what you do is more on the marketing/branding side than actual web design and build…?

        -3
  6. 16

    In my experience clients are just unaware that they really don’t want to judge progress by deliverables like wireframes. What they want is to be welcomed into the 21st century by explaining the advantages of planning by feature.

    The difference is, if you plan by task you get deliverables like wireframes or prototypes. Your ability to produce those deliverables are not the reason for hiring you. I hope. It’s just a leftover method to keep up the appearance of control over a project. The problem is that the client eventually wants a product that can be used. In a multi-feature project, an individual wireframe gives you no accurate information on how usefull or, in terms of money, valuable your (partial) product has become.

    However, by planning by feature you’ll get ‘deliverables’ like ‘I want a shopping card usable by a 12 year old child that makes him feel happy’. Admittingly that is definately much harder to define by a certain level of (technical) detail. But then again, even though it appears more vague, that weird looking story will actually give the designer both the clearity of the goal and the freedom to look around for creative solutions.

    It’s amazing to see what that change of focus will do to customer satisfaction. Especially after he realizes that by deliverying by feature, he can actually monitor the progress of the project in a MUCH more meaningfull way.

    3
  7. 17

    It sounds as if you’re explaining one of the core ideas behind Lean UX. I agree with previous posts where it has been said that heavy collaboration with clients to ensure a high quality product/design and how you break down the costs to a client are not mutually exclusive. Raise awareness with your agency sales director or whoever is in charge of pitching to clients that our approach is one of collaboration and ensure the approach is integrated in to core procedures.

    I like the idea of providing better value for money and a higher quality of project for clients by using a revised ideology but feel the phrasing of how we go about doing so hasn’t quite been defined as fit for purpose so far.

    Simon
    sidavies.co.uk

    0
  8. 18

    I have an idea… I’ll hire you for a gig, no list of deliverables, we’ll just skip the price line of our agreement too since the amount your work is worth to me will be variable also…

    I joke, but really you should be working time and materials, not based on a quote. If you can define deliverables, go for a fixed bid, if you can’t go time and materials. You still need to give an estimate, but now your estimate can be “I’ve done projects like this one, this one, and this one for about XX hours, and I feel like yours is a similar scope, let’s check in after a week and make sure we’re on track…

    0
  9. 19

    As someone who is hired to solve a problem, one should be able to hold the hammer, learn how to swing it properly, and make sure to nail the plank and not bend the nail.

    While you have a great point mentioning about optimizing the work done from point A (idea) to point B (product), you should not devalue the process of wireframing. It serves as a guide as you design and code.

    0
  10. 20

    Michaël van Oosten

    November 23, 2011 7:43 am

    Nice read Robert. And since there is a nice discussion going on here, you did an excellent job ;)

    I follow you on some parts: as a developer DRY is part of my system. When I look at some wireframe documents, I see at lot repetition. Wouldn’t it be more appropriate to just deliver a set of components? Both for designers as developers this would make perfect sense …

    … on the other hand we have to deal with clients. Some clients are not used to be part of a webproject; they sometimes have trouble to visualize certain parts of the site when they are not defined. Taken this in consideration it is wisely to have a wireframe document with more repetition designers and developers would neccessarily ‘need’. It is a nice clear picture of what the client can expect further on in the process. No surprises for the client and also not for designers/developers who all of a sudden need to build something which hasn’t been wireframed.

    0
  11. 21

    Honestly, one of the best articles I have ever read.

    This advice and thought process comes at a very relevant time in my career.

    Many thanks for this

    3
  12. 22

    Nice article Robert. I do agree that the wireframe process should be cut down. I’m fairly new to the the design realm (started in SEO), but I really enjoy designing webistes rather than marketing them (SEO /SEM). The first site I did, I wireframed just about every page of the 150 page site in Fireworks (I’m one of the minority who prefers fireworks over photoshop). Here is the end result of my first design: http://www.deltaone.com. I noticed that this process was redundent and took up alot of time. So on my next one, I just wireframed the 6 or 7 different templates and then went right into the design. On my third project I noticed that it was much more effective to just wire the home page layout and the general sub page layout. Once I get those two basic themes out of my head and into pixels, I then start ironing out all the details in the acutal design. I’d like to hear your thoughts on this as I am new to this area and would like the feedback.

    -2
  13. 23

    Thanks Robert. This article has totally reshaped my freelancing style.

    0
  14. 24

    “If the client is unwilling or unable to spend time and energy on the design as you develop it, find another client”. Sounds cool.

    In other words if a client doesn’t do what you think he should then fire him ?

    Maybe ok if you have a thousand clients waiting in line, otherwise there may be some alternatives….for example killing him and throwing is body on the world wide web.

    0
  15. 25

    Daniel Schutzsmith

    November 24, 2011 5:07 pm

    Robert, I understand where you are coming from with this article having literally worked on some projects with you in the past but i don’t think reducing the number of deliverables is necessarily correct, rather its explaining them in detail.

    For instance, in our proposals at Mark & Phil (markandphil.com) we literally say whether a deliverable is going to be mandatory or might be a possibility based on the findings or strategy we take as the project progresses.

    Also, to say that folks should NEVER do waterfall projects shows a bit of ignorance. There is a time and place for waterfall and a time and place for agile as well as three other project methodologies we follow.

    Really I know that success on projects with clients comes down to just being honest with them. It took me years to realize this but once I did, and started my own company because of it, I started to work with clients and on projects that I could only dream of previously. HONESTY in all forms is the absolute best policy, especially when outlining your deliverables.

    1
    • 26

      This article is a fine synthesis, thanks for sharing your experience. Sometimes it is necessary to think out of the box especially for designers.

      Nevertheless I sincerely doubt that reducing the number of deliverables could improve something. Above all it depends on openess and respect for deadlines. Clients love step-by-step projects because it’s accurate an under control. The Big think results from a complexe process and it is reassuring for clients to break it down.

      Last but not least: the time you spare y reducing the amount of deliverables could be actually wasted because of misunderstandings.

      1
    • 27

      Robert Hoekman, Jr

      November 30, 2011 10:20 am

      “There is a time and place for waterfall [...]”

      Not when it comes to UX. Design is holistic. It’s not a “phase” in a project, but an effect of the entire project. Every decision affects it, from beginning to end. Slotting “UX” into a finite timeline is an approach riddled with flaws. Many crucial decisions get made before and after a phased design effort, and they all run a high risk of damaging the user’s experience.

      Waterfall is bad for design. I’ll stand by that statement any day.

      2
  16. 28

    Thanks Robert for this great article.

    I have gone through the entire discussion, however regarding the entire debate, I would say since everybody has a different set of experiences while working with different clients either from a design firm, corporates or as a freelancers, they had a set of different experiences and thats how each process differs from others.

    0
  17. 29

    Ya very true… Agree with you on decreasing the number of deliverables and focusing on the end result. Many a times, when we work in larger teams the process tends to overrule the spontaneity of the individuals. Thereby innovation or excellence never shows up… We just become like one among the herd.

    0
  18. 30

    Just because your work product is an intangible doesn’t negate the fact that what you produce for the customer is a deliverable, and should be clearly defined at the beginning of the engagement. Failing to nail down the definition of your deliverables carries as much risk for the designer as for the customer. You could put in a thousand hours, strongly believe you’ve met or exceeded all the requirements of your contract, and the customer could point to a poorly written scope of work and list of deliverables and demand twice as much of your time. In addition, if your design skills are in such demand that developing images or wireframes is beneath you, it might be a better decision for you to subcontract that portion of the work and bill for it rather than simply toss it back to the customer. Our role is to solve the customer’s identified problem. I that includes removing the headache of creating immdiately usable copy, then by all means deliver it, and bill accordingly.

    2
  19. 31

    I think the problem is overuse (perhaps misuse?) of the word “deliverable”.

    It seems correct to me to describe a contractually specified, tangible unit of work as a “deliverable” – especially when the item in question has an associated value (either in dollars or time). Examples might be a product specification or a competitive analysis. If a client sees enough value in a “deliverable” to pay for it explicitly, then call it out and assign a value.

    However, an artifact of collaborative communication not expressly given value in an agreement (perhaps instead listed in a process doc) should probably not be called a deliverable just because it is shown to the client. In this context, the item in question is valuable only as a tool or documentation employed to help achieve the result for which the client is paying.

    Traditional agencies look at billable hours as units of value measurement, both in agency of record and project based situations. Even when they price a project at market value, they scramble to find a “time spent” justification of the charges. I suspect this might be a contributor to the perceived need for incremental “deliverables” throughout the course of a project.

    0

↑ Back to top