Portfolio of Lee Basnight: AI strategy, communications design, content strategy, and design systems work

Trane employees and new hires faced a sprawling internal knowledge base across products, protocols, and systems documents that had accumulated over decades of product development. The existing search returned documents: useful if you already knew which document you wanted, useless if you didn't. New hires especially spent weeks learning where to look rather than what to know, and tenured employees were doing repeated lookups for facts that should have been one-step retrievable. The work was to design a search experience that answered questions rather than retrieved files.

AI Content Designer contributing to the internal search tool's design. Owned the information architecture for how product, protocol, and systems content was organized for retrieval. Designed two architectural approaches to the search experience, wireframed both, ran cross-functional review with product, engineering, and brand, and partnered through to ship of the selected approach. Did not own the underlying retrieval engineering or model infrastructure; that authority lived with the engineering org.

Design the information architecture before designing the UI. Understand what employees were actually searching for (mostly questions, not document names), map those to the underlying knowledge structure (products, protocols, systems), then design two distinct UI approaches representing different philosophies of how to bridge from question to answer. Build wireframes for both. Test both with new hires and tenured employees. Let the evaluation, not a prior assumption, select the approach.

• Two approaches built and evaluated, neither pre-favored. Approach A kept the familiar results-first UI pattern and powered it with semantic understanding so the right documents surfaced first. Approach B dropped the results pattern entirely and used a conversational UI that returned synthesized answers with citations. Rationale: presenting both forced an honest evaluation rather than confirmation of a prior assumption. Either was defensible; the question was which matched user behavior.
• Information architecture organized by user mental model, not by document taxonomy. Employees thought in terms of the products they touched and the protocols they ran. The original documentation was organized by document type and originating department. The IA was rebuilt to match how users approached their work. Rationale: a search interface that surfaces documents by their producers fails because users don't know who produced what; they only know what they're trying to do.
• Source citations as a first-class feature, not a footnote. Every AI-generated answer surfaced its sources prominently, with one tap to verify. Rationale: enterprise knowledge search lives or dies on user trust. An answer without a verifiable source loses trust as soon as the user catches one wrong fact. Source-first citations made every answer auditable on first read.
• Three confidence-based outcomes rather than a binary answer-or-no-answer. High confidence returned a direct answer with sources. Medium confidence returned the answer with "verify against source" caveats. Low confidence returned no answer and offered human escalation. Rationale: a tool that gives a confident-sounding answer when it shouldn't trains users to distrust it. A tool that admits low confidence and routes the user to a human builds the trust that makes the high-confidence answers worth shipping.

• Information architecture mapping products, protocols, and systems into a retrievable knowledge graph
• Approach A wireframes: search-results UI with semantic ranking, faceted filters, and source badges
• Approach B wireframes: conversational interface with answer cards, inline source citations, and suggested follow-ups
• UX flow documenting user journey from query through intent classification, retrieval, and confidence-based outcomes
• Cross-functional review materials for product, engineering, and brand
• Design rationale documentation supporting the selected approach

The initial information architecture was organized by document type: SOPs in one bucket, technical specs in another, training materials in a third, field notes in a fourth. This mirrored how the documentation was produced, which seemed orderly on paper. User testing surfaced that employees didn't think in document types; they thought in terms of the product they were working on and the procedure they were running. Reorganized the IA around those user mental models. Lesson: an information architecture that mirrors how documents are produced is not the same as one that supports how they're consumed. Production-side ordering is a curatorial convenience; consumption-side ordering is what makes the search useful.

Approach B was selected for the primary employee experience based on the cross-functional review and user testing; Approach A pattern was retained as an advanced search affordance for users who knew exactly which document they needed. The two-approach methodology became a working pattern for evaluating future enterprise tool decisions rather than a one-time exercise; subsequent product decisions inside the AI content org used the same compare-then-commit process. The information architecture work outlasted the project itself and became a reference for downstream content design work across the broader AI content system.

