# Jason Sonderman — Full Site Content This document is generated at build time from the same content sources that build the HTML site. It contains the complete text of every published case study, the about page, and professional experience — everything needed to answer questions about Jason's background, roles, and project work in a single request. Canonical site: https://jason.sonderman.info Short index: https://jason.sonderman.info/llms.txt # Status and Contact Open to new roles as of August 2026. Most recent role: Head of UX at Arcos, Inc (Oct 2024 – Jul 2026). - Email: jasonsondermanux@gmail.com - LinkedIn: https://www.linkedin.com/in/jasonsonderman - Contact form: https://jason.sonderman.info/#contact # About Canonical URL: https://jason.sonderman.info/about/ Markdown: https://jason.sonderman.info/about.md ## Why This Work I'm in UX because I want to make people's lives better. That sounds simple. It gets complicated quickly. The complication is that "better" isn't obvious, and the people who would benefit most often can't tell you directly what they need. They describe symptoms, workarounds, the frustration with the thing that exists. Listening past that — to what's actually underneath — requires slowing down when speed is the pressure, staying curious when you're supposed to have answers, and giving the work enough room to miss. Missing the mark is part of it. Not as failure to be avoided — as instruction. Each iteration gets you closer to something genuinely useful, often in ways the people benefiting will never consciously notice. That's not a failure of visibility. That's the whole point. I've spent a lot of time thinking about how we actually come to know things — and how looking at the same problem through different lenses changes what you see. My faith, rooted in Jesus Christ and read through both Eastern Orthodox and Western theological traditions, shaped that instinct early. Not because I'm undecided between them, but because holding those perspectives in tension showed me that truth doesn't flatten when you examine it closely. It opens up. That's the same thing that happens when you bring research, systems thinking, and direct observation to a problem at the same time. The answer almost never lives inside a single frame. ## The Work I've spent 20+ years doing this across healthcare, SaaS, higher education, and critical infrastructure — leading teams across India, Poland, Belgium, and the US, in organizations where UX had to earn its place by demonstrating actual value, not by claiming it. I've built teams, designed systems, run research programs, and influenced product direction. The common thread in all of it is the same question: what does this person actually need, and are we building toward that? At Arcos, I built a UX practice from the ground up — growing from one designer and two consultants to a senior team with its own ways of working, its own design system, and a delivery model that takes work from discovery through to draft front-end code without leaving the design function. I built that not because it was technically clever, but because the people we were designing for couldn't wait two weeks for a decision. Speed in service of people is worth finding. Speed as a substitute for understanding isn't. The same conviction shapes how I think about AI in design. It should extend thinking, not replace judgment. It should free up the time and attention that belongs on the actual question. ## Beyond the Work Outside the office, I'm usually doing something that requires patience, systems thinking, or a willingness to be wrong. I design and play board games — and game design has taught me more about user experience than most UX books I've read. Mechanics have to be learnable, fair, and satisfying. Feedback loops have to be calibrated. Players have to feel agency even when they're constrained. Sound familiar? I cook my way through cuisines I don't know yet. It's the same practice as research: approach something unfamiliar with genuine curiosity, learn its logic from the inside, and then make something with it. I take coffee and bourbon seriously — not as lifestyle accessories, but as exercises in sensory discernment. Training your palate to identify what's actually there, rather than what you expect to be there, is a discipline. One that transfers. ## Credentials - Nielsen Norman Group UX Master Certification (UXMC) - IAAP Certified Professional in Accessibility Core Competencies (CPACC) - BFA, Visual Communications — Kansas City Art Institute # Professional Experience Canonical URL: https://jason.sonderman.info/experience/ Markdown: https://jason.sonderman.info/experience.md Two decades of UX leadership have taught me that the gap between great design and shipped product usually lives in the system… or the absence of one. I build AI-native design infrastructure: token, component, and MCP-enabled documentation layers that treat AI coding agents as first-class consumers alongside human designers and engineers. Deep practice in DTCG token architecture, Figma Variables, Code Connect, Dev Mode, and design-to-code pipelines, grounded in WCAG accessibility throughout. I design systems where the best choice is the obvious one — whether the hand reaching for it is human or artificial. ## Head of UX ### Arcos, Inc #### Oct 2024 – July 2026 Arcos builds SaaS and mobile workforce management platforms for utilities and critical infrastructure. - **Built and scaled an international design team across Poland and Mexico** — grew from one designer and two consultants to three Senior Designers and a consultant, establishing UX values, research methodology, and cross-functional working agreements from the ground up. - **Pioneered an AI-accelerated delivery model** — moved from discovery through UX design to draft front-end code entirely within the design function, cutting kickoff and handoff from a two-week investigation sprint to three days, reducing time to market by ~30%, and compressing a testable coded concept from 40 hours to 12. - **Led 2.5 months of embedded field research** across 14 customer sites with 120+ emergency workers — reframing product direction for the Control Tower platform and delivering UX strategy up to 9 weeks ahead of planning sessions through close collaboration with Product Leadership. - **Shipped the Control Tower MVP on schedule (August 2025)** despite two scope reductions, carving out 2–4 weeks of structured UX discovery within each Milestone definition and Shaping phase to validate feature value with utility users before development began. - **Strengthened partnerships with legacy Arcos products** — infused modern UX methodology and interaction principles into established product offerings, extending design system consistency across the full platform portfolio. - **Implemented an AI-enabled design system npm package and Figma MCP integration** — enabling designers to build Higher Order Components directly against the production front-end codebase, near-eliminating revision cycles. **Skills:** Team Building & Org Design, AI-Accelerated Design Operations, Figma MCP Integration, Research-Backed Product Vision, Cross-functional Strategy, Design Systems, Accessibility Strategy & Compliance ## Director of UX (Global UX Lead) ### TVH Parts, Co #### Apr 2023 – Oct 2024 - **Led strategic redesign** of the global e-commerce platform using UCD, Double-Diamond, and Design Sprint methodologies — increasing user engagement by 20% through a research-grounded, iterative process. - **Built and scaled a team of 8 UX Designers** across Belgium, the US, and India — establishing UX values, working principles, and a design culture that operated cohesively across time zones. - **Implemented enterprise-level discovery infrastructure**: live customer sessions for pre-release validation, session recordings, and behavior metrics to drive evidence-based design decisions. - **Architected design system strategy** — refined the Figma component library and developed a CSS token system, reducing development time by 35% across two major platforms. **Skills:** UX Strategy & Vision, Global Team Leadership, Design System Architecture, Discovery & Research Operations, Cross-functional Stakeholder Management, Budget Management ## Lead Product Designer ### BetterCloud #### Mar 2022 – Mar 2023 - **Designed complex enterprise features** through low and high-fidelity prototypes, increasing feature adoption by 32% - **Led platform experience strategy** and **mentored a team of three product designers**, establishing career development frameworks and design excellence standards - **Implemented enterprise-grade design system**, streamlining UI consistency across multiple product tools - **Reduced time to market by 20%** through cross-functional collaboration with product, engineering, and marketing teams **Skills:** Enterprise Product Strategy, Team Leadership & Mentoring, Design System Implementation, Cross-functional Collaboration, Discovery Workshop Facilitation, Accessibility Strategy, Data-Driven Design Decisions ## Lead UX Designer ### Archer Education #### Jul 2018 – Mar 2022 - Improved online higher education engagement by 35% through user-centered design strategies - Enhanced information architecture and experience design through high-fidelity prototypes for partner microsites, leading to a 23% increase in lead conversion - Established and documented WCAG AA compliance across online properties **Skills:** Wireframing, Information Architecture, User Research, Accessibility & Usability Testing, Multivariate & A/B Testing, HTML/CSS, React.js ## Lead Product Design Strategist ### Cerner Corporation #### Dec 2015 – Jul 2018 - **Managed a team of 4 product designers** — mentoring on craft and career, establishing goal-setting frameworks, and growing the team's leadership capabilities - Implemented design strategy for healthcare technology products, focusing on in-app coaching and compliance learning systems - Led the design and implementation of learning management systems for hospital administration **Skills:** Wireframing, Information Architecture, User Research, Accessibility & Usability Testing, Internationalization, Team Leadership, Business Management ## Principal UX Designer & Web Developer ### blue148, inc #### Jan 2003 – Dec 2015 - Led the design and development of web and UI projects, consistently exceeding client expectations. - Developed a customizable CMS, streamlining workflow and enhancing efficiency for client website management. - Managed a diverse client portfolio, including international manufacturers and start-ups, delivering B2B e-commerce sites, email campaigns, and digital content transformation. - Adapted UX strategies across various industries, demonstrating versatility and strong problem-solving skills. **Skills:** Wireframing, Information Architecture, User Research, Accessibility & Usability Testing, Internationalization, Team Leadership, Business Management, Front-end Coding (Javascript), Back-end Coding (PHP, MySQL) # Case Studies ## Harmony: A Design System Built for Machines - Subject: Harmony Design System — Arcos, Inc - Role: Head of UX, Arcos, Inc - Timeline: Q3 2025 – Jul 2026 - Canonical URL: https://jason.sonderman.info/case-studies/arcos-harmony-design-system/ - Markdown: https://jason.sonderman.info/case-studies/arcos-harmony-design-system.md What design systems become when AI is a first-class consumer — and what three companies of building them taught me about the architecture that closes the gap between human-readable and machine-executable. **Key outcomes:** - Figma Code Connect: 100% (Every Figma library component mapped to its TypeScript implementation) - HOCs in production codebase: First cohort shipped (Reviewable, trustable, and mergeable by engineers who hadn't built them) - Team enablement: 3 designers, 2 wks training (Into VS Code with Claude Code CLI; one co-established the token architecture) - Pilot footprint: 2 pods, 3 senior designers Jason built Harmony, a design system at Arcos architected to treat AI coding agents as first-class consumers alongside human designers and developers — the third design system he’s built, following BetterCloud Fulcrum and TVH Uplift, which taught him what infrastructure a design system needs to actually hold. **Facts:** - Figma Code Connect: 100% of Figma library components mapped to their TypeScript implementation - Engineering credibility: First HOCs shipped into the Control Tower codebase — reviewable, trustable, and mergeable by engineers who hadn’t built them - Team enablement: 3 senior designers completed 2 weeks of training into VS Code with Claude Code CLI; 1 went deeper, co-establishing the token architecture - Architecture: DTCG-format tokens, Figma Code Connect, Zeplin MCP and Figma MCP, an AI agent suite enforcing design-system use in code review - Status: Harmony npm package published to AWS CodeArtifact March 2026, in production as a versioned dependency; Storybook on Chromatic launched April 2026; Zeplin MCP and JIRA kickoff skill in production; Storybook MCP and enforcement agents in pilot across 2 Control Tower web pods **Scope:** Pair with BetterCloud Fulcrum and TVH Uplift for the org-adoption lessons that directly shaped Harmony’s architecture. For the delivery-speed metrics this pilot produced — kickoff time, time to market, and the 12-hour coded concept — see The Handoff Is the Bug, which credits the same Zeplin/Figma/Code Connect/Storybook tooling chain documented here as the infrastructure behind those numbers. **Team:** 3 Senior Designers, 2 Pilot Development Pods, 1 Engineering Advocate **Tags:** Design Systems, AI-Accelerated Delivery, Token Architecture, Agentic Prototyping, Design Infrastructure, Enterprise SaaS, Cross-functional Leadership

