Josh Covington

The problem

A technician working on a vehicle knows what they want: a brake caliper retraction procedure, the misfire data parameters, whether there's a service bulletin on this symptom. What they don't reliably know is which branch of the tool holds it.

Diagnostic software accumulates content over years — functional tests, special tests, live data lists, guided component tests, documented real fixes, reset procedures, technical bulletins, troubleshooting tips — and each type lives behind its own menu path. The tool knows the answer. The technician has to know the tool to reach it.

The hard problem was never looking up a repair scenario. It was deciding what the system should surface.

Constraints

• Scope had to come back small-to-medium or the project stayed on the backlog. That single constraint is why phasing mattered more than feature completeness.
• Platform engineering capacity was already committed to other releases, so any design had to survive a long wait without going stale.
• The content database is uneven. Not every vehicle variant supports every test. A results page that promises content it cannot deliver is worse than no search at all.
• No dedicated research budget. Validation came from existing focus-group findings, conversations with field-facing colleagues, and a demo build.

Process

I started by mapping the machinery rather than sketching screens. Working with the data and content leads, I diagrammed how the ontology and taxonomy, the web services, the content stores and the platform UI related to one another. That diagram went through several revisions and was reviewed before any mockup existed. It is the reason later feasibility conversations were short — everyone was arguing from the same picture.

For a content baseline I used a real vehicle on a real software load rather than placeholder test names. That exposed problems early, particularly how much content a single scenario actually returns.

I explored three entry points. A button on the vehicle confirmation screen stranded users, because returning them there to refine the scenario broke the vehicle-identification workflow. A modified main menu added a layer to the exact structure the feature was meant to flatten. A selector on the home screen won: it sits where users already start, and it puts repair scenarios alongside rather than behind the existing scan workflow.

Three entry points explored

Rejected

Button on the vehicle confirmation screen

Stranded users; refining broke vehicle identification

Rejected

Modified main menu

Added a layer to the structure it meant to flatten

Chosen

Selector on the home screen

Alongside, not behind, the existing scan workflow

The argument that shaped the product

Midway through concept, a senior stakeholder proposed a cheaper first pass: rather than returning the content, tell the user where to find it — a trouble tree-style experience handing over navigation instructions. It was a serious proposal with a serious rationale. It mirrored a support trouble tree that had shipped quickly, and it appeared to sidestep the database-coverage problem entirely.

I mocked the implications rather than arguing from preference. The counter-case was concrete: a navigation instruction still has to know whether the content exists for that specific vehicle variant, or it sends the technician down a dead end. It doesn't avoid the hard problem — it hides it behind a layer of text. And the value to someone standing at a vehicle is the answer, not a lesson in menu structure.

Decision record

Proposed

Tell the user where to find it

Trouble tree-style navigation instructions

versus

Decided

Surface content directly

Documented with its reasoning attached

The decision landed on surfacing content directly. I documented it as a decision with its reasoning attached, which matters more than the outcome: a future team that wants to revisit it can see what was weighed.

The design

Related: symptom-driven filtering patents

A technician looks up a component name from the home screen. If no vehicle is identified, the system prompts for identification first — the lookup runs only once the vehicle is known, which is what keeps the results honest. The results page then organizes everything the tool holds about that component into distinct containers: bulletins, live data, guided tests, and documented fixes.

Refinements that came out of review:

• A global system switch, because tests and data correlate to a selected vehicle system and early mocks made moving between them clumsy. Systems with no results are excluded from the UI entirely rather than shown as empty states.
• Lists rather than cards for dense result types, with tabs for parts-oriented scenarios. Documented fixes for a component can be numerous and read better as a list.
• Animated data visualizers make a static page feel live.
• Progressive disclosure — overflow for additional fixes, and an accordion for long content — so a component with a lot of complexity doesn't produce a page you scroll past to work.

One early constraint was to return content from only the top three vehicle systems. Reviewed against real scenarios, the cap proved arbitrary — some scenarios legitimately span more, others fewer. We removed it and let the platform interrogate each relevant system to confirm content exists before rendering them.

The problem

Government and institutional buyers require accessibility conformance documentation before they will buy. That is the commercial fact underneath this project. There were reference conformance reports for sibling products, but for this platform there was no established evaluation method and no agreed position on which criteria applied.

