Adobe Creative Cloud

June 23, 2016 /UX/UI Design /

Why UX Design Should be Aligned with Development Sprints

In my first job as a UX Designer, the company I worked for had no UX design process in place. They merely had an idea on how to integrate it in a waterfall model based on some project management guidelines. A lot has changed since then.

Agile development methodology has become increasingly popular in recent years and most people, like myself, would never want to revert back to a waterfall development process. However, Agile poses some unique challenges when it comes to UX design.

Agile and UX are not a perfect fit

One would think that Agile and UX go well together since Agile methods appear to match the way people typically solve problems, through adaptive planning, flexibility and continuous improvement. But since the Agile methodology is defined only by a set of principles and not a specific framework, it leaves room for interpretation.

This is where Scrum, an Agile software development framework that is based on several iterations (known as sprints) that last for a fixed amount of time, comes in. Scrum effectively introduces teams to an Agile type of thinking due to its prescriptive structure. By pairing the Scrum framework with Agile methodology, you solve the problem of interpretation.

In order to maximize the contribution of all the teams involved, Scrum defines roles which lead to a shared understanding of who needs to do what. It defines the product owner, the development team and the scrum master, but it doesn’t account for other roles like that of the UX team.

Defining the role of UX in Agile development with Scrum

Due to the fact that UX’s role isn’t clearly defined, many organizations whose development teams adopted Scrum as their preferred Agile method, are struggling to integrate UX design into the process.

Scrum is focused on the development team and leaves the rest of the roles involved, including UX, working around the development effort. This can leave the UX team acting merely as a support for when development needs wireframes and specifications.

In order to have a better team dynamic, UX needs to be integrated with the development team and it needs to be flexible when it comes to creating prototypes up-front or designing alongside developers in the same sprint.

Working ahead of development sprints isn’t always the answer

Lately, there seems to be a push toward the idea that the UX team should be working one or two sprints ahead of the current development sprint. This makes sense from the perspective of the product owner needing to align UX work to the development team’s sprint schedule. By doing so, time is allocated for UX reviews and to fine tune any corner cases that appear in the planning sessions before the next development sprint.

However, by always keeping UX ahead of the current sprint, the designer is disconnected from what is actually being developed. This in turn creates a small waterfall process that runs in between sprints. By designing first, then reviewing and waiting for the sign-off before the next sprint starts, Agile thinking is ignored and the process starts to look waterfall-ish.

If developers aren’t included in the design process until the review, it is more likely that they will not understand user needs and will implement a hybrid solution that incorporates their personal beliefs on the matter.

If they don’t feel ownership over the initial design, the need to “make it their own” might affect the end result negatively. With no UX designer overlooking the development process and answering research related or good design practice questions, whenever a corner case appears it will be handled randomly based on personal preferences.

So while the designer is working on the next piece of work, the actual delivery is different than what was signed off on. And by the time it is reviewed, in most cases refactoring would be too costly for the project, as deadlines need to be met.

The main issues that affect Agile teams who do UX work ahead of the current development sprint:

  • The lack of communication between design and development teams creates a discrepancy between what is designed and what is actually built;
  • The rigidity in the approach, as small waterfall processes in between sprints are created. This challenges the agile nature of the original process leading to confusion and frustration;
  • No shared ownership of the user experience between designers and developers. If the development team doesn’t see the value in the UX decisions made, the actual delivery suffers.

The UX team should work alongside developers

To make this happen, the development team, as a Scrum role, should embrace UX designers as their own and work gearsside-by-side. The practice of not designing the full solution before starting development may seem difficult for many UX designers, but being agile involves being responsive to change. By changing the belief that UX needs to be done ahead of the sprint will help the development process in multiple ways.

The benefits of working as a unified Agile team:

  • Everyone involved understands the problem and finding the solution. So by collaborating on the solution, the whole team feels ownership over the design, reducing the total time spent on refactoring and correcting mistakes;
  • The flexibility and the response to changing requirements is improved, making the overall process much easier to follow and understand. Any design issue that arises during the sprint can be solved on the spot, improving the end result and helping the sprint stay on track;
  • The solutions found for design problems are less error-prone and cover more use cases. By analyzing the problems from multiple angles, the team covers multiple scenarios and finds effective ways to solve design challenges.

There will always be challenges

Agile processes present huge challenges to UX, whether you work ahead, or in the current sprint. There is no foolproof path to make design and development work together as the collaboration depends on the team’s experience and trust. In this sense, even if a project requires design up front or not, it is up to the whole team to try and work more closely together and to develop a shared understanding of what needs to be delivered.

The UX team needs to become the link between the user, the business, and the development team. It needs to coach the development team on the user’s needs and transform them into UX supporters. This way all those involved in the development process will understand the value that lies within creating a great user experience for the end client.

UX/UI Design

Design. Prototype. Share. All in Adobe XD.

Go from idea to prototype faster with Adobe Experience Design (Preview) CC, the first all-in-one tool for creating and sharing website and mobile app designs. Test drive the XD preview and tell us what you think.


Join the discussion

  • By vishal waghmare - 12:40 AM on June 24, 2016  

    when is it going to lauch in india any tentative date

  • By tow truck cheap! - 6:58 AM on June 27, 2016  

    interesting stuff, thanks!

  • By Gabriela Villalobos - 5:10 PM on July 1, 2016  

    Hi Radu

    Thanks for the article. I was eager to read the reasons why you stated that working ahead of development sprints was not always the answer, because that is exactly what we have been doing in our team. Later the article states that the problem is due to lack of communication between design and development teams. This is exactly why we do not have issues on that. In our team as the designer creates the mockups, she shows them to the developer and they comment on them. When the mockups are approved by the client or customer, and sent for development, the developer knows what the design should look and function like, hence the development ends up being very smooth and of high quality. Definitely keeping good communication between these two parts improves the overall quality of the products.


    • By Radu Fotolescu - 2:00 AM on July 12, 2016  

      It’s a great approach and if it helps you deliver design solutions quickly then even better. I think it all comes down to how each team finds that balance between planning and actual development.

      Thank you,