Agile & Lean UX
A collection of tasks, strung together to achieve the best result.
In this session we cover introductions to:
- Defining a UX workflow
- Waterfall vs. Agile vs. Lean: what are they?
- The core Lean UX principles
- Double Diamond
Defining a UX workflow
Spoiler alert! UX Design doesn’t have a single defined process or workflow. There isn’t a definitive list of steps that work unchanged, each and every time (that would be boring!) Part of your job and value as a UX practitioner is to evaluate the project, define the goals, understand the organisation and then select the right tools for the job.
Let’s consider an example.
Here is your (simplified) UX toolkit. You can see tasks roughly separated by function:;
Discovery & User Testing
Tasks designed to help you learn about your users and their behaviours.
Strategy & Ideation
Tasks designed to help you form insights, work as a team, set strategic goals and find creative solutions.
Content & IA
Tasks designed to help you create meaningful content and organise it so users can find it.
Tasks for designing intuitive interfaces that users will interact with.
Note, tasks aren’t confined to being used in sequence.
Let’s review three different kinds of projects:
You can see that although there are many similarities, each project requires a different mix of UX activities. An eCommerce site has more content, requiring more time spent on organising the information architecture (IA), while the feature-heavy weather app needs more time spent ideating and understanding user behaviours.
Lastly, if we zoom in on the weather app project, we can see how the tasks flow together, feeding information from one stage to the next.
It is important to note that this process might contain many UX designers working together. UX designers can choose to specialise in a single area (a single row in the diagram) or apply their skills more broadly across the full spectrum of activities.
This granularity and flexibility allows UX as a discipline to work with and provide value to any organisation or project regardless of time or budget constraints.
There are many different project methodologies each with different strengths, weakness, advocates and evangelists. UX works in all of them.
UX is methodology agnostic.
Knowing your project methodology
There isn’t room in this post to discuss all the various project methodologies, but it is important to know whether you are going to follow a traditional linear model or take a more flexible iterative approach to your project.
Working in a linear way (‘Waterfall’)
Sometimes also called Prince2 or Pmbok
The term ‘waterfall' is often used to describe traditional linear ways of working because water in a waterfall only flows one way. Water starts at the top and then makes its way down level by level until it reaches the main body of water at the bottom. Similarly, in these kinds of projects, each person (or team of people) complete their individual part of the project before passing the job down to the next person (or team of people).
If you’re designing a website following a waterfall approach it might look something like this:
There is limited communication during the handover from one department to another, and for the bulk of the time, each team is working in their specialty silos.
Although not the most ‘trendy’ way of working in 2017, waterfall projects are still very common and can work well, especially when the project is small and well defined. The biggest benefit waterfall provides is that it calls for the bulk of the planning and strategising to be completed upfront before moving on to the implementation phase. This has many flow-on benefits:
- A well-defined project can be cheaper. Designers and developers can provide fixed-price quotes and business leaders can make decisions based on hard numbers and budgets.
- Upfront planning allows you to predict potential problems and then either mitigate or create contingencies.
- You can employ specific skill sets like designers or developers for smaller, discrete chunks of time as required.
This upfront planning is also the reason why so many I.T. projects go over time and budget. When something unforeseen happens or the base project assumptions change – like sand getting into the gears of a highly-tuned machine – the strengths of the waterfall approach start to work against it:
- If you have fixed-price quotes and then requirements change, budgets and schedules blow out. Often significantly.
- If an unforeseen problem arises, you have no contingencies or processes to deal with it.
- If you discover a design problem after the designers have finished up, it can be tricky or costly to re-engage their expertise. The same can be said of any skill set like content authors, developers, testers, managers and business analysts. The nature of these silos means that problems are solved by whoever is available when they arise not by the skill set best placed to solve them.
From a purely practical point of view, a waterfall approach is often very appealing. Most people like the idea of planning and feel nervous about jumping in without proper thought. I’m sure your parents and teachers always told you to ‘take your time’ and ‘don’t rush’. In an ideal world where all unknowns are known, and every contingency can be foreseen, then a waterfall approach would most likely be the most efficient way.
It is not an ideal world; the unknowns are never known. User needs, the technical environment and business requirements are always changing. The longer the project goes on, the higher the risks of the initial planning becoming out of date. What was a good feature in January is now not such a good feature in August. In a waterfall model, you tend to build it anyway because it is budgeted for and no-one has spent time since January talking to your customers to see if they still need it.
In an agile or iterative project, you split all the planning you would have done at the start of the project throughout the project. You do ‘just enough’ planning every week or two. The benefit of this approach is that the planning and strategy keep pace with the constantly changing market.
The problem with many waterfall projects: a lack of communication…
Taking an Iterative Approach (‘Agile’ or ‘Lean’)
For this article, we are going to use the terms Agile and Lean interchangeably. There are differences between the two ways of working, but they share many common principles, especially when it comes to UX Design.
Fundamentally, working in an iterative way means working as a cross-disciplinary team in short 2- or 3-week project sprints.
Instead of each department working separately and handing over requirements from one team to the next; clients, designers and developers all work together to collect the requirements, create the designs and complete the development.
Your project team can also include product owners, producers, iteration managers, researchers, subject matter experts and many other skill sets depending on the project.
A basic Lean model:
The assumption at the core of the Lean methodology is that the first thing you design will be wrong. The aim is to create something as quickly as possible so you can measure and test to find the problems as quickly and inexpensively as possible.
Agile has a much stronger focus on process and team rituals. There is a lot more structure in place to keep the team on track and constantly striving to deliver as much value to the business as possible.
Both Lean and Agile can be used effectively in any sized business primarily because each doesn’t have a fixed process so are free to adapt to the strengths and weakness of the team. For this reason, not all ‘Agile’ businesses work the same way, and when starting out it can often take a few weeks to work out the kinks.
The core Lean UX principles:
As there is no defined process, you would be right to ask ‘how do I know if I’m working in an Agile or Lean way?’ To help guide you, here is a cheat sheet of core Lean UX principles:
In this course, we are going to focus on Agile and Lean UX. This won’t be a course about these methodologies specifically, but we will work in an iterative way and give you the tools to thrive in these kinds of environments.
We will be working in an iterative, agile way for two main reasons.
Firstly, it is modern and popular. Agile is predominantly the preferred method of working for most development teams in 2017.
Secondly, as a beginner, knowing what you don’t know is tough. When starting out, it is hard to plan a full project’s worth of UX activities from a standing start. Agile is great for beginners because it allows you to select a task, do it, review how you went and then decide what to do next.
For example, if you conduct three user interviews and after looking at your results feel like you need to perform a few more, you can. Alternatively, if you have planned to run ten user interviews but after five feel like you are getting very similar or repetitive results, you can choose to move on to the next stage.
This is what our design sprint will look like:
Our six-week course is split across four themes: discovery, definition, development and delivery. We will start with a very broad problem statement and then use a range of UX techniques to research the business and its users to gain insight into real user problems that we can solve. We will then ideate to find the best possible solutions before prototyping the solutions so we can test them with real users.
When we zoom in, here are the activities we will be completing:
Hi, I’m Ben. By day, I’m the Founder & Head of Product Innovation at Beaker & Flint, where I help organisations design and deliver amazing customer experiences. By night you can find me running a trail or tinkering with code.
If this post sparked a question or idea you want to run by me, I’d love to chat it over with you. Reach out via the comments below or start a conversation via email here.