Agentic Experiences & Human–AI Product Systems
I design AI-enabled product experiences where people can understand what the system is doing, inspect what supports an answer, intervene when necessary, and remain in control of consequential decisions.
I work where product design, AI behavior, data, business rules, engineering, and human judgment meet. I turn ambiguous problems into interaction models and working systems that people can test, challenge, understand, and trust.
Conventional interface → AI assistance → agent initiative
Agentic design is not a decision to replace conventional interfaces with AI. It is a decision about which interaction mode should lead, when that mode should change, and what the user must understand during the transition.
Conventional interface
Leads when intent is known, the action is predictable, and direct manipulation is clearer and faster than interpretation.
The user chooses and the system responds.
AI assistance
Leads when interpretation, synthesis, search, discovery, or ambiguity makes assistance useful.
The system helps; evidence, feedback, and judgment remain visible.
Agent initiative
Leads only when intent, authority, boundaries, and recovery are clear enough to support delegated action.
The system may act, but the user can understand, review, correct, stop, or escalate what happens.
More initiative requires more visible state, evidence, boundaries, feedback, and recoverability—not less.
I design the system around the AI capability.
My strongest contribution is defining the product system through which AI becomes useful: interaction behavior, retrieval and evidence, system feedback, uncertainty, review, escalation, workflow, business rules, human authority, and implementation.
That means asking not only How should the AI interface work? but first Should AI be involved here at all?
My current independent work includes custom GPT and AI-agent decision-support workflows. I define when AI should assist, what remains human-controlled, and how conversational and agentic interaction models, retrieval, scoring, source visibility, system feedback, review, escalation, and operational boundaries work together.
The first design question is not whether an AI interaction can be made compelling. It is whether AI improves the decision, reduces meaningful friction, exposes useful evidence, or creates a capability the user could not reasonably obtain through a conventional interface.
I design, test, and calibrate AI workflow architecture across corpus and knowledge-file structure, retrieval behavior, instruction hierarchy, model constraints, evidence standards, scoring, and review gates.
I evaluate usefulness, reliability, drift, conflicting evidence, false positives and negatives, and edge cases. When actual use exposes ambiguity or failure, I change retrieval, instructions, constraints, evidence handling, scoring, or review behavior and test again.
Model behavior, context limits, retrieval structures, and instruction constraints change. I therefore treat AI behavior as an evolving product dependency, not a fixed implementation assumption.
The goal is not AI that appears confident. It is a product where people can understand what the AI is doing, what supports the output, and when human judgment must take over.
I design for source and evidence visibility, provenance, explainability, system feedback, uncertainty handling, human review, correction, escalation, source-to-answer traceability, and explicit boundaries on where authority belongs.
An AI suggestion, an AI-assisted decision, and an autonomous action are not the same interaction. The more consequential the action becomes, the more clearly the product must communicate state, evidence, authority, reversibility, and responsibility.
My prototyping work includes Angular and AngularJS, HTML/CSS, browser development tools, Qlik, R Shiny, live-data prototypes, responsive interfaces, and working AI-agent workflows.
When the browser can answer the question better than a static mockup, I use the browser.
Prototype fidelity follows the product question. I use working behavior to expose constraints, test interaction logic, evaluate responsive states, reveal implementation assumptions, and reduce ambiguity before those assumptions become expensive.
These examples show the product-design patterns behind the work: financial systems where business rules and consequences matter, search and discovery interactions, AI and data experimentation, and interaction systems designed to remain coherent at scale.
Where proprietary artifacts cannot be shown, I use reconstructed interaction logic and transferable patterns rather than presenting former-client material as portfolio screenshots.
At Softwise, I owned UX across five business-critical financial products spanning loan processing, point of sale, title lending, customer service, collections, and lending administration.
I prototyped directly in the Angular production environment so responsive behavior, reusable components, business rules, interaction behavior, and complex workflow logic could be evaluated together rather than separated by a design handoff.
I built reusable component and interaction patterns across the suite, used contextual research and usability testing, aligned business, design, and engineering, and trained 20–30 colleagues in HTML/CSS. Management credited the approach with a 35% reduction in development time.
Earlier work with FPS GOLD banking and GOLDPoint corporate lending extends that financial-domain experience across banking and lending systems.
These environments require confidence and clarity because interface behavior is inseparable from financial consequences, business rules, operational workflow, and implementation constraints.
At Ivanti, I designed a dynamic query, filter, and condition builder that enabled non-technical users to construct complex reporting and selection logic with clearer control and fewer opportunities for error.
It was not an AI search product. Its relevance here is the underlying interaction problem: helping people express intent, progressively refine a search space, understand conditions, combine logic, and see how a query will behave before they commit to it.
Reconstructed interaction logic — not a proprietary product screenshot.
Hybrid AI discovery introduces new possibilities, but the design problem remains grounded in understandable intent, useful refinement, visible system state, and predictable control.
At Booz Allen, Air Force work included Qlik dashboards, R Shiny prototypes, NLP across accounting data, RAG-modeled chatbot support, and high-fidelity HTML and live-data prototypes.
Stakeholders could evaluate and modify concepts while the underlying assumptions were still visible. The prototypes were used to test ideas, expose constraints, refine requirements, and determine which concepts deserved further investment.
That experience reinforces a pattern I use in current AI work: test behavior early enough that evidence can still change the product direction.
At Novell, I led UX architecture, design, and front-end work across GroupWise, Filr, Vibe, iPrint, Messenger, and ZENworks in an ecosystem serving more than 10 million users.
That included work on two consecutive major GroupWise generations, shared cross-product UI and semantic assets, a library of more than 1,500 icons, browser-based GroupWise administration serving more than 10,000 administrators, and dashboards exposing system health, load balancing, infrastructure relationships, and actionable state.
The lesson is larger than any individual artifact: products become easier to understand and build when interaction language, semantics, visual behavior, and implementation patterns remain coherent across the system.
Staff-level design means owning that coherence—not only producing a strong individual screen.