A feedback button is only useful when it carries the right context

A feedback button can collect a complaint and still leave the team guessing.

“The page is broken” is a start. It does not tell the person fixing it which screen was open, what action came before the error, whether the problem belongs to a particular record, or what the user expected to happen.

I have built feedback and operational reporting into several products. I assumed the pattern was more consistent across them than it really was. When I traced the actual routes, storage, and operator screens, I found a reusable reference package adapted in some apps, separate implementations in others, and tools that solve a different problem altogether.

That distinction matters. A familiar button does not mean the same workflow exists behind it.

The useful part is the context

In MedPrüf, the feedback form can capture the page or route, viewport, time, browser and language, and, where relevant, the exam or question context. The server associates the report with the authenticated account. An admin inbox lets an operator review the report and resolve or dismiss it.

That is more useful than an empty message box because it shortens the first round of investigation. It also needs restraint. A feedback report should include only the context needed to reproduce and understand the issue. It should not turn into an unbounded dump of a learner’s activity or private data.

The most useful question is not “what can we attach?” It is “what would the person fixing this need to know, and what is safe to include?”

The portfolio did not have one shared switch

I checked how the related features actually fit together:

• A reusable feedback pattern defines a contract, a route factory, a widget, and a database template. It is a reference for implementation, not a centrally installed runtime dependency.
• Some products copied and adapted that pattern to their own data and operator needs.
• Harmonia has its own feedback route and operational context.
• MedPrüf has an independent implementation, with a separate path for question suggestions.
• RetailOS error reports are runtime telemetry. They are not the same as a user choosing to describe a problem.
• A local error logger or an entity search tool can be useful, but neither is a feedback inbox.

The architecture is therefore a set of related decisions, not one portfolio-wide feature that is automatically available everywhere. This is a more honest and more useful starting point for the next build.

A report is not a repair

The reviewed code supports a human investigation loop: someone submits a report with context, an operator reviews it, and the team can make a change. I did not find a connected system that automatically reads feedback, diagnoses the code, writes a patch, and proves that the patch fixed the issue.

That is an important boundary. Context makes investigation easier to start. It does not establish the cause. A suggested fix is still a suggestion. A passing build still does not prove the original user journey now works.

For a product that depends on support feedback, I would make the steps visible:

1. Capture: record the screen and the relevant action, with a clear privacy limit.
2. Triage: assign the report to a person who can decide whether it is a defect, missing capability, or unclear expectation.
3. Change: make a small, traceable update with the user’s workflow in mind.
4. Verify: replay the failing path and check the result that matters to the user.

AI can help summarize reports or point an operator toward likely documentation and code. It should be introduced after the team can tell what a correct repair looks like.

Design around the business that receives the report

For an operator in Egypt or elsewhere in MENA, the relevant workflow might arrive from a phone, a staff member, a customer support thread, or an admin screen. The right form depends on who reports the issue, what information they can provide, and who is responsible for acting on it.

There is no single regional feedback workflow. Language, device, staff roles, privacy, and escalation rules need to be checked with the actual team. A custom product should fit that process instead of asking the business to adapt to a generic dashboard.

If your team keeps asking a user for the same missing details after every report, tell me what the report contains and what you still need to ask. That is usually a better first design brief than “we need AI support.”