AI Design Practice & Practice Transformation
I turn hands-on AI experimentation into repeatable design capability: understanding what the technology actually changes, defining how it should participate in the work, preserving human judgment, and building methods and systems other people can use.
My work connects product design, AI workflow architecture, evaluation, design–engineering fluency, reusable interaction systems, technical prototyping, team enablement, and practice evolution. The goal is not simply to introduce new tools, but to make useful changes in design practice understandable, testable, and repeatable.
AI changes design practice, not only the product.
AI changes how teams explore possibilities, create artifacts, evaluate evidence, collaborate with engineering, make decisions, and decide where human attention creates the most value.
That makes adoption an organizational design problem as much as a tooling problem. Teams need ways to experiment quickly, understand what is actually changing, distinguish useful capability from novelty, and translate what works into practices that can survive beyond an individual project.
Faster execution does not remove the need for human judgment.
Product and experience design still require judgment about customer need, context, business value, accessibility, evidence, uncertainty, system behavior, technical constraints, and consequences.
AI can increase speed and range, but useful adoption should make those judgments clearer rather than hiding responsibility behind automation. Review, evidence, boundaries, failure modes, and escalation therefore belong in the design of the practice itself.
I prefer to understand emerging capabilities by working with them directly. My current work with ChatGPT, custom GPTs, and AI-agent systems examines corpus and knowledge-file structure, retrieval behavior, instruction hierarchy, model constraints, evidence standards, scoring, review gates, context limits, and human-control paths.
Working close to the system exposes possibility and failure quickly. It creates a more useful basis for deciding what belongs in a design workflow, what needs further experimentation, and what is not yet reliable enough to scale.
AI experimentation becomes useful when teams can evaluate behavior consistently rather than relying on impressive demonstrations.
I use comparative and A/B testing, real questions, edge cases, false positives and negatives, drift, conflicts, retrieval behavior, evidence quality, model constraints, and behavioral calibration to understand what works and why.
Those observations can then become clearer decision rules, review structures, evaluation methods, and operating guidance rather than remaining isolated discoveries.
A recurring theme throughout my career has been turning useful project-level decisions into structures other teams and products can reuse: interaction patterns, components, semantic systems, evaluation methods, workflow structures, implementation guidance, and training.
The aim is not standardization for its own sake. It is reducing repeated ambiguity while preserving enough flexibility for teams to respond to different users, products, technologies, and operating conditions.
Practice change becomes durable when people understand not only what to do, but why the approach works and how to adapt it themselves.
I have trained developers and cross-functional teams in front-end practices, Design Thinking, user interviewing, UX methods, assessment approaches, and implementation concepts so useful methods can continue beyond my direct involvement.
The same principle applies to AI-enabled practice: experimentation should ultimately become understandable capability rather than permanent dependence on a single expert.
My current independent work centers on custom GPT and AI-agent decision-support workflows. I define purpose, interaction models, corpus structure, retrieval and scoring logic, evidence behavior, instruction hierarchy, human review, escalation, and boundaries for operational use.
I test usefulness, reliability, context limits, retrieval structures, instruction conflicts, false positives and negatives, edge cases, review behavior, and model changes, then translate what I learn into repeatable evaluation methods and operating rules.
I repeatedly work close to implementation so design decisions remain grounded in actual system behavior rather than separating design strategy from the medium in which the product operates.
At Booz Allen Hamilton, I designed and prototyped directly in Angular on an Army geospatial application. At Softwise, I worked in Angular production across financial products. Earlier work included AngularJS, HTML, CSS, JavaScript, TypeScript, responsive interfaces, browser tools, and working-code prototypes.
That technical fluency makes experimentation with emerging tools more practical and strengthens translation between design intent, product behavior, and engineering constraints.
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 built reusable component and interaction patterns, used contextual research and usability testing, worked directly in Angular production, and trained 20–30 colleagues in front-end practices to strengthen design–engineering fluency.
Management credited the approach with reducing development time by 35% by reducing ambiguity and making design decisions directly usable within the development cycle.
At Booz Allen Hamilton, I worked across Navy, Army, and Air Force modernization spanning product design, workflow transformation, stakeholder evaluation, technical prototyping, implementation, and AI/data exploration.
Air Force work included Qlik dashboards, R Shiny prototypes, NLP across accounting data, RAG-modeled chatbot support, and high-fidelity HTML/live-data prototypes stakeholders could modify as we tested assumptions, exposed constraints, and refined requirements.
Earlier enterprise work at TEKsystems and Novell required reusable interaction architecture across large, multi-role product ecosystems, including approximately 76,000 enterprise users at TEKsystems and more than 10 million users across Novell products.
Earlier at AxisPointe, I worked directly with executive and technical leadership while helping integrate five standalone tools into one platform. That work required aligning product-system decisions across stakeholders and workflows rather than optimizing individual surfaces in isolation.
Training and enablement have appeared repeatedly throughout my work. At Softwise, I trained 20–30 colleagues in front-end practices. At Service Repair Solutions, I trained developers in web standards, HTML/CSS, and implementation practices.
Across other roles, I have trained cross-functional teams in Design Thinking, user interviewing, UX practices, assessment methods, and front-end concepts.
The recurring goal is to translate an individual improvement into a repeatable team capability that improves how design and delivery work together.