The moment it clicked

The thing about BetterCloud Fulcrum is that it was good. The component library was well-structured, the Figma file was clean, the design intent was documented. What it became, in practice, was the best prototyping library we’d ever had. Design sprints moved faster. High-fidelity concepts that used to take days took hours. For design, it was genuinely transformative. For engineering, it never existed. Not because they rejected it — there was no rejection, no debate, no principled objection. There was just no capacity to investigate it, plan a pilot, build an implementation strategy. Every team was already mid-sprint, already negotiating what was getting cut this cycle. BetterCloud Fulcrum never crossed the boundary into engineering not because it wasn’t ready but because the organization never had a quiet moment to receive it. What I learned: a design system that lives entirely on the design side of the boundary is a very powerful prototyping tool. It is not, yet, infrastructure. TVH Uplift had made it across the design-to-engineering boundary, which is what made its situation more instructive. Engineering teams were using it — inconsistently, without full confidence, in pockets rather than as standard practice. The Figma library and the codebase had drifted enough that developers weren’t sure whether following the system would introduce more problems than it solved. Some teams trusted it. Others built around it. The system existed in a state of partial adoption that was, in its own way, more telling than no adoption at all: it showed exactly where trust breaks down when a design system doesn’t have protected organizational ownership. Moving design system engineers under UX, co-designing governance with an engineering advocate, and giving the system genuine capacity is what stabilized it and earned it broader use. Uplift taught me that a design system needs the right home in the organization before it can fulfill what it was built to do. Both of those experiences were building something more like calibration than cautionary tales. By the time I got to Arcos, I understood two things clearly: a system that doesn’t cross into engineering isn’t infrastructure yet, and a system without protected ownership can’t hold its own trust. Harmony starts from both of those as solved premises. But there was a third problem neither system had ever had to answer, because it didn’t fully exist yet. The moment AI entered the delivery pipeline, the gap between what humans could read in a design system and what machines could actually execute against it stopped being theoretical. That’s the gap Harmony was built to close.

The diagnosis

AI is very good at moving fast and very bad at knowing what it doesn’t know, which causes a heavy problem in the design-to-dev pipeline that isn’t plumbed for it. Feed a model a Figma spec and it will produce code. Confidently. With the same small judgment calls a developer would make, except a developer can ask a question and a model will just pick. The handoff problem didn’t go away when AI showed up. It accelerated. At the same time, agentic coding was emerging fast enough that the question stopped being theoretical. Cursor. Copilot. Claude Code. Figma Dev Mode with AI assist. Every one of these tools is only as good as the context it can access, and the context most design systems were built to provide was designed for a human reader who could infer, interpret, and ask for clarification. A token named `color-feedback-warning` tells a developer something. It tells a model a label. A component documented with props and variants tells an engineer how to use it. It tells an agent the syntax. What neither of those provides is the thing that actually determines whether the output is right: the why. Why this token and not the similar one two rows up. Why this component and not the raw library element underneath it. Why this layout serves the user’s actual goal in this specific moment. {/* IMAGE: Token comparison — side-by-side showing the same token with name-only vs. with DTCG description carrying intent. Have: No — recreatable as SVG */} Vibe coding accelerated the urgency further. As more teams started reaching for AI-generated UI as a starting point rather than a finishing tool, the design systems field started confronting a problem it had mostly deferred: a system that can’t communicate intent to a machine isn’t infrastructure anymore. It’s a reference document. Useful. Not load-bearing. What had to be true for Harmony to work was that intent had to be legible at every layer of the chain. Not implied by naming conventions. Not written in a Confluence page somewhere. Encoded, structured, and delivered into the agent’s working context at the moment the agent was making decisions. Token descriptions that carry the why and the when, not just the what. Component documentation grounded in user need and goal, not just interaction states and prop tables. Feature-level user intent flowing in from the design spec, scoped to the specific thing being built right now. And underneath all of it, a set of agents that don’t just assist but enforce: catching a developer reaching for raw MUI when a Harmony component exists, validating built output against the design spec before it ships. That’s a different kind of design system than the field has mostly been building. It’s also, given where agentic coding is going, the only kind that will still matter in two years.

The vision

The argument I needed to make at Arcos wasn’t that we should build a design system. Most organizations agree to that in principle and then never give it the protected capacity it needs. The argument was something more specific and harder to land: we needed to build a design system that treated AI agents as a primary consumer alongside humans. Not a downstream beneficiary. A first-class reader. _Figure: Solar system diagram with Harmony Design System at the center. Three orbiting bodies represent the three audiences: UX connected to Figma and design principles, Engineering connected to npm and the codebase, and AI Agents connected to context and tokens. Text reads: Three audiences. One vocabulary. The system speaks all three._ That sounds simple stated cleanly. It wasn’t simple to advocate for in 2025. Most of the design systems conversation was still focused on tokens and components: the shapes and values, the Figma file, the component library structure. The deeper bet I was making was that within the next two years, the question every design system would be asked is not “is it well-organized for designers” but “can an AI agent build accurately against it without supervision.” That’s a different brief. It changes what gets documented, where the documentation lives, how it’s structured, and who else has to be in the room while it’s being designed. The case I built had three parts. The first was cost: every investigation sprint, every correction loop, every revision cycle was a tax on velocity that would only get worse as AI accelerated the noise. The second was quality: a system that lets a model guess produces code that drifts from intent in ways nobody catches until QA, or worse, until production. The third was strategic: companies that built design infrastructure for the agentic era would compound their velocity advantage every quarter; companies that didn’t would discover that “AI is making us faster” wasn’t quite the same thing as “AI is making us better.” Arcos couldn’t afford to be in the second group. Getting that argument heard required building coalition before building anything. Individual developers came on board first. They were paying the highest cost for the existing handoff and saw the relief most clearly. Product leadership followed, because faster validated direction is something product organizations universally want when they can get it. Tech leadership was the harder room, and the conversation there is still ongoing. Their concerns about codebase ownership, accountability, and what “UX-generated code” actually meant inside an engineering org were legitimate questions that deserved careful answers, not workarounds. What I cared about more than full alignment on day one was shared direction. We agreed on the vision. We agreed on the path. We started moving together. Big ideas like this don’t land in a single meeting and they shouldn’t. What matters is whether the people in the room are negotiating in good faith toward the same outcome and whether the work is visibly making progress against the shared frame. That’s the kind of alignment I optimize for. It’s slower in the first month and dramatically faster everywhere after that. _Figure: Alignment map showing three stakeholder groups on a spectrum from skeptical to aligned. Individual developers sit at partial buy-in, asking 'Will this displace me, or amplify me?' Tech leaders and managers are in partial buy-in with conversation ongoing. Product leadership is aligned._

The approach

