Please note: In this post, I will refer to all design practices, User Experience Design, Interface Design, Visual Design, and Design Research as design.
Much has been written about Lean UX and the role of design in Agile development. Design’s primary role is reducing the risk that the team is building the wrong thing or building something that is hard to use. Yes, it needs to look good, but that’s the easy part. Over my years of working as a designer within Agile teams on new products, I have honed what I call “just-in-time design” – the concept of designing just enough, just when it’s needed. It is an approach that helps designers reduce waste and increase effectiveness.
No designer wants to spend time designing features that never make it to the customer or get drastically reduced in scope just before the sprint. In Lean terminology this is waste; time spent on activities that do not add value to the product value stream. Waste increases cycle time and reduces effectiveness. In short, it slows everyone and everything down. In a time where value acceleration is the ultimate goal, we need to make sure that design effort is maximized for value delivery.
Just-in-time design focuses effort in four critical areas.
- Backlog refinement
- Scoping
- Sizing
- Planning
1. Backlog refinement
Spend one to two hours a week reviewing the backlog. Timebox it. Go through the features quickly. Become familiar with the highest priority items (don’t do this for the entire backlog). Work with product to understand the business need if it’s not well described. Help the product owner define the business need if they need help. Make sure you understand the customers’ pain points. How will this feature remove that pain point? The first source of waste is designing a solution for the wrong problem.
When reviewing the backlog, look for features with large assumptions, or ambiguous requirements. An example of an assumption is, “We believe the user will have the necessary information to complete this form at this point in the process.” In this stage it is best to work with a subset of the team with different roles. More varied perspectives will unearth more assumptions.
Assign a size or value to each assumption by asking, “What if we are wrong about this assumption?” Write those assumptions and scores down. Then look for ways to prove or disprove those assumptions before the team begins coding.
Validation can include user research such as talking to customers to better understand who, what, where, when and how. Who does the work, what do they do, why they might need this feature, when would they use it and how would they want to use it? Another way to validate assumptions is to mock up a quick design to test with users. In this case your testing less for usability and more for usefulness.
But don’t do any of that work yet! Before you move to design, you need to scope, size and plan your work.
2. Scoping
Work with the team to scope the effort. The second source of waste is designing more than is needed or can be built. Designers often complain about “Minimum Viable Product”, but before there was MVP, there was the design maxim “less is more”. The famous French poet, Antoine de Saint-Exupery, is quoted as saying, “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.” Ask yourself, what is the minimum user experience needed to achieve the stated business outcome of this feature?
Work with the engineering team to understand the effort that may be required to build the feature. They have likely already done some thinking about how they would approach the problem and sizing of their own. If not, then now is a good time to get them thinking.
3. Sizing
Sizing is not just for the engineering team. Sizing the effort to design each feature will require you to think about the steps needed to complete the design. Who will you need to talk to or coordinate with? What are the dependencies?
Precision is not important, just a rough number of days or weeks you think would be required to research, design and test your hypothesis. Don’t worry, you’ll get better over time with practice. Sizing is critical because it tells you how much runway you need to have the feature ready for the team when they start implementation.
4. Planning
Third, rank the features based on size and grouped by the proposed implementation date. This will give you a rough idea of when to start working on a feature. This is why I do not advocate starting a sprint ahead or some standard timeframe as a guiding principle. Some features will require more work, others less.
Getting the timing right is important because if your design sits on the shelf too long, the team will forget the finer points of the feature and learnings from research. It will take time to either document the design or ramp back up at a later time. All of this results in time being spent on activities that don’t add value. The third source of waste is designing a feature too early or too late. If you start too late, then your work is rushed and you may have to cut important activities like research or testing, resulting in a design that does not achieve its end goal.
Too many things can change between the time you design a feature and the time it is implemented and delivered to customers. Other priorities become more important. Requirements change. Customers change their mind. Product pivots. The feature may be moved much lower in priority on the backlog and never be implemented. The fourth source of waste is designing a feature that is not implemented.
Once you have this information, you’ll have confidence in knowing what to design, how to design it and when to start.
Next steps
Revisit this process periodically. Invest a little more time in understanding the features and planning your work as you near an implementation date. This approach prevents spending too much time planning things that are too far out on the roadmap.
If you work in a larger design team, you’ll likely have a design manager that helps plan the work for the team. If you’re working on a smaller team or as an independent contributor, it is more important that you devote time to this process yourself. Your time is valuable and you don’t want to waste it on activities that don’t contribute value to the product.
Lastly, it’s crucial that you regularly test your products’ UX – you can learn more about how we run our own Usability Testing Program in-house to ensure we’re always delighting and delivering value to end-users.
https://blog.tasktop.com/blog/optimizing-ux-how-to-set-up-your-own-usability-testing-program-in-house/
https://blog.tasktop.com/blog/bootstrapping-a-usability-testing-program/