The risk was not failing. The risk was producing a document that showed accessibility had been considered rather than evaluated — a paperwork artifact that wouldn't survive a buyer's technical review and would leave engineering no clearer about what to remediate.

Constraints

• Automated tooling covered a fraction of the surface. The testing tool reported meaningfully against one criterion. Everything else had to be evaluated by hand.
• No issue-tracker integration. Findings couldn't auto-create work items, so results had to be captured and structured manually.
• Two evaluators, split scope, one document. I owned the platform and support resources and my counterpart owned a companion web application. Two evaluation contexts feeding one conformance story is an easy way to overstate coverage.
• The work kept getting paused and reactivated. Anything I built had to be resumable by someone who'd been away from it.

Process

I installed the testing tool on the device itself and set up a multi-monitor rig — device under test alongside inspection tooling — then worked through the main screens. Testing on shipped hardware rather than a simulated build mattered: focus behavior and screen-reader naming are properties of the built product, not the design file.

Because automation covered so little, I built a manual results structure with four states per item: pass, fail, uncertain, and an explanatory note.

Four states per item

Pass Fail Uncertain Explanatory note

The "uncertain" state is the important one. Automated accessibility tools produce false positives, and a binary pass/fail forces you to guess. Recording uncertainty honestly — and explaining why — is what separates an audit from an assertion.

It also meant a second evaluator could pick up where I left off.

For classification we adopted an explicit threshold before committing: items above a defined support level marked partially supported, below it not supported. My counterpart researched whether that convention differs between the two standards we were reporting against. A stated, researched rule is defensible in a way case-by-case judgement is not.

Making several hundred findings actionable

The tooling produced several hundred failures and cautionary results. A list that long is not actionable — it's a wall. I mapped every one to a specific screen and feature across the complete diagnostic workflow, so a developer reads "this dialog, this control" rather than "this criterion, several hundred instances."

From that I isolated the confirmed failures — roughly a fifth of the flagged results — and sorted them into three groups: focusable elements missing accessible names, list-action pattern issues, and a small number of bounding-box problems. The breakdown matters because those categories have completely different remediation profiles. Missing names are largely a labelling pass. List-action patterns are an interaction-model question. The rest are one-offs.

I then wrote plain-language explanations of what the labelling failures actually mean for a user, with a worked example, and flagged which results were likely false positives. The audience wasn't accessibility specialists — it was engineering and business leaders who needed to judge severity and fund a response.

Taking it to the room

I convened a checkpoint with a stakeholder group including the VP of Engineering, product leadership, and marketing. The agenda was deliberately three items: highlights from research to date, questions raised by comparing against the reference reports for sibling products, and two proposed paths forward.

I also gave my manager an early, unvarnished heads-up that the results weren't looking promising — before the formal update, and before an external-facing conversation was scheduled. Leaders can handle bad findings. They cannot handle bad findings that arrive late.

The most durable outcome is the least visible: accessibility moving into design practice rather than living in an evaluation phase. Concretely, that means specifying tab-stop order in mockups so focus order is a design decision rather than an implementation accident.

The problem

Design work lived in a legacy tool with years of accumulated project files, company-specific component governance, and an entirely manual developer handoff. Meanwhile four sibling businesses — diagnostics products, repair-information software, shop equipment, and dealer software — each maintained their own UI vocabulary for products customers increasingly saw as one ecosystem.

A second problem surfaced once we audited properly: the existing system wasn't responsive. Elements were resized by hand for every new product's screen dimensions, larger displays were handled with fixed ratios rather than by using the extra space, and off-the-shelf components arrived with unpredictable sizing. Without standardized sizing rules, every new screen size meant either a code branch or another manual pass.

There was also a live clock: an annual subscription renewal, and files in a proprietary format nobody would be licensed to open. That's slow-motion data loss.

Constraints

• I had no authority over three of the four businesses. Everything cross-company had to be achieved by agreement.
• Cost had to be justified honestly. The new tool was more expensive. Pretending otherwise would have cost credibility I needed later.
• Design capacity was two people — both with concurrent product delivery obligations.
• Legacy products aren't going away. Older mockups still need to be accessible for products on older stacks, so this couldn't be a clean break.

