Menu Search
Jump to the content X

Lean UX: Getting Out Of The Deliverables Business


User experience design for the Web (and its siblings, interaction design, UI design, et al) has traditionally been a deliverables-based practice. Wireframes, site maps, flow diagrams, content inventories, taxonomies, mockups and the ever-sacred specifications document (aka “The Spec”) helped define the practice in its infancy. These deliverables crystallized the value that the UX discipline brought to an organization.

Over time, though, this deliverables-heavy process has put UX designers in the deliverables business — measured and compensated for the depth and breadth of their deliverables instead of the quality and success of the experiences they design. Designers have become documentation subject matter experts, known for the quality of the documents they create instead of the end-state experiences being designed and developed.

When combined with serial waterfall development methodologies, these design deliverables end up consuming an enormous amount of time and creating a tremendous amount of waste. Waste is defined as anything that is ultimately not used in the development of the working product.

UX Discussion1
Engaging in long drawn-out design cycles risks paralysis by internal indecision as well as missed windows of market opportunity. Image by Claire Murray2.

As organizations struggle to stay nimble in the face of an ever-changing marketplace that is disrupted constantly by incumbents as well as start-ups, getting to market fast becomes top priority. Engaging in long drawn-out design cycles risks paralysis by internal indecision as well as missed windows of market opportunity. In other words, by the time the company decides internally how the product should be designed, the needs of the marketplace have changed.

Waterfall software development looks something like this:

Define → Design → Develop → Test → Deploy

The design phase typically breaks down like this:

Wait for requirements definition to take place and get approved →
Consume requirements documents →
Develop high-level site maps and workflows →
Gain consensus and approval →
Develop screen-level wireframes for each section of the experience →
Present to stakeholders and gain consensus and approval →
Create visual designs for each wireframe →
Present to stakeholders and gain approval (after repeated cycles of review) →
Write The Spec, detailing every pixel and interaction →
Usability test for future improvements →
Hand off to development for review, approval and start of implementation

This phase can take anywhere from one to six months depending on the scope of the project, leaving many wasted hours and much designer frustration in its wake.

Enter Lean UX.

Lean UX Link

Inspired by Lean and Agile development theories, Lean UX is the practice of bringing the true nature of our work to light faster, with less emphasis on deliverables and greater focus on the actual experience being designed.

Traditional documents are discarded or, at the very least, stripped down to their bare components, providing the minimum amount of information necessary to get started on implementation. Long detailed design cycles are eschewed in favor of very short, iterative, low-fidelity cycles, with feedback coming from all members of the implementation team early and often. Collaboration with the entire team becomes critical to the success of the product.

Interestingly and not surprisingly, one of the immediate casualties of Lean UX is the stereotypical solitary designer, working silently in a corner for a period of time, inviting only occasional peeks at their work before it’s “done.” This mindset is also the biggest obstacle to wider adoption of this practice.

Let’s take a look at the Lean UX process:

Lean UX process3
Stay lean and focus on the experience, not the paperwork.

Looks familiar? It should if you’re familiar with Agile or its derivatives. Lightweight concepting kicks off the process. This can be done on a whiteboard, a napkin or a quick wireframe. The goal is to get the core components of the idea or workflow visualized quickly and in front of your team.

The team begins to provide their insights on the direction of the design as well as its feasibility. Changes are then made to the original idea, or perhaps it’s scrapped entirely and a new idea proposed. The initial investment in sketching is so minimal that there is no significant cost to completely rethinking the direction. Once a direction is agreed upon internally, a rough prototype helps to validate the idea with customers. That learning helps to refine the idea, and the cycle repeats.

What’s most important to recognize here is that Lean UX is focused strictly on the design phase of the software development process. Whatever your organization’s chosen methodology (waterfall, Agile, etc.), these concepts can be applied to your design tasks.

Isn’t This Just Design-By-Committee? Link

Lean UX encourages you, the designer, to show your work early and often to the team, collect their insights and build that into the next iteration of the design. To many folks, this sounds like the dreaded “design by committee” approach, which has killed many designs in years past.

In fact, the designer is still driving the design by aggregating all of that feedback, assessing what works best for the business and the user, and iterating the design forward. By providing insight into the design work to your teammates sooner rather than further down the design road, you accomplish the following:

  1. Ensure that you’re aligned with the broader team and the business vision;
  2. Give developers a sneak peek at the direction of the application (speeding up development and surfacing challenges earlier);
  3. Further flesh out your thinking, since verbalizing your concepts to others forces you to focus on areas that you didn’t think of when you were pushing the pixels.

