Overview

This project emerged from several converging signals. Across the company, there was an ongoing initiative to unify Square and Cash App under a shared visual language. Product designers were independently gravitating toward a black-and-white palette with rounded buttons in their vision work. And we were consistently hearing that the current design system felt stale and outdated.

Then Square's brand team announced they had a brand refresh planned to launch in October. That created the forcing function to take what was already in the air and ship it.

As lead designer, I owned the project end to end: writing the initial proposal, updating Figma libraries across both current and legacy files, documenting changes for engineers, communicating to designers what to expect and when, and overseeing QA to make sure the rollout landed cleanly.

The Brief

The brand team's new direction pointed toward a significantly updated visual language, including a new typeface, lighter heading styles, a shift from blue to black as the primary brand color, and rounder corners throughout. Rather than tackling all of it at once, I proposed splitting the work into two phases.

Phase 1 focused on color and border radius. These are token-level changes that are relatively contained to update and quick to validate, making them the right place to start. Phase 2 would follow with the typeface, type style updates, and additional visual changes like button backgrounds, aligned with where the brand team was heading.

Phase 1 still needed to propagate across Square's entire product ecosystem — 19 teams, 130 designers, over 1,000 engineers, multiple platforms, and several legacy design systems — all within a 6-month window.

Process

1. Proposal

I created a proposal outlining the scope and approach for the design system update and presented it to the head of design for alignment.

2. Stress-Testing

Before executing, I recreated key product flows in the new visual direction to stress-test the changes, surface edge cases, and inform decisions before full rollout. We also built a custom theme on top of Storybook so engineers and designers could interact with a working proof of concept — exploring the updated colors and border radii applied across real components before anything shipped.

3. Usability Testing

Working with UX research, we ran usability testing to validate that the black system maintained the same level of usability as the blue, paying close attention to interactive affordances, focus indicators, and component states where color carried meaning. We also partnered with data science to define key metrics upfront and monitor them post-launch, ensuring the visual change didn't negatively impact task completion or error rates.

4. Figma Library Updates

Working in a Figma branch, I updated the library to reflect the new visual direction. This included updating variables for color and border radius, and applying those changes across component styles throughout the system.

5. Token Documentation

I maintained a spreadsheet documenting every design token change, organized by component, so updates were traceable and engineering had a clear implementation reference.

6. QA & Rollout

I QA'd all design system updates myself, then led company-wide QA sessions with designers across all 19 teams to ensure consistent adoption before launch.

7. Legacy Systems

After the primary system launched, I went back and updated legacy surfaces and design systems to bring them in line with the new visual direction.

Overview

I identified a recurring problem through designer and seller feedback: Market was looking too small on Square Register. Square Register runs Squid, Square's custom operating system. Unlike iOS and Android, it does not support text scaling through accessibility settings.

The design system had a single size and type scale for all platforms and devices. This became a blocker for product teams wanting to adopt the design system and migrate away from legacy systems.

Research

Before proposing a solution, we ran a multi-source research effort to understand the full scope of the problem:

• Collected seller feedback from multiple teams across the company
• Conducted in-person testing with sellers on actual devices
• Tested apps ourselves across iOS, Android, and Square Register
• Gathered feedback from product designers
• Reviewed competitor and parallel apps for sizing approaches
• Ran discovery sessions with engineering to explore technical options

Options Explored

We evaluated four technical approaches before landing on a solution:

DPI Adjustments

Not cross-platform — only solves for the X2 device. Doesn't work well for flows like checkout. Everything has to scale the same, so you lose the ability to tune things like font tracking or scale text and spacing differently (text should generally scale more than spacing). Also confusing and hacky to understand, especially for engineers.

Adding More Component Sizes

Requires every team to have an engineer manually update the size of every component. The size jump needed from medium to large feels too big to be a set. Positioning it as a set rather than a mode also gives designers too much freedom to mix and match sizes on a single screen.

Create a Large Theme

Engineers would apply a theme at an app or device level: Regular (1x) for current Market, Large (~1.3x) for X2 or iPad POS apps, and Jumbo (~1.5x) for buyer-facing screens like the checkout flow. This is harder for the systems team to maintain and more breakable. It's also less flexible for sellers who don't want the larger sizes.

Dynamic Sizing (chosen)