The business case

I built a short executive proposal rather than a tooling request. Four parts: the destination tool is the industry standard for product teams; counterparts at all three sibling businesses already use it; it connects to the embedded UI framework our developers use, opening the door for design-to-code handoff; and it was raised by engineering leads themselves on a weekly platform call — so this was not design asking for a toy.

I put the cost comparison in plainly, including the per-seat developer licensing, and named which developers would need seats. Presenting an unfavorable cost comparison without spin is, I think, why it passed. The proposal was about handoff and commonality; the price was a fact within it rather than something to be managed.

The commercial move

Rather than buying a standalone enterprise environment, I negotiated onto a sibling business's existing enterprise account with a dedicated private workspace for our team. Accounting on both sides worked out inter-business billing, which turned a one-team purchase into a model that scales — the next business unit joins the same environment, with their own private workspace, rather than starting its own.

The design consequence is the important part. Sitting inside a shared environment makes a parent/child design-library relationship possible. We could not have negotiated shared foundations from four separate accounts.

Architecture and migration

I designed the workspace structure before moving anything into it: workspace, team, project, file — with three teams covering our own business approved projects, joint work spanning sibling businesses, and shared experiments and assets.

Workspace structure

Workspace

Private workspace inside a shared enterprise environment

Teams

Our business: approved projects

Joint work across sibling businesses

Shared experiments and assets

Project

Flat, with status labelling

File

Links stay stable because files don't move

We worked through and rejected a phase-folder model where projects move through ideation, concept, development, launch, and archive. In practice teams keep evolving a project in place rather than migrating it through folders, and moving files breaks the links people have pasted into project docs, use cases, and planning boards. We went with a flatter structure and status labelling instead.

For migration, my colleague ran a full inventory and I worked the categorization with him. Every project landed in one of four buckets — migrate, archive, delete, undecided. The genuinely hard calls were files untouched for three or more years, where the question isn't "is this valuable" but "would anyone ever find it again."

Two mechanics made it safe. A temporary sort folder, so files could land in the new environment before the final taxonomy was settled — decoupling the move from the organizing. And a single pilot project moved first, chosen because we already knew where it belonged, to prove a file could travel from sort folder to correct archive before we committed the rest.

Migration mechanics

Full inventoryEvery project categorized

Temporary sort folderMove decoupled from organizing

Pilot project firstProves the path before the rest

Migrate

Archive

Delete

Undecided

One thing we caught: before deleting archived projects, my colleague extracted the graphics — then immediately flagged that graphics without their use cases, notes and rationale are close to worthless. That became a standing requirement for how we file future work.

Onboarding, built in

I treated onboarding as a deliverable rather than an afterthought. We created test accounts, then ran a deliberate permissions test: invite a colleague from another team, give them one project they should be able to open and one they should not, and verify the boundary actually holds. That colleague documented his own onboarding with screenshots as he went, which became reusable onboarding material at zero marginal cost.

Convening four design teams

I brought designers from the four businesses together to agree on common foundations first — color, typography, spacing, effects — on the principle that you cannot negotiate components with people who disagree about a primary color palette.

We adopted the most mature sibling library as the parent, with child libraries per product for legitimate variation: platform differences, screen sizes, market-specific theming, brand-specific icon treatment. A styling audit against our own development library surfaced the undocumented colors and outliers that accumulate in any long-lived product, plus a practical problem — the embedded framework expresses color in a different format than the design tool, so the system needs a defined translation rather than a designer eyeballing values.

I raised change control early: when the parent library changes, what happens to the products depending on it? How would owners of a child library propose changes to the parent? Agreeing that governance before the dependency exists is far cheaper than discovering it afterwards.

The problem

The prototyping loop was expensive. Teams typically spent an entire development cycle building and testing a prototype, and problems found by real users afterwards could cost roughly another six-month cycle to fix. Compressing that loop has obvious value.

The risk is equally clear. Generic AI design output ignores your design system and produces plausible screens that cannot be built on your platform — worse than useless, because it looks like progress. A sharper risk sat behind it: an AI tool with broad capability and access to internal systems is an intellectual-property question, not a tooling question.

