A SaaSy Introduction to Lean UX

Feb 1, 2019

Nicole Hitner

Lean UX, sister discipline to the agile development method, is user experience design and usability testing for fast-paced software teams. UX designers build flowcharts, construct wireframes, and conduct user research to help teams design new product features. A UX designer working with an agile team would do all these things while adhering to the tenets of lean UX.

But since we can’t really talk about lean UX until we understand agile, let’s make sure we’re all on the same page.

A (Very) Brief History of Agile Software Development

In 2001, 17 exceedingly smart guys went on a skiing trip and ended up writing a Manifesto for Agile Software Development12 principles meant to supply an alternative to the “documentation driven, heavyweight software development processes” of the day. According to its founders, the agile movement is less a process model than it is about “building the types of organizational communities in which we would want to work.” The principles prioritize customer satisfaction, efficiency, and close-knit teams capable of delivering “working software frequently” at a sustainable and consistent pace.

Adoption of the agile method continues to grow, and some studies suggest it has eclipsed the older “waterfall” method. You may even be familiar with agile terms like “scrum,” “sprint,” and “kanban” without realizing their provenance. Agile tools turn up in popular culture too, such as in the HBO series “Silicon Valley.”

lean ux

(Source.)

If an agile product team is going to deliver quality products in short, iterative sprints, it’s going to need a UX process model to match and keep pace. This is where lean UX comes in.

The Tenets of Lean UX

According to Josh Seiden and Jeff Gothelf, authors of “Lean UX: Applying Lean Principles to Improve User Experience,” lean UX also has its roots in Tim Brown’s “design thinking” as well as in “The Lean Startup“ by Eric Reis, required reading for any would-be entrepreneur. Because these philosophies overlap liberally with those professed by agile, we won’t go into them here. Suffice it to say that all three prioritize efficiency, user requirements, and agility over loyalty to fixed, predefined requirements. Their 16 principles of lean UX are nicely condensed in Anthony Viviano’s “Lean UX Manifesto,” which outlines the practice in just six tenets:

  • Early customer validation over releasing products with unknown end-user value
  • Collaborative design over designing on an island
  • Solving user problems over designing the next “cool” feature
  • Measuring KPIs over undefined success metrics
  • Applying appropriate tools over following a rigid plan
  • Nimble design over heavy wireframes, comps, or specs

To support an agile product team, UX professionals need to be able to verify a design’s end-user value before the development team builds the feature in question. Having a clear sense of what constitutes a successful design is critical for validating design concepts. Collaboration between departments as part of the UX effort helps to ensure that all wings of the company communicate effectively and help each other approach problems from a variety of perspectives. These problems provide an exigence for the feature being designed and remain the focal point of development projects from start to finish, helping to ensure that what gets built serves its intended purpose. Most importantly, the team should be prepared to alter designs that no longer appear to meet user needs and plan features to be easily modified as new needs arise.

So what do these principles look like in practice? Every team will have its own heuristics, but here are some common, fundamental ones you’re likely to find at the average modern software company.

Lean UX Practices

Test Early, Test Often

The sooner you test a design on prospective users, the sooner you can begin making changes to it and providing the rest of your product development team the specs they need to begin building the feature.

Quantitative Data Is the Exception, Qualitative Data Is the Rule

Lean UX teams typically don’t have time to test their designs on large numbers of users. Rather, they extract qualitative data from around 3-5 tests and make adjustments from there.

Do the Least Amount Possible to Improve Usability

When you identify a UX issue, look for the shortest path to resolving it. If a user isn’t seeing an important button, don’t default to rearranging the entire page. First try moving the button and see if that solves the issue. Review usability testing footage with your team immediately following the test to ensure that UX doesn’t become a development bottleneck.

Use Paper Whenever Possible

Use lightweight wireframing tools for user tests. In the event that a paper prototype is the fastest way to get the design feedback you need, go with paper. If you already have a robust wireframe library waiting in the wings, use that instead.

Go By the Data

