Working with Design Thinking, Lean and Agile

Design Thinking is the latest buzz phrase to have taken over the business and technology world. It seems like the phrase is popping up in nearly every context. A few years ago, Lean UX was all the rage, following a few years focused on the Lean Startup. A few years before that, every tech company I knew was rushing to implement Agile development processes. Experts like Lou Rosenfeld are already making predictions about what new approaches are coming next.

It’s not that any of these approaches have become less useful over time, but people are experimenting with new ways to build products and successful techniques to get attached to as “The Next Big Thing” that will prove to be a magical solution for everyone. The problem is that in the excitement of discussing something new, we don’t always connect the dots of our existing methods and people can be left confused as to how to best implement things all together.

Read on to better understand Design Thinking, Lean UX, and Agile, and how to implement elements of each for your team.

Before we get too far, let’s take a step back to understand each approach.

Agile

Let’s be clear: Agile is a software development approach. It was born out of frustration with traditional “waterfall” software practices, with a long period of upfront requirements gathering and design work, then a long development stage of implementing said designs but without the ability to understand or respond to changing needs. The outcome was that teams were spending a long time building things that people didn’t really want or need, and companies were struggling.

Software developers started experimenting with new ways to build, and came up with a set of shared values and principles to guide teams to do better work.

• The official Agile Manifesto was released in 2001, and called for valuing:
• individuals and interactions over processes and tools
• working software over comprehensive documentation
• customer collaboration over contract negotiation
• responding to change over following a plan

The Agile Alliance has also defined 12 detailed principles to follow, but does not prescribe any particular processes, so dev teams often end up using specific frameworks, like Scrum or Kanban, to help them figure out how to organize, plan, and execute their work. There’s a strong focus on teams’ independence to self organize, so no two Agile teams look the same, even within the same departments or organizations.

In theory, Agile approaches not only play well with UX practices, but actively require ongoing UX research to constantly understand the changing needs of the customers. However, in practice, teams can get caught up on trying to release more working code faster, and it can be hard to dedicate any time at all to conducting research or focusing on design decisions. Agile teams often struggle with how to best incorporate UX team members and their work into their practices.

Lean UX

Lean UX was born out of the struggle that so many teams had incorporating UX best practices as they adjusted their development processes to Agile methods and attempted to speed up time from idea to implementation. Lean UX is the umbrella term for altering traditional UX methods to fit faster timeframes, which often means shifting focus away from detailed deliverables.

But beware: you may also hear about Lean and Lean Startup, which often get conflated but do have specific meanings and distinct elements. Lean is derived from manufacturing best practices and focuses on general business and management practices to reduce waste and maximize value. Lean Startup is a broader business and product development approach that suggests incorporating periods of experimentation in order to reduce waste and risk. The terms aren’t mutually exclusive but nor are they interchangeable.

Back to Lean UX: the core idea is to alter traditional UX design methods to become faster. Rather than spending a lot of time thoroughly designing and documenting each element, the team is meant to quickly and collaboratively visualize ideas and gather feedback as soon as possible, from both other team members and stakeholders and the users.

Jeff Gothelf lays out the following Lean UX process: concept, prototype, internal validation, external validation, learn, iterate, and repeat. This process mirrors the “regular” UX process but each step is shortened.

Let’s say a team is working on integrating a new feature. The team might first have a quick whiteboarding session to flesh out the core workflow. Once the group agrees on a direction, they can show a low-fidelity design to users and incorporate the feedback found during a joint sketch session where they sort out more interaction details.

You’ll notice this example doesn’t have any fully functional prototypes or detailed test reports, but Lean UX isn’t an excuse to skip steps. Rather, it’s an invitation to do just enough to build a shared vision and get feedback, scaling up and back different tools or methods as it makes the most sense for your specific context.

Lean UX also doesn’t suggest you completely abandon documentation, nor that the experience decisions are taken away from UX professionals. Rather, it suggests that the whole team is involved with the design process so there are no surprises or unforeseen technical challenges. Feedback is collected early and often, and if changes need to be made, they can be done quickly and easily before much time has been invested in final designs.

Design Thinking

Design Thinking is a general approach to creative problem solving, popularized by the Stanford d.school and IDEO and recently adopted by many tech companies. The approach has five steps, and is couched as a way to frame and solve problems of all sorts.

The first step is Empathize, which looks an awful lot like old-school research phases. You gather as much information as possible to learn about the people involved, their problems and motivations, and their context. This could mean you do things like conduct interviews, observe people in their space, talk to experts, or look at past behavior patterns.

Next, you analyze what you’ve gathered and synthesize thoughts to Define a core problem for the audience you’re serving. Look at what you’ve learned about the group, what they need, and where there may be gaps to create a succinct problem statement to frame your next steps.

The third step is to Ideate solutions to the stated problem, incorporating creative techniques to look at the problem from many angles and come up with as many different ideas as possible. The idea is to first go wide, generating lots of alternatives before narrowing it down to a few possible solutions to test out.