The architecture had to do something unusual: communicate the same design intent at three different levels of abstraction, to three different consumers, in three different formats. Tokens needed to carry their own meaning at the value level. Components needed to carry their own meaning at the system level. Features needed to carry their own meaning at the user-goal level. And all three layers needed to be machine-readable in a way that flowed naturally into the agent’s working context — not requested, not retrieved, just present. _Figure: Architecture diagram of Harmony showing two lanes. The UX lane connects Figma as the source of truth through Code Connect to the Harmony npm package. The Dev lane connects Zeplin MCP for feature-scoped build context and Storybook MCP for component documentation. The Harmony npm package is published to AWS CodeArtifact at the center. An AI enforcement layer runs underneath both lanes._ The chain we built starts with the tokens. Harmony uses DTCG format because the standard is open, the tooling is mature, and the description field is structured. Every token carries a written description of why the value exists and when to use it versus a similar token. The names are still semantic, which solves the human readability problem, but the descriptions carry the layer of meaning a name can’t, the layer that determines whether a model picks the right token for the right reason instead of the closest syntactic match. From the tokens, the system builds upward: components in the Harmony npm package, published to private AWS CodeArtifact, consumed by engineering as a versioned dependency. Figma library components mapped to their TypeScript implementations through Code Connect, so the source of truth and the implementation can’t drift apart silently. Storybook running against the published npm, documenting component purpose grounded in user need rather than just interaction states. _Figure: Full system architecture diagram of Harmony. On the left, the Figma library feeds into a DTCG JSON token file and the Harmony npm package, which publishes to AWS CodeArtifact. Two lanes branch from there: a UX lane running Figma MCP for source-fidelity authoring and governance, and a Dev lane running Zeplin MCP for feature-scoped design context, a JIRA AI skill for kickoff automation, Storybook MCP for component documentation, and a Developer Build Environment. Underneath the full chain runs an enforcement layer covering accessibility spec validation, design spec review, component enforcement, and sync spec checking._ The architecture you see now isn’t the one I first drafted. My initial approach was to consume MUI components, override each one with a theme provider, and export the new component — so engineering would import `Button` from Lighthouse-web instead of from MUI, and UX would own the entire visual layer end to end. The argument for it was clean: total UX control over the rendered component. The argument against it became clear as soon as I worked through the implications. Owning components meant owning MUI version updates, owning bug fixes that originated in MUI, owning every regression that surfaced when MUI released a breaking change. UX didn’t have the engineering capacity for that. We don’t have dedicated React developers the way the design system org at TVH did, and committing to it would have created a dependency UX couldn’t honor. So I pivoted. Instead of consuming and overriding components, Harmony provides themes — detailed token sets and implementations delivered through MUI’s ThemeProvider, layered on top of unmodified MUI components. UX controls the visual layer through tokens and theme configuration. MUI handles the component layer. The architectures stay cleanly separated, and the system has a safety property that the original approach didn’t: if Harmony fails to load for any reason, MUI falls back to its defaults and the software still works. Nothing catastrophic depends on UX-owned infrastructure. That separation of concerns is what made the system safe enough to ship to production in pilot, and it’s what made tech leadership’s concerns about codebase ownership easier to address, because UX wasn’t claiming ownership of anything we couldn’t sustainably own. The agent layer is where the architecture closes. Two MCP servers, each scoped to a different consumer. Designers work in Figma MCP, with full source fidelity, used for authoring, governance, and system updates. Developers work exclusively in Zeplin MCP, which delivers feature-scoped design context and user intent annotations directly into the build environment. The split is deliberate. Designers need access to the source. Developers need the right information for the build in front of them, scoped to the feature, at the moment of implementation. Storybook is also MCP-enabled in pilot, so component purpose and user-goal documentation flow into the agent’s context alongside the feature spec. The kickoff itself is automated: an AI skill pulls the JIRA ticket that defines the feature, pairs it with the relevant Zeplin design context, and generates a build plan before a human opens VS Code. Underneath all of that runs a suite of AI agents and skills that don’t just assist but enforce. UX uses agents for design system governance and updates. Two development pods are piloting agents that run accessibility validation, review code against the AI-generated design spec, and catch developers reaching for raw MUI components when a Harmony equivalent exists. The system isn’t asking developers to follow it. It’s making the wrong path visible at the moment they take it. That’s the difference between a design system that works through persuasion and one that works through architecture. Harmony was built to be the second kind.

Building credibility

The pilot couldn’t run on my work alone. Three senior designers had to be genuinely capable inside the delivery model — not watching me demonstrate it, not rubber-stamping artifacts I produced, but authoring inside the same toolchain with the same fluency. Two weeks of training and environment setup got them into VS Code with Claude Code CLI. That’s a real ask for experienced designers who’d never opened a terminal, and they showed up for it. One senior designer went deeper, partnering with me on the token architecture and helping establish the external JSON file as the canonical source of truth for Harmony’s token layer. The model holds because the team can run it without me, not because I’m the only one who can. Engineering credibility came from the work being legible to engineers on its own terms. When the first higher order components (HOC) shipped from UX into the Control Tower codebase, the question wasn’t whether they looked right. It was whether they’d be reviewable, trustable, and mergeable by engineers who hadn’t built them. They were. The HOCs lived in the same repository as the production code, used the same vocabulary engineering already used, and arrived through the same dependency channels as any other internal package. None of this asked engineering to take anything on faith. The artifacts spoke for themselves. The sharpest proof of the architecture’s legibility came from somewhere I hadn’t planned. The mobile pod, which was never part of the original delivery model rollout — no training, no onboarding, none of the two weeks the pilot designers went through — connected the Zeplin MCP into their own Claude Code workflow during a planning session, using it to visualize shaping outcomes mid-discussion. They also built a UX Designer agent trained on our team’s documented ways of working, using it as a behavioral frame for a model that now operates inside their own delivery workflow. Nobody onboarded them. They read the same architecture the pilot pods were using and extended it on their own. That’s a different kind of evidence than a pilot metric: it’s proof the system is legible enough to hold up without me — or anyone from the original rollout — in the room.

What shipped

The honest inventory matters here, because the case isn’t “we built a complete system in nine months.” The case is that we built it in the right order, and each piece unlocked the next. Some of the chain is in production. Some is launched and instrumenting. Some is architecture-enabled and being evaluated. All of it was sequenced deliberately. **In production.** The Zeplin MCP is active across planning and initial build, delivering feature-scoped design context and user intent annotations into the agent’s working environment at the moment developers need them. The AI skill that orchestrates Zeplin and JIRA at kickoff is generating build plans against tickets before a human opens VS Code. What used to be a two-week investigation sprint is now an artifact produced in minutes. Storybook has been live on Chromatic since April 2026 with tokens and core components, importing the actual Harmony npm including the MUI dependency and the Harmony theme. UX is running AI agents and skills for design system governance and updates as part of normal operating practice. **Launched and instrumenting.** The Harmony npm package was published to AWS CodeArtifact in March 2026 and installed as a dependency in the Control Tower web pilot, where existing production code is being refactored against the new token and theme layer. Figma Code Connect just shipped, built using Figma MCP and Claude Code CLI, connecting every Figma library component to its TypeScript implementation in the npm. The pilot is the validation mechanism, not a delay. We’re learning how the model performs against real delivery cycles before scaling it. **Architecture-enabled, evaluating.** The Storybook MCP is in pilot with two Control Tower web pods, who are assessing accuracy and trustability against their actual feature work. A subset of the agent suite has been deployed in those same two pods for accessibility testing, code review against the AI-generated design spec, and component enforcement: catching developers reaching for raw MUI when a Harmony component exists. Chromatic visual regression is under evaluation by QA now that Storybook is live with the npm and the regression target is real. The pattern is intentional: foundation first, then chain, then enforcement. Storybook MCP couldn’t pilot until Storybook was live with the npm. Code Connect couldn’t ship until the npm existed. Chromatic only becomes meaningful once Storybook imports the actual Harmony dependency. Every layer needed the layer underneath it to be solid before the next one could be tested honestly. What’s in pilot is in pilot because that’s where the work is right now, not because it stalled.

The larger argument

