Lean UX: Getting Out Of The Deliverables Business

Advertisement

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 Discussion
Engaging in long drawn-out design cycles risks paralysis by internal indecision as well as missed windows of market opportunity. Image by Claire Murray.

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

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 process
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?

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.

Screenshot
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ørnard

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

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

“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.

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

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

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.

Screenshot
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 out 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

“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!”

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

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

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?

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?

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 agency
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?

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ørnard

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 way TheLadders has implemented it in a recent effort is an example of keeping deliverables light, fostering greater collaboration and achieving goals successfully.

Conclusion

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)

↑ Back to top

Jeff Gothelf is a user experience designer based in metro NYC. He has spent his career designing engaging experiences for clients big and small. He is currently the Director of User Experience at TheLadders.com where he helps executive jobseekers and recruiters make meaningful connections with each other. Previously Jeff helped shape the designs of AOL, Webtrends and Fidelity. Jeff publishes his thoughts on his blog and on Twitter. Jeff is presenting Lean UX: Getting Out of The Deliverables Business at this year's SXSW 2011 conference and the IA Summit.

  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.

    0
    • 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
      http://www.smashingmagazine.com/2011/03/04/in-search-of-the-perfect-captcha/

      Examining The Design Process: Clichés and Idea Generation
      http://www.smashingmagazine.com/2011/02/21/clich-s-and-idea-generation-how-to-turn-clich-in-a-successful-visual-solution/

      The Design Matrix: A Powerful Tool For Guiding Client Input
      http://www.smashingmagazine.com/2011/02/09/the-design-matrix-a-powerful-tool-for-guiding-client-input-amp-creating-better-websites/

      Mastering Photoshop: Noise, Textures, Gradients and Rounded Rectangles
      http://www.smashingmagazine.com/2011/02/07/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.

      23
      • 3

        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.

        8
        • 4

          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!

          3
      • 5

        Recycled content:
        http://www.smashingmagazine.com/2011/02/08/useful-web-services-tools-and-resources-for-web-designers/

        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.
        http://www.smashingmagazine.com/2011/02/23/new-smashing-ebooks-professional-design-web-typography-sm-book-1/

        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)

        http://www.smashingmagazine.com/2011/01/27/free-minimal-swiss-design-wordpress-themes-4-themes/

        once again. type the keywords into google.

        furthermore articles like

        http://www.smashingmagazine.com/2011/02/18/five-and-a-half-habits-of-highly-effective-designers/

        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:
        http://www.smashingmagazine.com/2011/01/25/showcase-of-beautiful-and-fresh-ecommerce-websites/

        more adverts:
        http://www.smashingmagazine.com/2011/01/10/free-html-4-01-html5-wordpress-theme-spectacular/

        more poster resources.
        http://www.smashingmagazine.com/2010/12/17/25-new-free-high-quality-fonts-typography/

        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.

        27
      • 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!

        @mthrlwd

        5
      • 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).

        Thanks!

        6
      • 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.

        0
    • 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..

      -3
    • 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)

      14
  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.

    0
    • 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!

      [Jeff]
      @jboogie

      0
  3. 13

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

    6
  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.

    1
    • 16

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

      [Jeff]

      0
  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.

    0
  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.

    1
    • 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.

      [Jeff]
      @jboogie

      3
      • 21

        Jeff,
        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.

        Kudos.
        K
        @kaffee

        1
        • 22

          Thanks K.

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

          :-)

          [Jeff]
          @jboogie

          0
  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.

    Jon

    0
  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.

    3
    • 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.

      [Jeff]
      @jboogie

      1
    • 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.

      @seriouslynow

      3
    • 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.

      1
      • 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.

        [Jeff]
        @jboogie

        1
  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//www.mindnode.com 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.

    2
  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.

    2
  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*.

    0
    • 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!

      [Jeff]
      @jboogie

      0
  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.

    0
    • 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.

      0
      • 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.

        [Jeff]
        @jboogie

        1
  13. 37

    GREAT Article! Thank you very much!

    4
  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.

    1
  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.

    1
  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.

    4
    • 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!

      [Jeff]
      @jboogie

      0
  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: http://seantoohey.blogspot.com/2011/03/apple-ipad-app-devlopment.html

    Cheers,
    Sean

    2
  18. 43

    Great Article Jeff!

    1
  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.

    1
    • 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.

      [Jeff]
      @jboogie

      0
  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! :)

    2
  21. 47

    Very well written article. Coincidentally I also came across http://methodandcraft.com/articles/invisible-deliverables which have both reminded me that a strong and lean process in any nature will allow for growth, ROI and certainly emphasize professionalism.

    0
  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?

    0
    • 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.

      [Jeff]
      @jboogie

      0
  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

    0
    • 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.

      [Jeff]
      @jboogie

      0
      • 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 :)

        Andries
        @dretio

        0
  24. 53

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

    0
    • 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.

      [Jeff]
      @jboogie

      0
  25. 55

    Excellent article and exactly at the right time for me!
    Chris

    2
  26. 56

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

    0
  27. 57

    good one indeed.
    thanx a lot.

    0
  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.

    1
    • 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.

      [Jeff]
      @jboogie

      0
  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.

    0
    • 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. :-)

      [Jeff]
      @jboogie

      0
  30. 62

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

    1
  31. 63

    This is a very well done article. As a freelance web designer for 7 years, I started with a documentation — deliverable paradigm. It took a lot of time and didn’t make my work any better. Over the last year I’ve gradually made the switch to a plan – prototype – design – deploy method. All my planning deliverables are now in simple Word docs or through email conversations (no fancy presentations or mock ups). Prototyping the site with content and functionality but no visual design elements is key. During this phase I get tons of client input and even like to have them put their content in place at that time. We mod the layout and functionality in the prototype site (again, all “white, no visual elements) until just right. Then I create the visual elements for the site based on the brand strategy and a “mood board” the client has already provided input to and signed off on. When I show the visual concept, it’s on the prototype site coded in already. The client rarely has any major changes because they are so involved in the process.

    Having said that, I keep the actual design work close to the vest once visual concepting begins. I never put that on a board for review or input. Think if you were on the operating table and your doctor starts asking around the room for the orderly or nurse or accountant or receptionists opinion on what he should do. Not comforting. They are not professionals. There is a time to shut the door to the design ark and be a professional.

    0
    • 64

      Nice evolution Frank. Though, I have to ask — comparing visual designs and designers to surgeons and surgery? Yes, both are skilled, trained, experienced professionals but, unless you’re designing nuclear power plant interfaces, cockpits or medical equipment, no one’s going to die if you share your work early and ensure you’re on the right track.

      :-)

      [Jeff]
      @jboogie

      0
      • 65

        The albeit exaggerated point I wanted to make was that surgeons have expertise and experience as professionals. Just because we all have knives, we’re not surgeons. And just because I fly as a passenger on commercial aircraft, my thoughts on takeoff and landing procedures mean nothing. And just because people have access to and use computers and design software, it doesn’t make them designers. I’m not really interested as a designer in non-professional opinions about design work any more than a surgeon is interested in the opinion of the receptionist on surgical technique.

        Should a pilot listen when the passenger says that the left engine wing is on fire? Yes, although he probably already knows it. And should a surgeon listen when their patient is screaming, yes, of course. And should a designer listen when the project manager points out something in the site that is broken or even might be improved upon? Of course. But a designer showing people how the sausage is made during the process is a recipe for disaster.

        I wanted to make one more comment on the idea that billable hours will go down when a Lean UX process is used. Agencies need to move away from a time based model for charging clients that’s really a relic of the industrial revolution. We should move to expertise and outcome based pricing instead. Then Lean UX would not impact the bottom line of agencies or freelancers because your pricing isn’t based on time but expertise and outcomes.

        2
        • 66

          I think you make some good points but I have to disagree slightly with your comment about pricing. To a certain extent a product should be priced on it’s value to the buyer, a piece of print machinery for example is bought to make money by a print company through the resale of services. The same can be said for a website, however I think its difficult to form a reliable business model on anything other than an hourly/daily rate. You know expenditure plus desirable profit margin which gives you a pricing structure. You are also more likely to get repeat business if your costs are transparent (often not the case in the creative industry)

          Outcome based pricing would require measurable impact which is often possible but can’t always be accurate.

          Just my opinion and experience from running a media company. I might indeed be wrong :)

          0
          • 67

            “Outcome based pricing would require measurable impact which is often possible but can’t always be accurate.”

            Actually, if you set out with a specific goal for each project (e.g., Increase revenue by 15%) then you can absolutely go with outcome-based pricing. In this way, the agency has skin in the game and gets paid on the experience it created, not the documentation.

            Nothing is more measurable than the web.

            [Jeff]
            @jboogie

            0
        • 68
  32. 69

    Just a follow on from my comment (editing function doesn’t seem to work with my iPad)…

    I believe that if you can cut down billable time you can almost use “Lean UX” or whatever you chose to call it as a marketing strategy and a business case builder. In other words another reason why you should get the job.

    In theory it should be like this…

    You save client money through efficiency > client gives you more work because you are efficient > you build a good reputation for being cost effective and accommodating > you retire with loads of money to the Bahamas :)

    1
    • 70

      I agree that you could take this tact and use your Lean UX efficiency and pass the cost savings off to the client and hopefully they will give you more business or you will get new business as a result of being the low cost provider. This is the WalMart model and eventually may reduce what you do to a commodity.

      I also agree that pricing is about what people are willing to pay not just the cost of the product or service. There is room for both models I think. I think that the current model of low efficiency, higher billable hours can only be sustained if the quality of the work justifies the price and the time the client will spend.

      My experience has been that if you do really good work, you can and should charge appropriately. Clients will not only be wiling to pay for it, but will come back to you even though it costs them more. Maybe you’re smaller, more efficient, do great work and provide one on one service that a larger more efficient agency can’t.

      I’ve been learning a lot about the time vs expertise shift from this blog:
      http://www.winwithoutpitching.com/

      0
  33. 71

    Great article. This is the process we are looking to implement for particular clients in the studio where we can. Some clients just NEED the documentation – mostly for their own internal stakeholder sign-off. Where that isn’t required this process is likely to end with a better result due to constant iteration and collaboration both internally and with the client.

    My question is – when doing the concepting and showing this to clients (in lieu of formal documentation), what is the preferred method of communication? Sketches? Whiteboard? Keynote? Concept specific software? Other?

    0
    • 72

      The answer to this is client-specific. If you have an enlightened client that can work with more abstract, less refined visuals then sketches or rough wireframes can work very well. These are especially effective if you implement that standing daily (or every other day) meeting with your client. They can see the document evolve and get more refined regularly.

      Some clients simply can’t abstract an end experience from sketches or wireframes. In this case do just enough design to get the idea across, caveat the document as a draft and iterate frequently.

      Let me know how it goes.

      [Jeff]
      @jboogie

      0
  34. 73

    What’s missing from this article is what “user experience” is and what a “user experience” person does? Even asking a “user experience architect” or a “user experience designer” will lead you to a bunch of answers, some stating that they are actually “information architects”… Having been at this for a while, seeing this title appear around 2000, and coming from a “human-centered” design program, my views on the matter probably venture into the “extreme” or “dogmatic” category, if not wholly untraditional. The basis of (good) “user experience” (in my humble soft-spoke opinion) is inquiry into what the actual “user’s experience” is. The tools that a user experience “architect” or “designer” have at their disposal are employed towards learning about stuff like “context” and “content” and “end use goals”. I’ve found in my work that focusing on the humans that both make and use a product leads to great insights into the design process in and of itself.

    Much too often the trouble with user experience is not the types of deliverables or the tools or methods but where and when and how user experience is employed in the process. There is a huge misconception in the industry, highlighted by this article (“and its siblings, interaction design, UI design, et al”), that user experience “evolves” from UI design etc. Strategy is a large part of user experience. Systems and framework design are key to user experience at a high level. Many of the “user experience architects” I worked and work with have never done UI design but are experts in stuff like sociology or cognitive psychology or electrical engineering…

    Much of the time, user experience is “guided” by (being political here) by people who seldom, if ever, think about the user (i.e. customer), are reacting to directives within an organization or business sources from a myriad of origins, usually at the top of a power structure… Much of the user experience I see employed at the “wireframe” level is simply an extension of “product requirements documentation”, a functional map or visualization of interface patterns sourced from existing libraries to meet a set of business goals and a tight deadline constrained by the limitations of legacy backends and scaleless middlewear and/or lack of comfort with new interaction patterns and content management systems/understanding of the importance of metadata on the web. Wireframes, in the age of “dynamic media”, are self-defeating… they are static and two-dimensional representations of “states” based on the assumptions of the “modes” a user/customer is in. Rarely do user experience people spend time doing primary or contextual field research, if not self-exploration and observation to understand behavior within context or life outside the seven degree peripheral field focus (a monitor, a cell phone screen, an iPad). It’s ironic to note this when most value comes from truly understanding design contexts and the users who employ designed stuff to get stuff done or have experiences with.

    “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.”

    Focusing on the design phase gets you farther from the source of why you’re doing the design in the first place. Why not start by focusing on the user needs and the contexts of those needs? Design solves problems. If you don’t know the nature of the problems, employing a solution to the unknown is a crap shoot. User research includes internal and external users. I hear all the time blabber about “agile” and “process” but the truth and reality in the industry is that the process and structures are the most inflexible parts of the experience of designing for a user when they should be the most flexible parts.

    Concluding, some of the best “user experience” deliverables I have seen have been ways of changing how people look at or approach a design process in and of itself. Not adapting to meet some mis or un-informed version of what “role” a user experience person plays in an assembly line called “agile”.

    2
    • 74

      Thanks for this. I think you’ll find that in the article I point to frequent and repeated reviews with customers — which is the crux of your point I believe. The tactics described here succeed explicitly because you are constantly testing with customers. Take a shot, test it with real people, get that feedback, iterate, rinse, lather, repeat.

      [Jeff]
      @jboogie

      -1
      • 75

        Hi Jeff,

        Good article, but I have to agree with Wandereye. Doing a reasonable amount of user research to understand needs, or even co-design – to collaboratively develop concepts, is not the same as concept- or user testing, which is inviting people in to comment on what you have already decided is the concept.

        Within our own community, I don’t believe there is yet a strong call for primary research prior to Agile kick-off, either. Generally what seems to be raised as Agile research is the user testing and review of prototypes, as you have described.

        I have worked in a number of Agile teams, and while I appreciate the immediacy of working with developers and other team members in rapid iterations (and the idea of a living prototype as the deliverable), it is precisely this lack of time spent with users before everything kicks off – before the business puts forward their concept and it is chunked up into stories and prioritised, etc. – that I find inordinately frustrating. Not only does it lessen the possibility of starting to work on an initial concept that has the highest chance of being relevant to your audience, it also lessens the chance of having an overall vision that relates to that audience.

        So, +1 on most of your thinking, but with the addition of “just enough” contextual research before you get that initial sketch. How much is “just enough”? Well, that is the question..

        1
  35. 76

    Jeff,

    Many people have already said it, but great article. My team couldn’t have said it better ourselves and, in fact, what you describe as “Lean UX”, we simply describe as an “iterative process”, and have been trying to teach its value to customers for the past couple of years.

    Customers that have been able to incorporate iterative sprints somewhere in their process (primarily wireframing / prototyping / requirements gathering) have seen the most benefit in delivering better products without draining budgets.

    “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…Next, get that prototype in front of everyone who matters internally, and validate whether you’re meeting the needs of the business.”

    We see these points as two critical pieces to successful development. You’re discovering the requirements for a project through prototypes, not building the prototype to such extreme that you are sad to throw it away when it comes time to actually develop the project.

    Also, as you mention, gaining feedback is important so that you know the project fits the needs of the end user, that key areas are not missing, and that your internal stakeholders (as well as your client) clearly understands what you will build before it’s built. It’s not design-by-committee, it’s validation.

    Enlightening comments have ensued for sure, but you explain the process and the benefits very well.

    Best,
    Andrea
    @protoshare

    2
    • 77

      Thank you Andrea. Glad to hear you guys are doing this and that it’s working for you. It’s helpful to see this succeed across teams, organizations and business models.

      Cheers.

      [Jeff]
      @jboogie

      0
  36. 78

    Michael Mancuso

    March 8, 2011 8:51 pm

    Jeff, brilliant post. Thank you for articulating that which I have been lamenting for a long time but couldn’t quite put my finger on. It will be very hard to shift gears from traditional agency behavior but with the right internal attitude and client on-boarding I really think this can work and will make for more dynamic and useful experiences.

    Mike
    @techvictim

    1
  37. 79

    Jeff,

    I love the article – but this time I think it means that I love to disagree. While I’d love to label myself as a designer, in actually I carry the job title as Business Analyst and Systems Analyst. My job is to document requirements for website redesign projects.

    Of course, I live in a small group of folks who can write code almost as well as developers, and get marketing better than most marketers. So I influence UX as much as I document it.

    But, I do what I do with writing requirements because I’ve come across, time and time again, environments where agile methodologies almost killed the organizations.

    Based on how you’ve described, Lean UX seems to be very user and designer focused. While that improves speed-to-market and ROI – it appears that there’s little consideration for stakeholder buy-in (like executives and CEOs) as well as budget and resource management.

    I think it’s great that you’ve presented an opportunity for producing quality UX – but won’t multiple iterations of prototypes burn up development hours? I’m thinking of a current client where we lost $1.5 million because we were Agile. Our developers and their manager talked to the wrong customer, so they spent 8 months developing the wrong product. When the true stakeholder found out we built an awful website, we had to protect ourselves from going from losing another $1.5 developing the wrong thing. So we documented everything first, delivered to a vendor, and then saved ourselves from future heartache.

    It seems Lean UX saves the designer and prevents heartache – and this is apparently for scenarios where the UX designer is the keep of the vision. I seldom have ever seen in the corporate world where a UX designer is the guardian of the organization’s online vision. At least in my encounters with UX designers, websites would never make money, but everyone would feel okay with that happening.

    I think you have a lot of assumptions in your statement: UX designer understands the vision, UX designer has final, or integral say, in design, Agile or Waterfall are okay – but they’re risky and annoying to those briliant designers.

    What’s wrong with just putting the UX designer at an integral part of a waterfall workflow: After a customer decides what they want, but before a developer starts coding. I would think you’d put UX where it counts: as the decision maker for UX, but with the task of delivering the organization’s vision.

    1
    • 80

      I think that one point I should have made is that I totally agree with the idea that making a UX designer’s deliverable quality requirements is an awful idea. That robs him of the expertise he should be contributing to the project. Especially in large projects, I believe that having Requirements Engineers or Business Analysts step in to manage documentation is ideal.

      0
    • 81

      Paceaux -

      Thanks for the great response. A few thoughts:

      1. You said, “Lean UX seems to be very user and designer focused” – in fact, Lean UX is *team* focused. The individual-as-hero philosophy is the antithesis of Lean UX. The team works together to solve problems and provide the various contributions they each do well.

      2. You were concerned with garnering stakeholder feedback — look at the process diagrams I (so brilliantly :-) drew above. The stakeholder is involved constantly and repeatedly. Progress is shown on a (almost) daily basis ensuring the stakeholders come along with you as your design and refine.

      3. UX designer empowerment is a true problem in many organizations. This is an opportunity for the UX designer to move beyond their traditional role and open up the problem solving space to all the members of the team. It may not have been *their* role to open up, but collaborative design has an amazing effect on those who don’t feel empowered to impact the direction of the project.

      4. re: failures of Agile — I am not privy to your organization’s challenges with Agile but my experiences have shown me that it can succeed if done well. Getting to “done well” however is a long and painful road.

      Good luck!

      [Jeff]
      @jboogie

      0
  38. 82

    This article is very useful. I follow the waterfall and agile development process, but with this in mind, I can speed up my processes and remove overheads along the way. This article really helped me realised the processes that I need to focus on.

    1
  39. 83

    @Jeff Gothelf…

    “if you set out with a specific goal for each project (e.g., Increase revenue by 15%)”

    Your right that the web is the most measurable medium available, but you are assuming that you can always measure an increase in revenue directly from a good user interface. What if you provide a great marketing website but you can’t directly buy from the website. You would then have to rely on internal measurements of ROI and more feedback sought by the company. If it’s a product based website and the increase is identifiable from a redesign of development there that could be straight forward, I just feel that this approach may require a bit of work for the return. Where as a fairly standard model will be easier to manage.

    @Frank…

    I agree it’s a balance between costing structure and the value of the proposition. I wouldn’t charge Nike the same as a small business. Why because chances are the attributed value to each product (although outcomes may be similar) will be infinitely different.

    1
  40. 84

    Excellent read, thank you for taking the time to share your ideas. What I find most compelling about this process is the engagement of the entire team, and how that makes a difference in the way folks approach their work and their interactions with other teams and team members. Software as a reflection of the organization.

    Not sure if you can talk to this point, but one area where my group is focusing is “how far to take the prototype?” It’s the ‘just-enough’ step that we are trying to hit, before moving on…and it’s definitely a work in progress for us.

    Hope to meet you at SXSW this weekend.

    @rickcusick

    1
    • 85

      Hey Rick -

      You nailed it with your comment on total team involvement.

      re: fidelity of prototype — This is organizationally contextual. It all depends on the level of comfort (and trust) you and your developers have with each other. If you can give them directional insight and they can get rolling you can critique/refine working code. If this is a new way of working for them, ease them in with higher fidelity prototypes and then, in future projects, see if you can get them started with lower fidelity work.

      Good luck. Ping me on Twitter at SXSW.

      [Jeff]
      @jboogie

      0
  41. 86

    Just a suggestion for a possible follow-up to this awesome article. Would it be possible to take us through the experience of someone who actually employs Lean UX in the industry (how’s that for meta)? I’d like to see what some of these prototypes look and feel like, what types of criticism comes back on them, where the problems lay in the validation with the rest of the org, and so on. This is great high level conceptual stuff, I just want to see if it really works!

    0
    • 87

      Hey Ankur -

      Everything in this article comes from real-world experience (failures and successes). I like your idea for a follow-up (cc: Vitaly Friedman) .

      Thanks.

      [Jeff]
      @jboogie

      0
  42. 88

    I love the idea of a lean UX process and have been trying to integrate that into my offices current work flow. Thanks for post, this has helped my effort greatly.

    I do have a question and would love to hear how you (and others) have been able to use a lean UX process when working with off site teams. I primarily work with a revolving team of freelance developers. So when designing a project, I usually have to create documentation for the purposes of getting pricing and timing from my developers. How do you limit the amount of documentation while still getting accurate estimates from offsite development teams? Additionally, how do you keep offsite team members looped in so that they can participate in the frequent off the cuff review and feedback sessions discussed in the article? To date I have not found a particularly helpful tool for off site collaboration. Or is this something that is only really effective with on site teams?

    0
    • 89

      Great question Brian.

      There are two scenarios:

      1. Your offshore team is a part of YOUR company — in this case we’ve used tools like Skype and Scribblar (sp?) to communicate, stay in touch and sketch together. It works rather well depending on time zones.

      2. Your offshore team is a third-party vendor (sounds like your situation) — in this case it becomes tough because most vendors want very explicit instructions on what they are building. This helps them scope and more importantly validate they’ve delivered what you asked for so they can bill you. In this case, Lean UX becomes very challenging to execute.

      [Jeff]
      @jboogie

      0
  43. 90

    Just a question I have been banding about today, then saw this article. When build a site, would you expect…
    1. the HTML/CSS structure of the site to be built before the developers hook into it with any programming functionality
    OR
    2. would you expect the developers to build their code first, then the designer style the code?

    Would be good to get a general feeling for this…

    0
    • 91

      To me it could be a parallel process early on. HTML/CSS being laid out as the back-end is being prepped to deliver the content/functionality to it. Then hand off to connect the two.

      [Jeff]
      @jboogie

      0
  44. 92

    Great article, thanks!
    I am a web developer and would like to get into UX. I am looking at graduate degrees.
    1. Is a graduate degree necessary? How do you train in UX enough to be employable?
    2. I am looking at U of Maryland, Rochester and Bentley. Are these schools where I could be employed in UX upon obtaining an M.S.?

    0
    • 93

      Hi -

      A graduate degree will certainly teach you a lot and help get you employed. I went to Bentley so am partial to that program :-)

      That being said, nothing tops hands-on experience. Ideally, find a mentor – an experienced practitioner who can put a plan in place for you. Read the books, blogs and articles on the topics and start doing. Combined with a mentor and hands-on trial and error, the graduate degree will be even more valuable.

      Good luck.

      [Jeff]
      @jboogie

      0
  45. 94

    Great article first off!

    As someone that works at a company that uses this process (something close to it), something we see a lot of is the same “stall by jury” hangups we saw with Waterfall. However, it now happens internally where when we bring the quick sketches to the internal staff, since there’s no longer a feeling of investment (ex; Mockups, wireframes, moodboards) the issue quickly becomes that internal stakeholders feel it’s easy to swap ideas/switch priorities/scrap and restart again.

    While this is a strength of the process it also becomes a weakness when you as a designer are stifled by an internal staff without a strong leader/vision.

    Any recommendations on how to best circumvent this portion? I’ve actually see a worse cycle of delay and revision in the early stages with the Lean/Agile process than I did in the Waterfall version and wonder what tricks/tactics I could use / others could use, to overcome this?

    Thanks!

    1
    • 95

      Brandon -

      Great question. The answer is, the designer has to be the leader. Take all the feedback, aggregate and, using the vision of the project as the filter, decide what you’ll keep and what you’ll discard. As long as the suggestions keep the core functionality and feasibility relatively the same, the devs can get started and you can refine the design.

      If the feedback starts to stray from the original vision, then you, along with the product owner, need to reign the group back towards the initial goals of the project. You’re right, though, without a strong leader you’ll spin cycles (true in any environment).

      [Jeff]
      @jboogie

      0
  46. 96

    I own and operate an interactive shop (30 people in nyc…web/mobile/social/video stuff) and I take your point about agencies being reluctant to give up those billable hours around (wasteful) deliverables (I think you’re right…many agencies do butter their bread on that roll) BUT…I actually have a different problem seeing this work in our backyard.

    Most of our gigs are project fee-based…and we are well-motivated within the structure of our agreements to maintain as lean a process as we can to arrive at the best possible product (all of which would make lean UX a nice fit)…my real problem is that getting the client to invest their time/energy so heavily/often is unrealistic in most cases.

    Many of the gigs that arrive on our doorstep come knocking because an internal resource and/or the stakeholder within the client organization itself doesn’t have time to do it…and they throw it over the fence to us so they can concentrate their energy elsewhere.

    I love what you are describing…I just don’t see 99% of my clients having the will to invest in those types of stand-up meetings (thrice weekly 30-min sessions). Lean, mean stand-up meetings are baked into our core internal process and I would love to see a client get into the muck with us as you describe…I just envision those being the meetings on their calendar they never attend if I could get them scheduled at all.

    Educating clients on how it could work is obviously the answer…I just see that as being a tough haul (based on my perspective…limited as it is).

    Having said that…I’ll say this:

    - On our best days…our process feels like what you are describing (especially on mobile app gigs where design and dev are collectively rowing their way through very unchartered territory anyway…and need that regular interaction and constant proof of concept work to get anywhere meaningful with the design).

    - Generally, as CEO, seeing my teams work together in ways they are not used to makes my heart glow (not just because i like to see people getting along…but because it does seem to yield a better product arrived at faster and with less of a hangover.

    Great piece…really well-articulated and very much appreciated.

    -Chris Sanborn // sanbornmediafactory.com

    2
    • 97

      Thanks Chris. Great insight.

      Perhaps, going ultra-light with your clients (or *a* client) first may have some impact. 15-minutes twice a week? Just to give them a heads up.

      If you try it, let me know how it goes.

      Thanks again for your thoughtful comment.

      [Jeff]
      @jboogie

      0
  47. 98

    i don’t think this way will work much better than the documentation way, right now the comp i work for uses this lean method and it still ends up design by committee, though they illustrate that we still take ownership of the designs. Seems impossible. There are still many iterations, although, I think if we stayed at the wire framing stage and then used your design by committee method then had the designer flesh it out after, there might still be a sense of ownership and utilize the designers expertise within the confines of the set wireframe or specs. I agree documentation is boring, and makes the designers life difficult, and I’m still unsure of the role of business analyst other than as another person or point of view in the committee.

    0
    • 99

      I’m not advocating for design by committee. I am advocating for a transparent, collaborative, just-enough-design process that gets the project moving forward faster.

      Perhaps trying it on something small like an internal project would be a good place to start.

      Thanks.

      [Jeff]
      @jboogie

      0
  48. 100

    I am currently practicing Lean UX and enjoying every bit of it!!

    Lean UX is a very good approach on the designer’s part. Designers get a quick feedback and can implement the change suggested and present again. The key here is the fast run around time and a heads up to the developer of what’s coming his way helps him prepare his flow accordingly.

    Thanks you for sharing this… the best one so far on Smashing!

    1
    • 101

      Thanks Umesh. I think you hit the nail on the head about giving the rest of the team a heads up of what’s coming. It’s very powerful.

      [Jeff]
      @jboogie

      0
  49. 102

    I originally read this sentence as:

    “To many folks, this sounds like the dreaded “design by committee” approach, which has killed many DESIGNERS in years past.”

    :)

    0
  50. 104

    Great article! I relate to so much of it–especially the idea of deliverables for maintenance purposes. However, like most Agile-type methodologies, it is important to keep scope down and communication up. If either of those things is off, the process falls apart. This requires a team that works together very closely and a company culture that encourages it.

    0
  51. 106

    I think there is a lot of merit to removing heavy design documentation/specification deliverables. Recently, I was able to employ this approach on a project and was quite successful with the design’s implementation. My publicly stated goal, which was a joke around the office, was to deliver nothing for the project…

    First and foremost however, this method of “no design deliverables” relies on strong IT team members willing to fully cooperate with UI design efforts and input, which is not always the case. Developers, both front- and back-end, must willing to work closely with the designer(s) to understand the interactions and the intent of the functionality. Too, it also requires a BA willing to capture design-specific requirements as part of the overall Functional Requirements. After all, QA still must be able to develop test cases and test to them, etc.

    Between the requirements, that still have to be captured somewhere, and the resulting, implemented interface, one should be able to have a working design output with fewer, or no more than usual, issues than you would working the traditional ways where heavy specs are involved.

    I was fortunate on this one project because I had an outstanding Business Analyst and a solid User Interface Engineer (front-end developer) working with me that were not only good at what they did but were willing to allow me to handle the design and then take that input by working directly and closely with me on it.

    I created just a few high-level, quick mock-ups to show to my UIE which enabled her to get started on a dirty prototype, which we would then run in front of the Business to ensure we were on track with the solution. After going through 2 or 3 iterations of prototypes, we were then able to move forward and rock-n-roll with a final concept. I then sat in a few meetings with my BA to have him capture the design specs I had in my head.

    In the end, the design went out looking and working 95%+ as intended; AND I was able to shave 2+ weeks from the project’s schedule using this approach. We also were able to do all of this with no use of the buzz term “Agile” anywhere. ;-)

    With all that being said, wireframes, design specifications, and all the other design-related deliverables still have their place.

    0
    • 107

      Jim -

      Great story. Sounds like you’re solidly on the Lean UX bandwagon. It’s worth pointing out that I believe, like you say, that deliverables do have a place in the process. It’s just a different place than they’ve held to date.

      [Jeff]
      @jboogie

      0
  52. 108

    Nice post, very well paced and thought out. Two points:
    1) Adding onto Chris Sanborn’s comment #94: It’s the client/owner that will need to be convinced, investing more time and exercising more ownership on projects than in the past. This would be a good thing, and we all root for it, but it is a change that will require some unlearning.
    2) Anything that accelerates the end-to-end process may in fact save the entire project. A recent project I’m familiar with spent a year in the definition/documentation phases, only to be cancelled. We could have designed and built the project, a website rebuild, before we lost budget to continue.

    1
  53. 109

    I saw this talk at #sxsw. Really good overall. Of all the sessions I saw I definitely took the most from this one. Thanks!

    1
  54. 110

    This is very well written but far from a new concept. Many agencies already work within this process and many universities teach this as the “ideal design process”. You are right in that a dev model that uses overseas development throws a big wrench into the equation. Unfortunately, most of the larger companies leverage the overseas model within one or more sections of the organization and a unified UX team ends up with multiple processes based upon the geographical location of the dev team. Not ideal to say the least. The other risk people should be aware of is knowing when to say the product is “great enough”. I know of two teams that have been using this process very successfully. Unfortunately, the iterations continued for 1-2 years because they continuously were learning more and more about their designs. At the end, the company killed the products and the team was deemed unsuccessful because no one knew when to stop the process and efforts did not generate revenue. I’m not saying this process doesn’t work, it does. But it does not work for every group or every company.

    0
  55. 111

    I agree with PixelKinks — not a new concept at all. However, it’s nice to see it getting some more attention, as it’s way past time for this to be the standard process. What I think this article fails to capitalize on, however, is how to make the process even more efficient by utilizing the production platform CMS as the prototyping tool. A few weeks ago, I posted a webinar on the benefits of such a process – http://t.co/ISVObmm – which I have been doing for 6 years. The problem with prototyping in applications like PowerPoint and Fireworks (the 2 mentioned in this article) is that you’re still spending the same amount of time to create a throw-away deliverable when you could instead use that time to prototype higher-fidelity (and therefore, much more useful) prototypes using the actual CMS for the site. Doing so combines much of the UX and development tasks, resulting in a shortened timeline, fewer missed requirements and a prototype that is much more representative of the actual site. As I mention in my webinar, this process doesn’t work for all projects, but CMS websites are ideal.

    In the end, no process can be considered truly “lean” if you’re creating the same functionality twice — once as a PowerPoint prototype and again as a functional site. Cut out the middleman. It works.

    2
  56. 112

    this is a great concept and makes complete sense. I’m going to adopt it on my next project and keep refining the process. Thanks for sharing it.

    I often find though that clients are so design deliverable focussed that they’re not actually interested in what their users think, even when prompted on how important it is. Like the opinions of their users would be a hinderance or something. Crazy but true.

    2
  57. 113

    Truly Agile, loved your caricatures and simple article. Also, very helpful to validate my direction in the new Agile UX team I am in.

    Thanks for sharing your knowledge Jeff.

    @Phil, you can save prototyping turnaround time by adopting to Paper Prototyping or using some Wireframing Tools like Axure, iRise etc…

    Also, keeping an updated pattern library is helpful for reusable components.

    1
  58. 114

    Thanks for the article, Jeff. It’s good to see a validation of the type of UX we’ve been practicing here — where the prototype is the spec. We have eschewed the traditional “spec” and the “thick report” since the earliest days of our practice, in favor of a more collaborative and iterative approach, with quickly delivered recommendations for improvement (sometimes just a bulleted list, and they’re often things we ourselves just need to tweak in the prototype). We own the experience vision, but rely on everyone’s contributions and our early studies with customers to mold the experience. Often, it’s our early prototypes that spark ideas and discussion with the rest of the team, so getting the prototype in front of them as early as possible really benefits the rest of the project.

    Thanks,
    Eric
    @ericdux

    0
  59. 115

    Great Article.
    I particularly like the statement at the beginning of the article:

    “Over time…the 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.”

    I couldn’t agree more with this statement. But I will also add that much of the UX industry has itself to blame for this. I personally feel that “UX” needs to start positioning itself as an industry focused on true “Experience Design” and end-customer experiences. While it may sound like I’m just being semantic, I think there is a big difference between UX and XD (Experience Design), where XD emphasizes the final Experience Design, not the deliverables along the way.

    Great article, though!

    1
  60. 116

    This was a really interesting article. Thanks for the great insight!

    0
  61. 117

    I am a little late to the party, but Jeff this was a fantastic article!

    I have been working on Agile software dev teams for the last 5 years and although in the beginning it was quite a “mind warp”, today I will not work any other way. I am a complete convert.

    There is one observation I want to make: for Agile teams you don’t do prototypes, you implement as you go–in sprint. Ux works hand-in-hand with the team (+ very closely w/UI Dev) so you actually see the interaction come to life in a few hours or days. If something is not quite right, it’s changed before end of sprint. If it’s too big to change in sprint, you write another story and do it in an upcoming sprint. That simple. But it’s important not to confuse Agile with speed or lack of quality–that’s a conversation for another day.

    0
  62. 118

    The article is the bollocks! The number of times I have worked on shelved projects because by launch time the environment had changed as to make the original solution irrelevant.

    0
  63. 119

    Very interesting article. Just read it today and I couldn’t agree more. I’m an ex frog designer that moved to prezi.com a few months ago and I work now as their Senior Designer. A few weeks ago I wrote that post explaining what I’ve learnt from this and it’s amazingly similar.
    http://beautifulbits.prezi.com/latest/2011/9/18/design-consultancy-vs-integrated-design.html

    Thanks for this post,
    cheers

    1
  64. 120

    This is the most solid guide to Lean UX we’ve found so far. We have colleagues who’ve tried this, and now our team want to try this as well. What other resources do you recommend for filling our heads with the spirit of Lean UX – for reading stories of others who have done this, for advice from others who have done this?

    1
  65. 121

    Boston PHP is having a free event that will be a 90 minute live presentation from Jeff Gothelf on Lean UX. If you are in the Boston/Cambridge area in March 2012, then you should join and RSVP! We cover a lot of great UX topics as well.

    http://www.meetup.com/bostonphp/events/41157472

    0
  66. 122

    This is an extremely interesting article. I’ll bookmark me

    0
  67. 123

    I highly disagree with this point-of-view. For one, this accounts for a utopian team, but the truth is that those critiquing have other agendas, including their own workload or who they think the user is. All too often the user story is assumed in haste in a Lean UX environment, particularly when the assumption that everybody understands UX, which most do not.

    In fact, I’ve seen UX be shoved out of the way for two-week sprints by developers who think they know users, but then again, there’s been no established or agreed upon narrative to the very experience they are programming for in the first place.

    I think there’s a place for SDLC because this is the time when at least some baseline personas and user stories can be talking points and something to reference in the big picture during development. Yes, these stories will adapt to what is tracked and comes up once released to users, but over all I’d rather have something that’s closer to a user base’s need, demographically and psychographically, at launch than to be three or four iterations away from being relevant. The process of documentation isn’t fun and it’s easy to dismiss it as waste, but users will travel through a task if they see narrative to it…after all, Dorothy didn’t go down the yellow brick road and come to a dead end, and she was still able to explore having the navigation to go home all the while.

    Do I think we can limit the role of the IA during UX? Sure, but it’s true that not everyone can do UX and deferring it to lean assumes the very opposite and can have costly effects at launch.

    1
  68. 124

    If one were stuck in a waterfall organization, how might we go about incorporating Lean UX principles in a practical way?

    How might we prioritize these principles to demonstrate the value of Lean UX for measurable wins without overwhelming TPTB?

    How do you incorporate Front-End and Creative disciplines into the prototyping process so that some actionable assets are produced that actually help Engineering, vs. just a bunch of brainstorming sessions cleverly dubbed Lean UX?

    0
  69. 125

    Great article elucidating the lean UX process, its relevance in different industry practices and the detailed lean processes.
    However, it has been mentioned that, “Constant feedback … will engender the same feelings of trust and co-ownership” under the section “I’m a Consultant/Freelancer. Does This Make Sense for Me?”, which I doesn’t find convincing as per my understandings.
    I believe, There is a great difference between client and the users. Also, feedback from clients may not be as useful as those from the users. The designs incorporating the feedbacks from clients may make the client satisfied and happy, but that may not delight the users or may engender an unexpected horrible experience for the users.
    Since the client, in general, is not having a perfect understanding of their users and their needs, the client’s feedback also needs to be debated over before any implementation. For instance, if client likes yellow color to be incorporated in the application interface, because he likes yellow. It does not make sense that the designer should change the color which he has opted due to some reason behind that color.
    Clients sometimes get influenced by anything and want the same to be incorporated with no reason and irrespective of the context. So, the client need to be educated about the reasons behind, and make them understand those. The designer should have the convincing skills to make the client understand the design’s demand and its reasons behind, instead of blindly following their feedbacks just to make them feel a sense of ownership to the design or make them happy.
    It’s great, that UX process is evolving to become leaner. But I am afraid, if its impacts, results and effectiveness would also become leaner particularly when the world is yet to be educated about complete UX processes and its effects and differences it makes.

    0
  70. 126

    Does anyone have a good, current, reference site for lean UX where collaborative design, living style guides, a weekly heartbeat and other techniques are being used successfully in the UK?

    I’d be very interested in having a chat if you do.

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top