Papercuts, Tech Debt and Stalled Features: How Design Teams Ratchet Quality Forward

Roadmaps get crowded. A product designer works under many forces that shape product quality and experience:

• time constraints
• code base constraints
• existing features
• known bugs and papercuts
• new product requirements
• user feedback
• business goals and constraints
• sprint capacity (priorities in the backlog)
• engineering and design talent

All of them push on the outcome of a design solution. The design team usually holds a directional conviction that conflicts with some of them now and others later.

But there are also opportunities. A design team should always look for ways to make progress on its convictions, solve existing problems with minimal effort, and use openings that sometimes appear at random among those forces. They span categories: polish, tech debt, UI component consolidation, or a new feature that leans on overlap with an existing service. Startups move and evolve quickly, so whenever a feature is being explored, weigh the priorities of the moment against the opportunities that ratchet the product forward.

Seven places to look:

• Problems you can solve for developers
• Papercuts
• Stalled features
• A canvas of ready ideas
• New feature work
• Components (atomic design)
• Overlap with existing features and APIs

Solve problems for developers

One of the best ways for a design team to move UX and UI value forward is to solve problems for developers. It has little to do with the usual hallmarks of design such as aesthetics, research or experience. It's problem-solving directed at teammates in engineering.

One of the best ways for a design team to move UX and UI value forward is to solve problems for developers.

Engineers are always battling tech debt, complex logic and variables, and permutations of use cases. Every sprint, new feature or old, is a chance to find simplification and consolidation that is slowing developers down.

Heal papercuts every time you touch the code

Bugs are obvious. "Papercuts" are subtler: issues that start as a mild inconvenience and eventually cause death by a thousand papercuts. Some are so small that people hesitate to report them through normal PM channels.

death by a thousand papercuts

So keep a running list of papercuts and chip away at it based on developer and sprint capacity, especially when a ticket opens an area of code a developer is already planning to work in. Typical entries:

• a minor UI blemish
• a sub-optimal screen transition
• small copy edits
• a loading indicator that needs improvement

With a documented, actionable backlog of papercuts in the designers' field of view, you can often make quick improvements on the run.

Give stalled features a ratchet

Some features never seem to get off the ground. They're prioritized, back-burnered, and prioritized again. Each time one returns to the product team's corner is a chance to make fresh observations for holistic improvement: polish, and better alignment with an evolved business strategy.

Keep a canvas of ready ideas

"Good idea! We have a design for that, actually."

Alongside the papercut list, my team kept a Figma canvas full of our favorite ideas for product improvements and new features. It was fun to see how often that canvas, often fully designed, became a handy show-and-tell in impromptu brainstorms with product leaders, or in response to "how come we don't have xyz?" questions.

Every new team member raises questions like that in their first weeks, and depending on their role it's another chance to move things forward.

Good idea! We have a design for that, actually.

New feature work: where the opportunities collide

This is what you thought a designer actually does: think up new designs for new features. It's probably where the most opportunities collide, and where the design team synthesizes the opportunities from the categories above into something special. The result should be greater than the sum of its parts and make elegant use of known problems across the organization.

Atomize and componentize (atomic design)

Atomic design is a favorite method among UI designers. It documents the smallest design elements (icons, buttons, text snippets) as atoms, which combine into increasingly complex components, called molecules and organisms to keep the metaphor going. All of them are designed for modularity and reuse, and the constant question is "how can we reduce this further?" That's also an opportunity to address the "solve problems for developers" category, since a leaner component set means less code to maintain.

Look for overlap with existing features and APIs

New features often use APIs that existing features already provide. Often that's what prompts a new feature in the first place: what do we already have that can do more with a small update? The more intimately you know your product, inside and out, the more chances you find to connect an API over here with another over there.

The more intimately you know your product, inside and out, the more chances you find to connect an API over here with another over there.

Keep looking for openings

These are examples of how an opportunity mindset in product design produces incremental, sometimes elegant solutions that build features, polish quality and speed things along. Try it on your next sprint. For the research side of the same habit, read Chasing Known-Unknowns. For how this fits a design leader's approach, see Product thinking. Questions or ideas? Start at About.