Working with Design Thinking, Lean and Agile

Design Thinking is the latest buzz phrase to have taken over the business and technology world. In 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.

The post Working with Design Thinking, Lean and Agile appeared first on SitePoint.

by Amanda Stockwell via SitePoint