← Back

Colorpal

A palette library organized around the image a color set came from, so saved palettes get reused instead of regenerated.

Project overview

Type: Product · 5-week 0→1 · web app + browser extension (for one-tap copy)
Project type: 0→1 · Creative Tool · Personal Library · Reuse & Retrieval
Role: Lead Product Designer · UX Research · Interaction Design · Experiment Design
Methods: First-click & 5-second tests · recognition study · unmoderated usability · A/B
Tools: Otter.ai · Maze · Figma + Dev Mode · Amplitude · Statsig
Case thesis: Designing a color-palette library that keeps the source image as a palette's recognition anchor and its colors one tap from the clipboard, so the palettes a designer saves stay findable and get reused.

The context

Illustrators and designers collect color inspiration constantly (a film still, a photo, a piece of packaging), saving it as screenshots, Pinterest pins, or generated hex sets. That inspiration scatters across tools and camera rolls, stripped of why it was saved, so when a designer needs a palette they tend to start fresh each time.

The problem

Saved palettes do not get reused. In research, color inspiration a designer had saved was reused later only 17% of the time (behavioral, self-report + library audit), and in a recognition test designers could find a specific palette they had saved a week earlier from its swatches and name only 41% of the time (behavioral). A set of hex codes is unrecognizable months on, and a saved screenshot is not a usable palette, so the saved item became noise.

The goal

Make a saved palette findable, recognizable, and reusable, measured by reuse rate, recognition and find time, and retention, rather than by how many palettes a designer could store.

Empathize — Designers recognized a saved palette by its source image, and from swatches and a name they found it only 41% of the time

In this section: Research foundation · Key insights

Research foundation (method)

Phase 1 — Interviews (n=18, ~35 min, illustrators and designers, recruited via dscout, transcribed in Otter.ai): how they collect, store, and return to color.
Phase 2 — First-click & 5-second tests: on a library screen shown for five seconds, which palette designers could locate and click first, run for a swatch-led grid and an image-led grid, which favored the image-led layout before the full recognition study.
Phase 3 — Recognition test (n=24): designers found a specific palette they had saved a week earlier, once from swatches and a name, once from the source image.
Phase 4 — Survey: ~904 invited; 170 analyzable responses (18.8% response rate); ~118 completed every item (13.0% completion rate). Attitudinal percentages are computed on the 170 analyzable responses; question types are labeled per question in the appendix.
Phase 5 — Prototype pilot (Amplitude-instrumented, 60 designers, ~30 per A/B arm, spring 2025): behavior on the image-first library.

Key insights

1. Designers recognize a palette by its source image, and swatches read as interchangeable. A row of saved palettes shown as swatches and names blurred together, while the same palettes shown as their source images were recognized at a glance. Triangulation:

Behavioral: find success from swatches and name 41%; from the source image 89%.
Verbatim (D6, illustrator) — coded: Visual recognition: "I don't remember it as five hex codes, I remember it as the moody photo of the harbor at dusk."

2. Inspiration is saved as images and rarely becomes a usable palette. Designers screenshotted color they liked and left it in a camera roll, never translating it into colors they could apply, and the reason they saved it faded.

Attitudinal: the most common reason given for not reusing saved color was no longer remembering why it was saved or what it was for.
Verbatim (D13, brand designer) — coded: Lost intent: "My camera roll is full of color I loved, but I have no idea now what any of it was for."

3. The deliverable is still the color value, so copying has to be instant. Recognition gets a designer to the palette; the action that delivers value is copying a specific color into their tool.

Behavioral: copying a hex was the single most frequent action designers wanted, and any friction on it sent them back to a generator.
Verbatim (D2, product designer) — coded: Copy friction: "If I can't just grab the hex in one click, I'll honestly just regenerate a new palette instead of digging for the old one."

Dashboard — Why saved palettes go unused

Why saved palettes go unused
Scope: recognition test (n=24) + survey (n=170)
Guiding question: Can designers find and reuse the palettes they saved?

  Find a saved palette from swatches + name .. 41%
  Find the same palette from its source image  89%
  Saved color inspiration ever reused ........ 17%

Key Insight: Recognition runs on the source image, and a swatch-and-name
library hides exactly the thing designers recognize palettes by.