Uphold the designs and practices supported by your data. Work toward improving your UX KPIs and avoid “sacred cows” at all costs.  If a design concept isn’t performing, cut it loose and move on; there will be other innovations to replace it.

A Tale of Two UX Teams

To illustrate the differences between traditional UX and lean UX, we’ll look at how two fictitious software teams—Team Waterfall and Team Lean—approach building a new feature for the dating app GetTogether. The new feature should supplement GetTogether’s traditional dating algorithm with a personalized matchmaking service, pairing users with live dating consultants. How these teams go about executing this task will speak to the differences between their UX process models.

Team Waterfall

Team Waterfall’s UX and UI designers, all specialists in the field, work together to sketch out their ideas for the new feature, refining their designs until they have exactly the workflows and layouts they want. They then send those mockups and specs to Development. Development and Design go back and forth regarding the feasibility of the proposed workflows, making necessary changes before greenlighting the project. Once the feature is in beta, Team Waterfall puts the product in front of end users for testing. Because the team wants to get as much as they can out of this first round of testing, they source dozens of end users and run tests on all aspects of the feature. The UX designers then take their test results back to the drawing board and start the process all over again.

Some extensive revision is required. During the first round of testing, Team Waterfall discovered that end users wanted to be able to choose their matchmaking consultants rather than be randomly assigned to them. This introduced the need for a matchmaker rating workflow designed to help users review and select consultants. The team also discovered that users disliked something they’d come to refer to as the “Tips Box,” a space for the consultant to critique the user’s dating profile. Even though users responded negatively to this tool, Team Waterfall decides to keep it because it is an integral part of their vision for the feature.

The second round of testing goes better than the first, but the team once again finds itself making major additions to the feature, requiring a third round of development and testing. Finally, with just some cosmetic changes remaining, the feature is ready for launch. Total design and development time: seven months.

 

(Source.)

 

Team Lean

Team Lean’s UX/UI designers partner with members of QA, Development, Support, Marketing, and other departments to sketch out ideas for the new feature. They keep their wireframes sparse and soon have prototypes ready for user testing. After 3-5 tests, the cross-department UX team comes together again to make modifications to the wireframes. The team learned during testing that users want the ability to be able to pick their matchmaking consultants and do not like the “Tips Box” tool, so they sketch out a matchmaker reviewing system and nix the tips.

The following week, another round of user testing indicates that with a few slight changes, the feature will soon be ready for design. The UI designer gets to work on mockups, passing along the UI specs to Development for coding. Total design and development time: two months.

 

(Source.)

 

Recap

Because the waterfall UX team is siloed from the rest of the product team, they spend more time progressing from the design stage to the development stage. It takes longer for them to rework the feature after each round of testing because designs are finalized and built before they are user tested. Lastly, because they prioritize their product requirements over users’ needs, they may engender UX issues when the product goes to market.

The lean UX team, by contrast, makes cross-departmental brainstorming part of their product sketching process in order to minimize the chance of conflict down the line. They only design and build the product onceafter the concepts have been user tested. They respond to their usability data, even if it means removing a tool they value. These choices culminate in a faster, more efficient development cycle.

There are of course drawbacks to both agile and waterfall, so the trick is finding the methodology that works best for your company or project. Ultimately, lean UX is about accommodating an agile development team and furnishing it with the user feedback it needs to put out quality releases on a timed schedule.

More Resources

Rocket Surgery Made Easy: A Do-It-Yourself Guide to Finding and Fixing Usability Problems” by Steve Krug

Don’t Make Me Think: A Common Sense Approach to Web Usability”  by Steve Krug

The Design of Everyday Things“ by Don Norman

Lean UX: Designing Great Products with Agile Teams“ by Jeff Gothelf  and Josh Seiden

Sense and Respond: How Successful Organizations Listen to Customers at Create New Products Continuously“ by Jeff Gothelf  and Josh Seiden


Originally published with Springboard.

Schedule a Demo

Leave a Comment