Skip to main content
Back to cases
ProductWindows app

Product Feedback Inbox

Centralize feedback from chat, email, mindmaps, and support tickets. Auto-tag and prioritize so planning meetings start with clarity, not chaos.

The problem to solve

PMs triage hundreds of feedback notes every week — one from chat, one from support, one forwarded from sales. It ends up as sticky notes on a wall. Planning meeting prep is a late-night job.

Solution

A local inbox. One card per item with source, raw text, user type. Auto-tag (perf / UX / bug / feature) and assign priority (high / med / low). One click exports a grouped list for planning.

Expected outcome

  • Home feed of feedback cards; filter by tag, sort by date or heat (hit count).
  • Add: single entry or bulk paste (one per line). Keyword-based auto-tagging.
  • Merge similar items; source history preserved.
  • Priority matrix view: impact x urgency; drag to adjust.
  • One-click export of "this week's discussion list" to Excel or Markdown for planning.
  • Local storage; data never leaves your PC.

Example input fields

Before copying, rename your Excel / CSV headers to match these fields — or just paste your real headers into Codex along with the prompt.

SourceUserFeedbackTagPriority

Copy-ready prompt

You are a senior engineer building local desktop tools and a thoughtful product manager. Before writing code, you walk through it as the user: what they see first, how they use it first, how they recover when something breaks. Build a runnable local desktop tool. The user is a product manager, focused on business outcomes and usability.

[Opening Brief]
Before you build, use 3-8 numbered lines to tell the user what's coming. If 3 lines do it, use 3 — one short sentence per line.
Picture, feel, result — not implementation. Plain words. Speak to "you".
Don't promise a timeline ("ready in X minutes") — you can't know. Don't wait for a reply. Follow the [Quick Start Protocol] below immediately.

[Goal]

Centralize scattered user feedback, auto-tag and prioritize, so weekly planning starts with a clean list.

[Platform & Stack]

- Windows 10/11 desktop app
- Electron + React + TypeScript
- Local SQLite; offline; ship a Windows .exe installer

[Core Features]

1. Home feed: cards with 150-char snippet, tag chips, priority corner, source icon.
2. Filter by tag (multi) / source / user type / status. Sort by date or heat (merged count).
3. Add: single-entry form with source + user type; bulk paste (one line per item) with keyword-based auto-tagging.
4. Auto-tagging via an editable keyword dictionary — tags like perf / UX / bug / feature / copy / compliance. Show confidence; user confirms or corrects.
5. Merge: select cards -> merge into one; preserve source history; increment heat.
6. Priority matrix: x = impact (1-5), y = urgency (1-5); drag cards to adjust.
7. Export: Excel for weekly list; Markdown groups for pasting into Notion / Feishu.

[Visual Style]

- Minimal fresh: white / light-gray / soft card shadows.
- Desaturated tag colors, a consistent palette.
- Follows system dark mode; bilingual toggle.

[Robustness]

- Flag likely duplicates during bulk paste.
- Keyword dictionary import/export as JSON for cross-machine portability.
- Auto-recover DB from last backup.

[Data Model]
Feedback card: id, body, source (chat / email / ticket / sales / internal / other), user type (paid / free / internal), created, tags (multi), priority (high/med/low), impact (1-5), urgency (1-5), status (open / planned / resolved / wontfix), mergedFrom (array).

[Safety Rules]
- Process locally by default; network calls require encryption and explicit user consent.
- No hard-coded API keys, absolute paths, personal emails, or internal hosts.
- All writes go through "Save as"; never overwrite originals; auto-timestamp on conflict.
- Do not invent npm packages; verify with npm view first.
- If real files are missing, create anonymized sample-data first; do not block on user files.

[Execution Discipline]
- Verify each feature immediately after writing it; do not batch all testing to the end.

[Warm UX Contract]
What happens around the code matters more than the code itself. The finish should feel like a gift.
- First launch = demo mode: auto-load sample-data/ and run the main flow once so the user sees a real result page, not an empty state.
- The workspace always has a "Try with sample data" button up top — one click to a full demo any time.
- Buttons, hints, and errors in business language. Example: "Can't find the Order ID column", not "Column 'order_id' not found".
- Operations with ≥3 steps offer Undo or Cancel; ≥5-step critical actions require confirmation.
- Long-running tasks show a progress bar + ETA, refreshed at most once per second.
- The moment the main flow finishes, give in-app feedback; if the window is in the background, also fire a system notification that opens the result on click.
- On failure, always offer the next move (retry / pick another file / view log / copy the error) — never leave a lone red line.

[Success Picture]
The screen at the end of the main flow is the user's lasting impression. Make it feel like a gift.
- Big-number outcome + a ≤30-word business-language summary. Example: "Reconciled 482 orders, 5 mismatches. Saved to Desktop/diff-2026-05.xlsx".
- Key findings as a single colored chip row: "⚠ 3 amount mismatches · ✦ 2 likely refunds".
- Three action buttons in a fixed position: "Open output folder", "Run again", "Pick another file".
- Include a collapsible "What just happened" panel with 5-10 lines of copyable activity log.
- No raw internals (millis, PID, stack traces); if you show time, use human words — "Done in 4s · 482 rows", not "4231ms".

[Project Structure]
├── src/main/          # Electron main process (main.ts, preload.ts)
├── src/renderer/      # React UI (pages, components, hooks)
├── src/core/          # Pure business logic (testable, no Electron deps)
├── src/types/         # TypeScript type definitions
├── sample-data/       # Anonymized sample data (main flow works on launch)
├── scripts/           # dev / build / package scripts
├── docs/              # User guide + known limitations
└── package.json       # entry, scripts, dependencies

[Error Recovery]
When hitting issues, follow these strategies instead of retrying the same approach:
- Dependency install fails → check spelling, try one major version down, or use --legacy-peer-deps
- Too many TypeScript errors → use any to get the main flow running, then add types incrementally
- Electron white screen → check preload path, CSP policy, console errors
- Packaging fails → confirm dev mode works perfectly first, then debug packaging config
- Styles broken → check CSS load order and selector specificity
- Same error 3 times → switch approach or downgrade that feature, do not keep retrying

[Delivery]
1. Summary should include the feed, add, matrix screens.
2. Phase 1: entry + auto-tag. Phase 2: matrix + merge. Phase 3: export.
3. Package .exe; 500-word user guide.

Acceptance checklist (all must pass):
☐ Double-click .exe launches; home shows feedback card feed
☐ Add feedback → auto-tags → user can modify
☐ Bulk paste multiple items → auto-detects and tags
☐ Priority matrix view → drag cards to adjust scores
☐ Merge similar feedback → source history preserved
☐ Export Excel / Markdown → ready for planning meeting
☐ Empty data, duplicates → friendly message, no crash

[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.

[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide

[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)

[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.

[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.

After you copy

1

Open Codex Desktop and start a new task

2

Paste the whole prompt into the chat and send

3

Let Codex build and verify, then tweak names, fields, and buttons as you like

More from this department