Product workflow case study
A conversational platform that turns evolving guidelines into governed, reusable decision logic—cutting policy-change turnaround by an estimated 60% and saving approximately $250K annually.
This case study presents selected work. Non-disclosure agreements prevent me from sharing the full set of project artifacts.
Quick Create, checklists, and the dashboard bring authoring, review, and monitoring into a single conversational shell.
Rules were duplicated across codebases, every update entered CI/CD, and users moved between disconnected tools to complete one outcome.
Rigid tools could not capture real-world exceptions, forcing teams to search across systems and manually carry context through the workflow.
More searching. Less deciding.
Every policy change triggered repeated engineering work, cross-team coordination, and another application release.
More releases. Slower policy.
Technical debt consumes an estimated 23% of developer time, and U.S. software debt has reached $1.52 trillion. Policy embedded in code adds to that burden.
Higher debt. Thinner capacity.
Technical debt figures from the CISQ Cost of Poor Software Quality report.
Help teams update business rules quickly without waiting for application releases or disrupting the user journey?
I led product strategy, research, conversational UX, and architecture, and built agents to extend the work.
I built an agent to cluster interview notes and source inventories into themes that I reviewed and turned into the mental model.
User mental model & source map
Explore each phase to see what I led, what I built, and how the work came together.
My discovery starts before the visible workflow. I trace how users recognise a need, find information, and navigate uncertainty—the mental model behind the documented process.
SOP builders think in outcomes, exceptions, and sequence, but their knowledge is scattered across emails, Jira, Teams recordings, GitHub, and SharePoint.
Traced how SOP builders search, interpret, and plan before any rule is written—revealing the searching and reconciling a conventional workflow map would have missed.
Start with a conversation, not an empty canvas.
Replaced a single workshop with a shared board stakeholders could build on across time zones, bringing requirements, questions, and constraints into one view.
Make brainstorming visible and reusable as product input.
Design implication: Rule Q should not begin with an empty rule canvas. It begins with a conversation, helps the user assemble trusted context, exposes uncertainty, and generates a reviewable first draft. The human owns intent and approval; the AI accelerates discovery, synthesis, and configuration.
One workspace, distributed logic—creation stays prominent while governance runs in the background.
A canonical rule model separates frequently changing business guidance from slower product release cycles.
Stable, version-aware request and response schemas let consuming applications integrate without duplicating logic.
Micro-frontends contribute focused capabilities to a shared shell while preserving independent team ownership and deployment.
Source references, test scenarios, approvals, versions, and audit history travel with each published decision.
Step inside the working prototype to explore the login, conversational rule builder, and governed workspace.
Conversation handles ambiguity first; structure supports precise review, testing, and approval later.
Assemble trusted sources before asking anyone to write a rule; the first draft should come from evidence.
Typed events and versioned interfaces stop one capability from leaking into the wider journey.
Loading, error, and fallback states belong at both module and journey level so one failure never breaks the flow.