The technical capabilities inside modern audio plugins are extraordinary. The interfaces that sit on top of them are intimidating. Dense rows of decimal-precise knobs, frequency curves, gain reduction meters, threshold and ratio controls, attack and release and knee parameters laid out for engineers and only engineers. A producer who wants the sound a compressor can give them has to first learn what a compressor is, why it has six knobs, and which combination of those knobs produces the sound they actually want. The tool gets in the way of the result. Existing solutions either preserve the engineering interface and accept the friction, or strip the capability down to make the interface friendly. Neither is the answer.

Audio plugins that hold onto the professional-grade processing inside the dense-interface tools and put a frictionless workflow on top of it. Capability without the cognitive tax. The user's intent leads; the parameters that serve that intent get exposed at the level the user actually needs them, and stay out of the way otherwise. The interface earns its keep by making the sound the user wants reachable in seconds rather than minutes.

Founded Fischer Music Club to chase that gap. Sole founder. Total ownership across product strategy, visual identity, UX design, audio processing decisions, the visual component system, AI-assisted development practices, and shipping. The constraint that defined every decision: build pro-grade audio software, alone, without falling back on the same intimidating interface patterns the existing market relies on.

The system is the answer to both halves of the problem. For the user, it produces plugins that read clearly at first encounter: a single dominant visual per tool, components whose state is obvious without a manual, gestures that map to intent rather than to engineering parameters. For the solo-founder workflow, it makes new plugins designable in hours rather than weeks. Color, scale, control patterns, meter styles, branding elements, and stateful interactions all live as composable components with versioned definitions. Designing a new plugin starts with picking the right primary control, the right meter style, the right preset toggle pattern from the library, and assembling. The system solves the access problem at the front end and the production problem at the back end.

• Design from user intent, not from processing parameters. Rationale: existing tools start from the engineering and try to add usability later, which is why the result is a parameter wall. Starting from intent and adding precision underneath inverts the failure mode and produces interfaces a producer can read on first encounter.
• One dominant visual per plugin. Rationale: a single bold focal point reduces cognitive load and gives the plugin a memorable identity. HONNIE's single primary dial, SADturator's face, Tonband's Lissajous curve — each is identifiable from a thumbnail and obvious at first glance.
• Component library that composes, not templates that lock. Rationale: templates produce same-looking products. A component library that composes produces a family of products with shared design DNA but distinct identities, which is what a plugin lineup needs.
• Treat the visual system as a product in itself. Rationale: same versioning, changelog, and discipline I'd apply to a shipped tool. Drift in the visual system would compound across every plugin built from it; treating it as a real product prevents that.

• Visual component system: color tokens, control patterns, meter styles, primary-control archetypes, state visualizations, branding elements
• HONNIE Compressor: frequency-response compressor with single-dial primary interface and at-a-glance gain reduction
• SADturator: multiband saturator with intent-driven face visualization
• Tonband: tape panner with Lissajous-curve primary visualization
• AI-assisted development framework supporting design-to-ship velocity across the lineup
• Process documentation as a standalone deliverable for AI-assisted product development

The first product attempt tried to do everything in one plugin. Multiple modes, layered menus, several "advanced" panels behind expansion toggles. The result ended up looking exactly like the cluttered tools the system was supposed to replace, just with the clutter hidden behind another click. Threw that out and restarted from a single question: what's the one thing this tool does that the user can feel? The "one dominant visual per plugin" rule came out of that restart and has held since. Lesson: complexity doesn't get reduced by adding modes or advanced views. It gets reduced by deciding what the tool is actually for and saying no to everything else.

The visual component system is now the shipping infrastructure for the company. New plugins start from the system rather than from blank canvases, which is the difference between a one-person operation that can sustain a multi-product lineup and one that ships once and stalls. The plugins themselves prove the framework's premise: audio tools can be friendly without losing their teeth, and the framework that produces them is itself a designable, versionable product. The AI-assisted development practices supporting this work became reusable substrate for documentation deliverables in other contexts.