Building the practices behind better product decisions.

At Digital.ai, I joined as Director of UX Research and Design to build the practice from the ground up across a complex enterprise DevOps portfolio. I led a team of five, built research intake, planning, recruiting, documentation, reporting, and socialization practices, and created a model that helped Product, Design, and Engineering use research earlier and more consistently.

The UX practice had strong people and important work underway. What the team needed was a clearer structure for planning research, recruiting participants, documenting insights, and sharing decisions across Product and Engineering.

I focused first on the infrastructure the team needed to operate well:

• Research intake.
• Study planning.
• Participant recruiting.
• Documentation standards.
• Stakeholder readouts.
• Research education through office hours and lunch-and-learns.

I also invested in culture by helping Product and Engineering understand when to use different research methods, what decisions each method could support, and how to participate in the work.

The work gave the organization a more reliable way to learn. It also gave my team clearer structure, stronger cross-functional relationships, and a better path to influence product direction.

At AT&T, I helped create and socialize an Experience Brief framework that changed how teams framed product work before design or development began. It supported one early project that produced $89K in cost savings and 11K new registrations in three months.

Large enterprise product teams often move quickly from request to solution. Teams could start designing or building before agreeing on the problem, the evidence, or how success would be measured.

I helped introduce a framework that asked four questions before work began: What problem are we solving? What evidence shows this is a problem? How is success defined? How will success be measured? This gave Product, Design, Research, and leadership a shared definition of the problem before the team moved into delivery, and made post-launch learning possible because success measures were defined before launch, not reconstructed afterward.

This helped UX move upstream. Instead of being brought in after direction was set, research and design became part of how teams clarified the problem, evaluated tradeoffs, and connected work to measurable outcomes.

At AT&T, I helped establish an enterprise customer panel that gave teams ongoing access to real users throughout the product lifecycle, with participants committing to multiple research activities across the year.

Enterprise teams often struggle to reach the right users at the right time. When customer feedback only happens at the end of a project, teams learn too late and the cost of change is higher.

I helped establish a structured customer panel with enterprise participants from organizations such as Walgreens, Lockheed Martin, The Hartford, BAE Systems, Fiserv, Best Buy, United Rentals, and others. The panel was designed for repeat access — participants committed to multiple activities across the year, giving teams a practical way to test concepts, clarify workflows, and gather feedback earlier.

Customer access became part of the team rhythm. Instead of treating research as a special event, teams had a more consistent way to learn from customers as decisions were being made.

At Digital.ai, the mandate was to bring research to the entire organization, not just individual product teams. That meant building an intake process, establishing continuous research cadences, running on-site contextual inquiries and ethnographic studies, and creating a shared model for when and how to use each research method.

Research was occurring in pockets, but findings were not yet consistently shared or connected to product decisions across teams. The practice needed a more consistent way to plan studies, recruit participants, document findings, and socialize insights.

I built research literacy through office hours, lunch-and-learns, and stakeholder readouts so product managers, engineers, and designers had a shared language for evidence-based decisions. When partners understood the purpose of the method and the decision it was designed to support, findings moved from decks into product direction.

Research became less of a handoff and more of a shared decision practice. The practice gave product teams a clearer way to use research, and it gave my team the structure to scale influence across a complex enterprise portfolio.

At Digital.ai, I led a top-task study that gave product leadership a clearer view of which Agility workflows mattered most to users: 264 responses, story creation identified as the highest-priority workflow area, findings used to inform usability baselines, UX scorecards, and analytics instrumentation.

The Agility product supported many workflows, but product teams needed a better way to understand which tasks mattered most. Without that clarity, prioritization could be shaped too heavily by internal assumptions, individual customer requests, or the loudest stakeholder voice.

I used a top-task survey to establish a stronger baseline. After collecting 264 responses, I looked for patterns across similar task language rather than treating every task label as separate. Story creation and related story-writing tasks emerged as the highest-priority workflow area, shaping which workflows to evaluate first, where to establish usability baselines, and what needed better product analytics.

Research moved from insight to prioritization. The study gave product and design leadership a stronger basis for deciding what to improve, what to measure, and where to focus team effort.

Across AT&T, Digital.ai, and McKesson, I used concept prototypes to help teams test product direction before committing engineering time, surfacing workflow gaps, labeling issues, missing states, and exception cases earlier in the process.

In complex enterprise products, requirements can look clear on paper but break down when users try to move through the workflow — especially when the product includes role differences, handoffs, exceptions, approvals, readiness states, or operational constraints.

I used prototypes as alignment tools. Rather than asking teams to debate a concept in the abstract, I helped them react to realistic flows, screens, and scenarios. At Digital.ai, concept testing informed navigation and spaces direction. At McKesson, this approach was critical for oncology workflows where clinical, product, and engineering teams needed to review logic, states, handoffs, and exceptions before engineering commitment.

Prototypes reduced the cost of learning. Teams could see where the workflow was unclear, where terminology failed, where states were missing, and where product logic needed more definition — before build, not after.

At Digital.ai, I built and facilitated design critique rituals that helped a team of three designers evaluate work through evidence, workflow fit, and user needs — catching usability risks and logic gaps before customer testing.

Design quality does not improve through taste alone. Designers needed shared standards, healthy critique, and a clear way to evaluate whether a design supported the workflow and the evidence behind it.

I structured critiques around better questions: not whether people liked a design, but whether it served the workflow, matched what we knew from research, handled the right states, and identified what still needed to be tested. This gave designers a safer and more useful way to discuss work, and improved what went into research sessions because concepts were stronger before they reached customers.

The team built better judgment together. Critique became a leadership tool, not just a design meeting. It helped designers grow, improved product quality, and gave cross-functional partners more confidence in the design process.

At McKesson, I applied the same practice-building approach to a healthcare product environment — mapping UX into the product lifecycle, identifying operational gaps, connecting design system work to delivery readiness, and creating the conditions for AI-assisted delivery.

The team needed a clearer structure for bringing UX into discovery earlier, validating concepts before build, and reducing late-stage issues from scope changes and design-development mismatch. The design system also needed to go beyond visual consistency — it had to support complex workflow decisions: states, queues, exceptions, handoffs, and readiness signals.

I focused on making the UX process visible inside the product lifecycle:

• Discovery.
• Ideation.
• Concept validation.
• Release planning.
• Sprint design.
• Development support.
• UX QA.
• Feedback and measurement.

I also mapped the operational friction that affected delivery, including user recruitment, engineering availability, late ideation, unclear acceptance criteria, scope changes, and design-development mismatch.

Healthcare product teams operate in complex, regulated, high-stakes environments. Better UX practice reduces ambiguity before build, improves cross-functional alignment, and helps teams make safer, clearer product decisions. At McKesson, the practice-building work created a stronger foundation for workflow consistency, product discovery, and delivery readiness — and made AI-assisted delivery more realistic because the team had clearer design intent and a more structured path from research to implementation.