Design backlog and feedback systems

I led a workstream to restore visibility, ownership, and momentum across a long-standing UX quality backlog at Meta Enterprise. The work connected two problems: how people reported issues and how teams decided what to do with them. Across a portfolio of more than 350 internal products, I helped establish a shared approach to feedback intake, routing, and backlog management.

“I’ve come to see Carissa as the core IC POC for all CD systems work; she understands the entire EP design landscape (one of few) and has developed mature opinions about the role that Content Design can play in helping Design land impact as scale.”

— Design leader

The problem: every team had its own system

Individual pods of Product Managers and Engineering had developed their own ways to handle bugs and product requests. External products had established systems, but a shared system had never been established for these internal products.

A standard bug-icon component existed, but teams could customize its dropdown. Some used it for bugs, some for product feedback, some for operations feedback, and some did not use it at all. The same entry point could mean different things in different products.

Over time, this produced a tangled backlog of bugs, feature requests, design requests, complaints, suggestions, and support questions across multiple intake systems. We identified roughly 2,000 abandoned tasks across Enterprise teams, including items dating back to 2021. We set a five-year cutoff for review because products change; in some cases, the original reporter no longer worked at the company.

Standardize the entry point

I identified the inconsistent use of the feedback component and presented the problem to the design patterns team. Together, we created a standard component with shared language and options:

• Bugs: Report something that is broken or not working as expected
• Feedback: Send feedback on the product or request a new feature
• Help: Ask for support from the operations team

Help was available only for products with an operations team that could provide support.

View larger +

Make the language work for internal users

Our users included accountants, purchasing managers, and people who did not necessarily use product-development terminology. A label such as “Bugs” needed an explanation that connected it to their experience.

I advocated for “broken or not working as expected.” Broken alone might suggest an obvious error. Not working as expected gives people a more human way to recognize and report a problem, even when they cannot diagnose it.

Feedback and Help also needed a clear distinction. People were sending operations support requests, such as asking for an update on their case, to Engineering. Clearer language helped distinguish a request for assistance from a product issue and supported routing it to the team equipped to respond.

Connect each option to an owner

Standardizing the component made it possible to establish consistent routing behind it:

• Engineering bugs went to Engineering. Issues needing redesign first went to Design.
• Product comments went to the PM, then to Design when relevant. Feature requests went to the PM.
• Help requests went to Operations.

Turn the backlog into a shared workflow

I partnered with a UXR lead, a Product Design lead, and our design program manager to establish a system for surfacing, categorizing, and tracking existing issues. We needed shared ownership and prioritization, as well as documentation, testing workflows, and triage that prepared tasks for Engineering.

Operations reviewed incoming bugs for quality, so its participation was essential. A new Operations team in Bangladesh took on the backlog as a training exercise. We worked with the team to distinguish bugs, feature requests, and comments, and identify which items should be routed to Design.

I personally managed the pilot in Spend and Workspaces and trained the Operations and Content Design teams to address those tasks. I also led Enterprise Design team training on backlog management, helping extend the approach beyond the pilot.

Establish a repeatable review process

We established a review sequence for the Operations team triaging the backlog, then used that process to train AI agents to do the work. Before classifying an input, reviewers checked:

1. Quality: Is it coherent?
2. Relevance: Is it still accurate, or has the product changed?
3. Existing work: Does a task already exist for this subject? If so, add the input as a dependent under that task rather than creating a separate task for the same issue.

For coherent, relevant inputs, the next step was classification and routing:

• Bugs: If the issue could be fixed without redesign, route it to Engineering. If it needed Design support—for example, a new component, a full redesign, or language changes—route it to Design, then assign it to Product Design or Content Design.
• Feedback: Route it to the PM and tag Design leads where relevant. Feature requests went to the team’s backlog for review.
• Help: Enable the option only when a support team was available, then route requests to that team. Most internal tools had operations support.

View larger +

Use real decisions to train AI triage

Working with Product Design and UXR, I reviewed real tasks to identify whether Product Design, Content Design, or UXR should address each one. Those examples created training data for an AI triage system.

The foundation was the shared process: clearer categories, routing decisions, and examples of who should own a task. The backlog work supplied concrete decisions that could be used to train the system.

Results

• 893 tasks addressed in the pilot, enabling training of an AI triage system.
• Roughly 2,000 abandoned tasks surfaced across Enterprise teams, making previously scattered work visible for review.
• A scalable system for intake and backlog management, developed with UXR, Design Ops, and Product Design to support shared ownership and prioritization.
• Enterprise Design training, alongside hands-on Operations and Content Design training in the Spend and Workspaces pilot.

Why this work mattered

I began identifying this problem when I joined Meta Enterprise and finally had the opportunity to address it before leaving. What I especially enjoyed was solving a problem that crossed team boundaries and establishing a process that could prevent it from recurring.

Feedback loops are essential to improving a product. They help teams see what real users experience and give UXR a valuable source of problems to investigate. Making that feedback understandable, visible, and actionable was the connection between a small interface component and a much larger operational change.

“Carissa was not only representative of content design but helped shape the overall approach on how we should be framing and participating in the UX Bug Bash program. She was an active contributor in improving documentation, testing workflows and triaging tasks so that they were ready for engineering.”

— PD