I turn ambiguous mission problems into product experiences people can test, build, and trust.
My work sits where operational reality, product design, engineering, data, AI, policy, and human judgment meet. I help teams understand what the problem actually is, make the workflow visible, turn that understanding into something testable, and stay close enough to implementation that the product does not lose the intent that created it.
I am especially useful when requirements are still moving, the information is dense, the decisions matter, and a static design handoff is not enough.
I own the path from an unclear problem to a product direction that users, customers, product leaders, and engineers can evaluate together.
That can include discovery, workflow definition, information architecture, interaction design, wireframes, high-fidelity concepts, working prototypes, stakeholder evaluation, implementation collaboration, and refinement in the actual product environment.
The output is not always a mockup. Sometimes the fastest way to learn is a workflow map. Sometimes it is a workflow model. Sometimes it is a dashboard with live data. Sometimes it is an Angular interface running in the browser.
The artifact should answer the question the team needs answered next.
I start with the people closest to the work and the environment they are actually operating in.
I listen, observe, question assumptions, map workflows and decisions, identify constraints and dependencies, and look for the places where the documented system and the lived system no longer match.
Then I make the problem concrete enough to test.
Product direction becomes progressively more real — workflow, interface structure, prototype, live-data behavior, code — until the team has enough evidence to make the next decision with confidence.
Early requirements are often descriptions of symptoms, inherited assumptions, policy language, technical constraints, or someone's first idea of the solution.
I work upstream of the interface to understand what people are actually trying to accomplish, what information and authority they need, what is preventing the work from moving, and where the real decision points sit.
On Navy modernization work, that meant 75+ interviews and workflow studies across an HR environment serving roughly 975,000 users. The work connected user experience, policy, operations, accessibility, workflow, and technical opportunity before product direction hardened.
Ambiguity is not something I wait for someone else to resolve. It is part of the design problem.
I do not treat customer contact as something that happens upstream of design. The people operating, approving, supporting, and depending on the system are part of the product work.
Across Navy, Army, and Air Force modernization, I worked directly with government stakeholders, users, product teams, and engineers to understand operational constraints, evaluate product direction, and turn incomplete requirements into something the group could reason about together.
On Air Force workflow work, that included facilitating document assessment, reassessment, signatures, approvals, mobile approvers, and movement across paper, PDF, and digital systems to define a process that could actually work.
In other Air Force efforts, live prototypes could be changed with stakeholders in real time so assumptions could be challenged while everyone was still in the room.
Customer trust grows when design decisions can be explained, challenged, changed, and connected back to the reality of the work.
A concept becomes useful when people can react to something concrete.
I move from discovery into workflows, interface structures, high-fidelity concepts, and interactive prototypes quickly enough that customers and technical teams can challenge the design while change is still inexpensive.
In Air Force work, I used HTML, Qlik, R Shiny, and live-data prototypes that could be changed with stakeholders in real time. The prototype was not presentation theater; it was a shared thinking environment for refining the requirement.
Prototype fidelity should follow decision risk, not a prescribed design sequence.
Mission interfaces are often dense because the underlying situation is dense. Simplification cannot mean removing the context someone needs in order to make a consequential decision.
I design information hierarchy around the decision: what changed, what matters now, what is spatially relevant, where the evidence came from, what state the system is in, and what actions remain available.
That pattern appears across Army geospatial mapping work, Air Force dashboards and analytical prototypes, financial consoles, operational workflow systems, and AI-supported decision paths.
The interface succeeds when complexity becomes understandable without becoming misleading.
I do not treat engineering as the place design goes after design is finished.
I have prototyped and refined product behavior directly in Angular, HTML, CSS, browser development tools, Qlik, R Shiny, and live-data environments.
On an Army mission-oriented geospatial application, I worked as a front-end Angular developer and UX partner, testing interaction ideas directly in Angular and browser tools before carrying them into the application.
At Softwise, I built high-fidelity concepts directly in the Angular production environment so interaction behavior, responsive design, component structure, business rules, and workflow logic could be evaluated in working code.
When the browser can answer the question better than a static mockup, I use the browser.
AI changes the product problem because an interface can now produce answers that are useful, uncertain, incomplete, or wrong.
I design around that reality rather than hiding it.
My AI-related work includes retrieval behavior, source visibility, evidence, human review, escalation, provenance, output constraints, relevance evaluation, false positives and negatives, instruction conflicts, and identifying where authority should remain human.
In Air Force work, that included NLP interface concepts and RAG-modeled chatbot support. In current independent work, I test custom GPT and agent workflows through structured comparison and A/B evaluation of retrieval quality, usefulness, constraints, and failure modes.
My value in AI is not backend model engineering. It is designing the workflow around the capability: how evidence appears, how uncertainty is handled, what remains reviewable and challengeable, where escalation belongs, and when authority must remain human.
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.
A successful project should improve more than the immediate screen or account.
At Softwise, I created reusable component and interaction patterns across five financial products. Management credited the design approach with reducing development time by 35% by making design decisions usable in production and reducing ambiguity across business, design, and engineering.
At Novell, I led UX architecture, design, and front-end development across GroupWise, Filr, Vibe, iPrint, Messenger, and ZENworks in an ecosystem serving more than 10 million users. That included two consecutive major GroupWise generations, pioneering browser-based administration for 10,000+ administrators, and operational dashboards that exposed server health, load balancing, and infrastructure relationships so administrators could act with confidence.
I look for the pattern inside the project that should become capability for the larger product system.
These examples are intentionally concise and sanitized. Much of the work occurred in defense, financial, HR, and proprietary enterprise environments. Where former-client artifacts cannot be shown, I use reconstructed workflows, interaction models, decision logic, and transferable patterns rather than proprietary material.
The emphasis here is the operating pattern: how I move from ambiguity toward a product that can be evaluated and built.
I served as a front-end Angular developer and UX partner on a mission-oriented geospatial mapping application and Angular modernization effort.
I developed and tested interaction ideas directly in Angular and browser development tools, connecting design decisions to the environment in which they would actually ship.
Demonstrates: mapping and geospatial product design, design–engineering collaboration, implementation-aware interaction design, and direct work in code.
I supported AI and data transformation through dashboards, analytical prototypes, NLP interface concepts, RAG-modeled chatbot support, and adaptive HTML/live-data experiences.
Prototypes could be changed with stakeholders in real time to explore possibilities, refine requirements, and turn early concepts into active product work.
Demonstrates: AI-integrated product design, analytical workflows, data-dense interfaces, rapid prototyping, stakeholder collaboration, provenance, and human review.
I owned end-to-end UX and interaction design across loan processing, point of sale, title lending, customer service, collections, and lending administration.
Instead of maintaining a long separation between design and development, I created high-fidelity product concepts directly in the Angular production environment.
That allowed business rules, responsive behavior, component structure, workflow logic, and interaction patterns to be evaluated together.
Demonstrates: staff-level product ownership, complex B2B workflows, code-native prototyping, reusable design patterns, and tight design–engineering alignment.
I currently design, test, and calibrate custom GPT and AI-agent workflows using structured comparison to evaluate retrieval quality, relevance, usefulness, evidence standards, output constraints, and human-review requirements.
I look for drift, instruction conflicts, false positives and negatives, retrieval weakness, and situations where AI creates apparent efficiency while degrading operational judgment.
Demonstrates: hands-on AI fluency, product evaluation, human-in-the-loop design, trustworthy decision paths, and practical judgment about where AI should and should not operate.
Staff-level product design means owning more than the interface.
It means understanding the operational reality, making the problem visible, creating something people can test, reconciling user and technical constraints, staying with the work through implementation, and leaving the product system stronger than it was before.
I make ambiguous mission work visible enough to test, concrete enough to build, and trustworthy enough for people to use in consequential decisions.