The trick is to stay lean: keep the deliverables light and editable. Eliminate waste by not spending hours getting the pixels exactly right and the annotations perfect. Got an idea for a flow? Throw it up on the whiteboard, and grab the product owner or project leader to tell them about it. Ready to design? Rough out the first page of the flow in your sketchpad. How does it feel? Is the flow already evident? Post it in a visible place at the office and invite passers-by to comment on it.

In the Lean UX methodology spending time on realistic goals and informed design decisions is crucial. It helps to effectively match expectations and reality for your clients. Image by Kristian Bjørnard5

As you iterate, suggestions and feedback from various team members will inevitably start to manifest themselves in the experience. The team members who suggested these ideas will begin to feel a sense of ownership in the design and notice it in others. It has now become something they had a hand in creating. This sense of ownership will equip the designer with new allies to defend the work when it comes under criticism from external forces. The team ultimately becomes more invested in the success of the experience.

Lean UX Is Not Lazy UX Link

It may seem at first that this is a lazy approach to UX, that the goal is simply to do less work. On the contrary, you’re actually using all of the tools in your UX toolkit. Sketching, presenting, critiquing, researching, testing, prototyping, even wireframing — these all get a solid workout in each cycle of the process. The trick is to use these tools when appropriate and, more importantly, to use them at the depth appropriate for the immediate problem you’re trying to solve for the business.

Designers Need to Feel in Control of Their Work Link

“But I’m giving up control of my design!” is one of the most often-heard complaints from designers who try out Lean UX. Their concern is that by collecting feedback from non-designers, they will be less valuable to the team and be relegated to the role of menial pixel-pusher.

Holding on to the concept and avoiding the unnecessary is vital in Lean UX. Image by Kristian Bjørnard7

By staying lean, however, the frequent collection of team-wide feedback actually minimizes the time spent heading down the wrong path. The designer continues to drive the design, but the guardrails (i.e. constraints) become more visible with each iteration and review. Basically, if you spend three months perfecting a design only to find out after launch that it fails to meet customers’ needs, then you’ve just wasted three months of your life, not to mention your team’s.

Lean UX also speeds up development time. By giving the team early insight into the design’s direction, it can begin to lay the groundwork for that experience. This foundational coding phase helps to expose feasibility challenges in the proposed solution. The time, material and resources available then help to prioritize the product’s elements, separating the parts that get built from those that get pushed out or reduced in scope. All of this affects where the designer focuses their energy, thus minimizing waste.

Prototyping: The Fastest Way Between You and Your Customers Link

Lean UX is where prototyping shines. As with the initial sketches, focusing the prototype on critical components of the experience is essential. Pick the core user flow (or two), and prototype only those screens. The fidelity of the prototype ultimately doesn’t matter, so create it the way you know best. Once created, it will be immediately testable by any and all users.

Successful lean prototypes have been created with code, with design software such as Adobe Fireworks and even with PowerPoint. At times, your client (internal or external) will demand a level of fidelity that helps them better visualize the experience. Work with the tool that is most comfortable and fastest for you and that delivers just enough fidelity for the client.

Next, get that prototype in front of everyone who matters internally, and validate whether you’re meeting the needs of the business.

Diagram of the iterative design and critique process. Warfel, Todd Zaki. 2009. Prototyping: A Practitioner’s Guide. New York: Rosenfeld Media.

Most importantly, get the prototype in front of customers. Bring them in regularly to test the workflows, ideally once a week. You don’t need to test with many customers. Jakob Nielsen found out9 that after five participants, the odds of finding new roadblocks in the experience were low. If you test regularly, you can cut the number of participants per week to three. This will also cut costs.

Collect feedback. Figure out what worked and what didn’t. Tweak the prototype. Hell, gut it if you have to: that’s the beauty of Lean UX. The investment you’ve put in at each phase is so minimal that rethinking, reconfiguring or redesigning isn’t crushing in workload or ego-bruising.

Once validated, demo your updated prototype to the team. Explain the flows, the user motivations and why you designed it the way you did. The prototype has now become your documentation. It is “The Spec.” Very little (if anything) more is needed. Regardless, you’re there to answer any questions that come up. The strength of Lean UX here is that, with the design validated, the designer is now freed to move on to the next core component of the experience, instead of spending six weeks creating a design-requirements document and pixel-perfect specs.

Prototyping puts the power of validating the design’s direction much more quickly in the hands of the ultimate decider: your customers. They are the ones with whom the design will speak for itself, and in the environment where it will ultimately have to succeed.

Maintaining a Holistic Vision Link

“But what about my vision? By chopping the design up and delivering it piecemeal to the team and, ultimately, customers, I’m compromising on my vision of the product and putting out a sub-standard experience!”

