Lean UX Process: Integrating UX into Agile Development

Behrad Mirafshar at UXDX Community: Rapid Product, UX and Agile and Circular Design. Video: https://youtu.be/Y61MZd3v2Yc

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and the problem with agile for UX

[00:00:00] Hello, my name is Behrad. I am the founder and owner of Bonanza Design. We are a global UX design studio based in Berlin, Germany. Interestingly, we work with both enterprises and fast growing startups at the same time, and help them to design better software faster.

[00:00:26] So I'm going to talk to you about what lean UX is, but before that I'm going to talk to you about a typical problem that pops up in the agile development process and causes a lot of frustration for UX designers. Then I'll define lean UX, talk about the advantages of it, and walk you through our process. And if we have time, I'm going to show you one of our Figma files of a large scale design project that we completed last year, and show you how we organize our files.

[00:01:10] Cool. So most likely you have experience working in such an environment: a scrum process, one to four weeks of delivery, sprint planning, retrospective, and do it all over again. This has caused a lot of frustration for UX designers. The typical complaint is that we cannot do our job. Why? Because in one to four weeks you cannot research, discover, test, deliver and support dev teams.

[00:01:55] It's been a while that we identified this problem and came up with a solution for it. We realized that product delivery is only half of the agile product development process. There is always a component of discovery, research and testing involved that requires its respectable place in this process. So we developed a product discovery process that goes in tandem with your product delivery process. In delivery you pay to build; in discovery you pay to learn. In such a tandem between learning and building, now UX designers can do their job. The process can go through a typical design process and do research, testing, prototyping, learning and iterating.

[00:03:05] However, there was a problem for UX designers as well. A typical design process is usually one where you go through a process of researching, learning, prototyping, testing and releasing. This process did not change since physical product designers were designing products. We really couldn't use their process to design software. So we needed to evolve, we needed to come up with a better process for UX design so we can design for software effectively. Lean UX design is the result of such a goal, so to speak. Lean UX design is designed to work within a product discovery process.

The three foundations of lean UX

[00:04:24] So let's dive deep and talk about what lean UX is. Lean UX has three foundations. It is inspired by and based on the agile mindset. Within a lean UX design process you cannot work forever. You need to work within sprints. Sprints usually take between one to three weeks, and you need to be able to condense an entire design process within that sprint. That's the first foundation of lean UX.

[00:05:09] The second foundation is design thinking. Design thinking is core for lean UX. Why? Because often a shortsighted view of the problem will lead to ignoring some key actors in the system that play a huge role in the success and effectiveness of that system. So we employ design thinking, a systematic view, to identify all the key actors in the system. We employ empathy to understand their pain points and goals, and the hope here is that if we can establish a deep empathy with the key stakeholders such as users and customers, this empathy, this deep understanding, will inform our key product and design decisions effectively. So that's the second pillar of lean UX.

[00:06:38] The third pillar is of course lean. And lean is itself a very interesting term, derived from Toyota factory lines. Toyota revolutionized their process during the 80s. Essentially they've done many things, but essentially at the core of their revolution, so to speak, was this obsession for reducing waste in their entire product development process. So their mantra was, let's reduce waste to create maximum impact for our customers.

[00:07:38] So when we talk about lean UX, we talk about improving our processes to create maximum impact. So as a lean UX design practitioner, you need to iteratively reflect on your design process and improve it.

The advantages: iteration and faster learning

[00:08:04] So what are the advantages of lean UX, and why should your company or startup adhere to and employ such a new mindset? We employ lean UX because we believe that great products rarely arrive by accident. Rather, they are the result of many rounds of iteration. If your UX design process takes a long while, if it takes you six months to develop a core feature, a big feature, or three months, you really cannot iterate. And often the problem with inexperienced product teams is that they go with their first idea, or second idea, or first prototype, or second design. The key to a great product lies in iteration, and your UX design process needs to allow you to do that.

[00:09:17] Another big advantage of lean UX is it helps you to maximize your learning. In 2023, my friends, your key competitive advantage is about learning faster than your competitors, not shipping faster. A lot of product teams want to ship faster because they can expose their product ideas and features to the market and learn from it. That was an effective strategy, but not in 2023. In 2023 you have an abundance of no-code tools out there that help you to release the early version of your product faster to the market.