The thing I most want you to take from this case is that design systems are no longer documentation projects. They’re infrastructure for a build environment in which AI agents are first-class participants. The systems that treat agents as primary consumers will compound velocity and quality every quarter. The systems that don’t will discover that AI’s speed advantage was never the same thing as a quality advantage. Harmony is the design systems equivalent of a compiler. Tokens and components define a constrained execution environment. Intent descriptions, MCP-enabled documentation, and enforcement agents make accurate output the path of least resistance. The system doesn’t ask developers to follow it. It makes the wrong path visible at the moment they take it. Where this architecture goes next is in three directions, each one building on what’s already in place. The intent layer wants to go deeper. Code Connect just shipped, and the richer version of this architecture has every component carrying an explicit machine-readable contract that an agent can reason about, not just match against. The enforcement layer wants to scale beyond the two pilot pods, with the right tuning for different team contexts, and to evolve from validation toward something closer to active collaboration with the developer during the build itself. And the pattern itself wants to become portable. What we built at Arcos for one product is the same architecture that scales to multi-brand and multi-platform systems, and the next maturity step is making it transferable rather than bespoke. The companies that get this layer right in the next two years are going to compound advantages that everyone else spends a decade trying to catch.
## The Handoff Is the Bug - Subject: Arcos, Inc - Role: Head of UX, Arcos, Inc - Timeline: Aug 2025 – Jul 2026 - Canonical URL: https://jason.sonderman.info/case-studies/arcos-handoff-is-the-bug/ - Markdown: https://jason.sonderman.info/case-studies/arcos-handoff-is-the-bug.md At Arcos, design specs were thorough but not executable — developers made hundreds of small judgment calls per feature, and AI entering the pipeline automated the ambiguity instead of solving it. I built Harmony as a context-rich npm package paired with Storybook and Zeplin MCPs, giving UX, engineering, and AI a shared design language. Kickoff compressed from two weeks to three days; a testable coded concept now takes 12 hours instead of ~40. **Key outcomes:** - Kickoff & handoff: 3 days (Down from 2-week investigation sprint) - Time to market: ~30% faster (Across piloted delivery cycles) - Revision cycles: Nearly eliminated (See-build-review-change loops) - Testable coded concept: 12 hours (Down from ~40 hours for a wired Figma prototype) Jason restructured the design-to-dev handoff at Arcos by building Harmony as a shared design language for UX, engineering, and AI agents, then moving the UX team into VS Code to author production-adjacent front-end code against it — compressing kickoff from a two-week investigation sprint to three days. **Facts:** - Kickoff and handoff: 3 days, down from a 2-week investigation sprint - Time to market: ~30% faster across piloted delivery cycles - Testable coded concept: 12 hours over 3 days, versus roughly 40 hours for a wired Figma prototype covering the same scope - Front-end story completion time (self-reported): 5–6 days down to 2–3 days, driven by earlier high-fidelity design work, detailed Zeplin annotations on user type and behavior, and tight Zeplin/Figma/Code Connect/Storybook linkage letting engineers pull design intent directly via the Zeplin and Storybook MCPs. Sample/period not confirmed to match the three Control Tower pilot cycles behind the other delivery metrics above — a related but separately-scoped signal, not a fifth data point on the same sample - Artifacts shipped: Harmony npm package (March 2026), Zeplin MCP in development use (March 2026), Storybook on Chromatic (April 2026), simultaneous Zeplin and Storybook MCPs in VS Code, and an agentically generated Design Implementation Spec the designer reviews rather than authors - Team enablement: Two weeks of training moved all three senior designers into VS Code with Claude Code CLI; one Senior Designer co-refined the token sets and established the external JSON file as Harmony’s canonical token source - Stakeholder alignment: Individual developers and Product leadership bought in; Tech leaders and managers are partial, with a pilot running — their stated concern is code quality and codebase ownership **Scope:** The metrics come from three delivery cycles on Control Tower — early signal from one platform, not a company-wide result. The formal code review and merge process for UX-authored Higher Order Components is not codified yet; what changed is that Tech leadership moved from asking whether UX should produce code at all to asking what the review process looks like. Pair with the Harmony case study for the token architecture underneath this pipeline, and with TVH Uplift and BetterCloud Fulcrum for the two earlier design systems whose adoption lessons shaped it. **Team:** 3 Senior Designers, 1 UX consultant

The Moment It Clicked

Early in the project, we made an assumption that felt almost too obvious to question: clinicians resisting EMR adoption were resistant because they didn’t understand the system. The answer, then, was clarity. Give them a full picture of the learning path — how many modules, how much time, how it all fits together. Show them the journey. Reduce the unknown. We built a prototype around that idea. It mapped the complete learning arc: a visual timeline, estimated hours per section, a progress meter that showed how far they had to go. We thought seeing the whole thing would reduce anxiety. We thought transparency would build confidence. The testing told us we had it exactly backward. Learners looked at the complete journey view and froze. Not metaphorically — they stopped clicking. They stopped talking. A few said versions of the same thing: *I don’t have time for this.* One nurse said she’d rather just figure it out on the floor. The visualization we’d built to reassure people was, instead, turning a manageable task into an impossible one before they’d done anything at all. That was the moment the real design problem came into focus. This wasn’t a training problem. It was a change management problem — and the tools we’d been drawing from weren’t built for this population. {/* IMAGE: What: Side-by-side comparison of the full-journey visualization prototype vs. the enumerated-step model tested in the same session Why: Shows the specific design decision concretely — the "before" that failed and the direction that worked — without requiring reading Alt: Two learning journey UI prototypes side by side: on the left, a timeline visualization showing all steps and hour estimates; on the right, a simple enumerated step list showing only current and completed states Have: yes — /case-study-images/ProgressionTests-80-1.jpg */} ![User testing visualization comparison: full-journey timeline view versus enumerated step view with locked, current, and complete states](/case-study-images/ProgressionTests-80-1.jpg)

The Diagnosis

To understand why that matters, you have to understand what was actually happening in hospitals in 2014. The ACA’s “meaningful use” mandate had set a hard deadline: healthcare providers had to demonstrate meaningful use of certified EMR systems or face financial penalties. This wasn’t a product rollout where users could opt in gradually. Adoption was compulsory, the timeline was externally imposed, and the workforce being asked to adopt had neither requested the change nor designed the workflows that resulted from it. Organizational change management frameworks — ADKAR, Kotter’s 8-step, Prosci’s methodology — were well-established by then. But they’d been developed and refined primarily for enterprise software rollouts: voluntary or at least internally-mandated migrations, with reasonably flexible timelines, in workforces where directed learning was a normal part of professional life. Clinicians are different. Their professional identity is bound up in demonstrated competence, not certified completion. A physician doesn’t think of herself as someone who completes training modules — she thinks of herself as someone who already knows how to do her job. An LMS built on corporate learning patterns asks that person to temporarily occupy the position of student, and the resistance that produces isn’t irrational. It’s a defense of professional identity. Add to that the structural reality: hospital workflows have almost no slack. There’s no “training time” carved out of a shift. Learning has to happen in the margins — between patients, before rounds, during whatever quiet moments exist. The existing playbook assumed learners had time and motivation. These learners had neither. What had to be true for a solution to work: the system couldn’t feel like a learning management platform. It had to feel like a tool for getting competent quickly. Those are different experiences with different designs. {/* IMAGE: What: Annotated diagram showing the gap between enterprise OCM model assumptions (voluntary, time-flexible, motivated learners) vs. clinical reality (compelled, time-scarce, identity-defensive) Why: Makes the diagnostic argument visual — shows why the standard playbook failed before the alternative is introduced Alt: Two-column diagram comparing enterprise OCM assumptions with clinical workflow realities, highlighting gaps in assumed learner time, motivation, and choice Have: no — recreatable as a simple two-column comparison diagram */}

The Vision

Cerner’s learning team had already arrived at a useful concept before I joined: *journeys*. Targeted, sequenced learning experiences designed to build competency incrementally on a specific topic. Not a course catalog. Not a curriculum. A path with a clear beginning and end, scoped to what someone in a specific role actually needed to know. The journey concept was right. What it needed was a design philosophy that matched the population. My read, after the user testing: the existing OCM frameworks needed to be adapted, not abandoned. ADKAR’s awareness-desire-knowledge-ability-reinforcement model still applied — but the sequencing had to be compressed, and the design had to work against the learner’s instinct to assess the total ask before committing to any of it. The journey view had to withhold scale deliberately. Show the next step. Make it completable. Let the learner discover the journey is manageable by doing it, not by being told. The enumerated-step model that emerged from testing was counterintuitive enough that it needed defending. Stakeholders and learning designers had built the original vision around visibility and transparency — *learners should understand what they’re getting into.* I had to make the case that what learners needed to feel capable wasn’t a complete picture of the path, but evidence that the first step was achievable. That’s a different argument than “simpler is better.” It’s a claim about how professional identity and motivation interact when learning is compelled rather than chosen. That argument held, and it shaped every subsequent design decision about information architecture, progress indicators, and how we structured the content management tools that administrators used to build journeys. {/* IMAGE: What: Early concept sketch or whiteboard diagram showing the journey architecture — role-scoped, sequenced steps with gated progression Why: Shows the strategic vision concretely — journey as a scoped competency path rather than a course catalog Alt: Whiteboard or concept sketch showing a learning journey as a linear sequence of role-specific steps with gated progression between stages Have: no — recreatable from lo-fi artifacts */}

The Approach

