Agile anti-patterns that will harm UX — Part 2

5 min readJan 15, 2024

This is the second article in a two part series covering the 10 most common Agile anti-patterns that can really harm UX. Part one of Agile anti-patterns that will harm UX covered anti-patterns such as zero upfront design, planning only a sprint ahead and not iterating after releasing. This second part will cover 5 more Agile anti-patterns to avoid. For each you’ll learn what the anti-pattern is and how to avoid it.

Lack of UX quality controls

When Agile teams consider whether a new feature should be released or not, it’s often framed as, “Are there any bugs?” or, “Are there any failing tests?”. However, the absence of bugs and failing tests doesn’t mean that a feature is necessarily of a high quality. The code might be brilliant, but the new feature might be unusable, it might be of no value to users, or might even be detrimental to the overall user experience.

It’s important that Agile teams have quality controls in place that assess not only the quality of their code, but also the quality of the user experience being delivered by their code. For example, assessing the usability of a new feature through usability testing, or a usability and accessibility review prior to release. It can be useful for Agile teams to establish a UX checklist to help introduce some much needed UX quality controls. See How to maintain quality with a UX checklist for the sort of UX checklist Agile teams could utilise.

Waiting for user feedback

Too many Agile teams assume that their users will let them know when they’ve got it wrong. They will release something very basic, perhaps based on lots of assumptions and then wait for the feedback to come flooding in. The problem is that most users are too nice, too busy, too lazy or simply too apathetic to provide any feedback. Rather than a flood of feedback, it’s usually barely a trickle.

Agile teams should absolutely be gathering user feedback and insights following a release. However, they should also be gathering user feedback and insights before a release as well. This might be by carrying out user interviews to better understand user needs and requirements, by evaluating ideas using early prototypes, or by carrying out usability testing to test the usability of potential designs. See The cost of waiting for users to complain and Why the user is not always right for more about how Agile teams can pro-actively carry out user research to find out whether they are on the right track, or not.

*Don’t wait for users to complain. Agile teams should be proactively carrying out user research*

Focusing only on quantitative feedback

When many Agile teams talk about feedback, what they tend to focus on are usage, or user metrics. How much is a new feature being used? Where are users dropping off in a flow? What is the customer satisfaction or NPS rating? Quantitative feedback like this is important, but it will only ever tell you one side of a story. The data will tell them what is happening, but not necessarily give an indication of why.

It’s important that Agile teams collect both quantitative and qualitative feedback. Quantitative feedback, such as metrics and ratings can tell a team what is happening. Qualitative feedback, such as open text user surveys, user interviews or even focus groups can give an indication of why. See Data informed design, not data-driven design and 12 tips for better data-informed design for more about utilising both quantitative and qualitative feedback.

Ignoring design debt

If technical debt is the unseen technical cost of MVPs, early iterations, sub-optimal solutions and quick fixes, design debt is the very visible cost of taking an Agile, fast paced approach. The UI components that are different from screen to screen. The siloed features that lead to a fragmented user experience. The navigation pattern that is no longer usable because it can’t accommodate the growth of product features.

Just as Agile teams should have a plan for dealing with technical debt, they should also have a plan for dealing with design debt as well. This could include introducing a design system to help maintain design consistency, setting aside dedicated sprints for dealing with design debt and using tools such as storymapping to help establish a clearer idea of the design roadmap. See How to deal with design debt for more about managing design debt.

*Some examples of the sort of design debt that can build up*

Putting off a design system

When building an early version of a product it can be tempting for Agile teams to put off using a design system until further down the line. Afterall, if a product might be short lived, why go to the bother of creating a design system for it? The problem is that in reality this invariably means that a design system never gets built, or if it does it takes a lot more work because the product has to be substantially re-designed and re-factored to accommodate it.

Rather than putting off using a design system, Agile teams are better to initially put a minimal design system in place, or at least the foundations for one. This might require a bit more work in the short term, but will most certainly pay off in the long term as a design system should lead to faster design, faster development and better consistency within a product. See Agile, design systems and the great railway gauge war for more about the importance of putting in a design system as early as possible.

Conclusion

Agile has become the defacto way for teams to design, develop and deliver software. However, too many teams take an approach that can hinder good design and therefore provide a poor user experience for their users. By avoiding the 10 Agile anti-patterns covered in these two articles teams can ensure that their Agile approach not only accommodates, but actively encourages good UX.

Image credits

Stop sign by Andrii Leonov on Unsplash
Unhappy user photo by Elisa Ventur on Unsplash
Blueprints photo by Daniel McCullough on UnsplashPhoto of rubbish by Gera Kulik on Unsplash

Originally published at https://www.uxforthemasses.com on January 15, 2024.