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

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

Waterfall software development looks something like this:

Define → Design → Develop → Test → Deploy

The design phase typically breaks down like this:

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

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

Enter Lean UX.

Lean UX

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

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

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

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

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

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

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

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

Isn’t This Just Design-By-Committee?

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.

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

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

Lean UX Is Not Lazy UX

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.

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

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

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

Prototyping: The Fastest Way Between You and Your Customers

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.

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

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

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

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

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

Maintaining a Holistic Vision

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

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

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

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

Deliverables For Maintenance Don’t Make Sense Anymore

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 agency12
Lean UX process for an interactive agency.

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

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

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

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

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

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.

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

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

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

Conclusion

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

(al) (vf) (sp)

Footnotes

  1. 1 http://www.flickr.com/photos/flat61/3883611573/
  2. 2 http://www.flickr.com/photos/flat61/3883611573/
  3. 3 http://www.smashingmagazine.com/wp-content/uploads/2011/03/just-the-ux-process-large.jpg
  4. 4 http://www.flickr.com/photos/64519085@N00/4305366199/
  5. 5 http://www.flickr.com/photos/64519085@N00/4305366199/
  6. 6 http://www.flickr.com/photos/bjornmeansbear/5279065887/in/set-72157623006302347/
  7. 7 http://www.flickr.com/photos/bjornmeansbear/5279065887/in/set-72157623006302347/
  8. 8 http://www.flickr.com/photos/rosenfeldmedia/3978302604/in/photostream/
  9. 9 http://www.useit.com/alertbox/20000319.html
  10. 10 http://www.flickr.com/photos/bjornmeansbear/4585293325/in/set-72157623006302347/
  11. 11 http://www.flickr.com/photos/bjornmeansbear/4585293325/in/set-72157623006302347/
  12. 12 http://www.smashingmagazine.com/wp-content/uploads/2011/01/agency_process.png
  13. 13 http://www.flickr.com/photos/bjornmeansbear/5309945659/in/set-72157623006302347/
  14. 14 http://www.flickr.com/photos/bjornmeansbear/5309945659/in/set-72157623006302347/
  15. 15 http://dev.theladders.com/2011/01/the-100-day-solution/

↑ Back to top Tweet itShare on Facebook

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

Advertising
  1. 1

    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
    • 52

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

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

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

    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
  5. 256

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

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

    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
  8. 409

    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
  9. 460

    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
  10. 511

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

    0
  11. 562

    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
  12. 613

    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
  13. 664

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

    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
  15. 766

    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
  16. 817

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

    0
  17. 868

    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
  18. 919

    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?

    1
  19. 970

    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
  20. 1021

    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

↑ Back to top