Working in an Agile environment as a designer is a delicate balancing act. You are constantly required to think ahead, backtrack, justify your design decisions, think of alternatives mid-sprint, and make compromises on your designs in the best interest of the product you are trying to ship.

But amidst all the chaos, it’s the designer’s job to provide order as well.

While a lot of articles cover the agile methodology in-depth, the textbook processes don’t always work. This article does not get into the Agile process itself. Rather, it provides some lesser-known but simple tips that mitigate the chaotic culture that Agile is notorious for.

1. Establish a common vocabulary

As basic as this might sound, establishing a shared vocabulary for design terminology across your team is essential. Oftentimes, teams use the same words to mean different things. I remember working with a team that used the word “mockup” to refer to a mocked-up code base for a test environment. For a designer, a mockup is a polished, pixel perfect representation of an actual product. Furthermore, mockups are created using a design tool without any code. It took me a while to figure out what they called “wireframes” is what we called “mockups”.

While this was a simple issue to tackle on our team, when it comes to business terminology, different stakeholders use the same words to mean different things, which magnifies the problem. With one team lacking knowledge of the other person’s viewpoint, it’s possible to get tangled up in unnecessary conversations. I once worked with a product manager who created a version of truth and a glossary of terms for everything used on a project. Since then, I’ve followed that practice religiously whether or not I have a product management role to play. Establishing a common vocabulary early in the process makes conversations across teams more intentional and saves loads of time and energy.

2. Understand and work within business and technical constraints

As important as it is to advocate for the user and be the user’s voice, it’s equally important to understand business objectives — what drives revenue for the business and provides value to the user you are designing for. The Agile environment is a constant negotiation between product owners, designers, and developers as to which features need to be shipped and which features should be added to a backlog.

Not everything you design will get shipped. It’s common for developers to challenge an idea mid-sprint because it’s not possible to code due to a  direction that was taken in a previous sprint. This is where your knowledge as a designer is put to test. It is essential to think on your feet and come up with alternatives on the fly to make sure a sprint doesn’t get halted, being detached from your work and making compromises in the interest of the greater good of the product being built is essential.

3. Establish and maintain a Design Language

Developers hate rework, period. When it comes to projects heavily constrained with budget and timelines, you often come across scenarios where you have no option but to cut down. The Agile environment is about picking your battles. It’s about letting go of smaller things to achieve larger things, particularly when you want a certain feature to be shipped.

The Atomic design principle definitely helps in this situation to maintain consistency across your design team. Establishing a Design Language System minimizes the time it takes to implement certain commonly used UI controls and enables the development team to focus on code reuse, ultimately saving time and money.

4. Deliver for the short-term, but plant your seeds for the long-term vision

Most agile best practices would recommend staying at least 2 sprints ahead of the development team’s schedule. This ensures that the developers always have enough to work on, but also ensures that the designs are not too far ahead in a state that’s going to take a year to get to after the implementation of other features. However, it is important to plan ahead and plant the right stepping stones to get there.

Getting too far ahead can lead to an unrealistic vision, but it’s also important to make sure the development team isn’t going from building a 2-wheeled bicycle straight to building to a 4-wheeled car. As nice as that sounds in Agile theory, the reality is that you’re completely throwing away the bicycle that was built and starting the car assembly from scratch. This is a common Agile misconception that designers and product owners run into. While technical teams often do a good job at handling these types of requests, it’s the designer’s responsibility to own up the vision and play the balancing act of pairing down a future vision into a current state executable.

5. Don’t make decisions too early but don’t procrastinate either

One of the myths about agile is the concept of “Last Responsible Moment”. This is often used as a procrastination excuse to avoid making decisions. If it’s too late to start building a feature, you’re never going to ship it on time. I was once in a situation where I found that the team was not working on a key feature required on a product and we were getting closer to the time of launch. It was not clear why the team had not started working on the feature and raising my concern allowed me to get the attention of the technical team to weigh in on the effort and prioritize it for the backlog.

When most people are heads down in their respective spaces, it’s the designer’s role in voicing out key strategic decisions and being the voice in guiding the product execution in conjunction with the product owner.

6. Avoid being a process purist

One of the worst mistakes you can make as a designer or a product owner is getting too attached to a process, so much that it comes in the way of the actual execution. Sometimes it is important to ditch the process. Knowing when to make such decisions comes with keen observation and intuition that comes from knowledge and experience.

I was once questioned by a Product Manager on why I was not waiting for the weekly design review meetings to present designs the first time. What he wasn’t aware of was how it would have affected the team had I not intentionally bent the process. It was going to affect the whole team had I not received timely feedback and buy-in from the myriad of stakeholders we were dealing with. Having known that it was going to take weeks to get the designs signed off, it did not make sense for me to play the waiting game as I had owned the responsibility of keeping the team moving. By doing that, I was also able to save the time and energy the developers were having to unnecessarily spend in those debates while letting them focus on what they were good at — building great products.

Ditch the process when you need to. Once in a while, it becomes the designer’s responsibility to shield the rest of the team from conversations they need not be part of, which is a good segue into the next tip.

7. Be an effective team player, but also a good negotiator

When you’re done with your job and in control of everything you need to do as a designer, it’s your responsibility to get into situations where you take one for the team. There is nothing more important than teamwork to get you past the finish line in crunch situations. Fostering good relationships with developers is going to encourage them to do extra work to ship your good looking designs. Product owners and stakeholders are going to listen to you more. You may need to sometimes let them win small battles. With people occasionally picking and choosing pieces of the designs to be built, it’s your job to continue to be a “yes, and…” person and foster a positive environment, because you are trained to do so.

At the same time, it’s important to avoid being timid. Your responsibility as a UX designer is to advocate for the user when the business contradicts it, support the business objectives when the development team tends to cut down on features, and stand up for the developers when there is technical debt that needs to be fixed.

Design is only one piece of the puzzle

Because design is ultimately an interconnected, cross-disciplinary effort, designers should know when to let go of an established design process. If it gets in the way of the design itself, it’s important to readjust.

Design is about making calculated compromises. The goal of a designer is not to create the most pixel perfect mockup, but rather, to ship designs that effectively solve a problem or problems that require solving. Being an Agile designer is about being nimble, open-minded, and tactful. It is about being truly agile in every sense of the word.