The testing finding shaped two parallel design tracks: the learner-facing journey experience and the administrator content management system. For learners: enumerated steps with three states — locked, current, complete. No time estimates. No completion percentage relative to the full journey. Progress feedback was local: *you finished this step.* The system validated momentum rather than measuring distance to a destination. Each step built on the previous one by design — we worked with the learning design team to structure content atomically, smallest conceptual units first, so that competence accumulated in a way that felt earned rather than assigned. For administrators: building a journey required assembling discrete content objects in sequence, which meant the content management tool had to support a fundamentally different workflow than a standard LMS course builder. I produced low-fidelity flows for the manager interface first, before any learner-facing screens — partly because the admin tool had to ship before the user-facing app could be populated, but mostly because the integrity of the learner experience depended on journey architects understanding what they were constructing. If the admin tool made it easy to dump content in without considering sequence and dependency, learners would end up with broken journeys regardless of how well the front end was designed. The transition from lo-fi to medium fidelity happened faster than I would have liked — engineering timelines compressed the iteration window — but we’d done enough testing on the core navigation model that the wireframe phase was mostly about refinement, not discovery. The decision to leverage existing design system elements aggressively, rather than introducing new components, was deliberate: it kept the learner experience visually familiar within Cerner’s ecosystem and reduced engineering risk at a point where we had little schedule margin left. {/* IMAGE: What: Low-fidelity admin journey builder wireframes showing the atomic content sequencing workflow Why: Shows the parallel-track strategy and the reasoning behind building admin-first — the admin tool's structure determined the learner experience's integrity Alt: Low-fidelity wireframe flows for the journey builder admin interface showing how content objects are sequenced into a learning journey with dependency relationships Have: yes — /case-study-images/Journey-Builder-Wires-80.jpg */} ![Journey builder admin interface wireframes showing the atomic content sequencing workflow and dependency structure](/case-study-images/Journey-Builder-Wires-80.jpg) {/* IMAGE: What: Medium-fidelity learner-facing wireframes showing enumerated steps with locked, current, and complete states — no global progress or time indicators visible Why: Shows the specific three-state navigation model that emerged from testing — the design decision made concrete Alt: Medium-fidelity wireframes for the learner-facing journey interface showing numbered steps with three visual states: locked steps grayed out, current step highlighted, completed steps marked as done Have: yes — /case-study-images/JournyUserWires.jpg */} ![Learner-facing journey wireframes with enumerated steps in locked, current, and complete states — no timeline view or total duration estimate visible](/case-study-images/JournyUserWires.jpg)

Building Credibility

The hardest stakeholder conversation wasn’t about the design. It was about the philosophy behind it. Cerner’s learning team had spent considerable time and energy on the journey concept. They believed in transparency — in giving learners a complete view of what they were taking on. The user testing that contradicted that belief was well-run and unambiguous, but it challenged an assumption that had been organizational consensus. I wasn’t presenting findings to a neutral audience; I was presenting findings that required people to let go of something they’d built. What made that conversation work was the specificity of the finding. This wasn’t “users prefer simpler interfaces” — that’s easy to dismiss as a preference. This was *learners looked at complete journey visualizations and stopped engaging entirely.* The behavioral data was concrete enough that it was harder to rationalize away. And because we’d tested multiple visualization approaches — not just the full-journey view versus the step view, but several variations of each — the recommendation came with evidence that the direction mattered more than any specific implementation. The clinical leadership on the team was actually the most receptive audience. They understood immediately why a nurse seeing 14 hours of required training before a shift would close the browser. That credibility made the design argument easier to prosecute with the learning design and engineering stakeholders who had more invested in the original concept. {/* IMAGE: What: Research summary or presentation artifact showing the behavioral testing findings — specifically the contrast between engagement in full-journey vs. step view sessions Why: Shows the rigor behind the counterintuitive recommendation — evidence concrete enough to shift organizational consensus Alt: Research findings summary showing user testing behavioral observations comparing engagement levels across full-journey visualization and enumerated-step design variants Have: no — consider creating a sanitized version of the testing findings summary document */}

What Shipped

The Cerner Learning Journey Portal launched as a modified LMS combining targeted courses into discrete, sequenced experiences. The learner-facing interface delivered journeys as enumerated steps with completion indicators — no timeline view, no total-duration estimate. Administrators built journeys through a content management platform designed around atomic content sequencing, with the manager tool preceding the learner-facing app in the release order. The platform rolled out across 253 client implementations. Per Cerner’s internal client reporting, measured software competency through training improved 48% compared to prior training approaches. Users reported recovering roughly 26% of the time that had previously been consumed by onsite training and bulky learning programs — which, given that “no time for training” was the foundational constraint the entire design was built around, felt like the most honest validation we could have received. That time recovery number is the one I’d point to first with a skeptical stakeholder. It’s not a satisfaction score. It’s evidence that the design premise held: if you build learning to fit the margins of a clinical workflow rather than asking clinicians to create margins that don’t exist, the math changes. The mandate that had seemed to doom adoption instead became a catalyst — learners who completed journeys reported feeling more capable rather than simply more compliant. Some progressed beyond basic competency and became learning leaders within their facilities, supporting colleagues navigating the same transition. That last outcome — clinicians who started as reluctant mandatory participants and ended as voluntary advocates — was the signal that the design had achieved something beyond compliance. It had shifted how those people related to their own competence. That’s a different result than adoption metrics. It’s what happens when the design is built around professional identity rather than course completion. {/* IMAGE: What: Final production screens of the learner-facing portal showing the enumerated step navigation model in a real journey Why: Connects all the design decisions to a concrete shipped deliverable — lets skimmers see what strategic opacity looks like in practice Alt: Production screenshots of the Cerner Learning Journey Portal showing a learner's active journey with numbered steps, step completion status indicators, and a current step in progress — no total journey timeline or duration estimate visible Have: yes — /case-study-images/lj-final-screens.jpg */} ![Final Cerner Learning Journey Portal production screens showing the enumerated step navigation model — no total journey scope or time estimate displayed](/case-study-images/lj-final-screens.jpg)

The Larger Argument

