Context
At CHS Inc., embedded with the internal AI engineering team building custom LLM tooling for non-technical users across the company. The platform lets sales, GTM, and operations teams set up their own knowledge bases, configure models, and define functions for their workflows.
The interesting UX problem isn't the tool's capability. The tool can do a lot. The problem is that the audience is smart people who don't and shouldn't have to know what an embedding is to get value from AI tooling at work.
The Problem
Three patterns surfaced before launch:
- New users couldn't tell what the platform could do for their specific role
- Users couldn't tell how it differed from the enterprise GPT they already had access to
- Setting up a custom knowledge base required back-channel help from engineering
The team's instinct was "we need more docs." My read was "the docs need to do the work of teaching, not just describe what exists."
What I Did
I worked the seam between the engineering team building the platform and the departmental users who needed to actually use it.
Biweekly research sessions with power users before the company-wide release. The sessions surfaced current usage patterns, future iteration goals, and the specific places users got stuck. Findings fed directly into the documentation structure and the templates we shipped.
Differentiation messaging. Users compared the new platform to the enterprise GPT they already had access to. The documentation had to make the difference legible without engineering jargon: what each tool is for, what each tool can't do, when to reach for which.
Comprehensive "getting started" documentation for a wide non-technical audience. Restructured around user task flows rather than feature inventories.
A custom chat dedicated to the documentation itself. Template prompts, embedded resources, and the platform's own functionality used to help users learn the platform. Dogfooding the tool for its own onboarding meant users encountered the product's mental model by using it, not reading about it.
Reflections
Documentation is product, not a separate deliverable. When the team's first instinct for "users don't get it" is to write a Confluence page, you've already lost. The documentation has to live where the work happens. The interaction patterns of the docs are the same as the interaction patterns of the tool.
The dogfooded docs-chat was the move I'd most repeat. Teaching a tool by using the tool short-circuits the gap between "read the manual" and "try it." Users learned the mental model by interacting with it instead of reading about it.
The actual UX bottleneck on enterprise AI tools is rarely the AI. It's the comprehension surface between capability and audience. That gap is where senior design earns its keep.
One meta note: the site you're reading is the same approach in miniature. Notion as content, database rows as variants, one-attribute theme switching. See the Colophon for the architecture.
Notes
Specifics of the platform have been kept high-level to respect ongoing project confidentiality. Available to walk through artifacts and outcomes in an interview setting.