Agile & Lean UX
Tips for devs and design teams: how to become allies, not enemies.
Alex has just started her new job as a UX designer at GoodSoftware, her aim is to design beautiful and useful products and always listening to her users.
Jo is a principal engineer at GoodSoftware, she loves best dev practices and clean code.
Alex joins the company’s design team. She doesn’t have much contact with Jo’s and her dev team because she is sitting on a different floor. Alex never sees the dev team, apart from some company meetings.
After a few weeks of onboarding, she is given her first design task to design a new feature for the website.
She created a few wireframes which she used to conduct user testing. Afterwards, she produced a high fidelity design.
The design and specs made by Alex are sent to Jo and her team to be built. The dev team was not involved in any conversations and they never saw the new feature before. This shows why following just the UX process in isolation is not enough.
Jo’s feedback goes back to the stakeholders to inform them that the development team have raised some concerns, but the stakeholders insist that the feature should be developed regardless.
The dev team starts development on the feature. They run into several issues and the feature takes much longer than expected to complete. Meanwhile, things change, the market changes, and unfortunately, users don’t need this feature anymore.
Extreme outcome: Data shows that after the feature was shipped only a year after it was designed, very few users used it. The business loses a large amount of money. This is one example of a bad outcome related to a bad process.
Differences between Waterfall and Agile
Jo’s team should choose to follow an Agile process instead of working with a Waterfall approach.
What is Agile?
In 2001, seventeen software developers met at a resort in Utah to discuss how to overcome the following Waterfall development methods.
Together they published a set of methods and practices based on the values and principles of the Manifesto for Agile Software Development.
This includes:
- Responding to change instead of following a strict plan
- Put people over process and tools
- If the requirements shift the development, you adapt the plan
- Delivering fast and often
- Communication and transparency
Because it seems that devs follow an Agile process, and designers follow another, companies are often struggling to bring the best practices together.
But the reality is that the two philosophies complement each other. They can blend nicely running parallel, not as an intersection.
Lean UX can be a useful technique when working on projects where the Agile development method is followed. Lean UX is inspired by Agile development and Lean theories. It defines the practice of shipping faster, with less emphasis on deliverables and a greater focus on the actual experience being delivered. The difference between Lean UX and Agile is that Lean UX does not focus on deliverables as Agile does.
The Lean process starts with a brainstorming session where you’ll state the problem which you have to solve. Then you can start to generate some ideas and assumptions.
What is an assumption?
An assumption is a true statement that helps to gain an understanding of the idea, which will then help to formulate a hypothesis. From there you can create your personas as you do in a standard design thinking process. The personas should include information regarding, goals, behavioural patterns, skills of your users etc.
It is recommended to have a very short, iterative, low-fidelity design cycle, with feedback coming from all members of the team and possibly from end-users. Collaboration with stakeholders and the team is crucial to the end success of the product.
When developers learn about design thinking and when they start to include their customers in the process, they find it useful because they can see how this benefits in gathering the right information for building software. On the other hand, when designers adopt agile strategies they can immediately see that this will drive better collaboration and communication on their teams and better results. This is why it is important that everyone is involved in design thinking activities.
How can you transform your organization and ensure every project delivers value to the business, your customers and your teams?
1. Teams
a. Balanced cross-functional teams. Successful teams are cross-functional and small (squads). Usually, a squad is made up of a product manager, devs and data scientists and one or more designers. You should build squads that are focused on a specific task.
b. Build a problem-focused team. The team should be given a problem to solve instead of solutions to implement. This creates a feeling of ownership, autonomy and accountability among team members.
c. Increase transparency. Participating in the scrum and other common team rituals will help to build trust among team members and to break the silos. Retrospective, for example, is a good way to analyse what went well and what could be improved.
2. Product
a. Make long term plans with short cycles of iterations. Iterations are the key to collecting evidence and to validating decisions with low risk and low cost.
b. Strip everything down to bare components. The documentation created should only provide the minimum amount of information necessary to get started implementing the Minimum Marketable Feature (MMF).
c. Make assumptions, ship often and fast, and learn. Don’t be afraid to fail. When you design or build features answer the question: What is the smallest thing with the minimum effort we can do to test our assumption?
d. Measure. After the launch, you can conduct various activities to observe how users use the product. Some of these are:
- Usability testing to learn user’s behaviours
- Offline surveys
- Analytics. For example, funnel analysis
- A/B testing
3. Tools and Practices
a. Show it, don’t tell it. As a designer, you should organise design activities and workshops with devs and stakeholders. This is a good way to align teams and to get everyone involved. Bringing everyone into the conversation helps to get feedback at the early stage. Use design tools with stakeholders. You can find lots of useful tools online that will help you to align your stakeholder and to set up expectations. Whiteboarding and sharing, for example, allow sharing early-stage ideas and sketches. Ask your team to use post-its and a whiteboard when you can, or preferably use remote tools like mural (Save the planet ❤). Remember that the goal of these activities is to move the conversation to the next step. Try to remove waste. In this case, remove the waste of time.
b. Arrange the technical conversations upfront. Have frequent conversations with the dev team at the very beginning to ensure feasibility. One of the tools I like to use to ensure this is the Prioritisation Matrices. This can help the team to focus on the right feature or user story combining feasibility for the team and value for the users.
c. As a designer, pair with your devs. This will help you iterate designs and build designs very quickly. Take advantage of a design system with common components and patterns to save time for the design and the implementation. A single and reusable design system is a powerful tool that allows not only to save time for the implementation but also to deliver a consistent experience across multiple platforms and products. It helps to break silos because it allows simplifying the design process.
Summarising:
Each team has to build its own process. Agile, Lean and design thinking are all great and offer methodologies and tools that need to be adjusted to each team. Remember to iterate!
The above article is personal and does not represent any current or past employers positions, strategies or opinions.