Lean and Agile Development are called for! Image by Kristian Bjørnard11

UX designers have traditionally worn many hats. You now have another to add to the hall tree: keeper of the vision. In this new role, your responsibility is to keep an eye on the big picture. Lean UX forces you to think of the experience in prioritized chunks. Ultimately, those chunks all have to roll up into one cohesive product. That cohesive product is your vision. Even as the design shifts and morphs through iterations and customer feedback, you are always designing towards that greater goal. “Increasing time on site for returning customers” could be a vision. “Deliver content faster and in a more contextual manner” could be another. Regardless of how the design shifts, these goals drive your work.

It won’t be easy. In the past, those hard-won, comprehensive, approved deliverables authorized you to design in a specific direction. With Lean UX, the iterative cycle and the frequent varying opinions will inevitably create conflicts with your vision. This is where you push back. Use the stated vision to help sort out conflicting feedback and focus your efforts on the end goal.

Deliverables For Maintenance Don’t Make Sense Anymore Link

Documentation has long served as a way for organizations to maintain their software. It becomes a reference tool to understand the decisions of the past, which inform the decisions of the present. While this may make sense for complex business rules, it doesn’t make sense for design. The final product is the documentation. It is the experience. Thick deliverables created simply for future reference regarding the user experience become obsolete almost as soon as they are completed. When a question arises about how something should behave in the UX, going through that workflow in the product to see what happens is easy enough. The old kind of documentation is waste and draws effort away from solving current design problems.

How Does Content Strategy and Planning Fit In? Link

Websites and applications that are focused on heavy content delivery (as opposed to task- or function-based websites) will need some up-front planning and documentation. Getting right down to the level of the page and article may not be necessary, but getting enough of an idea of the type of content that will be delivered and a sense of its hierarchy is essential to getting to that first sketch and prototype. Once the team grasps the scope and type of content needed for the experience, work can begin as the experience is refined.

Can It Be Done At My Organization? Link

At the risk of oversimplifying, let’s look at two types of organizations: the internal software/design shop and the interactive agency.

For internal software/design organizations, the transition to Lean UX is well within reach. You are in the problem-solving business, and you don’t solve problems with design documentation. You solve them with elegant, efficient and sophisticated software. Working in these new attributes should ultimately be an easy sell internally because you are advocating for more collaboration, more conversation and earlier delivery to customers. Yes, the culture will have to shift — shipping what amounts to the minimum desirable product can be a tough pill to swallow for those used to big-bang releases. However, the ability to make quicker decisions along the way, informed by regular customer feedback, should ultimately trump these concerns.

Interactive agencies have it a bit tougher because they are in the deliverables business. They get paid for their documentation and spend a lot of time creating it. A specialist creates each document, and they charge for that time. Reducing those efforts means reducing revenue.

Lean UX proposes that the shortfall in up-front revenue generated by deliverables can easily be made up, and then some, by delivering higher-quality work, faster, to the client. The process has to be modified slightly, though:

Lean UX process for an interactive agency12
Lean UX process for an interactive agency.

The core difference with the agency’s process is the regular and frequent involvement of the client. Set up twice- or thrice-weekly 30-minute reviews with them. Set the expectation that you’ll be showing rough, directional work and that you’ll want their feedback. Each time you review a directional sketch with your client, they’ll notice the evolution and progress. Their feedback will work its way in and, like an internal stakeholder, they’ll gain that sense of ownership.

By involving the client in the process, by iterating the design quickly and by testing the iterations with real customers, you will reach an optimal solution in less time than before.

In agency-land, less time typically means less revenue, which could potentially be the death knell for Lean UX. But while the output took less billable time to create, it will likely be more effective and will bring the customer back to your shop more frequently than in the past. In addition, you’ve made the client part of the process. This is empowering, and clients like that feeling.

This is not an easy change because agency culture has been the same for many decades. Only the boldest agencies will take this on. But those that do will find greater success from it and will quickly be imitated. These ideas are worth piloting on an internal project; perhaps the redesign of the agency’s website. Prove that they work, and then branch out to actual clients.

I’m a Consultant/Freelancer. Does This Make Sense for Me? Link

Consultants are, in essence, an agency of one. It stands to reason that the agency process could work in this situation as well. Constant feedback and iteration with the client will engender the same feelings of trust and co-ownership. The challenge for the consultant/freelancer is the amount of time they can dedicate to each client. Assuming they can handle multiple projects or clients simultaneously, providing the level of attention and communication necessary to maintain a true Lean UX process becomes difficult. In this case, falling back on a slightly deeper level of documentation makes sense to keep concurrent projects moving forward.