Define — A palette had to be found and recognized by the image it came from, then copied in one tap

In this section: POV · How Might We · Principles · Insight→decision map

POV statement. An illustrator or designer needs to find and recognize a saved palette by the image it came from and then copy its colors, because hex codes alone are unrecognizable months later and a saved screenshot is not a usable palette.

How Might We

How might we make a saved palette recognizable at a glance, months later, across a growing library?
How might we keep the why and where-from context attached so a palette stays meaningful?
How might we make copying a color the single fastest action in the tool?

Design principles (each traceable to an insight)

The source image is the anchor. A palette is found and recognized by the image it came from, with swatches alongside. (Insight 1)
Context travels with the palette. Reference images, tags, and a note on use stay attached, so the reason a palette was saved is never lost. (Insight 2)
The color value is the deliverable. Tapping any color copies its hex to the clipboard with no extra step. (Insight 3)
The colors are the designer's pick. Colors are sampled from the reference image, so the palette holds the specific tones the designer saw and chose.

Insight → decision map

Insight (from Empathize)	Concrete design decision
Find success 41% from swatches, 89% from the image	The library grid leads each card with the source image, with the swatches and name as support
Designers forget why a palette was saved	Each palette carries its reference image(s), tags, and a note, viewable from the palette, and the grid filters by tag
Copying a hex is the value action	Tapping any color in a palette copies its hex to the clipboard in one action

Ideate & Craft — The library led with the source image; the colors stayed one tap from the clipboard

In this section: Design execution · How colors are sampled · Before → after · Other deliverables

Design execution

Image-first library grid — each palette card leads with its reference image, with the color swatches and name beneath, so a designer scans a wall of images they recognize. Tags filter the grid down to a mood or project.
One-tap copy — inside a palette, tapping any color copies its hex to the clipboard immediately, the most frequent action made the lowest-friction one.
Attached context — a palette holds one or more reference images, viewable from its name, plus tags and a short note on where the colors came from and what they are for.
Pick from the image — colors are sampled from the reference image, so the palette holds the specific tones the designer chose rather than a muddy average of the photo.
Status of a palette as a working set — a designer builds, names, tags, and returns to palettes as reusable assets.

How colors are sampled (the mechanism, made explicit)

Colors come from the designer, not an averaging algorithm: an eyedropper on the reference image lets them pick the exact tones they saw, and an auto-suggested set seeds the palette which they then adjust. This is why the saved palette holds "the specific tones the designer chose" rather than a generated approximation — the picking is a design decision, and the sampled hex is what later copies to the clipboard.

Before → after

	Before (generators / screenshots)	After (Colorpal)
How a palette is recognized	Swatches and a name, or a screenshot	Its source image, leading the card
The reason it was saved	Forgotten	Reference image, tags, and a note, attached
Getting a color out	Re-pick or regenerate	Tap the color, hex on the clipboard
The colors themselves	Auto-averaged or guessed	Sampled from the image by the designer

Other deliverables

Built in Figma with Dev Mode handoff: the image-first card and grid, the in-palette copy interaction, the reference-image viewer, and the tag-filter system.

Dashboard — Image-first recognition drives reuse (A/B: rejected swatch-first vs shipped image-first)

Image-first recognition drives reuse
Scope: Last 30 days · pilot · swatch-first (A) vs image-first (B)
Guiding question: Did leading with the image make palettes findable and reused?

  Find a saved palette (recognition) .... 44% (A) → 89% (B)
  Median time to find a palette ......... 38s (A) → 7s (B)
  Saved palettes reused ................. 17% (real-world) → 63% (tool)

Key Insight: Leading the library with the source image made palettes
recognizable, so designers reused what they had saved.

Prototype / Test — A swatch-first grid looked like a palette tool and made saved palettes hard to find; leading with the source image fixed recognition

In this section: The experiment · What it taught

The intuitive first design showed each palette as its color swatches and a name, the way a palette tool usually looks, with the reference image tucked behind a tap on the name. It was A/B tested against the image-first grid in Statsig across the pilot.

The failed variant. The swatch-first grid was clean and read clearly as a color tool, but at library scale the swatch rows and names blurred together, and designers found a specific saved palette only 44% of the time — the same low level the research had measured for swatches-and-name (41%) — with the longest find times of any variant. The thing they recognized palettes by was the one thing the layout hid.