[00:10:19] One thing that you want to know, also pay attention, is that not all the learnings that you want to gain are equal in terms of cost and effort. The learnings that you gain in production are costlier than the learnings that you could gain in the pre-build discovery phase. Also, if you launch a feature and it was a mistake, undoing that feature is costlier as well. So as a product team you want to strategically gain most of your learning in the pre-build, in the discovery phase.

[00:11:26] And lean UX is perfect for it. It allows you to prototype your ideas as fast as possible and as cheaply as possible, so you can get out there and expose your product ideas at early stages to your target market and learn from it.

[00:11:52] Talking about products in 2023, you need to change your perspective of what a product is. In 2022 we've had clients that, based off the interactive prototypes that we designed for them, have raised seven figure investment, they have closed contracts. So if by definition a product is a systematic workflow that solves a target group's pain point in exchange for monetary value, the interactive prototype is the first version of your product. So you can gain a lot of learnings using no-code solutions as fast as possible, as quickly as possible, as cheaply as possible, using lean UX.

Our three-week discovery cycle

[00:13:09] So I talked about the foundation of lean UX, which is based on agile, design thinking and being lean. I talked about product discovery and how it helps to solve the challenges designers face working in an agile environment. I talked about the advantages of lean UX. Let's go through a typical lean UX process that we use at Bonanza Design to deliver large scale design projects for our clients.

[00:13:54] Just for the context here, at every given time we usually work on five to ten different projects. So we use this process iteratively, and this process gets optimized based on the learnings that we gain from each of these projects.

[00:14:23] We follow a three-week cycle of learn, prototype, test. You can call it a sprint of product discovery. We always start with learning. We use a combination of qualitative and quantitative methods to learn, including expert interviews, customer interviews, user interviews, trend analysis, market research, competitive research. Then in the second week we jump into prototyping, fast prototyping. And in the third week we test a prototype with the target market.

[00:15:15] It could be an interactive prototype, or it could be a landing page, especially if you're testing a problem-solution space, if you're testing, validating a value proposition. So it really depends at which stage of product development you are. If you're at early stages, we use landing pages, LinkedIn posts, to test these ideas. If you are at later stages, we use wireframes and interactive prototypes. In the testing, we find people relevant, similar to your user personas, and we will test with them in the third week.

[00:15:57] And we conduct this cycle many rounds, and each time that we conduct this round our prototypes evolve. And important is that when I talk about iteration, I'm not talking about incremental improvements. I'm talking about overhauls, radical change in the way we assume this product should be about. That's the definition of iteration. Why? Because great products rarely arrive by accident, they are the result of many rounds of iteration. Your iteration must be bold and daring.

Inside the weeks: learning, ideation, wireframes

[00:16:50] So in the first week I talked to you about learning. We learn however is possible, qualitative and quantitative. We usually start with qualitative, then we use quantitative methods like surveys to test some of our assumptions.

[00:17:12] In the second week we start with ideation, a fast ideation process to come up with random ideas. We prioritize them, and based on those ideas we develop hypotheses, and for every major hypothesis we start wireframing. Our early wireframes could be as simple as something like this. This is actually a developed version of a wireframe. We have wireframes on stickies that only briefly, visually talk about what that idea looks like. This is a much more developed wireframe that you're seeing.

[00:18:08] And each time we do wireframes, we want to create conversation around the wireframes. In the early stages we want to do internal testing, we do limited user testing. As we develop our wireframes, we get out there more, out of the office, and reach out to customers. I'll show you an evolution of this wireframe so you could see it for yourself, after many rounds of iteration what would happen to a design like this. So this was the first version, and after a few rounds of iteration we have a wireframe like this.

[00:19:03] And when we develop wireframes, then we get them to test. This testing could be interactive prototypes, this testing could be going to a cafe and showing a landing page to a random person and getting their impression. But after each round of testing we create stickies, we generate insight, we create affinity diagramming, and we categorize all of our insight that we get from the testings. And we try to basically grade our insight based on the frequency: how many times this insight was raised during the test. The more it is raised, the stronger that insight or signal is. And based on the insight that we get from the test, we continue iterating. And this is the high fidelity version of the wireframe that I showed you.