When adoption is mandated rather than chosen, the designer’s job isn’t to make learning easier. It’s to make the learner feel capable. Those are different problems with different solutions. Making learning easier is an information design problem: reduce cognitive load, improve navigation, clarify instructions. Making someone feel capable is a psychological problem: sequence experiences so that evidence of competence accumulates before the scale of the task becomes visible. The first problem is solved by clarity. The second is sometimes solved by strategic opacity. The existing OCM playbooks didn’t make that distinction because they were built for contexts where learners had a choice — where motivation could be developed, where adoption could be gradual. Healthcare EMR adoption in 2014 had none of those affordances. It required a different theory of change, and getting to that theory required testing assumptions that the client’s internal team had treated as foundational. That’s a pattern I’ve returned to across different domains: the most important design work is often the work of identifying which assumptions are load-bearing and which aren’t. The journey concept was load-bearing. The transparency assumption wasn’t. Knowing the difference is what made the project work. {/* IMAGE: What: Conceptual two-column diagram — "Making learning easier" (information design tactics) vs. "Making the learner feel capable" (psychological sequencing tactics) Why: Externalizes the meta-level insight in scannable form — makes the larger argument accessible to a reader who skips the prose Alt: Two-column diagram comparing information design tactics for making learning easier on the left with psychological sequencing approaches for building learner capability on the right Have: no — simple diagram, recreatable */}
## BetterCloud Secure: Redesigning Risk Remediation for IT Teams - Subject: BetterCloud Secure Platform - Role: Lead Product Designer, BetterCloud - Canonical URL: https://jason.sonderman.info/case-studies/bettercloud-secure-elevate/ - Markdown: https://jason.sonderman.info/case-studies/bettercloud-secure-elevate.md As Lead Product Designer, I led persona research, workshop facilitation, and prototyping to transform BetterCloud’s Secure platform from passive monitoring to active risk remediation. Three core capabilities — Quick Actions, Risk Lifecycle Tabs, and Universal Action Properties — tested well before a strategic shift shelved the product. The Figma design system built to support the work outlasted it, becoming platform infrastructure that cut prototype time across the team. **Key metrics:** - Task accuracy: 68% → 82% (Correct bulk-remediation action selection across 13 users, alpha builds 1–7 (Apr–Oct 2022)) - Capabilities designed: 3 (Quick Actions, Risk Lifecycle Tabs, Universal Action Properties — validated in design-sprint and alpha-build testing, never shipped to production) - Design system: Outlasted the product (Became platform infrastructure, cut prototype time across the team after strategic pivot) As Lead Product Designer, Jason led persona research, workshop facilitation, and prototyping to redesign BetterCloud’s Secure platform from passive risk monitoring into active remediation — three tested capabilities were shelved before full implementation following a company strategic shift. **Facts:** - Audit: 86 potential remediation actions identified across 5 applications - Capabilities designed: Quick Actions, Risk Lifecycle Tabs, Universal Action Properties — all tested well with users - Testing program: 4 design sprints and 7 alpha builds, April–October 2022, tested with 5 external customer-partner companies, internal professional services staff, and IT admin users - Task accuracy: 68% → 82% correct bulk-remediation selection across 13 users, alpha builds 1–7 - Time to perception: New users averaged 3.8s (target: 3s); returning users found key actions in under 1s. Blended across 7 design-sprint users and 10 alpha-build users, April–October 2022 — two testing methodologies, not one controlled sample. - Outcome: Full implementation was shelved at the alpha stage due to budget constraints and a strategic shift in company market focus — the product never reached beta or production - Lasting artifact: The Figma design system built to support the work outlasted the shelved product and became platform infrastructure **Scope:** The redesign tested well but never shipped to production — stated plainly in the case study; don’t imply it launched. The Universal Actions ~70% action-reduction figure is a projection from user interviews, never measured in production; don’t cite it as a measured result. **Team:** Product Design, Product Management, Product Operations, Front-end Engineering, Full-stack Engineering **Contributions:** Persona Creation, Workshop Facilitation, User Research, Sketches, Task Flows, Figma Prototyping, User Testing, Planning, Stakeholder Alignment, User Advocate **Tools:** Miro, AHA!, Figma, UserTesting.com, JIRA **Tags:** Design Systems, Enterprise SaaS, User Research, Cross-functional Leadership BetterCloud is a SaaS management product that enables IT teams to maximize efficiency through automating manual tasks and enforcing company security policies. BetterCloud was undergoing a strategic effort to redesign the existing experience for the Secure platform. I worked as the Lead Product Designer on the team, leading the design process and defining the experience’s ‘remediation’ journey. ### Setting the Stage: The Challenge Before Us In the fast-paced world of SaaS management, BetterCloud had already made a name for itself. Our platform was the go-to solution for IT teams looking to automate manual tasks and enforce company security policies. But in the realm of cybersecurity, standing still means falling behind. We faced a critical challenge: our customers needed the power to mitigate security risks in real-time, preventing data breaches before they could occur. Our existing Secure platform allowed users to discover and monitor exposed data, but it lacked a crucial capability – the ability to resolve these risks swiftly and effectively. As the Lead Product Designer, I found myself at the helm of an ambitious project. Our mission? To redesign the Secure platform, transforming it from a passive monitoring tool into an active guardian of sensitive data. ![Legacy Secure platform remediation options screen](/case-study-images/bettercloud-secure-oldstate-options.jpg) ### Discovery: Bringing Our Users to Life Our journey began not with wireframes or prototypes, but with people. Real people, with real challenges and aspirations. We had a wealth of data at our fingertips – hundreds of user interviews and support calls. But data alone doesn’t tell a story. Working hand-in-hand with our Business Intelligence team, we sifted through this treasure trove of insights. Slowly but surely, patterns emerged. We weren’t just looking at numbers; we were uncovering the hopes, frustrations, and needs of our users. That’s when the magic happened. We transformed these insights into living, breathing personas. We crafted detailed actor sheets, complete with goals, quotes, and even imagined workspaces. These weren’t just profiles on a page – they were the characters in our product’s story. These personas became our guiding stars, ensuring every decision we made was grounded in real user needs. ![Persona cards created from user research](/case-study-images/bettercloud-secure-persona-stack.jpg) ### Mapping the Current State: Understanding the Journey With our personas by our side, we dove into the existing Secure platform. We put ourselves in our users’ shoes, navigating through the process of identifying and addressing security risks. The journey was eye-opening. Users could view their assets – files and folders shared across their organization – and identify potential risks. But when it came to taking action, they hit a wall. The platform presented a dizzying array of remediation steps, often leaving users unsure of the best course of action. Through a painstaking manual audit, we uncovered a staggering 86 potential actions across just 5 applications. It was clear: we needed to simplify without sacrificing functionality. ### The Design Sprint: Where Ideas Take Flight Armed with our insights, we launched into a design sprint. Picture a room buzzing with energy – designers, product managers, and customer-facing roles all coming together to tackle our challenge head-on. ![Design sprint whiteboard ideation session](/case-study-images/bettercloud-secure-designsprint-whiteboards.jpg) We set an ambitious goal: Guide users to quickly remove 100% of risks. But we also acknowledged the hurdles. How could we ensure the right action for all users? How could we balance bulk actions with digestible steps? Through story mapping and rapid sketching, ideas began to take shape. Each team member brought their unique perspective, resulting in a rich tapestry of potential solutions. ![Early design sprint sketch concepts](/case-study-images/bettercloud-secure-designsprint-sketches.jpg) ### From Sketch to Screen: The Prototype Emerges As the Lead Product Designer, my role shifted into high gear. I led the charge in transforming our storyboards into a clickable prototype. We divided and conquered, with each designer taking ownership of a section while I ensured consistency across the entire journey. ![Storyboard for remediation journey prototype](/case-study-images/bettercloud-secure-designsprint-storyboard.jpg) ![Risk remediation task flowchart](/case-study-images/bettercloud-secure-risk-flowchart.jpg) The clock was ticking – we had users scheduled to review our work. But as the prototype came together, excitement built. We were creating something that could truly transform how our users approached security risks. ### Key Features: The Heart of Our Solution Our design sprint yielded three core features that would redefine the Secure platform experience: **Quick Actions:** A streamlined interface allowing users to take the correct action to secure their risk with minimal clicks. **Risk Lifecycle Tabs:** A visual representation of the user’s security landscape, showing current risks and successfully remediated issues at a glance. **Universal Action Properties:** A consistent interface for configuring action properties across different asset types and applications, reducing cognitive load on our users. ### Refining Our Vision: From Idealism to Reality The design sprint had given us a bold vision, but now came the crucial task of grounding it in reality. I worked closely with our Product Manager and architects, mapping out the technical feasibility of our ideas. We identified ‘chunks’ – what would later become our development epics – that would allow us to build iteratively towards our end goal. It was a delicate balance, preserving the high-value capabilities while ensuring we didn’t overextend our technical resources. ### Putting the Prototype in Front of Users From April to October 2022, we ran four design sprints and built seven alpha versions of the interface, testing each one before moving to the next. Five external customer-partner companies took part — two to three system admins per company — working through specific tasks with us: finding files, bulk-securing files, setting notifications, and walking through their existing remediation process outside our tool. Internal professional services staff, who support customer setup, tested alongside them. Between sprints, two to three IT admin users sat with us each week to react directly to the Figma prototype. The three capabilities held up under that testing. The redesigned flow gave users: #### A comprehensive view of all current risks, allowing users to prioritize their actions effectively. ![Alpha-build file remediation interface](/case-study-images/bettercloud-secure-final-fileremediation.png) ![Alpha-build Secure dashboard showing risk overview](/case-study-images/bettercloud-secure-final-dashboard.png) #### Streamlined, universal action properties that worked consistently across applications, reducing confusion and errors. ![Alpha-build universal action configuration screen](/case-study-images/bettercloud-secure-final-configure.jpg) #### A clear Risk Lifecycle view, enabling users to track their progress and audit their security actions over time. ![Alpha-build risk lifecycle status view](/case-study-images/bettercloud-secure-final-risklifecycle.jpg) Two numbers came out of that testing, tracked in aggregate by our product manager. Against a 3-second target for how quickly users could perceive and act on a key task, new users averaged 3.8 seconds; returning users found the same actions in under a second, often clicking before we’d finished explaining the task. That figure blends two different testing methods — seven design-sprint users on the Figma prototype and ten alpha-build users on the built feature, with some overlap where sprint testers came back for alpha retesting — so treat it as two data sources merged into one directional read, not a single controlled sample. Task accuracy showed a clearer trend. Early testing on tasks like selecting 50+ files and choosing the correct bulk remediation action found a 68% success rate, with most failures coming from misclicks. That climbed to 82% by alpha build 7, across 13 users total tested between April and October 2022. ### Learnings: Unexpected Turns and Silver Linings While our redesigned Secure platform tested extremely well with users and generated real excitement among the partner companies who tried it, the project ultimately took an unexpected turn. Due to budget constraints and a strategic shift in the company’s market focus, the project was shelved in October 2022 after seven alpha builds — before it reached beta or production. Not everything held up under testing. Data-refresh performance never met the mark: our target was under 50 seconds for infinite-scroll file loading — the same number users independently named as their own expectation — but the best we achieved was on-request-only refreshes averaging two to four minutes to download, cache, and rehydrate. We never solved it before the project was shelved. Universal Action Properties was designed to collapse the 86 actions we’d audited into a much smaller, reusable set of interaction patterns. User interviews suggested roughly a 70% reduction in the number of distinct actions someone would need to learn — but that number is a projection from interviews, not a measured result. The feature never shipped, so it was never tested in production. However, in the world of UX, no effort is ever truly wasted. The insights we gained and the problem-solving processes we developed during this project proved invaluable as the company pivoted to its new focus. Our team’s ability to rapidly ideate, prototype, and test solutions became a model for future projects across the organization. Perhaps the most tangible legacy of our work was the creation of a highly effective Figma Design System library. This comprehensive resource allowed our UX designers to create extremely high-fidelity prototypes for most tools in our platform. What once took weeks now could be accomplished in days, dramatically accelerating our ability to move from initial idea to user testing. In the end, while the Secure platform redesign didn’t reach full implementation, it left an indelible mark on our design processes and capabilities. It served as a powerful reminder that in the fast-paced world of technology, adaptability and learning are just as crucial as the end product itself. The skills we honed and the systems we built continue to drive innovation and efficiency across our design teams, ensuring that BetterCloud remains at the forefront of user-centered design in the SaaS management space. ## Athens State Online: A Microsite Built for Graduate Enrollment - Subject: Athens State Online Degree Microsite - Role: Lead UX Designer, Archer Education - Canonical URL: https://jason.sonderman.info/case-studies/archer-higher-education-website/ - Markdown: https://jason.sonderman.info/case-studies/archer-higher-education-website.md Athens State needed more than a website update — it needed a full-funnel marketing microsite that ranked independently on program keywords while looking like the parent institution. I led UX across journey mapping, information architecture, wireframes, and usability testing to build a site that entered prospective students into the admissions nurture pipeline. The launch drove a 20% enrollment increase in struggling graduate programs. **Key metrics:** - Graduate enrollments: 20% increase (In struggling programs following microsite launch) - Site structure: SEO-first IA (Ranked independently on program keywords while matching parent institution brand) As Lead UX Designer at Archer Education, Jason built an SEO-first microsite for Athens State’s online degree programs, journey-mapped and structured to rank independently on program keywords while matching the parent institution’s brand — driving a 20% increase in graduate enrollments. **Facts:** - Enrollment increase: 20% in previously struggling graduate management degree programs - Launch: Summer 2021 - Method: Persona-based user interviews, journey mapping, SEO-first information architecture, low-fidelity usability testing **Scope:** The 20% figure applies to a subset of struggling graduate programs, not enrollment site-wide. **Team:** User Experience, Creative, SEO, Paid Search Marketing, Admission Advisors, Audience Intelligence, Web Development, Web Analytics **Tags:** Information Architecture, User Research ### The Challenge Athens State had expanded its online program offerings, but getting viable prospects for enrollment was lagging behind capacity. Due to limited institutional resources, this university hired our team to audit its marketing-to-application process and implement strategies to increase applications for the five enrollment segments. ### Project Overview Our team was engaged to create an optimized microsite and a suite of landing pages utilizing the existing university brand to motivate online degree seekers to submit a request for more information on a subset of program offerings. This submission would begin a journey for the seeker through our nurturing, enrollment, and retention programs, which assist degree-seeking users through their discovery and enrollment stages. Key to the success of this project would be a content-rich website for the user to engage with to gather information on the program of interest. Crafting the site in a way that would rank high on organic searches based on program keywords would also be key. The new site had to look as close to the parent site as possible to avoid too much dissonance and erosion of confidence if the two sites looked to be from different sources. ### Journey Map To better understand the challenges the client faced with enrolling in their online degree programs, we utilized the personas developed by the audience intelligence team to recruit and interview possible users who aligned with these personas. The interview asked a variety of questions based on the type of activities they would do if they were seeking online degree programs. From these findings, I developed user journey maps to identify areas of negative response, areas we could focus our efforts on with our new web properties to mitigate the seeker’s barriers to submitting an application. ![Journey Map](/case-study-images/Online_Partner_Site_Journey_Map-80.jpg) ### Information Architecture The microsite’s structure is unbalanced. The div for the programs has a deeply nested information architecture, while the supporting top-level divs are flat in structure. We had to collaborate closely with the SEO team to align an architecture that would provide saliency and discoverability for the user and present structured data in a manner that would gain positive search engine ranking value. A secondary challenge was that the university was to manage a number of the online programs. This meant we had to link back to the parent site on some of the programs and link to our site on others. To the user, there needed to be as little visual difference between the two types of programs as possible. ![Information Architecture](/case-study-images/MicrositeInfoArch.jpg) ### Wireframes Focusing on the areas of opportunity identified in the journey maps, aligning with the business requirements, and using the content strategy outlines for each page, I utilized user experience patterns and principles to build a flow highlighting the key actions the user would take on a given page. The wireframes would be used in low-fidelity usability testing to ensure we were getting the expected behaviors and discover any new barriers to the user completing the task. ![Wireframes](/case-study-images/Microsite1-wireframes.jpg) ### Conclusion Our final deliverable was a microsite that existed outside the main brand site but kept much of the functionality and design to make any transition between the two as seamless as possible. This would also include a blog focused on online degree content to help the site gain SEO value beyond the brand value it was already benefitting from. With the launch of the microsite in the summer of 2021 and the coordinated online marketing efforts to drive new organic and paid search traffic to the site, the client saw a 20% increase in enrollments into a few of the programs that were struggling to attract attention, primarily in their graduate management degree programs. Currently, the website is undergoing a phase 2 refresh, which utilizes the findings from the initial six months to evolve and improve content and site structure. ## Peru State: A Tiered Landing Page System That Beat Conversion Goals - Subject: Peru State Online Degree Program Marketing Pages - Role: Lead UX Designer, Archer Education - Canonical URL: https://jason.sonderman.info/case-studies/archer-higher-education-landing-pages/ - Markdown: https://jason.sonderman.info/case-studies/archer-higher-education-landing-pages.md Peru State’s online programs had ad traffic but no landing pages built for conversion. I led UX across journey mapping, IA design, wireframing, and usability testing to create a tiered system — from program-overview pages down to individual degree pages — with a multivariate testing rhythm built in from the start. The 15-page launch exceeded both visitor-to-lead and lead-to-applicant conversion targets. **Key metrics:** - Pages launched: 15 (Tiered from brand overview to individual degree program pages) - Conversion targets: Exceeded (Both visitor-to-lead and lead-to-applicant goals surpassed at launch) As Lead UX Designer at Archer Education, Jason designed a tiered landing-page system for Peru State’s online degree programs, built around the student decision journey, which exceeded both visitor-to-lead and lead-to-applicant conversion targets at launch. **Facts:** - Pages launched: 15, tiered from a branded program overview down to individual degree pages - Conversion: Both visitor-to-lead and lead-to-applicant targets exceeded at launch - Method: Journey mapping, direct user interviews, low-fidelity usability testing, and a built-in multivariate testing rhythm **Scope:** The case study states conversion targets were exceeded but doesn’t disclose a specific percentage — don’t invent one. **Team:** User Experience, Creative, Paid Search Marketing, Admission Advisors, Audience Intelligence, Web Development, Web Analytics **Tags:** Information Architecture, User Research ### The Challenge Our partnership with Peru State was to raise brand awareness of their online degree programs, with the outcome of growing enrollments into the online programs. The school had very general information pages to which ad traffic was directed, and they were experiencing a high bounce rate for visitors to the page. ### Project Overview Our team partnered with the client to create a suite of landing pages utilizing the existing university brand to motivate online degree seekers to submit a request for more information on the program offerings. This was a tiered approach, with a general branded landing page that would display information on all the available online programs, a set of pages that would focus on the programs for the two levels of degrees (Undergraduate and Graduate), and then focused pages for each program. Since the university’s brand was not widely recognized, our challenge was to instill trust in the quality of education offered, the affordability and flexibility of the education, and the social proof that a degree from the institution would be recognized in the industry. Prior to the discovery, part of our strategy was to plan out multivariate tests at regular intervals to evolve the content and visuals, as users’ expectations tend to change in a 5-8 month cycle. ### Journey Map The university had the challenge of attracting degree-seeking students to their online programs due to a lack of brand awareness and a thin online marketing strategy. We worked with the school to understand more deeply the types of learners that typically attend their on-campus programs, as well as researching the current trends in psychographic and demographic audiences who enroll in online higher education programs. Direct user interviews were set up based on the personas derived from the data to understand what a typical process of searching for an online degree for a Bachelors in Accounting, a Masters in Education, and a Masters in Organizational Management. These steps and user feedback were captured and visualized in a journey map to discover the areas we would need to focus on to remove friction for the prospective student. ![Journey Map](/case-study-images/OnlineLandingPageJourneyMap-80.jpg) ### Information Architecture The nature of the landing page system was the initial gateway a user would only see a targeted page through an ad campaign, and the requirement was that there would not be any cross or interlinking between pages, nor any linking to a parent site. This was established to focus the user on the primary task: Fill out and submit the request for more information. This action would enter the user into the admissions nurturing program where consistent and regular contact would be made with the interested user through personalized digital experiences to further inform and engage the prospective student, email drip campaigns to keep the prospect engaged with key admission and enrollment dates, and direct phone calls from assigned admission and enrollment advisor. ![Information Architecture](/case-study-images/LandingPageArch.jpg) ### Wireframes Focusing on the areas of opportunity identified in the journey maps, aligning with the business requirements, and using the content strategy outlines for each page, I utilized user experience patterns and principles to build a flow that would highlight the key actions the user would take on a given page. The wireframes would be used in lo-fi usability testing to ensure we were getting expected behaviors, as well as discover any new barriers to the user completing the task. ![Wireframes](/case-study-images/Landingpage-WIres.jpg) ### Conclusion Our teams produced 15 unique landing pages to suit the needs of paid search marketing as well as persona-driven social media campaigns. These pages delivered a range of content from full overviews of all programs, targeted programs, as well as contexts such as community college transfers and non-traditional degree seekers. The launch of the landing pages has exceeded the proposed conversion of visitor-to-lead and of lead-to-applicant. The traffic to these pages is solely dependent on paid search ads on social media outlets, which are optimized to reduce ad spend per lead and target education seekers. With the worldwide pandemic moving many traditional students into less traditional online learning, we saw an initial spike in enrollments into this school’s online programs. Adjusting for the post-2020 spike, these landing pages continue to generate a moderate number of qualified leads for the managed online programs of this school. Our teams regularly test new content and layouts based on findings from the analytics and qualitative data channels to keep engaged with our prospective students and walk with them as they look to improve their lives through higher education. ## The Content Is the API - Subject: jason.sonderman.info - Role: Site owner / builder - Timeline: Jul 2026 - Canonical URL: https://jason.sonderman.info/case-studies/agent-layer-extraction/ - Markdown: https://jason.sonderman.info/case-studies/agent-layer-extraction.md This site’s own redesign produced three candidate patterns worth reusing elsewhere: a static, agent-facing content layer; an intent-based lens entry system; and an offline fit-brief generator. Investigating them side by side showed they were architecturally independent, not one coupled idea. I extracted only the agent layer — the part with the highest reuse value and the clearest thesis — into a standalone template, and left the other two out on purpose. **Key outcomes:** - Systems investigated: 3 — agent layer, lens entry system, fit-brief generator (Assessed each against reuse value and coupling, not just whether it shipped) - Systems extracted: 1 — the agent layer only (The other two were real engineering, just not reusable in the way the redesign’s own plan assumed) - Packaging: Standalone Astro template, GitHub template repo intended (Rejected an npm package and an Astro integration as the wrong shape for what’s actually being shared) - Template status: Public on GitHub, marked as a template repo (github.com/blue148/agent-layer-template — CI groundedness eval passes 3/3 against a real Anthropic credential) This site’s redesign produced three candidate patterns for reuse — a static agent-facing content layer, a lens-based entry system, and an offline fit-brief generator. Investigating them against reuse and coupling criteria showed they were architecturally independent, not one idea; only the agent layer was extracted into a standalone Astro template, with the other two deliberately left out. **Facts:** - Systems investigated: 3 (agent layer, lens entry system, fit-brief generator) - Systems extracted: 1 — the agent layer only (qaContext schema, llms.txt/llms-full.txt generators, per-page markdown mirrors, JSON-LD, CI groundedness eval) - Packaging decision: GitHub template repo — rejected an npm package (wrong maintenance commitment for a portfolio project) and an Astro integration (wrong API shape for page/schema conventions) - Template status: Public at github.com/blue148/agent-layer-template, marked as a GitHub template repo - CI groundedness eval: 3/3 passing against a real Anthropic credential — one ground-truth question had to be fixed first (see ‘What shipped’) **Scope:** This case study documents the extraction decision and the resulting template’s design. The template itself is a starting point, not a maintained product — it’s public and verified working, not under an ongoing support commitment. **Tools:** Astro content collections, Zod, Anthropic API (Claude) **Tags:** Agent Layer, Content Architecture, Astro, AI Discoverability, Structured Content