A swatch grid looks right and hides what designers recognize
Scope: Statsig A/B · pilot · ~30 designers / arm
Guiding question: Which grid lets designers find and reuse their palettes?

  Variant A — Swatch-first grid (image behind name)
    Recognition / find success ...... 44%
    Median time to find ............. longest
    Saved palettes reused ........... low

  Variant B — Image-first grid (image leads the card)
    Recognition / find success ...... 89%
    Median time to find ............. 7s
    Saved palettes reused ........... high

Read with care: ~30 designers per arm. The recognition and find-time gaps are
large and consistent; the 30-day retention figure (in Outcomes) is directional.

Key Insight: Showing the colors first looked like the obvious palette tool
and buried the recognition cue; leading with the source image surfaced it.

What it taught. For a library of visual assets, the recognition cue belongs on the surface, even when a more literal layout looks more on-the-nose; designers retrieve by the image a palette came from, so that is what the grid should lead with. The image-first grid shipped.

Outcomes & reflections

In this section: Causal chain · Limitations · Competitive context · Reflections

Causal chain (pilot, 60 designers, spring 2025)

Two comparisons run here, and the table keeps them separate. The thesis is real-world: designers found a saved palette from swatches and a name 41% of the time and from its source image 89%. The experiment is the A/B: the image-first grid (shipped Variant B) against the swatch-first grid (rejected Variant A). Leading with the source image raised recognition from 44% (swatch-first) to 89% (image-first) and cut median find time from 38s → 7s, so designers returned to and reused saved palettes instead of regenerating them — lifting reuse from 17% (real-world baseline) to 63% (in the tool) — which turned the library into a working asset and raised day-30 retention from 40% → 58% for the image-first cohort.

Metric	Baseline	Result	What it compares
Palette recognition / find success	44% (swatch-first A)	89% (image-first B)	rejected variant vs shipped
Median time to find a palette	38s (A)	7s (B)	rejected variant vs shipped
Saved palettes reused	17% (real-world)	63% (tool)	real-world vs shipped tool
Day-30 retention (directional)	40% (A cohort)	58% (B cohort)	rejected variant vs shipped

Reading note: the reuse row is a tool-vs-real-world before/after; recognition, find time, and retention are the shipped image-first design against the rejected swatch-first variant. The win is that the image-first layout surfaced the recognition cue the swatch grid hid.

Scale note: a palette reused is a color decision a designer does not remake, so as the library grows, recognition is what keeps it a working asset rather than another folder of forgotten screenshots.

Limitations (stated, because a portfolio claim is only as strong as what it concedes)

Small pilot. 60 designers, ~30 per A/B arm. The recognition and find-time effects are large and consistent; the 30-day retention lift is directional.
Short horizon and self-report. Reuse combines self-report and a library audit; recognition was tested at one-week recall, not over the months the problem describes.
Reference images are third-party. Film stills and packaging shots are others' images held as personal reference; the library treats them as the designer's private inspiration, not redistributable assets.
Sampling quality depends on the source. A low-quality or compressed reference image yields less faithful sampled tones, so the picked color is only as good as the image saved.

Competitive context

Color tooling is a crowded, mature category — Coolors, Adobe Color, Khroma, Paletton, Huemint, Colormind — and extracting a palette from an image is table stakes (Coolors and Adobe Color both do it). But those tools are generators: they optimize getting to a palette fast and applying it, and the saved library, where one exists, is swatch-based. The recurring critique of the category is that the tools end at flat swatches. Colorpal's wedge is not extraction and not generation; it is the personal reuse library organized around the source image for recognition — the part the generators leave swatch-shaped. The bet is that designers already have enough ways to make a palette and not enough to find the one they already saved.

Reflections (transferable principles)

For a library of visual assets, the recognition key is the visual itself; a designer finds a palette by the image it came from far faster than by its codes, so the library should be organized around the source. (The A/B is the evidence: the swatch-first grid that looked correct hid the recognition cue.)
Saving an asset and making it reusable are different design problems: reuse needs the context (where it came from, why, and what for) to travel with the asset, or the saved item turns into unfindable noise.
The smallest interaction carries a focused tool: copying a color is the moment of value, so it has to be the single fastest action in the product.