It’s a situation every designer knows; we work on a feature, we release it, but always we say to ourselves:

• The microcopy is not the most accurate, but the developers need to begin developing the solution.
• I’m not sure about this interaction, but I must deliver today.
• I used this simple icon since I didn’t have time to design a new one.

Furthermore, we notice little errors when we use the app we designed.

For example:

• Hover that misses in some places.
• Colors that cause accessibility problems.
• Tiny bugs.

Many of us hope the PM will take care of it, and we will continue to improve the features we release. Unfortunately, this does not always happen. Often, the team is focused on adding new features instead of improving what’s already there.

This article offers an idea that product teams can use to fix these issues.

I will call it: “Soft Sprint.”

What is a Soft Sprint?

A soft sprint is a sprint in which the team focuses only on:

• Improving and fixing minor visual bugs (Fix icons, fix colors, fix hover state).
• Improve microcopy.
• Tune some features.

Why I call it a soft sprint

It’s normal for designers to design complex solutions in a sprint. Finding an accurate solution that balances the user needs, the business, and the development side can be hard, especially when there are a lot of edge cases.

Soft sprints are easier and do not require much mental effort to make these small improvements.

Why do I believe it is so important?

People look at the small issues separately

Earlier in the month, I fixed several small things in my house, like a squeaky door, some paint issues, a door that rubs against the floor, and more details.

Honestly, I wanted it fixed long ago, but I didn’t. After I fixed them all, I felt a huge difference.

If we look at each minor issue separately, it isn’t a look as big deal, so we don’t take care to fix them. But we fail to notice that many small issues on a product can significantly impact the overall user experience.

For this reason, solving many small bugs in one sprint can greatly impact the product user experience.

There is a perception that creating new features always gives more value than fixing problems

Some people believe that delivering more features gives the user more value than fixing existing features. I can understand it, but if there is a feature in your product that the user is suffering from bad UX, it means that the value you give them is low.

For example, if the user is frustrated when they click by error repeatedly on an icon button because it does not explain itself clearly.

Another example is when the user gets an error message that does not explain the situation well. When people don’t understand the message, they can feel frustrated.

These two examples are easy to fix and can solve a big pain for many users.

One thing I studied from Figma
Figma was released last year 30 small improvements in one release. All the features were small, but it felt like a big improvement. This release greatly helped designers, and I remember hearing them talk about it in the design community.

Again, a lot of small improvements give significant value to the users.

Why do we need a special sprint for small improvements?

Small bugs are often overlooked because we do not see their importance when we decide what to prioritize. By clustering many issues in one sprint, we provide value to the user.

The team must prioritize

Almost every product has many small issues that need to be fixed, but prioritizing what will make a difference is the most important thing. Before starting the soft sprint, prioritize with the team the issues so you can deliver real value.

Where you can find small issues?

Talk with users
Many times users share small details with you. For instance, an accessibility issue with a color, a microcopy that confuses the users, or a function they cannot find.

If you find a small problem many complain about, document it.

Use the product you work on
When you work on the product, take a screenshot or record a small video and save it as a reminder of what needs improvement. You can organize and prioritize the list once you have it and show the PM.

Be aware that improvements should have a clear value for the user. If the changes you suggest are so small that no users will notice them, it isn’t worth the effort.

My team has no time to devote a whole sprint to it

If your team doesn’t have time to dedicate a full sprint to it, ask your product manager to add a small design task every sprint, For example, improving an icon.

This way, the team will give the user great value and won’t require much effort.

That way, you can fix a minor design bug each sprint, and the team won’t have to dedicate an entire sprint to fixing small issues.

The product manager doesn’t want to invest in any UX improvements

Whenever you think there’s something the team can do to improve the product, take the initiative and make the change, don’t wait for others.

Sometimes we have less work, so you can take advantage of that time to design the change.

Take an icon as an example. If you have an icon that you think isn’t good for the system or doesn’t represent the function, you can design a new icon and show it to your team.

Ask the developers how much time and effort they will need to fix the problem. Then show it to the product manager and explain why you think it needs to be addressed.

If they agree, it’ll be easy to make the change. Remember that people are more likely to agree when you clearly explain the effort and value.

Thank you for reading the article. I hope that this article helped you to understand the idea of Soft Sprint. Please feel free to share it with your friends or team members, and if you have any questions, please let me know.

If you enjoyed my article, I suggest you follow me and subscribe so you’ll receive an email whenever I post.

Want to get the most out of Medium? Click here to become a member. As a member, you’ll support me and lots of other writers.