Three systems, one assumption

This site’s redesign shipped in stages. Cycle 1 built a static, agent-facing content layer — every case study, rendered at build time into a short index (llms.txt), a complete document (llms-full.txt), per-page markdown mirrors, and JSON-LD, all sourced from the same content collections that build the HTML. Cycle 2 built a lens-based entry pattern — a dismissable, persisted prompt that routes a visitor into a curated sequence based on why they’re here, degrading to full static content with JavaScript off. Cycle 3 built an offline fit-brief generator — a two-phase CLI that reads a job description, matches it against case studies using the same agent-facing facts Cycle 1 produced, and writes a static, unlisted page.

The plan’s own scope for this phase was one line: extract the pattern into a reusable, documented codebase. Singular. It read like these three things were one idea that happened to ship across three cycles — which made sense on paper, since all three touch content, and two of them explicitly reuse Cycle 1’s output. The obvious move was to package all three together and call it “the redesign, extracted.”

I didn’t trust that framing enough to start building against it. Before writing any extraction code, I went back through all three systems and asked a narrower question of each one: if I handed just this piece to someone building an unrelated site, how much of it would they actually keep, and how much would they have to tear out?

The diagnosis

The agent layer turned out to be almost entirely mechanism. qaContext — a structured, optional field co-located with the content it describes — has no assumptions about what the content actually is. The generator that projects it into llms.txt/llms-full.txt hardcodes a handful of things specific to this site (a site URL constant, an About/Experience special-case, an exact field list), but the core loop — iterate a collection, render its facts, write a file — doesn’t care whether the collection holds case studies, blog posts, or product docs. The CI groundedness eval that checks the generated document against ground-truth questions is cleaner still: nothing in the harness itself references this site at all, only the ground-truth file does, and replacing that file is the entire point.

