Design and Agile are two terms that have been difficult to bring together. While developer teams moved to agile ways of working a while ago, the design part of the same teams have tended to stay in some variant of a waterfall. That means often that the designers work a few sprints ahead of the developers and in bigger blocks, creating a separation of cadences between two practice areas of the team that makes it harder to move together and perform as a unified group.

This way of working is often translated in designs that are “chopped” by the developers and PMs during the sprint planning sessions to adjust to user stories, scopes and MVP requirements. The constant “chopping” generates constant tension between design and devs/PM and a certain grade of frustration from the design side as their hard work never see the light properly.

You could say that is a “healthy” and “necessary” tension between desirability and feasibility, but I strongly disagree. That is not a team working together in a healthy and collaborative way. Design magic happens when the team lives, breath and collaborate in the intersection.

The alternative to this is to move to a fully agile way of working, and the design response to that obvious:

We can’t design one user story at a time, as we need see how them fit in the bigger vision and do pertinent research before proceed to design.

That is completely true, but not the only way to be agile in design.

Over the years I found an interesting formula of doing agile design avoiding this lack of vision, bringing the team together and really delivering a better product in the hands of the users. It’s inspired by many brilliant people that I worked with over the years and based in 4 principles:

1. Strategy Plan together the roadmap and build to learn and de-risk the functionality
2. Fidelity Evolve the fidelity of the design as you get clarity and alignment
3. Rhythm Move in sprints, bringing together the team in the design process and incorporating research and discovery loops
4. Feedback Incorporate feedback loops from the team, from users and from real customers

1. Strategy

Plan together the roadmap and build to learn and de-risk

After a hight level definition and alignment time (how long depends on the type of project you are at, I loved this framework), you need a loose North Star to start working. But don’t define it too detail or you’ll get attached to the solution. Good defined goals, a tentative architecture and maybe some high level concept designs are more than enough to start with.

Decide with the product manager what things are you relatively sure about (login, payment, register) and what things need further research. Choose strategically the map and make sure you make it small enough that you can learn and iterate on it. Once you have that, prioritise the low hanging functionality first so the development team can start building things, and distribute the research through the different sprints (see point 3).

Being strategic is not related to define the vision, is to define the way to achieve that vision, step by step.

2. Fidelity

Evolve the fidelity of the design in phases as you get clarity and alignment

For each piece of functionality, think in different fidelities

Fidelity 1 is for alignment, to share ideas with the team. You don’t need more than a sketch for this, and is better if you ask everyone to participate and discuss. Once the alignment goal is achieved and you need the info and buying from the team you need, move on.

Fidelity 2 is for testing & feedback, to make sure the ideas work. Make It enough to test with users, yo don’t need all the details yet. Once you have tested and got feedback, move on.

Fidelity 3 is what is going to be build. Can be detailed design or pair designer with an engineer if your design system is mature enough. Make sure yo build enough to learn and test for the next iteration. Once is there, move on.

3. Rhythm

Move in sprints, bringing together the team in the design process and incorporating research and discovery loops

Design cadence is a thing. Get the design ceremonies into the team rhythm, and bring people along in every spring. Make sure there is alignment with product and buying from engineers. Believe me: if the the developing part of the team feels is also their solution, they will really go the extra mile and the product you put in the hands of the user will be incredibly better.

The sprints from design move from fidelity 1 to 3 each of the blocks of designs that we aligned previously in step 1, making sure that everyone is align and understand how this fits in the bigger picture that we call the North Star. They have their own ceremonies.

Design kick off, where we bring together the team, align on goals and work in fidelity 1 solutions

Design check in, where we bring again together the team, align in what is going to be tested and researched in this sprint and get feedback

There is also things that happen on the background

Design work, where we translate solutions into outputs, that is better to share as often as possible. Sometimes it happens in Figma, but not always. The less time you spend on your own, the better for the product. Keyword is Collaborate

Test and discovery, where we make sure we are testing with users and at the same time, discovering what we need to know for next sprints.

• Doesn’t need to be very polished because frequency is better than quantity and we want to be incorporating user feedback every spring. Is better to talk with 3 users every two weeks for 3 months than with 8 user only once
• Bring people along, as for volunteers notetakers and help in recruitment from the rest of the team. This is not a only design activity
• Share the love. You don’t need big reports after the testing, just a list of actionable items and maybe highlights after each test/interviews in slack

And there are things that don’t happen:

Handovers to the devs, because everyone is align and participating in the process. It’s handy to mark a day where the design is “ready” if you are working in Figma, but this is pretty much it. The glory about this way of working is that everyone is really involved in the solution so they know how it needs to work, and you’ll save a lot of time documenting stuff and clarifying misunderstandings.

4.Feedback

Incorporate feedback loops from users and from real customers

Working agile is not an excuse for don’t doing research and testing, just a distributed way to do it. In addition to the sprint as usual testing/discovery loop, you’ll want to incorporate more and more feedback as you are progression in the build:

The beauty of shipping something early is that you will be playing around with the product early, and that will allow you to learn and correct stuff as you build.

The beauty of having an MVP, even if it’s rough, is that you can have some real users using it, and you will be able to incorporate learnings before the great launch. As soon as you have some kind of MVP out there, is very useful to create a costumer stream that surveys that control users and get their feedback about the working product as they are using it in real time. Not to say about keeping an eye on the analytics and usage stats of your product.

The beauty of having the product in market, is to be able to incorporate that feedback of real users. For this, any feedback tool that you can incorporate to your product is welcome, and will be a really valuable source of real inputs

The extra ball: Team feedback

As important to get fast and frequent feedback from your users/customers, is to get feedback from your team and create spaces to get it as soon as possible and as regular as possible. That is why you are creating collaboration spaces in your design Rhythm (principle 3)

That doesn’t mean the team is the owner/responsible of the user experience. As a designer, you are. But opening spaces where the team can contribute to the design decisions and make so as soon as possible in your design process (whiteboard is thousands of times better than Figma) will help you to get better results. Diverse feedback will force you to operate in that magic intersection of desirability, feasibility and viability. It’s easy: really listen to feedback, collect it, process it, and decide what, how and why you incorporate it (make it sure you communicate that back).

Truly listening to diverse feedback and opinions consistently during your design process will keep you and your team true to what you’re building together.

‍