Walking through the Figma file

[00:20:13] Quickly, before I close it and open it to questions, this is our typical Figma file. I don't know if you see it properly. I hope you see it properly. On the left side we have different pages, but let me just go through one of the pages so you could see what we're doing, especially the research phase, because that's the Achilles heel of a lot of design teams. We create personas, we create one-page summary personas. One-page summary is because a lot of product leaders that we work with are busy.

[00:21:01] We record all the user testings and put it here for review. We create a video summary of all the videos too, because we know that our product leaders are busy and they cannot go through seven hours, but they can go through 20 minutes. And then we do insight gathering based on each screen, as you can see. Insights are color-coded. Yellow means doubt, red means negative, green means positive. Emotions next to each sticky.

[00:21:39] And we do these for all the screens. As you can see, if I zoom out, you could see different rounds of user testing that we conducted. This is one round, this is another round here, this is another round below, and this is another round. As we gather insights, we create the exhibition and we encourage our product leaders and clients to do random walks. This is the exhibition that we create for them. They can come in, look at all the insights that we conduct and generate in each round of user testing, and hopefully this will inspire them and inform their decisions.

[00:22:27] Thank you everyone. This was a bit of an intro on lean UX and a bit of a showcase on how we conduct research. I hope this was useful to you. I'm more than happy to answer a couple of questions if you have.

Q&A

[00:22:48] Rory: Thank you very much. Yes, Gary is asking some questions here. Thanks for sharing that. I'm always personally really interested to see, like you just showed there, the Figma file of how people structure things. So thanks for sharing that, it was really interesting for me. I've got two questions. Great points on learning fast. Okay, so can you speak more on how you were able to change a large corporation to think this way? That's the question.

[00:23:23] Behrad: It doesn't happen overnight, it happens on small steps. So what we do, we usually pick a very important project that they have, and we try to work with a dedicated team from the corporate on that project. We try to get to a result, we try to create a showcase, and as we are getting to success hopefully on that project, we will try to work with other teams. So we start to train a few teams in the beginning and we try to basically plant the seed in some core teams. And then after a time frame between 3 to 12 months, then we see that a couple of teams, or some teams, have been trained with this new way of working, then we will try to evangelize that process for larger groups of people in that corporate.

[00:24:20] Rory: Great, yeah. Change is never a quick thing. I have one: I love that Figma structure you had, but it kind of went from persona straight to screens. Do you do an intermediary step before, of trying to figure out what screens you'll need, or really understanding the problem space before you get to the step of having screens?

[00:24:42] Behrad: Oh yeah, there's a lot of messiness in between that we don't show in the presentation, because these are the exhibitions that we create and it is for review of all the teams of our clients. So sometimes there is like 25 pairs of eyes going to these Figma files and looking at the insight. So when we create exhibitions as such, we try to be really strategic about the key insight that we are presenting. But we usually go through a messy process of guessing who our user personas are, then go through ideation especially on stickies, then go through storyboarding, from the storyboarding we go through paper ideations, then wireframing, then prototypes and interactive ones. So it's a very messy process. That's itself another topic. In case, Rory, you want to invite me for that, I'm happy to give a presentation on that. But yeah, it's very messy in that sense.

[00:25:50] Rory: Okay, great. I was just making sure that I wasn't missing something and that the step is happening, or many steps. Brilliant. I have a new one here: what are your thoughts on the typical lean UX canvas from Jeff?

[00:26:12] Behrad: I think it's a fantastic framework and you should use it if you don't have experience with lean UX. But in the book itself Jeff says that you can ignore this canvas and do it if you're a practitioner. So always my answer to my students here is that use a framework that is tested and is popular, because that gives you a framework, and as you gain practice and experience in your process then you can ignore that framework and do it yourself.

[00:26:45] Rory: Yeah, no, it's great. I think it's when you become an expert in something you no longer need the crutches or the prompts that the beginners need.

[00:26:58] Behrad: Exactly.

[00:26:58] Rory: Excellent. Well, I think that brings us to the end of time. So thank you very much. We're getting some good feedback there on the chat that people enjoyed the talk. So thank you for sharing, and yeah, I think that brings us to an end. So once again, thank you Behrad.

[00:27:14] Behrad: My pleasure.