The lens system was real engineering — a no-JS-first state machine handling URL params, localStorage persistence, and session-scoped dismissal, plus two genuinely reusable primitives (an escape hatch, a persistence helper). But the part doing the actual routing work is a hardcoded union of four personas and the literal copy for each one, including a line as specific as “I’m evaluating Jason for a role.” Another site adopting this pattern doesn’t want my personas. What’s reusable is a smaller kernel inside a larger, more bespoke surface: a dismissable, persisted, URL-overridable entry choice that degrades to static content. Real, but narrower than it looks from the outside.

The fit-brief generator had a different problem — not coupling, but validation. Its two-phase generate/review/commit flow and its prompt-injection hygiene (a pasted job description is always treated as content to analyze, never as instructions) are ideas worth reusing on their own. But at the point I was investigating this, the script had never actually produced a real fit brief. src/content/fit-briefs/ was empty. Extracting and genericizing a pattern that’s never been exercised against a single real input isn’t extraction — it’s guessing that the current shape is right before anything has tested that assumption.

The decision

Bundling all three into one “extracted pattern” would have manufactured a shared abstraction between things that aren’t actually coupled — they shipped in the same project, not from the same design. The agent layer is a build-time content projection. The lens system is client-side progressive enhancement over static routing. The fit-brief generator is an offline CLI. Nothing in one depends on the other; the PRD driving this redesign says as much explicitly for Cycle 3 and Cycle 2.

I scoped the extraction to the agent layer alone. It has the highest reuse value of the three — portable to any Astro site built on content collections, regardless of what the content actually is — and the lowest genericizing cost: pulling a few hardcoded constants into a config file, not a rearchitecture. It’s also the most differentiated idea on its own. “Treat agents as first-class consumers of your content, the same way a design system treats agents as first-class consumers of design tokens” doesn’t need the lens system or the fit-brief generator to be a complete thesis.

Packaging was its own decision, weighed against three alternatives. An npm package implies a semver and maintenance commitment out of proportion to a portfolio project’s appetite — and half the value here isn’t “install a dependency,” it’s “copy this schema shape into your own content.config.ts and adapt it.” An Astro integration is the wrong API surface entirely; these are page, schema, and script conventions, not renderer-level hooks. A documented reference with no formal packaging was the lowest-effort option, but the weakest forcing function — nothing would actually require the genericizing work to happen; it’s easy for docs to gesture at “swap this for your content” without the swap being clean. A GitHub template repo sits between all three: someone can click “use this template” and get a working site with the agent layer wired up, which forces every site-specific string to actually become a placeholder, without taking on a package’s versioning burden.

What shipped

The template is a standalone Astro project: a generic items content collection standing in for whatever your primary content type is, the qaContext schema copied as-is, a genericized generator reading site name and URL from one config file instead of a hardcoded constant, the same three routes (llms.txt, llms-full.txt, per-item markdown mirrors), parameterized JSON-LD, and the CI eval harness with a small example ground-truth file in place of this site’s actual content.

One piece of the original code got fixed on the way out, not just copied: the generator tracked which published entries were missing qaContext but never surfaced that list anywhere — no build warning, no CI gate, a signal nobody was reading. The template version logs it as a build warning instead. Small, but worth naming, because it’s exactly the kind of dead tracking code a template shouldn’t silently inherit.

I confirmed llms.txt, llms-full.txt, the per-item markdown mirrors, and both levels of JSON-LD all render correctly against two example content entries — that was true before the eval ran once. Running the ported eval harness for real, against a live Anthropic credential, is what actually caught a problem: one ground-truth question required the literal digit ”5”, but the model’s correct answer spelled it out as “Five channels,” so a right answer failed the check. The fix was the same alternate-phrasing pattern this site’s own ground-truth file already used elsewhere for exactly this reason — I just hadn’t applied it to every question. That’s the specific value of actually running an eval instead of trusting that a well-built harness implies a well-built ground-truth file: the harness was fine. The test data wasn’t. With that fixed, the eval passes 3/3, and the template is public at github.com/blue148/agent-layer-template, marked as a GitHub template repo.

Knowing what not to generalize

The lens system and the fit-brief generator aren’t in the template, and that’s stated in its README as plainly as what is included — not as a hedge, but because leaving them out was itself the harder decision to make well. It would have been easy to extract all three and call it thorough. It would have been just as easy to extract nothing and call the whole investigation a wash because it didn’t produce one clean “the pattern.” Neither of those is what the evidence supported. One of the three systems had a real, portable idea at its core; the other two didn’t, for two different reasons — one because its reusable core was smaller than its bespoke surface, the other because it had never been tested against reality yet.

That’s the same instinct this site’s case studies keep returning to elsewhere: a partial result, stated honestly, is more useful than a complete-sounding one that overclaims. This one just happens to be about the site’s own construction instead of a client’s product.