Agile Design Traps & How to Avoid Them

agile design traps

Previously, we defined and explained various approaches to Agile UX. Here, we identify design traps related to Agile and offer suggestions for avoiding these traps.

In Some Thoughts on Design Research, Agile, and Traps Charles Lambdin identifies common design process traps. The root of these traps is the absence of research goals. These traps lead to bad design and are only exacerbated by Agile.

Agile Design Trap 1: Thinking We Can Only Learn from Live Product

This mindset emphasizes delivery over usable design and ignores the types of questions researchers, designers, and product managers should be asking. Agile makes this problem worse by emphasizing the need for delivery of working software: “If you’re building the wrong thing, then building more of it isn’t going to solve the problem.”

In this design scenario, teams are taking orders and delivering products. They are not solving problems and creating value.

Agile Design Trap 2: Viewing Value as Product Delivered, as Opposed to Value Created

Indeed, the emphasis on delivery “confuses a way station with the goal. In this view, anything we suspect will slow the filling of orders thereby slows value,” writes Lambdin. This mindset leads stakeholders to view research as a waste of time: “If what is being left unsaid is that the org is going to continue funding the HiPPO (Highest Paid Person’s Opinion) come what may, then, yes, doing any research would in fact be waste!”

When leaders define value solely based on product delivery, the organization cannot be truly Agile. As Lambdin explains, Agile is not about building quickly: “It’s about empowering teams to discover what they should be doing as they quest…something design research can and should help with.” The purpose of research is to probe the problem, analyze the findings, and generate value based on these findings.

Agile Design Trap 3: Thinking of Design Research as Unneeded Trimmings, as ‘Icing on the Cake’


UXers are well familiar with the complaint that research takes too much time. Managers emphasize the need to get the product out the door. Lambdin gets right to the point: “This statement is only true to the extent that whatever research is done will be ignored! The very point of design research, after all, is to determine what work the team should be doing in the first place. If discovery is ‘icing on the cake,”’ then where did the cake come from?”

Agile teams seem to presume that research is somehow already underway. Lambdin argues that this is rarely the case. Our experience at UI UX Training supports this conclusion.

In short, when decision makers refer to research as ‘icing on the cake,’ it usually means that someone persuaded leadership to fund a specific product. It might be a great idea, but it’s hard to know without conducting research.

Agile Design Trap 4: Dictating Activities Without Knowing What Outcome You’re Trying to Achieve

This trap stems from vague goals such as providing a good user experience or delivering innovative software. Agile is not the main cause. Yet, the drive to deliver often prevents teams from thinking carefully about what they are trying to achieve. To succeed, the organization must provide a product or service that provides value to both users and the organization.

Certainly, this point sounds straightforward. As all design professionals recognize, however, it’s not easy to balance user and internal stakeholder needs.


Fortunately, one solution falls squarely into the UX designer’s wheelhouse. Lambdin explains: “Research your stakeholders and learn how they make decisions. Learn what data they find persuasive. Before doing research for them, research to learn how to make your research effective.” The point is to reach beyond the traditional questions about business goals and product specs. The purpose of this research is learn how to meet stakeholder needs and then present findings in a way that will fit into their existing decision process. In short, treat stakeholders like users to learn how to meet their needs.

In Agile Is not Easy for UX: (How to) Deal with It Page Laubheimer of Nielsen Norman Group offers another solution. One way UX can work within an Agile environment is when “the Agile process isn’t completely policed and strict.”

In other words, if scrum masters and others permit UX designers to work a sprint ahead of developers, the team can achieve usable design without disrupting the Agile development process. Teams that integrate UX effectively into development can learn “to manage tasks and user stories so that UX has some time to get ahead of production and create validated, researched, and thoughtful designs,“ writes Laubheimer. In short, flexibility, cooperation, and planning are the keys to a successful design.


Agile is not the enemy. The emphasis on iteration aligns well with UX. The challenges discussed in this post are Agile-related but also stem from evergreen organizational issues such as:

  • Rushing a product to market
  • An emphasis on short-term revenue over long-term value and forging strong customer relatiosnhips
  • Decisions based on assumptions rather than rigorous customer research

UX practitioners must continue efforts to demonstrate the value of UX, especially in the fast-moving Agile environment.