When I worked at Oscar, we had a Product Principle: We believe in a culture of continuous improvement – both about ourselves and about our work – and are always open and honest about what we don’t know. This was a phrase we repeated frequently, used as a powerful tool to reflect and improve, and to base decisions around. However, a challenge we consistently faced was being able to tackle design debt.

In simple terms, design debt is all the good design concepts or solutions that you skipped in order to reach short-term goals. It’s all the corners you cut during or after the design stage, the moments when somebody said: “Forget it, let’s do it the simpler way, we’ll come back to it later”. The problem with debt is it feels negative. People don’t like working on debt because it’s backward-looking, not the exciting work of looking to the future. Maybe this is a language problem, where we think of debt as the bad part of spending. We already got the thrill of buying something, and now we’re left with the empty promise of paying for it.

Much of design debt is made up of tiny moments of discomfort. These can be the easiest IOUs to pay back, but are rarely prioritized because on their own, they feel insignificant. Things that are just a little off aren’t going to break our experience by themselves, but they add up and aggregate in the minds of the people who use our products and cause a lack of trust and a perception that we don’t care. We can call these tiny inconsistencies “papercuts,” because they individually are a pain, but en masse they are agony.

Papercuts are the illustrations that are from two brand refreshes back. They are inconsistencies where we upgraded a pattern but didn’t implement it everywhere. They are the little shortcuts we took that added friction to an experience, where we promised to revisit it later. They are system loading indicators we chose for speed, but they don’t feel like ours. These are all real issues we faced.

Discovering where those papercuts exist can be a task added to our design process. We can use regular usability testing, qualitative research, and dogfooding our own products with a critical eye to add to the list. Regular audits of our experiences with a documented takeaway each time will help spot inconsistencies on a recurring basis. Customer support should have a clear process to share feedback heard from users.

Blocking papercuts

So why aren’t these taken care of if they are so easy to resolve?

You may have too many P0 tasks that take up time and resources, often blocking the ability to get to P1s and lower. Maybe there isn’t proper motivation to work on something that could be considered voluntary since it’s not being tracked right and doesn’t appear on the roadmap.

In many teams I’ve observed, there are so many papercuts it’s overwhelming and hard to see where to start or how to prioritize, so they keep pushing on high-value big swings.

But a major blocker to getting started is that there is no leadership mandate to work on papercuts. This contrasts with where there is a mandate to work on tech debt, allowing teams to prioritize and track it. The incentive to do the work is built into having to articulate why they haven’t if the end of the year comes and the work isn’t completed.

Ways to reduce our papercuts

If a design leader is intent on moving the needle on healing papercuts, they must work with the system, find the metrics to track and move, and commit to the experience improvements that come with the effort.

Tracking. Tracking where we have papercuts will allow us to measure our current status and our success at fixing them. The design team should regularly scan existing pain points and document them in some way, whether in your issue tracking system, Figma, or a spreadsheet.

Influence. Designers and engineers should take control of minor papercuts without needing to ask permission, and they should have a relationship that allows for mutual respect when giving critical feedback. The IC teams should be encouraged to spot quality issues and proactively take on ownership if they are already working in that space. In the days of AI, this is even easier; integrating a designer into the front-end code is high value and allows continuous improvement.

Brute force. Use hackathon-style sessions where time is blocked at a defined cadence to look for opportunities to make things better. This can be at the team level, and teams should be empowered to decide how much time they need to clean up their experience area. Quarterly focused sprints to heal papercuts with a measurable outcome come to be expected and built into the roadmap. Work laterally to sell the concept, make explicit public statements about expectations, and follow up with outcomes.

Planning. Design and product partners should meet monthly to groom the design backlog for their area. This has the benefit of weaving papercut fixes into existing work areas and allowing for a more efficient approach to making these fixes. Adam Stepinski’s Death by a Thousand Papercuts, and How to Avoid It describes a 90-minute weekly process that helps keep craft quality high in a timeboxed plan. In my opinion that’s a little too frequent and heavy, but the structure works well.

Culture. In an ideal world, teams would have a culture of dissatisfaction where we look at our own work and think about how we can make it a little better. Taking pride in the experiences we’ve created allows us to look frequently at the live software and question how it could be improved. When our culture expects this critical lens, papercuts have no right to sit in a backlog; they must be addressed in order to satisfy our need for excellence.

Measuring the effect of papercuts

What is a useful method to determine the cost of not doing something?

  • CSAT. Customer satisfaction is the most obvious area negatively affected by papercuts, but how do we measure this?
  • NPS. In our qualitative research to uncover the rationale behind our NPS, we should include questions that help us understand users’ perception of quality. Setting aside that I hate NPS, I recognize in the business world many people use it.
  • Task success rate. Observing changes in a user’s ability to complete tasks may indicate a papercut. This should already be a part of your usability testing process, so keep track as you observe.
  • Time on task. Same as above, taking too long on a task.
  • Attitudinal studies. Observing users in product in a think-aloud study to hear their perceptions of the experience.

Let’s be real: designers will always notice and feel the pain these little annoyances cause, and it will always be on us to make the case for fixing them. By putting ourselves in business mode, tracking problems, and making a case for the value of solving them, we can bring the broader group on board.