So the real question was narrower than "is AI useful for design." It was: can this be constrained enough to be safe, and still be good enough to be worth it?

Constraints

• No formal company guidance existed. We weren't going to be handed a policy. Someone had to define the boundary — and if we didn't, another team would define our role for us after the fact.
• Usage is metered and genuinely expensive. Compute consumption per session is capped, and exceeding it stops work. This is not a flat-rate tool.
• Our design system is not clean. The product has accumulated real drift — font sizes that disagree, color specified one way on one platform and another way elsewhere.
• Budget was personal-scale, which I offset by cancelling an existing subscription rather than asking for new money.

Evaluating before proposing

I attended a demo and Q&A run by a sibling team already using the tool in production, and asked the two questions that actually determine whether an evaluation is fair: which model and effort level do you recommend starting with, and will you share your configuration file? Both were answered. Starting from a working configuration rather than defaults is the difference between evaluating the tool and evaluating your own inexperience.

The demo was instructive in a way the presenters may not have intended. The prototype shown had been built over four weeks with iterative, targeted prompting against specific screen regions, layout containers, buttons, text and spacing boundaries. My read, shared with my colleague afterwards: this is substantially more meaningful than generic AI app generation, and it reflects significant design effort and many rounds of refinement rather than the tool doing the work.

We concluded the incumbent design tool still has a clear role for creative ideation and quick component refinement. That conclusion — that the new tool does not replace the old one — is what made the pilot credible internally.

Constraining the output

The pivotal step was importing a full design system and compiling it into the tool, so generated output was bounded by real tokens rather than generic defaults.

I framed the configuration file for what it actually is: a rules, boundaries and guardrails document defining fonts, line widths, corner radii and the other building blocks the tool generates from. I made reviewing that file a prerequisite for anyone trying to understand the workflow — people evaluate the outputs and miss that the outputs are entirely a function of that file.

Constraining it also exposed an honest limitation. A design system imported from a source that later changes its structure can break, and an imported system is not authoritative — it's a copy that may not have reproduced the original correctly. I flagged that explicitly rather than letting the team treat a generated artifact as ground truth, and named bringing the source team into the conversation as a prerequisite before using it meaningfully.

Drawing the boundary

I bounded the pilot deliberately and wrote the boundary down:

• Design tooling only. Not code generation.
• No connections to internal systems.
• Lowest capability settings on the recommended model, so the tool is less likely to reach into secure internal systems for references.
• Work kept local.
• Approval, access and cost as explicit checkpoints before wider adoption.

The reasoning is worth stating: the intellectual-property risk sits in the methods, not in the visual design. Once you name that, the boundary becomes obvious rather than arbitrary — and you can explain it to people who are nervous about AI without either dismissing or indulging the concern.

Cost as a design practice

Early on, rendering a full design file consumed an enormous amount of usage. That could have been a one-off annoyance. Instead we turned it into practice: I had the tool draft best practices for working efficiently within usage limits, and established a standing habit of asking for a usage estimate — and giving explicit approval — before committing to a task.

Estimate before you commit

Describe the task

Ask for a usage estimate

Give explicit approval

Run it

Repeated for every task, as a standing habit

Treating compute as a budget line designers are responsible for isn't a common instinct yet, and it's the difference between a pilot that scales and a pilot that quietly stops working mid-sprint.

A worked example: for a visual-direction exercise, I ran demographic pre-research on our user base, compiled it separately, fed that summary in as grounding, and asked for mood boards plus a usage estimate before any action. Low usage, useful output — and a clear-eyed note that it excluded graphics and would cost more to iterate.

Where the value actually is

Most discussion of AI in design stops at handoff. I argued for a wider frame: A/B and beta testing, focus-group feedback synthesis, future-state roadmapping, and evaluating designs against explicit goals — ease of use, accessibility, and the needs of distinct user personas.

The broader ambition was to evaluate customer experience across the full lifecycle — pre-sale, product usage, post-use support — combining product and marketing perspectives. That's a design-research application, not a mockup-generation one, and it's where I think the durable value sits.

I deliberately ran this in parallel with an ongoing tooling migration rather than stopping either, letting the approach that proved more effective determine the longer-term direction instead of picking a winner prematurely.