Optimize your workflow and win time. Image by Kristian Bjørnard14

It’s worth mentioning that one big challenge for Lean UX to be successful in any of these settings is the use of offshore development vendors. One of the fundamental principles needed for Lean UX to succeed is collaboration — ideally in real time and place it can even work via Skype or other virtual meeting technology. When a vendor has minimal contact with your design group and requires a certain level of documentation in order to produce work, Lean UX may not work in its entirety.

Lean UX is being actively used by a growing number of organizations. The way15 TheLadders has implemented it in a recent effort is an example of keeping deliverables light, fostering greater collaboration and achieving goals successfully.

Conclusion Link

Lean UX is an evolution, not a revolution. UX designers need to evolve and stay relevant as the practice evolves. Lean UX gets designers out of the deliverables business and back into the experience design business. This is where we excel and do our best work. Let’s become experts at delivering great results through these experiences and forgo the hefty spec documents. It won’t be an easy road. Culture and tradition will push back, yet the ultimate return on this investment will be more rewarding work and more successful businesses.

(al, vf, sp)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15

↑ Back to top Tweet itShare on Facebook

Jeff Gothelf is Neo's lean evangelist, spreading the gospel of great team collaboration, product innovation and evidence-based decision making.
Jeff is a speaker and thought leader on the future of user experience design, often teaching workshops or giving talks on building cultures that support teamwork and innovation. Jeff is passionate about advancing the principles that lie at the core of Neo, and often does so on a global scale.
Prior to joining Neo, Jeff lead the UX design teams at TheLadders and Web Trends. Earlier he worked with and lead small teams of software designers at AOL. He is the co-author (with Josh Seiden) of “Lean UX: Applying Lean Principles to Improve User Experience.”

  1. 1

    This might a bit harsh, but honestly the first decent, original writeup on SM so far in 2011. Everything else has been self-promotion, or selling ebooks, or collection of poster resources, found through various online sources, recycled tutorials, and more self-branding promotions.
    Articles like these are a rare find. I congratulate the author, on writing a fantastic post, for what is slowly but surely becoming a magazine too concerned with only itself.

    • 2

      Vitaly Friedman (Editor-in-chief of Smashing Magazine)

      March 7, 2011 6:15 am

      Thank you for your comment, but I must say I don’t agree with you at all. Can you please link to our “collection of poster resources”, “recycled tutorials” and “self-branding promotions”? Could you provide further details please? We always welcome constructive critique, but it really has to be more specific.

      What about these articles, all published in 2011? Do they match your description, too?

      In Search Of The Perfect CAPTCHA

      Examining The Design Process: Clichés and Idea Generation

      The Design Matrix: A Powerful Tool For Guiding Client Input

      Mastering Photoshop: Noise, Textures, Gradients and Rounded Rectangles

      …and the list goes on.

      I wouldn’t want the comments to go in the wrong direction here. Please respect our work and the work of our writers who all try to do their best to contibute to the design community.

      • 3

        Recycled content:

        google gives a good list too when you search for tools you need.

        Self promotion/ ebooks:

        you write one article everyday. and if that article is about yourself, why not put it in a different section for adverts of your own. or a news section.

        there are blogs out there who have reviewed the books. why talk about yourself, and tell the reader why they absolutely NEED to have your book. i call it self promotion.

        poster resources: (a term i used)

        once again. type the keywords into google.

        furthermore articles like

        should be on some self-help motivational site (yes every designer has issues sometimes, but their solutions are also different, and this is no preacher’s den)

        more recycle:

        more adverts:

        more poster resources.

        and these are mostly this year.

        so with all due respect, this is a fantastic article. nevermind if the fans of this site are offended…i like this blog, i read it everyday. and have never met any of the commentors. so i will express my opinion about the site.
        what i am trying to say is that it is articles like this that sets this blog apart from the rest (and i mean including some completely recycled blogs even on the SM network ).
        and it was nice to see the return of such a post after a long long time.

        p.s. if you think i am a troll, feel free to delete my comments from your backend.

      • 4

        While I agree with SM on this one, I feel there’s no need to try and convince someone of their personal opinion by overwhelming them with a list of articles. It shows arrogance, which is what a lot of the great articles on the SM sites actually keep telling freelancers to skip and just accept feedback from various angles.

        I think a lot of articles are great, some are obvious and just ‘another one of those’ and I personally feel there has been a change with SM since the first book – but it’s still worth a daily visit, especially with indepth articles like these.

        People should also understand that the web and business online and offline are all involved in the same community. Everybody has an opinion, and there’s old and new media, and there is a lot to learn for CEO to web designer, contracted or employed. SM fills the learning gap between beginners and the pro-Professionals.

        That there is a spot on the web like SM where everybody with experience and knowledge can share great content is clear. But obviously it means that some articles are top notch where others are just ‘very good’. If someone feels (while being constructive) this is a top notch one. I then don’t really feel it’s the right approach to jump on him and say ‘see see!! we got more content, see see!!’, it might not be the intention, but defending yourself makes it appear that’s how it comes across.

        Ergo: Keep up the good work, commenters, writers, and SM.

        • 5

          I also agree with SM and Floris,
          SM has helped every one of us in some way, that’s why we keep coming back.

          Awesome post Jeff!

      • 6

        i’m with you, hyp – this article was particularly BANGIN. i think it cut to the heart of what so many of ‘us’ struggle with, lose sleep over if we do, and a big hunk of the reasons for feeling unresolved about work while we’re standing in the shower half-consciously trying to figure out how to solve this or that on any given morning.
        but, i have to side with mr. friedman’s points – based on both technical accuracy, as well as my own ‘ordinary-joe-schmoe-reader’ perspective.
        there’ve been a few self-interested editorials this year, and they typically come off a bit flat, yes. but complaining about them is like complaining about the member drive on your local public radio station…
        question is: did you pledge?

        bottom line for me: i’ve gotten lift out of a dozen or so this year so far that have brought unseen perspective to my day, helped me manage tricky client relationships, work more efficiently, do better work…
        end of day i don’t think either one of us are going quit the daily feed any time soon.
        thanks for the thought-provoking points, and bones to both the editorial staff and jeff gothelf for this kickass piece that inspired me to stand up and start making things happen a bit differently starting tomorrow morning, by damn!


      • 7

        You guys do know that SM serves a wide audience of not just experts and gurus? There are also the beginners and intermediates that make a big part of this audience. I think SM does a great job of trying to please everyone with their content.

        And BTW….those “recyclable” articles that you talk about are of GREAT convenience to myself (and others I’m sure).


      • 8

        I agree that this is a diamond in the rough considering the level of articles that have been out this year. It has real content and makes people think about real issues and even offers a great alternative methodology.

        95% of the articles I read come from the network section.

        Smashing is a great resource regardless.

    • 9

      @hypvyper At least don’t troll on SM. This is the best design blog you will find. Everyone loves their work and respects their efforts to make design community more informative..

    • 10

      I think hypvyper is trying to say that this article is actually well written and thought through/complete, one of the rare finds on Smashing that isn’t akin to 101 level course….Not to say that there aren’t great tidbits here and there, but, as a whole this is one of the few in depth articles that goes well beyond the very basic overview of a subject (and it seems to be written by someone with some real-world experience…again, something that isn’t always the case here)

  2. 11

    Thank you for the great write up!

    “Lean UX” is actually what I’ve seen and practiced most of my agency time, since usually there is no time or money for bloated UX processes.

    • 12

      Hi –

      Great to hear! Though I would say that this process gets you to a better end result by removing bloat. It doesn’t necessarily imply less work.

      Thanks for reading!


  3. 13

    Would love to see more of these types of posts in the future—excellent article Jeff.

  4. 15

    Jason Richardson

    March 7, 2011 6:03 am

    Thank you for writing this article. I’ve had past projects where I definitely felt like the checkmarks in the “deliverable completed” category were far more important than a quality proudct being turned over. This is worth striving to develop in my organization or at least in my own process. “Lean UX Is Not Lazy UX” is an important note in this article. In fact, reading through this, I think it would keep a UX professional on their game at all times using all their tools including the team itself. Thanks again.

    • 16

      Totally agree Jason. We’re still using all of our tools and skillsets. We’re just targeting them better.


  5. 17

    This article, in particular this thought, really resonated with me:

    “The final product is the documentation. It is the experience. Thick deliverables created simply for future reference regarding the user experience become obsolete almost as soon as they are completed.”

    Not considering the product the final piece, needing mounds of “documenting” is busy work, and silly in fact- “whitepaper limbo”.

    But, I also wonder about the culture behind allowing anyone inside the organization to recommend changes to a product. While money and time is saved from outputting deliverables, I think that that time and money could be reinvested in an educational culture that promotes “hallway brainstorming”. It’s this kind of design, where everybody gets up from their machines, whiteboards and talks about design, that I’ve always loved, promoted and felt most comfortable working with.

    • 18

      Hey Van –

      Yep, organizational design thinking needs to take greater hold.


  6. 19

    As a novice in this field, would you recommend jumping right into lean UX design without learning about the deliverables-heavy process?

    Is it imperative to understand the foundations from which these UI/UX ideas came from before moving on to the lean prototyping?

    Thanks for the article. Very eye-opening.

    • 20

      Hi Carla –

      Great question! In the 90’s I took a class on audio editing. We spliced tape – physical tape. The reason, the instructor told us, was to get a full appreciation for what digital audio editing was gaining us. It worked. After going through what was, at times, a brutal mental and frankly physical exercise (tape is flimsy and susceptible to just about everything), moving to the computer to edit was a blessing.

      In the same way, I think it’s important to understand the tools and skills available to you. I don’t believe you can select the right tool without knowing its full extent and value. Once you’ve mastered them, knowing where to go “lean” becomes easier.

      Good luck.


      • 21

        One of the most sensible articles out there (and I don’t mind the long read at all).
        What even makes it more meaningful is that the you wrote something that applies to all types of process involving design.

        And I couldn’t agree more on your statement which is something I myself practice when explaining not just the value of design but things in general to most people:

        RE: I think it’s important to understand the tools and skills available to you. I don’t believe you can select the right tool without knowing its full extent and value. Once you’ve mastered them, knowing where to go “lean” becomes easier.


        • 22

          Thanks K.

          Like the old saying goes, “you gotta know where you came from to see where you’re going.”



  7. 23

    Fantastic Post! We’ve been practicing Agile UX for the past 5+ years at – the leaner the process – the greater volume and speed. There is something to be said for spending the appropriate amount of effort in nailing and documenting the requirements – needed to mitigate rework.

    I’ve found that keeping the design deliverables lean helps to keep pace with rapid and continuous deployment. Keep in mind that some clients may and often do ask for design documentation – particularly as they feel the need to take the process in-house. So it helps to be prepared to hit these at some point as you hit critical milestones.


  8. 24

    “Post it in a visible place at the office and invite passers-by to comment on it.”

    Designers are actually agreeing to this statement?

    Any team of professional designers working on a project should already feel a sense of ownership through any level of their contribution. Side-stepping the main criticism of the idea, “design by committee”, and stating collaborators need to be spoon-fed their importance only exacerbates what you acknowledged as the main obstacle of this concept: the solitary designer.

    Creative kick-offs or milestone meetings are rarely attended by creatives alone. More often, there are several other team members who are willing to contribute their own opinions and since they were invited to do so, to keep the process iterative and communal, the committee is born. This is where the concept deflates and is either bogged down by internal changes (versus client requests for change in other models) well before it reaches development.

    I agree that more time can be spent on the design stage and I recognize the importance making changes before development/deployment. However, this moves the bottleneck from outside the building to inside the building and encourages the designer to stay “solitary” until a more complete design is presented.

    • 25

      I didn’t say it was easy :-)

      There will be many obstacles including the designers themselves. This is as much a cultural shift as it is a process shift so proceed with small steps.


    • 26

      Azuki, the essential bit here is that a designer is not a sage, confidently delivering the right answer to her team. In a healthy team, your role is to channel the creative forces of the group, champion an understanding of your users and customers, and appropriately respond to feedback with sound designs _to be validated and iterated_.

      Exposing work in progress is not design by committee–it is a vital step to reducing the time between having an idea and learning from its exposure to reality.


    • 27

      I agree with you Azuki.

      I think keeping designs comps close to the vest is just more practical. Not because we want to be creative mizers, but that it’s human nature for people to drill through a comp and nitpick. A few errors in a comp that are made because of the cutting corners on proofing time cam create a storm of panic from the business owners. Designers get all sorts of hassle when the comp is low-fi. Better to bake it out right, and have a bit of delay for that.

      • 28

        Tim (@seriouslynow) nails it here. The designer-as-hero mentality needs to be worn away. If *the team* can push an experience forward collaboratively, then a low-fi version of the experience is enough to validate direction and continue iteration towards the desired end state.

        There is a level of trust here that is engendered by demystifying the design process. By “showing our work” on the way to the desirable experience we open our world to outsiders. That’s scary because it makes us fee less unique. In reality, that transparency builds trust within the team. When you have that trust, showing work in a more raw form is far less concerning and more just a point for further discussion and iteration.


  9. 29

    Great article! I do this now, but the only thing I throw on front of the wireframe is a brainstorming Mind Map. I do that with the client to pull their ideas out of their head. I use http// on the iPad. Clients love it. Better than filling out a form or answering questions. What’s great about the brainstorming part is you define the goals, so everything from that point on, has to coincide with that framework. I’ve found that usually keeps everything in line and project creep down.

    The bloated project deliverables that used to happen are still needed at some point. A lot of clients come to you with an idea that functionally, societally or financially doesn’t even work. So, what do we do, just spend a bunch of free time helping them flesh out their idea? In those instances, you have to charge for some sort of design spec. In essence, you are renting them your brain. Once you have a foundation you can move on to the real development and prototyping. I’ve been using this process for a few years now and the iPad just made it easier. When this process is followed, we get a great product out the door, every time.

  10. 31

    Love the article; and I wanted to especially comment on the illustrations. All text and no graphics makes an article plain and dull. This one is just perfect. Thanks for taking the extra time to make this a bookmark.

  11. 32

    I really enjoyed this article – thank you for posting.

    We’re in the process of actually establishing a process for our team. Until now we’ve gunslinged it every time, and we’re getting tired of reinventing the wheel.

    I especially agree with Van regarding the statement on documentation being obsolete almost as soon as they’re completed. The other thing to realize about documentation is that the thicker it is, the less likely it is to be *used*.

    • 33

      That’s spot on, Chip. The thicker the documents, the more people resort to conversation (interesting, no?) as opposed to reading “the spec.” Good luck!


  12. 34

    Some very interesting points in this article. The reality for me is that the specific nature of individual projects dictates the approach we use. I think part of the skill of the designer and the wider team is in finding the right level of documentation for the project. Different clients will have different needs / expectations, different projects will have different development needs, content needs, routes to defining the content etc. etc. The length of a project may affect the level of documentation required, on a long project the team and or client contacts may well change throughout the lifecycle of the project.

    No projects are exactly alike and a one size fits all approach doesn’t work for me.

    I definitely agree that creating documents for the sake of it is a waste of time.

    • 35

      I agree for the most part that each project is individual, but there are a few situations that come to mind where continually reworking project UX’s is highly profitable. For example, I work in the documentation department as a small-medium sized software company. Unfortunately the biggest on-running product needs a severe reworking for layout because it’s starting to confuse new users. In this type of instance I think the Lean UX idea works well mixed with a small amount of documentation. When working on projects that get sold over and over again, a standard practice can be developed over time that is beneficial to a maximum amount of customers with each iteration. It just unfortunate many companies will only use Agile in programming, and not design.

      • 36

        Lean UX is a framework – a methodology to use as much philosophically as literally. Every step you can take towards creating a greater balance between team members, reducing waste and focusing on the end goal and experience is a step in the right direction.


  13. 37

    GREAT Article! Thank you very much!

  14. 38

    I’m a novice at UX myself, and I really had no idea there was a ‘lean’ version of the work I do. Your first three paragraphs describe EXACTLY what I do all of the time. This was such a great article. I’m going to see if I can start fitting this into where I work.

  15. 39

    This is very much the approach I have followed for awhile now and it is great to see it written out this way. Cheers.

  16. 40

    I love walls! Personally, as an IA, I like putting stuff up!

    Since I was the only IA in a creative department that had 8 designers, I had a wall for IA work, because people where always wondering what wireframes meant to the bottom line. (Also, there are a lot of people in business organizations that have to be conditioned to accept wireframes as proof of concept.)

    Comps get all the attention. The wall was great because it caused all sorts of panic and arguments. It woke people up from the Agile Story Grind. Also it allowed me to post things that got rejected by business owners. Orphaned ideas that, in my humble opinion, had something worth fighting for. Innovation is fragile sometimes it just needs time for it to grow.

    I love stirring up ideas. The worst thing in the world, is a non-reactive agile team. When everyone is on an Agile Scrum Death March, they can be so focused on what stories are on this sprint, they often miss the over arching Epic.

    • 41

      “Agile Story Grind” ? “Agile Scrum Death March” ? Sorry to hear that.

      When done well, in an integrated and collaborative fashion, cross-functional scrum teams can have tremendous success. Try our some of the tactics in this article and see if increasing the transparency of your decision-making opens up new channels of conversation and team cohesion.

      Good luck!


  17. 42

    Great Article, I think few people really understand the power of prototyping in development and design. Even though i mostly run projects these days, I will often do a quick prototype just so that my design & development team understands the direction I’m taking. Even for my own personal use i prototype, here something i did over the weekend for ipad:


  18. 43

    Great Article Jeff!

  19. 44

    One of the best articulated and most comprehensive articles I’ve read in the last year. Outstanding work Jeff!

    Although I understand the use of wireframes, sitemaps, mockups, etc., which I use to employ I’ve been rapid prototyping for a couple of years now and this approach has proven very productive. I’m still very focused on ascertaining and documenting the client’s requirements, as well as, understanding their vision and expectations, however I’ve eliminated the deliverables-based practices because I came to realize that the majority of my clients weren’t interested in all the additional layers, but wanted to see a functional site.

    • 45

      Thanks Mario.

      What if you involved your clients in the refinement of the prototypes? This way, when you finally get to the finished site, they’ll feel like they had a strong part of getting there.


  20. 46

    Mariusz Woźniak

    March 7, 2011 1:23 pm

    Excellent article. I guess this approach is in fact being used by a lot of UX designers in startup environment, but I haven’t seen it all that well thought and written down yet. Thanks and congrats! :)

  21. 47

    Very well written article. Coincidentally I also came across which have both reminded me that a strong and lean process in any nature will allow for growth, ROI and certainly emphasize professionalism.

  22. 48

    The lean UX approach makes sense on many fronts and I have found it to be valuable for working with external clients. However, currently I am working on an internal software product and the QA on the project relies heavily on UX documentation for reference when testing. In your experience were the prototypes that became “the spec” for the team suitable for the QAs on the team as well?

    • 49

      Hi Cheryl –

      The short answer is yes.

      In some instances error cases had to be documented beyond the prototype. We did this on an as-needed basis.


  23. 50

    Great article Jeff!
    As a pro PM/Producer I see a lot of people fail at the practical side of agile UX:
    How do you make a quick interactive prototype with some design for the client, if it’s not a basic website but a full blown webapp or campagn for example? Our designers make screens (a lot of work, no interactivity) – I make wireframes in Omnigraffle (fast & interactive, no layout & styling). Sometimes we use Flash to quickly add interactivity to design mockups, but this could be time consuming too.

    Any thoughts or best practices from the Agile field on that?

    Cheers – Andries

    • 51

      Hi Andries –

      Everything I wrote in this article is applicable in an Agile environment. The goal is to get just enough design done to move forward. Moving forward means your dev team can gather stories and estimate, your client/stakeholder knows what you’re building and agrees you’re headed in the right direction and your design team knows what they have to refine/define next.

      The trick is to have a broad understanding of the UX toolkit and skills (sounds like you’ve got that) and to pick the right tool at the right time and, most importantly, used at the right depth. In other words, just because you’re breaking out Photoshop, it doesn’t mean you need to produce a pixel-perfect deliverable. What will be enough to get the point across? Anything beyond that is waste.

      Good luck.


      • 52

        Tnx Jeff,
        I think there is no golden grail yet, and we have to think at every step if it’s worth it or not. You’re completely right on that.

        There is a massive amount of tools, we only have to choose wisely as PM’s/Producers/.. at the right time, what’s best for team & client.

        Keep up this great series of articles! We need more pro stuff on SM :)


  24. 53

    How does this relate to the work done by ‘business analysts’? How do they fit into this picture (if at all)

    • 54

      The scope of a business analyst’s domain varies greatly from company to company so it’s hard to be specific. My experience has been with BA’s largely focused on requirements gathering and project definition. BA’s in that capacity can help define the best way to break down the project into manageable chunks that the team can then iterate forward.


  25. 55

    Excellent article and exactly at the right time for me!

  26. 56

    Great article! I work using this model for a long time and author got it very right!

  27. 57

    good one indeed.
    thanx a lot.

  28. 58

    I am currently working on a software UI (almost finished actually). This article highlights most of the challenges found in a bloated, over worked process. We are working with another development agency who have an 80 page spec list to follow most of which has fallen by the wayside. The process started at the development stage (with basic wire frames) It was very difficult to get on board and rework the ordering of the functions and user journey’s so that they were obvious and intuitive. More often than not I find clients need to see a variation of the tangible product because they can’t fully comprehend what they’re getting without it. I have always believed that agile modelling was a more organic method of working and now having been on the other side of the fence I can say that “Lean UX” will ensure a much better product is produced.

    • 59

      “More often than not I find clients need to see a variation of the tangible product because they can’t fully comprehend what they’re getting without it.”

      This is exactly where the strength of rapid, focused prototyping shines. Show them what you’re going to build, don’t tell them.


  29. 60

    Lean UX process for an interactive agency – isn’t that yet another mini-waterfalls approach? Prototypes are dangerous – they tend to be prototype forever and go online.

    • 61

      This article tries to convey a lean approach to UX design. So whether you’re in an agency, internal, agile, waterfall, agilefall, etc. these tactics can hopefully improve what your’e doing.

      With the agency, the idea is to empower the client. Instead of waiting days or weeks to show them something, show them something every (other) day. They’ll see their fingerprints in the work and become invested. You’ll also show constant progress and evolution. It’s empowering and builds confidence and trust through your transparency of process.

      If the prototype launches, that’s great! Your next project will be to iterate on that launch. :-)


  30. 62

    Jeff, you rock! Build to think while building to ship “.”


↑ Back to top