ShootProof Design System · Mindy Lee
✕
ShootProof

ShootProof Design System

Laying the groundwork for a scalable, inclusive system.

ShootProof Design System

Touch Targets

Example

Touch targets are the parts of the screen that respond to user input. They extend beyond the visual bounds of an element. An icon may appear to be 24 x 24 px, but the padding surrounding it comprises the full 44 x 44 dp touch target.

44 ◉ 36
44 ◆ 40
44 Payments
ShootProof Design System
version 3.0

Pill

Pills allow users to categorize content. They can represent keywords, filters, categories, and are grouped to describe an item.

Medium
Default Label Hover Label Focused Label Disabled Label Long pill This is an extra long label that trun… Activated ✓ Label Error Label ✕
ShootProof Design System
version 3.0

Accessibility

Principles baked into every pattern, not checked at the end.

Color contrast, never color alone as an affordance
Typography that scales
Touch targets aligned with iOS and Android guidelines
Labels and alt text on links, icons, and images
Natural tab ordering
Closed captioning for videos
Aa
12.4:1 AAA
Aa
6.8:1 AA
Aa
8.1:1 AA

The situation

Four acquisitions in quick succession sounds exciting, and it was, but it also meant four different sets of design habits, patterns, and assumptions all colliding inside the same product. There was barely any shared documentation, and the result of that was teams were building in parallel without a common language.

It worked fine for a while. But as design grew, the cracks started showing. Shipping anything new meant rediscovering decisions that had already been made somewhere else. It wasn't sustainable.

My first move was to just go look at everything. I did a deep audit alongside designers and developers to discover what patterns were actually working, what was broken, what was duplicated, and what was quietly causing pain nobody had named yet.

From there I built a plan and started consolidating. The goal was a shared component library that teams could actually rely on, so that every new feature didn't start from zero, and so new acquisitions had something real to plug into instead of a blank slate.

The downstream effect: faster shipping, less rework, and a product that felt like it came from one team.

Theming tokens
token
A
B
C
D
background-brand-strong
background-default-subtle
radius-default
4 px
14 px
2 px
6 px
border-default
none
none
1 px solid
1 px dashed
font-display
Söhne
Raleway
Georgia
Karla
One component. Four themes. No forks.

Make it inclusive by default

One of the most meaningful pieces of this work was a full accessibility audit using Axe and Google Lighthouse. What came back was a pretty honest list of things we hadn't been intentional enough about, like low color contrast, missing alt text, unlabeled form elements, no keyboard navigation, and touch targets that didn't meet iOS or Android guidelines.

Rather than treat these as one-off fixes, I took the lead on documenting accessibility as part of the system itself. The idea: bake it into every component from the start, so it's not something you have to remember to check at the end.

The principles we worked from included color contrast (and not relying on color alone to communicate meaning), scalable typography, appropriate labels and alt text, natural tab ordering, and closed captions for video. Small things individually, but together they meaningfully expanded who could actually use the product.

Who we design for
Visual, physical, hearing, and cognitive impairments
Visual, physical, hearing, and cognitive impairments we designed against
Guiding principles
Color contrast, and not depending solely on color as an affordance
Ensuring typography scaled
Ensuring touch targets were aligned with iOS and Android guidelines
Appropriate labels and alt text on links, icons, and images
Natural tab ordering
Closed captioning for videos
Axe + Lighthouse
94 AFTER
before61
after94
✕Contrast below 4.5:1 on secondary text
✕Icon buttons missing accessible names
✕Focus order broken inside modals
✓Fixed in the shared components

Documentation and components

Every pattern shipped with documentation: when to use it, how it behaves, and the accessibility rules it already follows. Tokens gave each theme its own look without forking the components.

Tokens
background-brand-strong
#3D92D6
background-default-subtle
#14283A
background-danger-strong
#D1584F
background-success-strong
#5FB95F
text-default
#F2EFE9
text-subtle
#A8A49C
border-default
#2A2926
icon-accent-default
#A06FE0
Touch targets
Icon button
24 px icon · 44 dp target
Payments
Text button
min height 44 dp
Radio
padding carries the target
44 dp minimumiOS + Android
Foundations
Display32 / 1.1
Heading20 / 1.3
Body14 / 1.6
Caption12 / 1.5
4 · 8 · 16 · 24 · 32
GalleriesLive
Invoice
Wedding package$2,400
Second shooter$450
Total$2,850
Send invoice
Client mobile
Favorites All
♥ Download

What changed

A design system isn't glamorous work and now more important than ever, it's the kind of thing that makes everything else go faster. One solid foundation. One source of truth. One shared language. 

Speed
Faster to ship

New features started from shared components instead of zero, with less rework along the way.

Alignment
One shared language

Four products designed and built from the same library,.

Inclusion
Accessible by default

Contrast, labels, tab order, and touch targets were built into components