Before you can gather any feedback, the team needs to Prototype, or create low-cost representations of the solution. A prototype can be anything from a series of sketches to a pixel-perfect, front-end simulation of a proposed process. The goal is to strike a balance such that the solution seems real enough to get authentic feedback but is relatively low cost and easy to produce.

Finally, you want to Test the prototypes, by putting them in front of real or representative users and observing what they do and how they react, then using the information to form next rounds.

You should note that while the process is presented linearly, in reality the phases may overlap, or something you learn along the way will prompt you to revisit problem empathy or definition. The approach is meant to be structured but flexible.

All of this should sound pretty familiar. Design thinking is a formula to help teams collaboratively understand and solve problems by framing them around the people involved and incorporating feedback early and often, which is also at the core of good UX practice.

Tying It All Together

The good news is that each of the approaches I’ve mentioned has some valuable components for nearly every team. Agile’s focus on collaboration, iteration, feedback and speed means that teams are less likely to waste time building things no one wants, and Lean UX helps adapt UX’s traditional practices to match the pace of faster development teams. Design Thinking gives people from all kinds of disciplines an approach to explore problems and focus on users.

The bad news is that, in practice, the three methods can sometimes seem at odds with each other, because they’re approaches that are meant to address different problems. Agile is about software, Lean UX is about design and research processes, and Design Thinking is an idea exploration tool. Very often, different people or groups within a company will be responsible for these different domains, and their individual timelines and goals may not be aligned.

For instance, a team of strategists may use design thinking approaches to explore ideas at the onset of an initiative, then start to partner with UX designers to flesh out the concepts—and in the meantime, the development teams may be using Agile iteration cycles to build out what they know. This isn’t necessarily a directly linear process, and the handoffs and differences in stakeholders and key players can cause tension or rework. Lithespeed’s illustration does a great job of visualizing how the processes may be intertwined successfully.

Of course, the unique set of implementation details that work best for each team and project will depend on a whole bunch of factors, like what sort of organization you’re in, what you’re trying to build, and where you are in that process.

The following steps should help every team.

Shared Vision

The first step I’d take is to get everyone involved with each of the three main domains to agree to a shared vision and explicitly state and share it across all the members of the teams. This sounds like an obvious first step, but it’s fairly common for each team or person to have their own version of the ultimate destination of the organization. Try it: go ask a developer, a UX designer, and a product strategist who work together what their vision is. It’s rare that all three will answer the same way, if they can answer at all.

The shared vision should outline the ultimate goal of the company, but not how the teams should get there. For example, Amazon’s vision is

to be Earth’s most customer-centric company, where customers can find and discover anything they might want to buy online, and endeavors to offer its customers the lowest possible prices.

The idea isn’t to be prescriptive, but to make sure everyone is headed in the same direction, and you can gut check your own work to make sure it’s aligned.

Clear Measurement Cycles

Teams should also determine how they’ll measure success against that vision. Each of these approaches recommends frequent experimentation and feedback cycles, but you need to clearly define what outcomes you’re aiming for, what metrics help you understand those outcomes, how you’ll collect that information and what parameters will determine what you do next.

I particularly like this hypothesis framework:

If we do, build, or provide x thing , Then these people Will do some desirable outcome . We’ll know this is true when actionable metrics.

Aim to craft experiments that will answer your questions as quickly as possible and give you a clear decision point, so that you feel comfortable abandoning efforts that aren’t getting you where you want to be.

Remember that you may learn the most from efforts that have “failed” their hypotheses. There’s inherent value in learning what works well and what doesn’t, even if you have to throw away some work.

Maintain User Focus

The foundation of each of these methods is to thoroughly understand the people you’re solving for and make sure they remain at the center of feedback loops and decision points throughout the process. In practice, that means constantly talking to and learning from your existing and potential users. It’s important to try new solutions, but also to recognize that users and their goals or contexts may change over time. Continue taking measures to understand your users and their needs no matter where you are in product development.

Set Teams Up for Success

Cross-functional collaboration is another foundational element in each of the approaches, and it’s ideal for teams to have dedicated members for multiple disciplines working together. Providing value to your users should be top of mind for everyone, and the best solutions come from diverse individuals contributing their talents and knowledge.

It’s also important to continually check in with your teams to assess what’s working well and what could be improved process-wise. What works for one team may not for another, and it’s important to allow yourself time to reflect and try new things. Rather than focusing on a specific process, focus on a commitment to experimentation and constant learning.

At the end of the day, there’s no single “right way” for every team to implement Agile, Lean UX, or Design Thinking into your practices. Each approach is meant to solve a particular problem, and elements of each may be useful, so you’ll have to find what works for your team. Enjoy experimenting!

Frequently Asked Questions (FAQs) on Design Thinking, Lean, and Agile