Role: Lead UX Architect
Scope: UX strategy, workflow analysis, information architecture, requirements definition, AI experience design, wireframing, high-fidelity prototyping, stakeholder facilitation, engineering collaboration
The Company, a specialty chemical manufacturer and distributor, relied on three expert authors to research, write, and maintain Safety Data Sheets (SDS) for its product portfolio, a function with direct downstream impact on manufacturing readiness, shipping, regulatory compliance, and customer support. The process had grown manual and fragmented over time. Authors moved across a system of record for SDS content, a regulatory phrase library (ExESS), a product lifecycle management system (Optiva), an ERP system (Infor M3), supplier documentation, and regulatory sources just to assemble the information needed to write a single document, then repeated much of that research from scratch for every new or updated substance.
There was no standard operating procedure for many of the most common decisions, so quality and speed depended heavily on the judgment of those three authors. Each could work independently, but the knowledge behind their decisions was undocumented. Any absence cut capacity, and there was no process to train against. Leadership needed a path to a scalable, consistent authoring process that didn’t depend on any one person’s tribal knowledge and that could keep the existing system of record intact as the backbone of the workflow.
I led UX strategy end to end for the SDS Automation initiative: discovery, workflow analysis, requirements definition, experience design, and prototyping. Working directly with SDS authors, technical writers, chemical experts, compliance specialists, IT architects, application teams, machine learning specialists, and executive sponsors, I ran user interviews and demo observations of authors working through real SDSs to understand how they actually made decisions, where the process broke down, and what automation could responsibly take on without weakening the compliance rigor the function depends on. UX was deliberately paired with machine learning expertise. My part was deciding where AI helps, where it stops, what the author sees, and how they stay in control. I was also the connective layer between design and engineering, translating research findings into a high-fidelity, testable prototype that let both stakeholders and developers see and react to the same thing.
Discovery and current-state mapping. I ran a structured discovery process, project kickoff, a series of SDS-focused workshops, Copilot-supported current-state analysis reviews, and solution architecture sessions with IT and application teams, combined with demo observations, hands-on exploration of each application authors used, and research into each system in the existing workflow. The goal was to reconstruct how SDS work actually happened, not how it was assumed to happen. Compliance, IT, and machine learning specialists were in the conversations from the start, so research and feasibility moved together. I documented current-state workflows across new SDS creation, SDS modification, classification, composition lookups, phrase authoring, similar substance research, regulatory review, and vendor SDS comparison, using process maps, decision trees, and information flow diagrams as the shared reference point for every stakeholder conversation that followed. That surfaced five connected problems: authors context-switching across five-plus disconnected systems and sources to complete one document; heavy dependence on a small number of expert authors for undocumented decisions; substantial manual time spent comparing phrase libraries, prior SDS documents, and chemical compositions; limited support for the technical compliance judgments authors made dozens of times a week; and single-point-of-failure risk to a business-critical compliance function.
From first-round wireframes to a stakeholder-ready prototype. Early concept flows mapped five core workflows as separate top-level journeys: Chemical Search, Similar Composition Search, Classification, comparing phrases, and SDS generation, each branching into its own low-fidelity screen sequence. Working sessions with engineering and stakeholders made it clear that some of those screens added an extra step: once a user identified a chemical through Chemical Search, they had to leave that context and re-enter a separate Similar Composition workflow to keep going. I restructured it so Chemical Search became the primary entry point, returning results with next-step actions into Similar Compositions, Classification, or SDS generation. Similar Composition became a downstream action instead of its own workflow, taking the structure from five workflows to four before the design moved into high fidelity.
I then moved the surviving concepts from Figma mockups into a high-fidelity, clickable prototype, taking the designs into Figma Make and then into Claude Code, working from the existing Figma designs rather than a blank prompt, to build out realistic interaction and data behavior beyond what static mockups could show. That prototype became the primary artifact for stakeholder alignment: executives and compliance leadership could experience the future-state workflow directly instead of interpreting static screens, and engineering could see the intended interaction and logic expressed in working code, which shortened the distance between design intent and technical feasibility during handoff. Solution architecture sessions kept the prototype grounded in the systems authors already used.
Designing a unified authoring workspace. Three activities consumed a disproportionate share of authors’ time: reconciling standardised phrase language across documents, researching chemically similar compositions to avoid starting from scratch, and researching hazard classifications that could take an hour to several days per substance. Rather than designing three separate tools, I designed one purpose-built authoring workspace that consolidated research, comparison, editing, and validation into a single experience, with the existing system of record preserved as the backbone. Side-by-side comparison workflows surface phrase differences and preferred language directly; similar-composition lookups recommend comparable formulations and reusable content; classification workflows surface supporting data and comparable precedent so authors validate a judgment instead of building the evidence for it from scratch. The intent throughout was to augment expert judgment, not replace it.
Deciding where AI helps, and where it stops. The proposed solution was an Azure-based AI assistant using multi-agent workflows, drawing on past SDSs, ingredient lists (Infor M3), product formulas (Optiva), and hazard and regulatory phrases (ExESS). It isn’t one monolithic agent. Five modules work together as one solution: phrase standardisation, similar composition search, classification support, reaction chemistry, and regulatory assistance. The four workflows are how authors experience it; the five modules are what powers it. Output is always a draft. The author reviews, edits, approves, and publishes, and the system never publishes on its own.
Designing for adoption. Change management was a design constraint, not an afterthought. Rather than introducing an unfamiliar tool, I designed interfaces that mirrored authors’ existing mental model of the SDS workflow and layered automation in gradually, keeping human review and approval steps intact at every stage. The level of control matched the level of risk: AI search expansion is an opt-in checkbox; phrase changes are confirmed one by one, with a change count and undo; for hazard classification, AI recommends and the author decides; and publishing is always a human decision. That was a deliberate choice: the goal was faster, more consistent authoring with full traceability, not a black box asking compliance-critical experts to take an algorithm’s output on faith.
Standardising knowledge and reducing expert dependency. In parallel, I translated undocumented, tribal-knowledge workflows into current- and future-state process maps, documented decision models, functional requirements, and a feature prioritisation framework, giving the organisation a repeatable operating model for SDS authoring that didn’t live only in a handful of people’s heads.
At the time of writing, the platform had moved into pilot and implementation, with go-live planned for late May.
Estimates from discovery, not post-launch results.
