Role: Lead UX Architect
Scope: discovery and user research, conversational UX and chatbot experience strategy, trust and transparency design, accessibility recommendations, UAT strategy and test leadership, future-state roadmap and website integration planning
The Company, a national manufacturer of windows and doors, held a large volume of product documentation, technical specifications, performance data, installation guidance, warranty materials, and architectural resources spread across multiple disconnected systems. Employees, dealers, architects, and builders all needed fast, accurate access to that information, but the existing search experience made it hard to find. Terminology was inconsistent across documents, answers were difficult to verify, and routine questions fell back on a small group of subject matter experts, which slowed everyone down and didn’t scale.
User interviews confirmed the pattern: people generally knew what they needed to find, they just couldn’t find it efficiently, and they didn’t trust the results enough to stop double checking them. Leadership saw an opportunity in retrieval-augmented AI, generative AI grounded in the company’s own product content rather than an open model guessing at answers, but adopting it meant solving a harder problem than search. It meant building a conversational experience that technical, risk-aware users would actually trust.
I led UX for this initiative from an internal proof of concept through customer-facing readiness planning, across multiple funded phases. During the proof-of-concept phase, I worked alongside the client’s internal design team, leading the effort and doing the majority of the hands-on research, strategy, and design work myself. My scope covered the full arc: discovery and user research, conversational experience strategy, trust and transparency design, accessibility, a UAT framework I built and ran personally, and the future-state roadmap that carried the work from an internal tool toward a public-facing product. I worked directly with AI engineers, product managers, and client stakeholders to translate research findings into requirements the engineering team could build against.
Grounding the problem in real user friction. I ran interviews and discovery sessions with trade lead managers, lead development representatives, architects, and internal support and product teams to understand where information retrieval actually broke down. That work surfaced a consistent set of pain points: inconsistent search results, difficulty interpreting technical documents, historical product data that was hard to validate, content scattered across too many systems, and product terminology that shifted from one document to the next. It also shaped how I segmented the audience, since internal users (sales, call center, support, architects) and future external users (builders, dealers, homeowners, contractors) needed meaningfully different things from the same assistant.
The core design risk with an AI assistant in this context wasn’t whether it could find an answer, it was whether technical, liability-conscious users would believe the answer once they had it. I authored UX recommendations built around that problem, directly by grounding every response in authoritative source content, surfacing citations and source documents, and setting transparent boundaries around what the assistant was and wasn’t confident about. I paired that with conversational guidance, prompting the assistant to ask clarifying questions on ambiguous requests instead of guessing, and defined clear escalation paths to human support when the assistant reached the edge of what it could reliably answer, directly responding to what users like the architect I’d interviewed had told me: they wanted a knowledgeable human, not a chatbot, for anything beyond the basics. Accessibility was part of the same trust question: I reviewed colour contrast, typing indicator behaviour, keyboard navigation, and screen reader support so the experience held up for every user, not just the default case.
One of my most direct contributions was creating structure around how the assistant got tested. I developed the UAT strategy, test cases, success criteria, and a defect categorization model that gave the team a repeatable way to evaluate product knowledge accuracy, technical specification retrieval, document discovery, installation guidance, escalation handling, and human handoff readiness. I also ran a substantial amount of that testing myself. That hands-on testing surfaced specific, fixable problems: gaps in source traceability, inaccurate document and page citations, missed synonym recognition, mismatched product terminology, and inconsistent response generation. Those findings fed directly into later phases of refinement rather than sitting in a report, which is the part of AI UX work that doesn’t show up in a mockup: deciding what “good enough to trust” actually means for a given answer, and building the process that catches it when the system falls short.
Alongside the strategy and testing work, I collaborated with on the chatbot interface across its range of states, greeting, active conversation, document response, empty states, and both desktop and mobile layouts, working in Figma alongside the client’s internal designer.
Beyond the initial internal tool, I developed the future-state vision that extended the assistant toward a genuine product: context-aware behavior, role-based experiences for architects and builders, proactive assistance, product recommendation opportunities, and a strategy for integrating the assistant into the company’s public website. That work gave the team a rollout and governance framework to work from as the initiative moved from internal deployment planning toward customer-facing readiness, rather than treating the internal pilot as the finish line.
