UX Design is useless and it slows down the software development

“Design activities slow us down”, “We don’t have time for user research activities, we have to push new features to production”, “We’ll think about it later”.

We hear those phrases often, both from our team and external software development teams. Why does this happen?

Because adding design activities to an Agile software development process is hard. It is often frustrating for both software engineers and designers and the results are poorly designed products and bitterness among team members.

That’s why after many projects we realized we had to improve. We started by analyzing our design and development process and the issues of the teams involved.

The solution we found consists of three changes:

1. The design team started working on Sprints, like the development team
2. We plan the design activities more in advance compared to the development team
3. We introduced a daily stand-up between the team members to share the project’s status

But how did we get there? What has changed in the way we work after these changes? Here’s what happened.

Where did we start?

The projects I am talking about in this article involve the entire product team and they last at least six months, or more.

The project’s team consists of:

• Belka design team
• Our software engineering team or the client’s software engineering team or hybrid

The whole team works on objectives and not on a specification document defined a priori. Approaching projects in this way allows us to work towards a concrete, measurable and valuable direction. We channel the team towards a clear goal.

On the other hand, this approach leaves room for a natural uncertainty about the activities. To address this problem we use the principles of the Agile methodology, trying to adapt it to the team’s needs.

Agile is well suited to development tasks — it was born for this. Unfortunately, adding the design team to the process wasn’t as easy.

adding the design team to the development process wasn’t as easy

With the introduction of retrospectives, we found that the work of the designers was not understood. The goals and causes that led to the mockups were not understood and the given material was treated as a mere graphic output.

What is happening? Let’s investigate 🕵️

In order to understand the situation we decided to apply the design principles to our design and development processes. We focused on identifying problems and avoiding the Design VS Development syndrome.

We started with a phase of interviews with all the participants involved.

Feedback from software engineers

As a first step, we interviewed the software engineers. This is what they told us:

🤔 We don’t understand what designers do
There is no clarity on the activities. The outputs are mockups and documentation but we don’t see much of the designer’s work and we don’t understand what they do.

📅 Poor planning
Building robust technology requires planning. We need to look beyond the current development sprint but we don’t have the design of that.

🙆‍♂️ The sprints contain incompletely designed features
The design team doesn’t always meet the deadlines, therefore the development work is harder.

Feedback from the design team

To close the circle we also interviewed the other side — the designers. The problems they see are:

💔 Incomplete user stories
In Belka, the design team writes the user stories for the development team. Then, we share a moment to introduce the user stories to the developers. But even doing so, during the development, software engineers may find unexpected corner cases. It is impossible to completely prevent this, but we need to manage it.

🚨 We can’t plan for the next steps because we are handling emergencies all the time
The design team needs to manage the incomplete stories for the current sprint instead of planning the next one.

🕵️‍♂️ User research activities are blocked due to the previous issues
The team often works in an emergency status. The result is that design debt builds up and the gap between design and development widens.

Once we collected the problems from both teams, I started thinking about possible solutions.

Possible Solutions

First thing first I started researching on the topic. The relationship between development and design is not new.

I added lot of good material referenced at the end of the article to start learning more about.

How to improve

After the interviews I grouped the problems. There are two categories:

📢 Communication problems
Teams don’t understand each other’s activities and this hurts everyone.

⚙️ Process Issues
Handling unclear features is expensive and it negatively affects the design planning.

To address the issues I introduced some gradual changes. Just like during an iterative design, the introduction process has been split into 4 states:

1. Introducing a small change with a real impact on the process
2. Testing with one team alone
3. Collecting feedback
4. If the experiment works try to extend it to other teams. Otherwise leave it

Daily Stand -up

I started with the communication issues. We decided to introduce product designers to the daily stand-up.

This is called Daily Stand-up and it is very common in the Agile world.

This first experiment was received positively by the whole team. The changes were not long in coming:

• The team started to recognize and solve the blocking situations immediately
• Everyone is up to date about the design team activities — especially for the user research phases
• Awareness of the activities increased for everyone

I integrated this practice gradually, after collecting initial feedback, into all the other teams. I acted as a facilitator during the initial daily stand-ups to avoid the most common mistakes. Do you want some examples? Keep reading.

How a Daily Stand-Up Can Go Wrong, and How to Prevent It

These points when not managed can derail this type of activity.

It lasts 15 minutes and they must be 15
If the event becomes too long it loses its value. The biggest risk is that the team starts considering it as a waste of time. To make the duration clear to everyone I recommend using a time-timer or a smartphone countdown. Don’t be afraid to cut out conversations.

Design and engineers must have the same weight
during the stand-up and communication must be encouraged. This is not an event to talk just about user research, but not even just about tech issues on the database.

