# Hugh Berryman

> At Freeport-McMoRan, I work end to end—from user research and product design through design systems and code—to align operators, product partners, and engineers around model-informed decisions people can challenge.

Design Engineer in Phoenix, Arizona. Contact: hugh.g.berryman@gmail.com, https://linkedin.com/in/hughberryman. Source: https://github.com/HughBerryman/hughberryman-design-engineer-resume-site

Generated at build time from the same TypeScript content modules the pages render from, so this file cannot drift from the site.

## About

I'm a design engineer in Phoenix. Since 2024 I've worked on industrial and enterprise software at Freeport-McMoRan, where interfaces support decisions about real equipment and the users are metallurgists and haul-truck fleet managers. The work rewards clarity under load.

The thread through my work is closing loops. Design systems drift when Figma, code, documentation, and model instructions evolve separately. I work at those seams: Figma variables bound to Flutter theme extensions, component rules an AI assistant can follow, and tokens translated into the constraints of an enterprise platform.

## Localization lab

The production portfolio is English-only. [Localization lab](https://hughberryman.com/pseudo) derives accented, bracketed, expanded interface strings from the English dictionary and can mirror the same page between LTR and RTL. The lab is noindex and excluded from hreflang and the sitemap.

## Theme lab

[Theme lab](https://hughberryman.com/theme) applies Paper, Sonoran, and Blueprint families in light and dark modes to the real portfolio. All six expressions remap the same semantic surface, text, rule, accent, and focus roles; the selection persists across pages and is restored before first paint.

## Case studies

### MDS 2.0 / FORGE: A design system that an AI can read

- URL: https://hughberryman.com/work/mds
- Year: 2025—26
- Role: Owned the color foundation, component-state matrices, and button Code Connect mapping; framed the experimental modernization pipeline built on top.
- Team: One of three designers on the library, working with Flutter engineers who owned the code implementation.
- Metric: 1,830 Figma variables across nine collections
- Tags: Design systems, Figma Code Connect, Flutter, Design tokens, AI tooling

I owned the color and component-state foundations for MDS 2.0, a 1,830-variable Figma library connected to Flutter through Code Connect. I then framed FORGE, an experimental pipeline that reduces legacy screens to structured JSON for model-assisted modernization.

#### Three copies of the truth

A design system tends to exist three times. Once as a Figma library, once as the code that implements it, once as documentation describing both. Each copy has a different owner and a different update cadence, so they drift. Add an AI assistant to the workflow and there is a fourth copy, because the model needs an instruction set and somebody writes it by hand.

MDS 2.0 was an attempt to collapse that into one thing. A token architecture in Figma, bound to the Flutter codebase through Code Connect, with component rules written in a form a model could read directly. Not a library plus docs plus prompts. One artifact with several outputs.

I owned the color foundation, the component-state variable matrices, and the Code Connect mapping for the button set. Most of my time went to the seam between those, which is also where all of the arguments were.

> A component library, its documentation, and a model's instruction set are one artifact rendered three ways. Most teams maintain three.

#### Two tiers, and one collection that exists for the compiler

Seven named tonal ramps at thirteen stops each. Nothing consumes a raw palette value. Semantic theme roles alias into the ramps, and every role carries an explicit light assignment and an explicit dark one, so a theme swap is a lookup rather than a redesign. Elevation is authored twice for the same reason.

Material 3 gives you primary, secondary, tertiary and error. It does not give you success, warning, danger and info as themed roles, so teams invent them per screen and the greens stop matching. We promoted all four to first-class themes with full light and dark pairs, in design and in code. That means leaving the spec, and every future Material upgrade now needs a reconciliation pass. It was still cheaper than the alternative, which was status color as folklore.

About 1,830 variables across nine collections. The split matters more than the count: primitives separated from semantics, semantics separated from component-state matrices, and one collection built purely to serve the codebase rather than the canvas. Component interaction state runs off variable modes instead of hand-built variants. A text input resolves fifteen bound properties across five modes, so the stroke walks from outline to primary to danger by state and the floating label is a boolean, with no duplicated variant holding either.

#### The bridge, wired

Code Connect maps one Figma button set to five Flutter symbols, including a named constructor. The mapping targets Flutter's `ThemeExtension` classes rather than bespoke wrapper widgets.

That choice has a visible cost. The snippet Dev Mode hands an engineer is a plain `FilledButton(...)`. Nothing in it names the design system, which makes the handoff demo look like nothing happened, and it means adoption cannot be audited by reading a screen. It is also correct: theming belongs in the theme, not in a parallel widget layer somebody has to keep in step with the framework.

The spec board and the sandbox are deliberately separate objects. The master variant set is locked. Next to it sits a playground of roughly sixty rendered permutations including a disabled state for every style, because the question a developer actually has is not what the spec says, it is what this looks like when it is off.

#### FORGE

FORGE is the pipeline built on top. Three ingest paths converge on one representation: analysis of legacy screens, the proven path from Figma files already built out of MDS components, and an R&D path starting from prompt-generated HTML. All three produce the same enriched JSON. Per-component skill files are what the model reads, and those files are treated as source of truth rather than as prompt scaffolding.

The enrichment step is what made it work. Raw Figma JSON is mostly noise for this purpose. Enriching and reducing it cut the parse payload from roughly ten thousand lines to roughly one thousand, which is the difference between a model holding context for a screen and a model holding context for a button.

Which model runs is a controlled variable in the design rather than an implementation detail, so output can be compared across models instead of argued about.

#### What shipped, and what remained experimental

Code Connect was wired and reporting connected. The artifact I can show is the panel rather than the `figma.connect()` source file, so that is the limit of the public evidence.

FORGE's enrichment step reduced the raw parse payload from roughly ten thousand lines to roughly one thousand. End-to-end Flutter generation was not feasible when I last worked on it, output quality had not been benchmarked, and adoption was not instrumented.

If I returned to it, I would instrument adoption first. A design system cannot improve a workflow if nobody can answer whether it is being used.

#### Decisions

**1.** Point Code Connect at Flutter `ThemeExtension` classes instead of building a wrapper widget for every component.

- Tradeoff: Wrappers would have made the system visible in application code and trivial to audit. Theme extensions make the generated snippet a plain `FilledButton(...)` with nothing in it that names MDS, so the handoff looks unimpressive in a demo and adoption cannot be checked by reading a screen.
- Outcome: No parallel widget layer to version against the framework, and engineers write ordinary Flutter that inherits the system for free. Auditing moved to the theme layer, which is a handful of files rather than hundreds of call sites.

**2.** Drive component interaction state from Figma variable modes rather than from hand-built variants.

- Tradeoff: Modes are invisible to a designer browsing the library and harder to teach than a variant picker. A designer who wants a one-off error state has to understand the matrix or detach the component, and some detached.
- Outcome: One text input holds fifteen bound properties across five states with nothing duplicated. Changing the error stroke is a single edit that lands everywhere, and the matrix reads to an engineer as a table of resolved values rather than as a pile of variants.

**3.** Insert a JSON enrichment step and treat per-component skill files as source of truth, instead of writing better prompts.

- Tradeoff: One more artifact for the design team to maintain, and an artifact engineers now depend on at build time. It slowed the pipeline down and put the design system team inside a code path they had never been in before.
- Outcome: Parse payload dropped from roughly ten thousand lines to roughly one thousand, and the prototype consumed the same component instructions on every run. That reduced prompt-by-prompt variation without claiming end-to-end output quality we had not benchmarked.

### MIRA 2.0: Making a model's recommendation arguable

- URL: https://hughberryman.com/work/mira
- Year: 2024—25
- Role: Designed the operator-facing experience and information architecture; conducted onsite research at the plant. Data science and engineering owned the model and infrastructure.
- Team: Product team with data scientists, cloud engineers, plant metallurgists, and operations staff.
- Metric: ~20% lower recommended fresh-ferric addition than the legacy bleed calculator — Monitored seven-day comparison, internal tracking
- Tags: Data visualization, Machine learning, Field research, Information design

MIRA recommends operating changes in a molybdenum leach circuit. After onsite research, I designed a review flow that shows operators the forecast, current setting, and consequence of accepting, adjusting, or rejecting each recommendation.

#### A recommendation operators cannot challenge gets ignored

MIRA predicts impurity concentrations in the molybdenum leach circuit at Sierrita, outside Tucson, and recommends changes to throughput, fresh ferric addition, decant bleed, and digester runs. The open question was whether an operator on shift would act on it.

Operators already had a legacy bleed calculator and years of judgment. A screen that prints a number and offers a green button would ask them to replace both with blind trust. The design problem was to make the prediction arguable: show what the model expects under the recommendation, what it expects under the current setting, and where both sit against the spec limit.

> The interface's job was not to be believed. It was to be verified.

#### Onsite, October 2024

I spent a day at the plant with operators and metallurgists. Two findings changed the structure of the product.

The first is that assays lag. Lab results arrive hours after the material they describe, so every recommendation rests on a slightly stale picture, and everyone on the floor already knows it. The second is that the decision is not made by one person at one moment. It crosses a shift handoff, and the person who acts is frequently not the person who reviewed.

Neither is visible from a model output or a stakeholder workshop. Both became structural. Data recency is printed on the home screen rather than implied. Any calculator run can be shared by URL or locked in as the committed strategy, with an author and timestamp attached, because the decision has to survive a shift handoff even when the reviewer changes.

#### The screen the product exists for

Review is a five-step flow with one recommendation type per step. The alternative was a dashboard asking for four decisions at once, which is how you get all four accepted without any of them being read.

On the fresh-ferric step, six impurity elements are drawn as small multiples on one shared axis under one shared spec line. Solid to the left of today, dashed to the right, which encodes the actual-to-forecast boundary with no legend to look up. The recommended setting and the current setting are both forecast, in two colors, on the same chart. When the current setting breaks spec and the recommendation does not, that reads as a shape before it reads as a number.

The interface offers three choices: accept the recommendation at its setpoint, adjust to a custom value, or reject and keep the current setting. Both setpoints are printed on the buttons, so the consequence of disagreeing is as legible as the consequence of agreeing. A metallurgist who wants to investigate rather than act can expand any chart or switch it to a table.

#### Trust as a first-class metric

The home screen carries two figures most ML products keep in a status deck: the share of recommendations operators approved, and the share of days anyone reviewed at all. Publishing a model's rejection rate to the people accountable for acting on it is uncomfortable and useful. A model nobody reviews is not a model in production; it is a model in a database.

The blend calculator's results screen follows the same instinct in reverse. It leads with the constraint violation—the number of days beyond target in red—above every positive number on the page. Then it shows the arithmetic underneath so the result can be checked rather than accepted.

#### What the evidence supports

Over one monitored week, internal tracking put MIRA-recommended fresh-ferric addition roughly 20% below what the legacy bleed calculator would have called for. The team's note said savings still needed month-by-month validation, so this site does not convert that comparison into an annual or dollar claim.

The home screen and blend calculator do not share the same chrome. The design system caught up mid-project, and I chose not to rework a surface already in use by people on shift. I would unify them now.

#### Decisions

**1.** Make reject a full third option with its numeric consequence printed on it, rather than accept-or-dismiss.

- Tradeoff: It puts disagreement one click away at the exact moment the program is being measured on adoption. A two-button flow would have shipped sooner and produced a better-looking approval rate.
- Outcome: Rejections became data instead of silence. Operators had somewhere to put disagreement other than not opening the app, and the team could see which recommendation types were being turned down and argue about why.

**2.** Put six elements on one shared axis under one shared spec line, instead of six independently scaled charts.

- Tradeoff: Elements with small absolute ranges get flattened and lose exactly the resolution a metallurgist wants. Covering that cost a per-chart expand and a chart-to-table toggle, both of which are extra surface to build, test and maintain.
- Outcome: Cross-element comparison is instant and a spec breach reads before any number is parsed. The people who needed precision got a route to it that is one interaction deep rather than a separate screen.

**3.** Print the model's rejection rate and the staleness of the lab data on the operator home screen.

- Tradeoff: Both facts argue against acting, on the screen whose entire purpose is to get someone to act. It also invited early questions from stakeholders about why the approval number was not higher, months before there was a good answer.
- Outcome: Review coverage became a tracked number rather than an assumption, and assay lag became a stated property of the system instead of an implicit limitation. The interface could not fix the lag, but it could make it visible.

### ServiceNow employee portal: A design system for a platform we did not control

- URL: https://hughberryman.com/work/servicenow
- Year: 2025
- Role: Led research on both sides of the ticket, designed the portal, and wrote the token and SCSS guidance used for implementation.
- Team: Platform developers and IT service owners. The developers implemented the shipped portal.
- Tags: Research, Information architecture, Design tokens, SCSS, Enterprise platform

Employees were misrouting support tickets because the portal exposed IT's service taxonomy instead of the language people used. I led research across submitters and service teams, redesigned the catalog around request behavior, and delivered tokens and SCSS primitives platform developers could apply across ServiceNow.

#### The interface problem was vocabulary

The company-wide employee support portal is where people report something broken, request a service, and check the status of earlier submissions.

Research ran on both sides of the ticket: employees who submit, and IT staff who receive. What came out was not a layout problem. People could not reliably tell an incident from a request. Catalog labels used internal service language, categories overlapped, and when the distinction was unclear the safest move was always the broadest option. Tickets landed in the wrong queue, got recreated, and a catch-all category absorbed everything the taxonomy had failed to name.

The taxonomy was IT's model of its own services. Nobody outside IT held that model, and no amount of visual refinement was going to install it.

> The taxonomy was IT's model of its own services. Nobody outside IT held that model.

#### Designing for a front end we did not own

The portal lives inside an enterprise platform with its own page-building model, its own component markup, and its own styling system. There is a portal, which is what employees see, and a native view, which is where IT works records. Neither is a codebase a designer hands React to.

So the deliverable could not be a stack of page comps. Anything expressed as a pixel redline gets applied once, to the pages someone designed, and diverges on every page nobody did. The design had to arrive as primitives: a global token sheet authored to compile into platform-compatible SCSS, a type scale, a spacing scale, and a small number of patterns strict enough to survive being applied by someone who never read the research.

#### What held up inside the platform

One neo-grotesque across the page with a clear scale. A near-white ground, one interactive blue, and a single reserved accent used only for the two assistant entry points, so 'this is an AI surface' is a color rule instead of a badge stuck on every component.

One card pattern reused nine times, fixed height, labels top-aligned so a two-line service name cannot break the row. That constraint exists because the catalog content is not under design control and never will be. Designing for the ugliest string the catalog can produce is cheaper than asking service owners to shorten their names.

The Figma file was structured as the backlog: an epic spine, feature lanes, user story sections, and the global token frame sitting above all of it. That is delivery hygiene rather than craft, and on this project it is what kept the tokens from being read as decoration.

#### The content decision

The default catalog view was ranked by what people actually requested over the previous three months, not by the service taxonomy. Alongside it, a personalized carousel scrolls while a popular grid does not, so the two lists read as different kinds of content rather than two rows of the same thing.

That is a small change with an organizational cost. Ranking by volume demotes services whose owners expect to see them near the top, and it has to be kept current. It was the right call because the taxonomy was the thing that had failed, and reproducing it as navigation would have reproduced the failure.

#### Implementation and the remaining gap

Platform developers built the portal. I worked directly with them on CSS primitives and interface structure, because the system would survive only if its implementation carried the same logic as the Figma file.

The portal shipped, but ticket routing, help-desk load, and satisfaction were not measured after launch. Those remain goals, not outcomes I can claim.

No build step enforces the tokens, so adherence depends on review and shared practice. In a codebase I owned, I would make that a lint rule.

#### Decisions

**1.** Deliver the redesign as a token sheet and SCSS primitives instead of per-page redlines.

- Tradeoff: Much slower to show progress. Weeks of work produced a variable sheet and no visibly redesigned page, which is hard to defend in a stakeholder review, and it meant accepting the platform's component markup rather than controlling structure.
- Outcome: Pages nobody designed inherited the system, and later work started from primitives rather than from a screenshot. The residual cost is real: with no build step to enforce them, the tokens hold by agreement.

**2.** Rank the catalog by actual request volume rather than by the service taxonomy IT maintains.

- Tradeoff: It demotes services whose owners expect prominence, so it needed an argument with service owners rather than a design review. The ranking is also a moving target somebody has to keep current.
- Outcome: The design shortened the common path and moved the broad catch-all out of the primary route. We did not instrument whether that reduced misrouting after launch.

**3.** Keep incident and request as two plainly named doors instead of merging them into a single help flow.

- Tradeoff: One door is visually simpler. Two doors means some people still choose wrong, and the home page carries two primary actions competing for the same attention.
- Outcome: The platform routes on that distinction, so merging it would have pushed classification into the back end, which was already where the misrouting happened. Fixing the vocabulary in the labels was cheaper and more honest than hiding a distinction the system depends on.

## Earlier work

Selected evidence connected to the employment record rather than presented as current case studies.

### Centro

- Portfolio anchor: https://hughberryman.com/#work-archive-centro
- Original visual archive: https://dribbble.com/shots/23330596-Design-System-Centro
- Company: Tribal Credit
- Period: 2020—23
- Discipline: Design system

I created Tribal's first shared component and token system—the starting point for design-to-code work I later carried into Storybook, Code Connect, and model-readable guidance.

### Tribal Platform

- Portfolio anchor: https://hughberryman.com/#work-archive-tribal-platform
- Original visual archive: https://dribbble.com/shots/23337346-Tribal-Platform
- Company: Tribal Credit
- Period: 2020—23
- Discipline: Product platform

I designed the cards, payments, reporting, and navigation workflows that connected Tribal's expense platform across web and mobile.

### Whoin

- Portfolio anchor: https://hughberryman.com/#work-archive-whoin
- Original visual archive: https://dribbble.com/shots/23312639-Whoin
- Company: Whoin
- Period: 2019—20
- Discipline: Design + React Native

I co-founded Whoin, designed the product, and built its React Native app from concept through release.

## Recommendations

Selected excerpts published on LinkedIn. [View all 11 recommendations](https://www.linkedin.com/in/hughberryman/details/recommendations/).

- “Hugh combines a keen sense of strategic thinking with a hands-on approach to design leadership. He doesn't just design; he thinks ahead, aligning every project with our broader business goals while keeping creativity at the forefront.” — [Leonardo Shapiro](https://www.linkedin.com/in/leonardoshapiro/), Chief Product Officer, Tribal Credit. Relationship: Managed Hugh directly.
- “I've had the pleasure of working with Hugh for almost 5 years, and he has been instrumental in designing customer-centric products that have helped grow our company from seed-stage to Series B with presence across 10 markets. Hugh has always been exceptional in transforming complex requirements into seamless user experiences and products that customers love.” — [Mohamed Abouhussein](https://www.linkedin.com/in/mohamed-abouhussein12345/), Group Product Manager. Relationship: Worked with Hugh on different teams.
- “Hugh played a large role in helping to improve our design system processes. His insights and meticulous approach were instrumental in improving them and strengthening collaboration with engineering. In a short timeframe, he taught the team valuable design system methods that enhanced our workflow and productivity.” — [LaBoria Willis](https://www.linkedin.com/in/laboria/), Director, User Experience (UX), Symetra Insurance. Relationship: Worked with Hugh at Symetra Insurance.
- “Thanks to his guidance, I've grown from a junior designer to leading design for a new product as a Product Designer. Hugh is also a strong advocate of systems thinking and integrating tools like design systems or DesignOps to support others' work.” — [Emiliano Carrillo](https://www.linkedin.com/in/emiliano-carrillo/), Product Designer, Tribal Credit. Relationship: Worked with Hugh at Tribal Credit.

## Employment record

Design engineer working across product interfaces, design systems, and implementation. At Freeport-McMoRan, I design operator tools for industrial machine-learning products and the systems that connect Figma, Flutter, and AI-assisted workflows. I also build in React and TypeScript, including this localized portfolio and resume system.

### Freeport-McMoRan

Phoenix, Arizona · Aug 2024 – Present

#### Senior Product Designer · Aug 2024 – Present

- Design lead on RAMP, a mobile-equipment reliability product taken from zero through UAT into production. Core designer on MIRA and on the company-wide employee support portal redesign.
- MIRA: designed the operator review flow for a model that recommends throughput, fresh-ferric addition and bleed at a molybdenum leach circuit. Over a monitored one-week comparison, internal tracking put MIRA-recommended fresh-ferric addition roughly 20% below the legacy bleed calculator.
- MDS 2.0 / FORGE: owned the color foundation, component-state variable matrices, and Code Connect mapping that binds the Figma button set to Flutter ThemeExtension classes, then framed an experimental modernization pipeline built on that system. Roughly 1,830 variables across nine collections; per-component skill files provide consistent instructions for model-assisted Flutter generation.

### Qashio

Dubai, remote · Nov 2025 – Present

Concurrent with Freeport-McMoRan

#### Design Consultant · Nov 2025 – Present

- Set the evaluation criteria for a design-engineering hire at a Dubai fintech and ran the interviews. AI-assisted design-to-code fluency and pull-request literacy were gates, not nice-to-haves.
- Advised on building the Figma system outward from an already-mature Next.js UI codebase, treating the code as the source of truth rather than trying to make Figma authoritative after the fact.
- Mentor the design team toward design-engineering practice rather than handoff-only product design.

### Symetra Insurance

Remote · Feb 2024 – May 2024

#### Senior Product Designer, Design Systems · Feb 2024 – May 2024

- Extended the design system into Storybook and Chromatic so component review happened against built code instead of screenshots.
- Built components the design team consumed directly in Figma.

### Tribal Credit

Remote · Jan 2020 – Nov 2023

#### Director of Product Design · Mar 2022 – Nov 2023

- Led a team of 10 product designers and the delivery partnerships with product, marketing and engineering (headcount per internal reporting at the time).
- Conceptualized and shipped Centro, the company design system, adopted across the product and engineering organization.

#### Senior Product Designer · Mar 2021 – Mar 2022

- Led design for five expense-management features and the product's expansion into Latin American markets.
- Designed card and payments integrations across Marqeta, CurrencyCloud and Stripe, turning compliance requirements into flows customers could follow.

#### Product Designer & React Native Developer · Jan 2020 – Mar 2021

- Designed Tribal Pay and shipped it as a React Native and Expo application with TypeScript and React Query.
- Built the Figma design system the product organization worked from and landed its color system in the app codebase, which is the earliest version of the design-to-code work I still do.

### Whoin

Phoenix, Arizona · Feb 2019 – Jan 2020

#### Co-Founder, Product Designer & React Native Developer · Feb 2019 – Jan 2020

- Co-founded a social community startup. Product design and React Native development from concept through release.

### ARMLS

Phoenix, Arizona · Aug 2018 – Feb 2019

#### Product Designer & React Native Developer · Aug 2018 – Feb 2019

### Apple

Phoenix, Arizona · Aug 2017 – Mar 2018

#### Product Specialist · Aug 2017 – Mar 2018

### Airbnb

San Francisco, California · Sep 2015 – Apr 2017

#### Production Specialist · Sep 2015 – Apr 2017

## Capabilities

Next.js & React, TypeScript, Design systems, Figma Code Connect, Flutter & Material 3, Tailwind CSS, Data visualization, AI-assisted tooling, Research

## Education

- Pomona College: Bachelor of Arts, Media Studies. Claremont, California, 2011 – 2015.

## Languages

Personal background only.

- English: Native
- Chinese: Conversational
- Spanish: Beginner