RISA Labs · Product Design Assignment ·4 min read
Agentic Workflow Browser
for Product Managers
Product Managers don't struggle with decision-making.
They struggle with gathering the context required to make decisions.
I asked: what if the browser itself became the execution layer?
The shift
From coordinator to decision-maker
The agentic browser doesn't just make PM workflows faster, it fundamentally changes what a PM spends their cognitive energy on.
| Before — PM as coordinator | After — PM as decision-maker |
|---|---|
| 10–20 tabs open, still lacking full context | Auto-grouped contextual workspace, full picture in one view |
| Manual standup updates rewritten every day | AI generates summary in one tap, PM reviews and sends |
| Blockers surface during standups, too late | Predictive blocker detection flagged before they cause delays |
| Meetings produce messy notes, manual conversion | Meeting Mode converts discussions to structured, assigned tasks |
| Following up with devs manually — "any update?" | Auto-notify Slack, AI drafts, PM approves in one tap |
01 — Problem
What was actually breaking down
PMs are the most tool-dependent role in any product org, and the most penalised by fragmentation. I mapped the structural failures before opening Figma.
The core insight: the problem isn't too many tools. It's that context is never assembled at the moment of decision. Information exists everywhere, and is available nowhere when it's needed.
02 — Primary Research
Conversations with working PMs
Before committing to any direction I spoke with three PMs across different stages — Series A SaaS, early-stage startup, and fintech scale-up. Three questions: tool switching frequency, most repetitive task, and whether they'd ever missed a blocker that existed somewhere in their stack.
"Information is there but scattered… nobody connects it until it's too late." — Senior PM, Fintech. This became the design brief in one sentence.
03 — Ideation
Three directions explored — two rejected
Each alternative had genuine merit. That's exactly why pressure-testing them mattered before committing.
Early explorations — wireframes
Before moving to high-fidelity I mapped the core flows in lo-fi to validate structure and information hierarchy without visual noise getting in the way.
The defining principle: don't replace the tools PMs use. Sit underneath them, at the browser layer, and make the entire stack intelligent from below.
04 — Design principles
Five principles that governed every decision
05 — Final screens
Five screens, each solving a specific failure mode
Every element has a reason rooted in research, not aesthetic preference. Here's what I designed and the exact decision behind each key element.
06 — Visual identity
Colour, type, and every visual decision explained
Every visual choice was functional — rooted in the PM's work context, session length, and cognitive environment. Nothing was chosen for aesthetics alone.
Colour palette
Typography
Display / Headings · Weights 500, 600
A single type family across the system keeps hierarchy clear without visual noise.
Inter — readable body and UI at every scale.
Body / UI text · Weights 300, 400, 500, 600
Light → Regular → Medium → SemiBold gives enough range for dense PM dashboards while staying consistent.
Dark mode wasn't an aesthetic choice — it was a UX decision. PMs work long sessions in front of high-density dashboards. A warm dark palette reduces eye strain while matching the dev tools ecosystem they operate alongside daily.
07 — Decision log
Every micro-decision and its rationale
| Decision | Chosen | Rejected & why |
|---|---|---|
| Colour mode | Dark throughout — reduces eye strain for long sessions, matches dev tools ecosystem | Light mode — conflicts with long-session use case and creates dissonance with GitHub, VS Code |
| Navigation | Persistent left sidebar — mirrors Linear/Jira, predictable, reduces decision fatigue | Top nav — conflicts with PM's existing mental model and reduces vertical screen space |
| AI panel placement | Right panel — keeps main tool intact, AI acts alongside work not replacing it | Inline overlay — competes visually with the tool PM is actually using |
| Execution model | Step-by-step modal with content preview — trust built through visibility not assumed | Silent background execution — creates black-box perception, kills adoption |
| Homepage state | Empty canvas on load — PM starts calm, pulls context on demand | Dense homepage — replicates the overwhelm PMs are trying to escape |
| Primary interaction | "Ask Anything" centred — natural language, AI feels accessible not buried | Menu-driven AI access — requires PM to remember where features live |
08 — Validation
What changed after showing it to real PMs
After completing the initial screens I shared core flows with the same three PMs from research — directional gut-check on the Dashboard, Agentic Task View, and AI Action Modal.
09 — Edge cases
Designing for when the AI gets it wrong
Trust is built in failure moments, not success moments. I designed explicit handling for four critical failure scenarios.
Design principle for all error states: never fail silently, never guess confidently on low-signal data, always leave the PM in control of the final state.
10 — Success metrics
How we'd know if this actually worked
These hypotheses anchor every design decision to a measurable outcome — baselines drawn directly from research conversations.
| Metric | Baseline | Target | Feature |
|---|---|---|---|
| Context-gathering time per task | ~15–20 min | Under 2 min | Auto-tab grouping, AI summary panel |
| Daily standup prep time | ~25–30 min | Under 5 min | Auto-generate standup quick action |
| Blocker detection lag | 12–24 hrs | Under 30 min | Predictive blocker detection |
| Manual update actions/sprint | 40–60 actions | Under 10 actions | AI Action Modal, Auto-notify |
| AI suggestion acceptance rate | — no baseline | Above 65% at 4 wks | Analytics feedback loop |
11 — What's next
Where this goes in phase two
12 — Reflection
What I actually learned
The most important decision in this project wasn't a UI choice — it was the framing. Choosing "browser as co-pilot" instead of "yet another dashboard" shaped every subsequent decision about interaction model, information architecture, and automation design. The framing is the strategy.
Working on an agentic interface forced me to think carefully about the human-AI trust curve. Automation is only valuable if users trust it enough to let it act — and trust is built through transparency, not capability.
If I were to iterate, I'd invest most in onboarding — specifically how a PM first connects their tools, sets privacy preferences for AI reading, and establishes the baseline trust that makes agentic behaviour feel safe rather than intrusive. The first 10 minutes of a product like this will determine whether a PM uses it for a week or for a career.