# Hugh Berryman > Product designer and design engineer at Freeport-McMoRan, connecting design systems, AI-assisted tools, and industrial software from research through implementation. Design Engineer & Product Designer in Phoenix, Arizona. Contact: hugh.g.berryman@gmail.com, https://linkedin.com/in/hughberryman, https://github.com/HughBerryman. 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 based in Phoenix, working on software that helps people make decisions about real equipment. An operator needs to understand what a model recommends, why, and what to do next. A maintenance team needs to trace an alert back to its cause. Those are the kinds of problems I like to work through. I lead design engineering for Prototype Studio, where designers build frontends directly in code. I designed, coded, and launched the tool and established a shared GitHub repository, branching and pull-request workflows, and Skills so design and engineering can work from the same frontend code. Before Freeport-McMoRan, I grew from Tribal Credit's first product-design hire into Director of Product Design, leading 10 designers while staying hands-on with product and design-system work. ## Portfolio lab [Portfolio lab](https://hughberryman.com/lab) combines the live design-system viewer with selectors for Copper, Sonoran, Monsoon, and Pine in light and dark modes. Every expression remaps the same semantic surface, text, rule, accent, and focus roles; selections persist across pages and restore before first paint. The [localization test](https://hughberryman.com/pseudo/lab) derives accented, bracketed, expanded interface strings from the English dictionary and can mirror the same viewer between LTR and RTL. That generated route is noindex and excluded from hreflang and the sitemap. ## Case studies ### Prototype Studio / MDS 2.0 / FORGE: Prototype Studio: designers building in code - URL: https://hughberryman.com/work/mds - Year: 2025–26 - Role: Design engineering lead; designed and implemented Studio and established the shared repository, review process, and Skills. - Team: I implemented the workspace and prototyping features independently and lead the design team's move into code. Developers use Studio to optimize FORGE ingestion. The underlying MDS 2.0 library was a shared effort with three designers and Flutter engineers. - Result: Live and expanding across design; developers use working UI, sample JSON, and requirements to refine FORGE ingestion. - Tags: Design systems, Product design, Design engineering, Figma Code Connect, Flutter, AI tooling I designed, coded, and launched Prototype Studio, where designers build frontend UI through a shared GitHub workflow. I lead its design engineering as adoption expands and developers refine the handoff to FORGE, the enterprise AI harness. #### Moving design work into code I designed, coded, and launched Prototype Studio so designers can build frontend UI in a shared repository and bring it through review. Figma remains available, but working code is now our primary prototyping medium. The tool grew from an MDS component sandbox into a workspace for creating concepts and preparing engineering handoffs. The earlier workspace below shows that shift; the opening comparison shows the current Studio library. > Designers contribute frontend code through the same repository and review workflow that carries it toward engineering. #### A shared GitHub workflow for designers I established the shared GitHub repository, branching conventions, pull-request process, and repository-backed Skills. Studio makes that workflow accessible through personal and team views, search, filters, and project ownership. Reviewers can open working UI, resize it across breakpoints, leave comments, and inspect its source. Status, contributors, and update history keep the experience connected to the people and files behind it. The earlier review canvas below shows how preview and implementation context come together. #### Preparing the handoff to FORGE I iterate with developers on UI code, prototype JSON stubs, and requirements for ingestion into FORGE, the enterprise AI harness. The searchable Skills catalog holds this guidance alongside instructions for prototypes, branches, and design pull requests. Studio supplies working UI, sample data, requirements, and a manifest connecting the files. FORGE owns production API design and implementation decisions. The older architecture diagram records an earlier proposal; it is not evidence that every proposed generation path is live. > Sample data explains the experience; engineering owns the production API. #### The MDS foundation behind Studio I led creation of MDS 2.0 in Figma and collaborated with developers on the component library. The system separates primitives, semantic themes, and component states: about 1,830 variables across nine collections, with seven tonal ramps at thirteen stops and explicit light and dark assignments. Success, warning, danger, and info extend the Material theme, adding a reconciliation task for future upgrades. Variable modes replace duplicated interaction variants: one text input resolves fifteen properties across five states. The boards show both the color architecture and the state matrix. #### Earlier work connecting Figma to Flutter The button artifact is one example of our broader Code Connect setup: a Figma component set mapped to five Flutter symbols, including a named constructor. Engineers receive ordinary Flutter button snippets, with the design-system connection carried by ThemeExtension configuration. That avoids a parallel wrapper layer, but reviewers must check the theme to confirm the connection. A locked master set and roughly sixty rendered permutations, including disabled states, give engineers both a specification and a behavior reference. #### Live, in use, and expanding Studio is live and expanding across the design team. Designers use it to build frontend UI; developers use the work to optimize FORGE ingestion. I continue to lead its design engineering, support designers through repository review, and refine the handoff with developers. The underlying MDS library remains a shared effort with designers and Flutter engineers. #### Decisions **1.** Move designers into frontend code through a shared GitHub repository, branches, pull requests, and Skills, supported by the Studio library. - Tradeoff: Designers take on repository and review conventions as part of design work. I also have a live tool, responsive previews, metadata, and instructions to maintain as the team adopts it. - Outcome: Designers use Prototype Studio to build frontend UI in code through a shared repository and review process. The tool is live and expanding across the team. **2.** Package working UI, sample JSON, requirements, and a manifest for handoff, with FORGE responsible for production API decisions. - Tradeoff: The prototype's behavior, data examples, requirements, and source references need to stay aligned as the concept changes. - Outcome: Developers use Studio to optimize FORGE ingestion. Working prototypes and shared guidance have substantially reduced UI handoff effort. **3.** Point Code Connect at Flutter ThemeExtension classes instead of building a wrapper widget for every component. - Tradeoff: Wrappers would make system use explicit at each call site. Theme extensions require reviewers to inspect the theme configuration to confirm the design-system connection. - Outcome: The connected button set uses ordinary Flutter components with MDS theme configuration, avoiding a separate widget layer to keep aligned with framework updates. **4.** Drive component interaction state from Figma variable modes rather than from hand-built variants. - Tradeoff: Variable modes require more explanation than a variant picker. Designers need to understand how the state matrix resolves before making a local override. - 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. ### RAMP / Remote Asset Management Platform: Making a five-system alert chain operable - URL: https://hughberryman.com/work/ramp - Year: 2024–26 - Role: Design lead for discovery, responsive workflows, UAT, and production review. Engineering owned implementation and system architecture. - Team: Product and engineering partners, telemetry and alarm-logic specialists, SAP APM stakeholders, equipment subject-matter experts, and operations users. Engineering owned implementation and system architecture. - Result: Alert handling reached production; RAMP 360 research extended the work into missing-alert diagnostics. - Metric: 5 technical layers translated into one alert-handling workflow - Tags: Complex workflows, Observability, Enterprise product, Information architecture, Responsive design I led RAMP's design from discovery through UAT and production, bringing a five-system alert chain into one workflow for reviewing equipment signals, recording findings, and creating maintenance notifications. #### One alert, five systems An equipment alert crosses telemetry, alarm logic, maintenance records, monitoring, and RAMP before someone can act. Each layer has different identifiers, states, and owners. The operator needs one accountable workflow instead of reconstructing that chain. The discovery board below brings together the legacy interface, Grafana dashboards, and weekly review spreadsheet that fragmented the work. > The interface had to make a distributed technical process feel like one accountable workflow. #### Researching a workflow no one person owned No single specialist could explain the complete workflow. I combined interface audits with sessions across telemetry, alarm configuration, maintenance, and operations to map disagreements and handoffs. Recurring jobs included refining thresholds, reducing false positives, validating telemetry, and tracking alert ownership. Those findings separated fleet, alerts, mobile equipment, fixed plant, approvals, and database management into distinct areas, while keeping status language and table behavior shared. #### Designing the queue for action The queue keeps workflow status and equipment severity independent. New or In Process describes the team's work; Warning or Error describes the signal. Counted, dismissible filters preserve context, while two-line cells pair machine codes and identifiers with readable names. Live Stream, Pending, Closed, and an unavailable Errors state frame the queue over time. Unresolved names and missing links have explicit states. Notification creation and status handling moved into RAMP, while SAP APM remained the underlying maintenance system. > Severity describes the machine. Workflow status describes the team. The queue has to show both. #### Making design traceable to delivery The MVP design file mirrors the delivery backlog: epic and feature lanes contain responsive journeys at four widths, with eighty-six frames marked ready for development. Shared filters, tables, status tokens, and navigation keep the workflows consistent. I led design from concept through UAT and production, resolving responsive behavior, edge cases, and review feedback. Engineering owned implementation and system architecture. #### When an alert never arrives RAMP 360 explored where an eligible alert stopped: qualification, processing, downstream acceptance, or delivery to the interface. Operations needed a simple health summary; technical specialists needed identifiers, timestamps, failure points, and diagnostic history. The research kept those views separate, with a route from summary to evidence. Authoritative counts, resolvable errors, ownership, and history retention remained open implementation questions. > A missing alert is not one failure. It is a question about which system last knew the truth. #### Delivery and the next measurement step The alert-handling experience reached production after discovery and UAT. The evidence supports its workflows, states, and delivery structure; it does not establish reductions in response time, false positives, cost, or downtime. My next measurement plan would track acknowledgment and resolution time, false-positive disposition, filter reuse, cross-system failures, and complete alert traces. Those measures would test whether the redesigned workflow improved operations. #### Decisions **1.** Move alert handling, notification creation, and status management into RAMP instead of keeping SAP APM as a required step in the operator workflow. - Tradeoff: RAMP had to model maintenance states and validation rules that previously belonged to another system. That increased product scope and created another integration surface to maintain. - Outcome: The user could review and act on an alert in one operating surface while SAP APM remained the underlying maintenance system. The dependency moved out of the interaction path rather than being described as eliminated. **2.** Keep workflow status and equipment severity as two independent state systems in the alert queue. - Tradeoff: Every row carries more visual information, and two amber treatments can compete if hierarchy is weak. A single status pill would be quieter and easier to implement. - Outcome: A reviewer can distinguish what the machine reported from what the team has done without opening the row. Urgency and accountability remain separate, which prevents one from overwriting the other. **3.** Give operations a simple delivery-health view and technical specialists a separate detailed trace instead of exposing the full diagnostic chain to everyone. - Tradeoff: Two levels require an escalation path, role-aware permissions, and agreement about when the summary is no longer enough. One universal diagnostics screen would have been cheaper to build. - Outcome: The RAMP 360 research defined a summary for operations and a detailed trace for specialists. Diagnostic ownership and authoritative counts remained open questions for implementation. ### MIRA 2.0: Making a model's recommendation arguable - URL: https://hughberryman.com/work/mira - Year: 2024–25 - Role: Operator experience, information architecture, and on-site research. Data science and engineering owned the model and infrastructure. - Team: Product team with data scientists, cloud engineers, plant metallurgists, and operations staff. - Result: Delivered recommendation review, history, and blend-calculator designs with explicit forecasts, data recency, and operator choices. - 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 on-site research, I designed a review flow showing operators the forecast, current setting, and consequences of accepting, adjusting, or rejecting a recommendation. #### A recommendation operators cannot challenge gets ignored MIRA recommends operating changes in the molybdenum leach circuit at Sierrita, outside Tucson. Operators already had a bleed calculator and years of judgment. The interface needed to make each prediction inspectable before asking them to act. The fresh-ferric screen below puts the forecast for the recommendation beside the forecast for the current setting, against the same spec limit. Accepting, adjusting, and rejecting remain explicit choices. > The interface's job was not to be believed. It was to be verified. #### On-site, October 2024 A day with operators and metallurgists revealed two structural constraints: lab assays arrive hours after the material they describe, and decisions cross shift handoffs. The person who acts may not be the person who reviewed. I made data recency explicit on the home screen. Calculator runs can be shared by URL or committed as a strategy with an author and timestamp. The blend input screen keeps lot selection beside the assay data needed to judge it. #### The screen the product exists for Review uses five steps, one recommendation type per step. On the fresh-ferric screen, six impurities share an axis and spec line. Solid lines become dashed at the forecast boundary; two colors distinguish the recommended and current settings. Accept and reject show their setpoints, making disagreement as legible as approval. Expanded charts and table views preserve precise values when the shared scale compresses smaller ranges. #### Trust as a first-class metric The home screen exposes recommendation approval and the share of days anyone reviewed. These distinguish disagreement with the model from a recommendation no one examined. The blend calculator applies the same scrutiny to its output: days beyond target appear first, ahead of positive results. The arithmetic and compliance meters below let operators check the result instead of accepting a summary. #### What the evidence supports In a monitored seven-day comparison, internal tracking put recommended fresh-ferric addition roughly 20% below the legacy bleed calculator. Savings still needed month-by-month validation; this is not an annual or dollar claim. The home screen and blend calculator retain different chrome because the design system caught up mid-project. I chose not to rework a surface already used on shift; unifying those interfaces would be the next design improvement. Data science and engineering owned the model and infrastructure. #### Decisions **1.** Make reject a full third option with its numeric consequence printed on it, rather than accept-or-dismiss. - Tradeoff: A third action requires a distinct recorded state and clear confirmation of the retained setting. It also makes disagreement visible alongside approval, which complicates a simple adoption narrative. - Outcome: Operators can record disagreement with a specific recommendation while retaining the current setting. The review history distinguishes that choice from a recommendation that was never reviewed. **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: A consistent scale and spec line make breaches easier to scan across elements. Expanded charts and table views preserve a route to precise values. **3.** Print the model's rejection rate and the staleness of the lab data on the operator home screen. - Tradeoff: Data lag and low approval can reduce confidence in a recommendation. Making them visible requires the interface to support scrutiny as well as action. - 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. ### Company-wide ServiceNow platform: Making employee support easier to navigate - URL: https://hughberryman.com/work/servicenow - Year: 2025 - Role: User interviews, navigation architecture, and visual design. Platform developers implemented the shipped experience. - Team: Primary stakeholders, key power users, platform developers, and IT service owners. The developers implemented the shipped experience. - Result: Shipped revised navigation, request flows, and a shared visual system with the ServiceNow development team. - Tags: User research, Information architecture, Navigation, Visual design, Enterprise platform I researched and redesigned how employees find help, submit requests, and track progress in ServiceNow. The company-wide platform serves a workforce of approximately 28,000, with clearer navigation and a shared visual system. #### Finding the right form was the first problem Employees struggled with confusing catalog labels, overlapping categories, and the distinction between incidents and requests. Tickets were misrouted, while broad Other Requests categories absorbed work that belonged elsewhere. The research workspace below captures the interviews behind the redesign. The first task was to clarify how employees enter support, then make that route consistent across the interface. > The employee's first decision should be what they need help with, without having to learn how the platform organizes it. #### Deep interviews before new navigation I conducted in-depth interviews with primary stakeholders and key power users, then combined them with survey planning, CSAT analysis, personas, and request-path synthesis. The focus was specific: where employee language diverged from catalog labels, which paths mattered most, and which groupings or entry points needed to change. That gave stakeholders a shared basis for revising familiar routes. #### Re-architecting the navigation flow I re-architected the navigation flow around finding help, starting a request, and returning to submissions or approvals. Search, frequent destinations, and personal work become clear entry points. The design file connects those routes to feature flows and a shared token sheet. Page hierarchy, catalog patterns, and content priorities reinforce the same navigation model. #### A visual system the platform could support A clearer type hierarchy, restrained color, consistent spacing, and reusable card and navigation patterns gave the experience a common visual language. I translated that system into global design tokens and ServiceNow-compatible SCSS guidance. Developers could apply it beyond the initial Figma screens while working within the platform's constraints. #### Shipping inside ServiceNow Platform developers implemented the experience. I worked with them on navigation, interface patterns, and CSS primitives to carry the research-backed design into the shipped platform. The company-wide redesign served a workforce of approximately 28,000. That describes organizational scope, not active users. Post-launch adoption and task-efficiency changes were not measured, so the supported outcome is the shipped modernization. #### Decisions **1.** Interview primary stakeholders and key power users before defining the new navigation. - Tradeoff: It delayed visible interface work and surfaced needs that could not all fit into one navigation model without prioritization. - Outcome: The architecture was grounded in how the platform's most important audiences actually worked, giving stakeholders a shared basis for changing long-established flows. **2.** Re-architect the navigation instead of preserving the legacy flow under a new visual layer. - Tradeoff: Changing familiar routes creates more implementation and change-management work than a reskin, especially for power users who have learned the old structure. - Outcome: The shipped experience gave employees a coherent hierarchy for finding help, starting work, and returning to tasks already in progress. **3.** Express the modernization as reusable tokens and platform-compatible patterns, not isolated page comps. - Tradeoff: The system work is less immediately visible than a sequence of polished screens and still depends on implementation discipline inside ServiceNow. - Outcome: The modern visual language could extend beyond the initial screens and remain consistent as platform developers applied it across the employee experience. ### Tribal Credit / Product design & leadership: Tribal Platform: one experience across web and mobile - URL: https://hughberryman.com/work/tribal-platform - Year: 2020–23 - Role: I joined as Tribal's first product-design hire, designed and shipped mobile experiences in React Native, and grew into Director of Product Design as the company scaled from Seed to Series B. - Team: I grew and led a team of 10 product designers, partnering with product, marketing, and engineering while staying hands-on with the product and design system. - Role progression: Product Designer & React Native Developer (Jan 2020 – Mar 2021); Senior Product Designer (Mar 2021 – Mar 2022); Director of Product Design (Mar 2022 – Nov 2023) - Result: Delivered core web and mobile experiences, shipped Tribal Pay in React Native, and established Centro, the company design system, alongside a growing team of 10 product designers. - Tags: Product design, Design leadership, Design systems, React Native, Mobile, Fintech As Tribal grew from Seed to Series B, my work expanded from designing and building the core product to leading the design team. The challenge stayed consistent: make cards, payments, and account management feel like one product across web and mobile, even as more designers worked on it. #### One product across different screens I started with the core web and mobile experiences, including designing and shipping Tribal Pay in React Native and Expo. I built the early Figma system and brought its color foundation into the app codebase. The platform needed a common language for balances, cards, transactions, and actions. The screens shown here carry that language across mobile navigation, web tables, and detailed card controls while giving each format the space it needs. #### Shared standards for a growing product As the product expanded, multiple designers needed to work on different flows without creating separate visual systems. I established guidelines and working processes that kept those contributions aligned and supported iterative review. That work developed into Centro, the company design system. Shared patterns gave the team a foundation for experiences such as card management and bulk payments, where navigation, status, and next steps need to remain clear through a more involved task. #### Growing the team with the platform After the Series A and B rounds, my focus broadened to scaling the team and the processes around its work. I progressed through Senior Product Designer to Director of Product Design, leading 10 designers and partnering with product, marketing, and engineering. My role connected hands-on product work with the conditions that let others contribute. Clear standards and a shared design system helped the team work concurrently across web and mobile while keeping the platform recognizable as Tribal. #### Decisions **1.** Carry a shared design language across web and mobile while adapting the layout to each platform. - Tradeoff: Consistency required agreement on common patterns while leaving room for mobile navigation and denser web workflows. - Outcome: Cards, payments, and account views share a visual foundation across the platform. **2.** Invest in a shared design system and working processes as the design team grew. - Tradeoff: Maintaining the system and aligning contributions became part of the team's ongoing product work. - Outcome: Centro gave a team of 10 designers a common foundation for concurrent work across the product. ### Tribal Credit / Reporting & data visualization: Tribal Reports: from V1 to V2 - URL: https://hughberryman.com/work/tribal-reports - Year: 2020–23 - Role: I designed the initial vision for Tribal Reports across mobile and web, then updated the experience to Tribal's V2 design system. - Result: Carried Reports from its initial design into V2, applying the updated design system to spending insights, transaction lists, and supporting states. - Tags: Product design, Data visualization, Design systems, Responsive design, Mobile, Fintech I designed Tribal Reports to make spending data easier to navigate across mobile and web. When Tribal's design system evolved, I refined the reporting experience for V2 while preserving its core functionality. The mobile screens below show that progression. #### Making spending data easier to explore The initial challenge was to make complex reporting approachable on both mobile and web. I designed an interface that let users choose a time period, explore spending by category, and move from an overview into transaction details. The component work brought together donut and line charts, a shared data-visualization palette, date selectors, legends, and transaction rows. Loading and selection states were part of the design, so the experience extended beyond a single populated report. #### Refining the experience for V2 V2 needed to adopt the updated design system without losing the reporting functionality. I refined the visual hierarchy and layout around date ranges, filters, spending totals, and the switch between Insights and All Transactions. The light and dark mobile designs show how those patterns carry across different presentation modes. Updating Reports meant applying the system to the whole experience: chart summaries, transaction status, navigation, and the controls people use to narrow their view. #### Decisions **1.** Use the V2 design system to refine the existing reporting experience. - Tradeoff: The visual language needed to evolve while preserving the reporting tasks and functionality from the first version. - Outcome: Spending insights and transaction views adopted shared patterns for hierarchy, navigation, filters, and status. ### Tribal Finance / DeFi & crypto: Tribal Finance: connecting brand and product - URL: https://hughberryman.com/work/tribal-finance - Year: 2020–23 - Role: I supported product design over three years, working with the team on brand and marketing strategy, design-system creation and implementation, and the DeFi product experience. - Result: Helped connect the brand identity, marketing site, and product interface through shared design standards and working processes. - Tags: Product design, Design systems, Brand alignment, DeFi, Fintech Tribal Finance brought together a multifaceted DeFi product and the marketing that introduced it. I worked with the team to align these efforts around users, a shared visual language, and clear product experiences. #### A shared language for brand and product The challenge was to align the team around a user-centered, product-focused approach while developing the brand. I helped establish processes that connected design decisions with marketing strategy. The identity treatments show a consistent wordmark across light and dark backgrounds, providing a recognizable starting point for the product and marketing surfaces. #### Making component states explicit I worked with the team on creating and implementing the design system. The UI kit documents alert anatomy, status colors, and subtle and solid variants alongside the component library. Defining these states gave designers a common reference for communicating information, success, warnings, and errors across the interface. #### Connecting the introduction to the experience The marketing page introduces lending and borrowing, explains the flow, and presents lending insights. The account views carry that story into balances, earnings, portfolio composition, and activity. Keeping those surfaces aligned was central to my contribution: helping design and marketing work toward one coherent product experience. #### Decisions **1.** Develop the brand and product within a shared design language. - Tradeoff: Marketing needed room to explain the offering, while account screens needed to make financial information easy to scan. - Outcome: A common identity and component system connected the landing page with the mobile and desktop account views. ### Tribal Credit / Design system: Centro: a shared language for Tribal - URL: https://hughberryman.com/work/centro - Year: 2020–23 - Role: I conceptualized and implemented Centro during my time at Tribal, leading the design team in defining shared components, colors, and interface guidelines. - Result: Established a common design language that supported more consistent product work and reduced the need to resolve the same interface decisions across projects. - Tags: Design systems, Design leadership, UI design, Figma, Fintech As Tribal's product and engineering teams grew, their interfaces needed a more consistent foundation. I developed Centro with the design team to bring reusable components, a unified color palette, and UI guidance into one shared system. #### Giving a growing team a common foundation Different design practices were producing inconsistent interfaces and slowing development. Centro gave the growing team a shared foundation for colors, typography, icons, and elevation. #### Turning repeated decisions into reusable patterns I led the design team in formalizing reusable components and UI guidelines around Tribal's product needs. Specifications for anatomy, sizes, and interaction states made those decisions available to both design and engineering. ### Tribal Credit / Marketing & editorial design: Tribal Marketing Blog: bringing the brand together - URL: https://hughberryman.com/work/tribal-marketing-blog - Year: 2020–23 - Role: I worked with Tribal's marketing team to integrate Centro with the existing brand guidelines and redesign the blog's visual presentation. - Team: Collaboration between product design and marketing. - Result: Resolved styling inconsistencies through a shared approach to product design and marketing, giving the blog a coherent Tribal identity. - Tags: Web design, Design systems, Brand alignment, Editorial design Tribal's marketing blog needed to feel connected to the wider brand. I worked with marketing to bring its typography, colors, and interface components into alignment with Centro and the team's existing brand guidance. #### Connecting two sets of design guidance The blog's visual elements had become inconsistent, weakening the connection to Tribal's brand. The redesign needed to bring those elements together while preserving the blog's function as a communication channel. I initiated the integration of Centro with marketing's existing brand guidelines, working with the team on typography, color, and UI components. The collaboration gave both teams a common basis for decisions about the blog's presentation. ### Tribal Credit / Design leadership & operations: Design Team Jams: aligning how the team works - URL: https://hughberryman.com/work/design-team-jams - Year: 2020–23 - Role: I led a review of design and product processes, tools, and costs, and facilitated workshops to align the teams around shared product goals. - Result: Helped align the teams around a common product direction and a more coordinated approach to tools, processes, and collaboration. - Tags: Design leadership, Design operations, Facilitation, Team strategy At Tribal, separate tools and working practices made collaboration harder. I led an initiative to review how design and product worked together, simplify the toolset, and establish a shared direction through workshops and team conversations. #### Reviewing the way work moved between teams Teams were using different tools, processes, and strategies. I reviewed that setup against the product goals, looking at friction, duplicated costs, and disconnected decisions. The planning work covered design reviews, version history, and how initiatives moved across teams. #### Making alignment a shared activity I facilitated workshops and meetings to bring design and product into the same conversation. The shared canvases connected customer goals, proposed workflows, and team development with the practical decisions about how we worked. ### Liquos / Water data & prototyping: Water Report Card: making water data understandable - URL: https://hughberryman.com/work/water-report-card - Role: As a consultant for Liquos, I led the Water Report Card project, developing prototypes with Figma, Next.js, and Mapbox to explain drinking-water data for businesses and consumers. - Result: Created prototypes that connected complex water-data sources with an understandable interface for business and consumer audiences. - Tags: Product design, Data visualization, Prototyping, Next.js, Mapbox Water Report Card explored how businesses and consumers could make sense of drinking-water information. I brought together sensor readings and municipal report data in prototypes designed to make complex measurements easier to interpret. #### Making different data sources understandable The project needed to translate IoT TDSBot readings and municipal water reports for business and consumer audiences. I brought the information together through interface concepts and data visualizations, including dashboard summaries and the empty state before a device is connected. #### Exploring the experience through prototypes I used Figma, Next.js, and Mapbox to develop the prototype experience. Alongside location and water-report exploration, the interface work covered device setup, connection details, input validation, and shared component states. ### Whoin / Community discovery: Whoin: from community idea to mobile app - URL: https://hughberryman.com/work/whoin - Year: 2019–20 - Role: I co-founded Whoin and led its design in Figma and development in React Native, carrying the experience from early designs into a released app. - Result: Launched a community discovery app, carrying the work from interface design through React Native implementation. - Tags: Product design, React Native, Mobile, Co-founder, Community Whoin was built to help people explore communities and make connections. As co-founder, I worked across product design and implementation, using feedback to refine the interface and React Native to turn it into a working mobile app. #### Refining the experience through feedback The goal was to make exploration and connection feel approachable. I designed the interface in Figma and iterated using user feedback. Map discovery, event filters, and community pages gave people different ways to find activities and shared interests. #### Carrying the design into a working app I implemented Whoin in React Native and carried it through release. The connected design canvas covers event creation, messaging, profiles, and the supporting account flows needed to turn discovery into a working community app. ### Daily prompts & reminders: ChillRems - URL: https://hughberryman.com/work/chillrems - Tags: Mobile design, Interaction design, Reminders ChillRems presents one prompt at a time, from calling someone to planning an outdoor activity. The screens explore editable preferences, contextual suggestions, and simple accept or skip controls within a dark, quiet visual style. ### Personal budgeting: Piggggy - URL: https://hughberryman.com/work/piggggy - Tags: Mobile design, Personal finance, Onboarding Piggggy organizes budget setup around three inputs: income, recurring expenses, and a savings goal. The interface moves from empty setup cards to a populated budget, with everyday language for editing an expense and a prominent daily spending amount. ### Android property search: ARMLS: Real Estate - URL: https://hughberryman.com/work/armls - Year: 2018–19 - Role: Product Designer & React Native Developer. Designed and developed the Android application in React Native. - Tags: Mobile design, React Native, Android, Real estate The ARMLS Android experience brings property search and listing details into a mobile interface. Map markers and listing cards lead into photography, property facts, notes, school information, market history, and agent contact options. ### Café discovery & ordering: Pikmeup - URL: https://hughberryman.com/work/pikmeup - Tags: Mobile design, Food & drink, Visual design Pikmeup pairs café photography with a mobile flow from discovery to a shop's menu. The artwork explores sign-in and guest access, café search, item quantities, and quick actions for favorites, directions, calls, and the cart, alongside typography studies. ## Earlier work Earlier projects connected to the employment record, with context, imagery, and case studies hosted on this portfolio. ### Tribal Platform - Case study: https://hughberryman.com/work/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. ### Centro - Case study: https://hughberryman.com/work/centro - Company: Tribal Credit - Period: 2020–23 - Discipline: Design system I created Tribal's shared design system, defining reusable components, a unified color palette, and interface guidelines for its product and engineering teams. ### Tribal Reports - Case study: https://hughberryman.com/work/tribal-reports - Company: Tribal Credit - Period: 2020–23 - Discipline: Reporting & data visualization I designed Tribal's original reporting experience and evolved it with the V2 design system, making spending data easier to navigate across mobile and web. ### Tribal Finance - Case study: https://hughberryman.com/work/tribal-finance - Company: Tribal Credit - Period: 2020–23 - Discipline: Product design & branding I worked with the team to connect Tribal Finance's DeFi product, design system, and brand, establishing shared design processes as the platform evolved. ### Whoin - Case study: https://hughberryman.com/work/whoin - Company: Whoin - Period: 2019–20 - Discipline: Design + React Native I co-founded Whoin, a community discovery app, and took it from Figma designs to a released React Native product. ### Tribal Marketing Blog - Case study: https://hughberryman.com/work/tribal-marketing-blog - Company: Tribal Credit - Period: 2020–23 - Discipline: Web design & branding Connecting a product design system with marketing's brand guidelines to give Tribal's blog a consistent visual language. ### Design Team Strategic Jams - Case study: https://hughberryman.com/work/design-team-jams - Company: Tribal Credit - Period: 2020–23 - Discipline: Design leadership & operations Bringing design and product teams together through a review of their tools, processes, and shared priorities. ### Water Report Card - Case study: https://hughberryman.com/work/water-report-card - Company: Liquos - Discipline: Data visualization & prototyping Translating water-quality readings and municipal reports into prototypes that help people understand their drinking water. ### ARMLS: Real Estate - Case study: https://hughberryman.com/work/armls - Company: ARMLS - Period: 2018–19 - Discipline: Design & React Native An Android real-estate experience connecting map-based search with property details and agent contact options. ### ChillRems - Case study: https://hughberryman.com/work/chillrems - Discipline: Mobile design A mobile interface for personal reminders, activity suggestions, and daily prompts. ### Piggggy - Case study: https://hughberryman.com/work/piggggy - Discipline: Personal budgeting Mobile budgeting screens that connect income, recurring expenses, and a savings goal with a daily spending amount. ### Pikmeup - Case study: https://hughberryman.com/work/pikmeup - Discipline: Café discovery & ordering A mobile café experience with discovery, shop details, menu browsing, and ordering controls. ## 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 and product designer connecting design systems to shipped web and mobile products. Lead design engineering for Prototype Studio at Freeport-McMoRan, enabling designers to build frontend UI through shared GitHub and AI-assisted workflows. Previously shipped fintech products in React Native and led 10 designers at Tribal Credit. Hands-on in React, Next.js, TypeScript, design tokens, and component tooling. ### Freeport-McMoRan Phoenix, AZ · Aug 2024 – Present #### Senior Product Designer · Aug 2024 – Present ##### Prototype Studio & MDS 2.0 - Lead design engineering for Prototype Studio, a live internal tool I designed, coded, and launched. Designers use it to build frontend UI in a shared GitHub repository with branching, pull requests, and agent-readable Skills. - Established a code-first handoff to FORGE, the enterprise AI harness. Refined UI code, prototype JSON stubs, and handoff requirements with developers to improve ingestion. - Led creation of the MDS 2.0 design system in Figma, collaborating with developers as they implemented the updated component library. ##### MIRA: ML Recommendation Engine for Moly Processing - Designed ML recommendation review and feed-blend workflows, with Dutch localization for a five-site production rollout. ##### RAMP: Remote Asset Management Platform - Led design from concept through production, connecting five technical layers in alert triage, approvals, and mobile maintenance workflows. ##### ServiceNow Platform Redesign - Led research and navigation design for a ServiceNow redesign, serving a workforce of approximately 28,000. Translated design-system tokens into CSS/SCSS guidance with developers. ### Qashio Dubai, remote · Nov 2025 – Present Concurrent with Freeport-McMoRan #### Design Consultant · Nov 2025 – Present - Advise on extending a mature Next.js UI into a Figma design system with code as the source of truth, and mentor designers on the workflow. - Defined design-engineering hiring criteria and conducted interviews assessing AI-assisted design-to-code fluency and pull-request literacy. ### Symetra Insurance Remote · Feb 2024 – May 2024 #### Senior Product Designer, Design Systems · Feb 2024 – May 2024 - Extended the design system with Storybook and Chromatic, and created reusable Figma components to align design and development. ### Tribal Credit Remote · Jan 2020 – Nov 2023 #### Director of Product Design · Mar 2022 – Nov 2023 - Led 10 product designers and shipped Centro, a shared design system with reusable components and guidelines for consistent web and mobile experiences. #### Senior Product Designer · Mar 2021 – Mar 2022 - Led design for five expense-management features, expansion into Latin American markets, and card and payments integrations across Marqeta, CurrencyCloud, and Stripe. #### Product Designer & React Native Developer · Jan 2020 – Mar 2021 - Designed and shipped Tribal Pay in React Native and Expo; established mobile architecture with TypeScript and React Query. Built the Figma system and implemented its color foundation in the app codebase. ### Whoin Phoenix, Arizona · Feb 2019 – Jan 2020 #### Co-Founder, Product Designer & React Native Developer · Feb 2019 – Jan 2020 ### 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 & tools ### Capabilities AI agent workflows, Design engineering, Design systems, Design tokens & theming, Reusable components, Design-to-code tooling, Accessibility, Design leadership, Product design & strategy ### Tools & platforms OpenAI Codex, Claude Code, Hermes Agent, MCP, Agent Skills, React Native, Expo, React, Next.js, TypeScript, Tailwind CSS, Flutter, Figma, Figma Code Connect, Storybook, Chromatic, Widgetbook, GitHub, ServiceNow ## Education - Pomona College: Bachelor of Arts, Media Studies. Claremont, California, 2011 – 2015. ## Languages Personal background only. - English: Native - Chinese: Conversational - Spanish: Beginner