If possible, include members from all business functions, such as customer success. Keeping the customer success people in the loop allowed the development team to better empathize with the users.

Rethinking the design’s organization

The second more substantial experiment was on process problems, with the introduction of the Dual-Track Agile.

Dual-track Agile: how does it work?

Unlike classic Agile, which defines the plan of the engineering team only, in a dual-track process the design activities are considered in the planning.

Dual-track is characterized by one principle: the design team works in advance of the development team. With at least a sprint of advantage, the design team can provide complete and validated material with users.

Both teams reported that the User Story management was lacking: poorly defined user stories, continuous emergency adjustments. This seemed like a suitable solution.

In this methodology the designers’ work is organized in sprint. The goal of each sprint is to produce detailed and complete user stories to be discussed and prioritized with the software engineers and the product owner.

Let’s start with one team

I chose the team with the best UX Maturity to run the first test. That’s because I knew they would be the most receptive to the proposals, making the whole test quicker.

Introducing a new work process from scratch is never easy. Everyone’s contribution is needed for things to work. I presented the changes early on as a way to address the problems that they told me.

I explained that the challenge wasn’t designer vs software engineer but rather the whole team against problems.

Once this message was understood, everyone joined the new work process.

A new backlog for the designers

I created a brand new board accessible to everyone (engineers as well) to facilitate the design team planning. As with the development activities, the board of the design team was divided into 2-week sprints.

The design team then chose four statuses for activities progression tracking within the sprint:

• To be completed: the user stories that the design team aims to complete during this sprint
• In Progress: the name should be clear
• Review: stories whose design needs internal or external review
• Completed: the story contains the mockups and the Condition of Satisfaction (COS)

When the design team finishes a task it updates the development backlog accordingly.

We defined a convention to link the development backlog and the product backlog. There are three states on the development backlog’s user stories:

• discovery
  The design team is in the research phase. They are investigating the problems and opportunities of the chosen target.
• developing-design
  The objectives of the story are well defined. The team is working on creating the user experience.
• ready-to-develop
  The story is ready and can be developed. Here we go! 🏁

Plan for the future

The product backlog is not just the reference point for ongoing activities. It allows planning for what will come next. The key point is planning the sprints in advance, because it brings several advantages.

• The whole team has a vision on what the direction will be
• Creating a buffer between the design and development activities allows adjustments on the plan without slowing down
• The design team can manage activities beyond a single sprint, such as interviews and research sessions with users.
• The development team can manage activities such as code refactor or software architecture improvement without impacting the roadmap, taking advantage of the design team’s research moments.

What we learned

Change is hard

Changing the way you work is a long process. In our case, the migration to Dual-Track Agile of all projects is still ongoing. Other than that, our teams are similar, but not the same. This means getting different results at different times. It’s part of the game!

Documentation is expensive

At Belka, we consider the product backlog management activities a responsibility of the design team. Maintaining a backlog is a time-consuming activity and it may slow down the development roadmap. It is one more thing to do and it is worth considering if you plan to introduce it to your team!

Two sprints in advance

For the design team, working a few sprints early has been what enabled them to focus on the user experience and reducing emergencies management.

From our experience, the process is healthy when there are at least two development sprints organised in advance.

Divide Et Impera, does it always work? When does it work? Let’s find out!

Dividing the work between two backlogs has not always been successful. Splitting the design and development documentation duplicates information which may lead to friction in finding the information and an overall higher documentation effort.

For this reason we are also experimenting the use of a single project backlog.

It is a neverending process

Last point: try, try, try without being afraid of making a mistake! On paper, the principles are all valid, but the reality is that they must be tested with the team and adapted to the needs of the individual realities and individual projects.

If you are asking yourself ”but can I also apply these practices in my team?”, The answer is YES! I advise you to start with the biggest pain point and, starting from that point, gradually introduce process improvements.

I.e. starting from daily stand-ups we streamlined our communication and immediately saw the first results without having to dramatically change everyone’s work.

For the record here are the experiments still in progress:

• Unify the product backlog with the development backlog
• Align the state management of the design board with the double-diamond
• Improve the involvement of other team members not directly employed in the project (i.e. the C-Levels who does not directly follow the development of the project but wants to stay updated)

References

• NN Group — Report: Effective Agile UX Product Development
• UIE — Balancing Continuous Discovery and Delivery
• Agile Isn’t Supposed To Be UX Hostile, by Jared Spool
• Introducing Dual Track Agile — the theory
• NN Group — Accounting for UX Work with User Stories in Agile Projects
• NN Group — DesignOps 101
• The Change Curve
• Atlassian Playbook: the standup