Case study · UL Solutions · AI Lab
How my team brought AI into certification work that engineers sign their names to
- Problem
- UL's AI Lab had models that worked, but early builds were made to test the models, not to fit how engineers work. Engineers won't use an answer they can't check.
- What I did
- Led UX on three AI projects, folded a risky user test into our own research, and wrote the case for a dedicated AI product manager.
- Result
- A team rule that no AI feature reaches users before a heuristic review, interaction standards for AI output, and a pilot that uses the check-and-override pattern we recommended.
- My role
- Single UX contact for the AI Lab since October 2025. I directed two designers and design the UL 3115 tool myself.
None of these tools has launched yet. Search stopped at feasibility, the report tool reached a pilot, and the UL 3115 tool is scheduled for November 30, 2026.
The problem
UL's AI Lab had models that worked. The early builds were made to test the models, though, not to fit how engineers actually work. That matters a lot here. A certification engineer signs off on the result, so they won't trust an answer they can't check.
Two things made careful design harder. A business sponsor wanted to put the first search build in front of field engineers right away. And the person covering the product role was retiring on February 1, 2026, with nobody lined up behind him.
My role
In October 2025 I became the single UX contact for the AI Lab. I led UX on three projects: search across inspection documents, a tool that drafts test reports, and an assessment tool for UL 3115, a new standard for certifying products with embedded AI. I directed a designer on each of the first two, and I'm designing the UL 3115 tool myself. The lab owned the models. Product and delivery teams owned the apps.
What I tried first
I gave the lab a four-phase research plan for search: discovery workshops, concepts, iteration, then validation once there was an MVP. The plan assumed we'd test a designed concept. Then the sponsor asked us to test the lab's raw build with real users.
What changed
Saying no would have hurt the relationship. Running the test as asked would have told us users disliked a screen nobody had designed. So we combined the two. Each 90-minute session with a field engineer spent 30 minutes on the existing build and 60 on our concept.
Before the sessions, we ran a heuristic review on the build. It scored 3 out of 10, with gaps in system status, user control, error prevention, and help. Since then my team's rule has been simple: no AI feature goes in front of users until it passes a heuristic review.
The sessions turned up something a review can't. Engineers told us they'd rely on a high relevancy score. Then they opened every result anyway. We recommended ranking results instead of showing a number people read as certainty.
The missing product owner needed a different fix. I wrote a proposal for a dedicated AI product manager and brought it to the lab's executive owner. The manager over the lab's capability teams agreed in writing that those teams didn't have "the remit or appropriate resources to take on workflow responsibilities."
What we delivered
- AI design guidance for the UX team, covering confidence and uncertainty, correction loops, and when not to use AI at all, plus a shared pattern library for human review.
- For the report tool, five sessions with project handlers that set the MVP priorities. The pilot uses the pattern we recommended: the AI proposes, the engineer checks or overrides, then exports. When it ran on real projects, it hit the data problems our research had flagged.
- For UL 3115, the UX scope (co-written with my manager), a kickoff plan with a risk register, and a Figma Make prototype engineers could react to within weeks. The product manager and business analyst signed off on its core pattern: the AI helps but never blocks, so the tool still works when the AI doesn't.
- Inside my own team, an evaluation loop we built that cut research synthesis from about three days to one per study.
Search stopped at feasibility. Our research went to the business as the needs list for any future version.
What I'd do differently
I'd ask for a product owner before the first sprint. Most of the hard moments came back to the same gap. The lab could prove a model worked, but nobody owned getting it to the engineers who sign the certificate.