Similar to Apple's dynamic type for accessibility, this approach gives Market a spectrum of sizes adjustable by the seller. POS apps and the X2 device would default to a larger size, available in Figma. Sellers could then override the size if it doesn't work for them.

Solution: Dynamic Sizing

The dynamic sizing system works similarly to Apple and Android dynamic type. It provides a range of size options, with the default set to a larger size for Square Register. As component sizes increase or decrease, both type and spacing scale together, ensuring things look proportional across the full range.

An added benefit: sellers can adjust their preferred size in device settings, giving them direct control over their experience at the counter.

We designed and tested a few different size ramp options, then brought in eight designers across various product areas to validate the approach in real product contexts.

Validation & Status

Eight designers across different product areas tested the sizing system in their own work. We also conducted in-person testing with sellers on actual Register hardware.

Initially, a handful of product designers pushed back on the project. By the end, all of them were regularly asking for updates, pinging to find out when it would be ready because they wanted it for their teams.

The feature shipped in Figma and code. I was laid off before the full rollout. Seller demand remained consistently high throughout the project, and designer sentiment shifted from early skepticism to strong advocacy.

Experiment 1: Editing our Figma library with Figma Console MCP

I used Figma Console MCP with Claude to explore what bulk design system operations could be automated. Things I tested:

• Token cleanup across the library
• Proposing and applying semantic token updates
• Creating new components from scratch
• Refactoring existing components
• Generating documentation artifacts: bulk color swatch pages, type style pages

Experiment 2: Vibe Coding Tool for Market Design System

Working with Square's web engineers, I helped build a tool that lets designers generate real UI using actual design system components via generative AI.

Instead of mocking up designs and handing them off to be rebuilt in code, designers could describe what they need and get working UI that's already using the right components, on-system by default.

The video below is a casual recording I made to share the work with my immediate design systems team on Slack.

Challenge

I joined Limbix as the first designer about five months before the product launch date. At the time the company only had a logo and a couple months of engineering work that was styled with default bootstrap components.

My task was to come up with branding and a from-scratch design system that was versatile enough to use across web and iOS/Android mobile apps (built using React).

A year later, our startup decided to completely rewrite and redesign our product for an Android tablet app, as well as add a VR interface. This gave me a unique opportunity to completely rebuild our design system while making sure it stayed consistent with our existing branding.

This case study documents the process of creating and updating a design system at an early stage startup. The process is particularly challenging given the fast-paced nature of startups. As with any software company, at a startup it's essential to organize and consolidate components into a design system in order to build a consistent product as quickly as possible. At the same time, startups have fewer design resources and are more likely to encounter rapid change which can make organizing and documenting design systems difficult.

Part 1 — Creating a Design System from Scratch

I only had five months until launch, and the product had a huge scope: a responsive web app with separate therapist and patient experiences, a patient-facing iOS & Android mobile app, and a therapist-facing Android app for managing content and launching Daydream VR. I also had to design our marketing site and carry out enough UX research to have a solid understanding of our users and validate design choices.

Stakeholder Alignment

The first thing I did as a new employee was complete individual stakeholder interviews with my team members. This was to see if we were all aligned on the desired look and feel of the brand, as well as the purpose and direction of the product. As a group we agreed on several adjectives and I created a mood board presentation to help visualize our options.

Style Guide

From there I made a base style guide with grids, type, and color that I updated and expanded upon throughout the product design process. I opted for system fonts for the product since we were moving fast and working with so many different platforms, but used Apercu as the brand font for the marketing site. I also made small tweaks to our logo to make it bolder and match the rest of our branding.

Building Components

Designing the product from scratch meant that I was constantly creating new components as I designed different pages, then reusing those components whenever possible. One of the benefits of being a design team of one is that I knew both the visual traits and function/behavior of each component, which made it easier to keep the product consistent. With limited time, I went straight from sketching and iterating with teammates to high-fidelity designs.

During the two weeks around launch, I hired a remote, part-time freelancer to help me stay on top of organizing and converting components into symbols within Sketch. We used Abstract to allow us to work on the same Sketch files. She used atomic design system naming conventions, and the file was later called "the most organized Sketch file I've ever seen!" by an employee at a design school where I mentored.

I kept the mobile and web app files and components separate to keep things simpler — for example, the Android-only app required Roboto type styles which would have crowded the web app interface.

Part 2 — Redesigning for an Android Tablet App

