Agile methodology, in its truest form, is not a series of processes, sprint cadences, and ceremonies. It’s the ability to quickly adapt or pivot when faced with unforeseen challenges or new information. It often comes into play while reprioritizing a backlog of work or deciding on a quicker/cheaper way to implement a feature during development.
Following an Agile approach in development has been so heavily advocated that it has become the norm. But what about design?
While we’ve integrated design into our processes, we still hold it to waterfall expectations. Once a feature is reviewed and approved, the design team is done with it.
New Info, Big Changes
There is a delicate balance in UI/UX design. What may seem like small changes can have rippling effects throughout the interface.
In my last blog post, I talked about how users need rules. When we start to ask for changes that break established rules, we should take a moment for the design team to assess any other changes that need to be made at the same time.
As developers continue to build out new features and components, they can accrue technical debt. But projects can also accrue design debt as they go along. As we gather requirements or user feedback, we may learn more about the application we are building, and we may find features or components that need to change.
This goes hand-in-hand with the previous section. New info often leads to design debt.
Allow Design to Change
Designers can be their own worst critics. There is always a better solution, a more concise workflow, or even a better shade of grey. But once a design is reviewed and approved by the client, we may lose our opportunity to make it better.
Obviously, a minimally viable product “works.” But we are designing for users. We are empathetic. We want to provide the best looking and most usable software that we can deliver.