After a year, we decided to focus solely on the VR side of our product and to rewrite and redesign our product for an Android tablet in kiosk mode. This was a fantastic opportunity to update our design system from the ground up as well as build out a version of the design system to use within VR. While I left the colors the same so the brand would be recognizable and continue to pass accessibility standards, I also made several improvements.

1. More Consistent

I had started our product style guide with system fonts in order to keep web/mobile speeds quick, but switched to our brand font Apercu in order to keep the digital experience more consistent. Moving to a single device also allowed me to simplify components so there would be less variation for different platforms.

2. Bigger Type and Buttons

Since all interactions in the new product would be through touch, I made everything larger and more legible. This has a nice, bold feel and has the added benefit of being easier to read and use.

3. Better Naming & Documentation

I added better documentation by turning the design system into a separate Sketch library with pages showing sample components and explaining how to use them. This makes it easier to collaborate with other designers in the future while also protecting the official design system from accidental changes. I updated naming conventions from atomic-design specific to groupings that better matched my mental model — for example, "buttons" instead of "atoms/buttons". I also made improvements to nested symbols to help consolidate components.

Background

Slapdash was a Y Combinator startup with a command-based interface for quickly searching for or creating files across web and native apps, as well as saving documents from different apps in one place. It was acquired by ClickUp in 2022.

I took this on as a side project alongside my full-time role, contributing focused design systems work across three areas.

1. Established Initial Design System in Figma

Slapdash had a product but no organized design system. I audited existing UI patterns, identified inconsistencies across components, and established the initial system in Figma — creating a shared foundation for buttons, type styles, color, and core components that the team could build from consistently.

2. Cleaned Up Main Dashboard / Card System

The main dashboard was the core of the Slapdash experience — where users saw their apps, recent activity, and saved documents. I cleaned up the card system and navigation to create better visual hierarchy and consistency, making it easier for users to scan and navigate their content at a glance.

3. Reworked Marketing Site

The existing marketing site wasn't effectively communicating Slapdash's core value proposition. I reworked the layout and content hierarchy to more clearly convey what the product does and why it's useful — leading with the key user benefits and using the product UI to show rather than tell.

Background

Notable Systems' product allows outpatient surgery centers to digitize paper forms without changing their existing workflows. Surgical rooms have to be sterile, so bringing an electronic device into the room is not feasible. But using paper forms requires manual labor to file and audit form data, as well as analyze company operations to improve efficiency.

Their system solves this problem by using barcode stickers and a high-speed scanner to quickly process batches of paper forms. They then computationally parse the forms to remove identifiable information and translate the written data to digital with mechanical turk.

Surgery centers set up audit rules (for example, certain forms must have a surgeon signature, or all forms for one surgery must have the same surgery start time) and are alerted when there are errors. They can also analyze the data across surgeries to find operational inefficiencies (for example, Dr. Doe is always 10 minutes late).

Challenge

The client approached me to design the entire interface for their product — a web app used to audit and analyze surgery forms as well as a display for their scanner. When I started, they already had a style guide and the back-end built for a few of the pages. I took this freelance project on in addition to my full-time job leading design at a startup, so I had limited time to work on it.

Process

I started by making a few minor changes to the existing style guide. The client didn't want to overhaul the style, but I changed the type sizes and weights to add contrast and hierarchy. I also changed the primary button colors so they passed accessibility standards and added some additional colors for UI details like hover states or borders.

Since there was no time or budget for extensive UX research, I completed interviews with the stakeholders, who had done their own informal research. I built a rough timeline for the project, and for each section of the app I went through sketching, iteration and client review before finalizing the UI.

The main goals of my design were to:

1. Make statuses extremely clear.

This would help staff tell at a glance what was happening with a surgical chart — whether it was the scanner display showing the chart finished scanning or the web app indicating which charts were ready for review.

2. Make it easy to find and correct form issues.

In this case, helping surgeons address errors quickly would save the centers from expensive liability issues and could even help prevent life-threatening mistakes.

I designed the web and scanner interfaces in about 50 hours over 2.5 months. Since users would be on desktop only, we decided not to prioritize mobile screen sizes (though the site is mostly responsive). I also saved design time by starting with a template for tables in Sketch that I tweaked to fit my baseline grid and colors. Since we were using bootstrap tables, I worked with the front-end developer to get the appearance to be what I designed.

Here's an example of one of the whiteboard sketches I made to discuss with my clients before creating digital designs: