Kennedy Castelli


Product and User Experience Designer



Work

Workshops

Studio









About


Paint Mixer

A digital tool for translating colors from photographs into practical paint-mixing recipes.
Try Paint Mixer





How do you translate a color you see into a physical recipe you can actually mix?




Paint Mixer started from a problem I noticed in a community art class. Color theory is complex and can be a barrier to entry. Some tools can tell you what a color is, but they don't tell you how to make it with the paint already on your palette.

I designed and built a tool that analyzes a photograph, lets the user select a color, and generates a practical paint-mixing recipe.













Designing and building with AI

I used Claude Code as an implementation partner throughout the project, while owning the product direction, interaction design, visual design, testing, and iteration.

Rather than designing every screen in Figma before implementation, I worked directly in the product, evaluating each change in the browser and iterating from there. My career in product design and my background in painting and color theory gave me a uniquely spot-on perspective.


My Role
  • Product design
  • UX / interaction
  • Visual design
  • Prototyping
  • Testing & iteration
  • AI-assisted implementation

    Tech: React, TypeScript, Vite
    AI-assisted development: Claude Code
    Deployment: Vercel


    How can a digital tool help someone move from seeing a color to actually making it?



     Research Rabbit Hole: From RGB to Pigment

    Digital color ≠ physical paint

    A color on a screen is produced with light. Paint produces color through pigments absorbing and scattering light. So the RGB value I get from a photograph tells me what the color looks like digitally, but not which physical paints will produce it when mixed. I looked into how physical paint can be modeled, including the RIT Artist Paint Spectral Database, which documents measured spectral properties of artist paints and computational mixtures based on Kubelka–Munk theory.

    This made it clear the problem was bigger than simply converting one RGB value into another. I needed a way to predict how combinations of physical paints would behave when mixed.




    RIT Artist Paint Spectral Database



    Choosing an Approach

    Rather than building a spectral pigment model from scratch, I looked for an existing model that could make the experiment practical to build. I chose Mixbox as the mixing engine. It gave me a practical way to approximate physical pigment behavior without building a spectral paint model from scratch.

    That gave me a useful middle ground: I could work with the digital RGB values coming from a photograph while using a mixing model designed to behave more like physical paint.

    Mixbox Pigment Colors




    Building the Recipe Generator

    From there, I built the product's own search around Mixbox.

    Each available paint is represented by a name and RGB value. When a user selects their available paints, Paint Mixer tests combinations of up to four paints, in 5% increments, and uses Mixbox to predict the resulting color. The app then compares each candidate to the target and returns the closest result. I tested whether expanding the search beyond 4 paints and 5% increments meaningfully improved the result, but it increased computation without producing enough improvement to justify the added complexity.







    Model-Selection
    Assumption VS. Evidence

    I tested the “more sophisticated” option too.

    I tested my assumption that the sophisticated model would be a better-suited match. I wanted to choose based on evidence. I compared RGB distance against Lab-based color distance across several sampled colors. I expected Lab to produce better matches because it is designed to represent perceptual differences more closely. But in my tests, it didn't consistently produce better results. I kept RGB scoring instead.


    Accuracy VS. Usefulness

    I wasn't trying to build a scientifically perfect digital replica of physical paint.
    I was trying to build something a painter could actually use.

    That meant accepting the model’s limitations and framing the result as a Starting Mix,
    rather than claiming that the app had found the physically correct recipe.

    The painter still has the final step: calculate → mix → look → adjust







    Using Claude Code

    Working with Claude Code changed my development process from designing an interface first and handing it off to implementation, to designing through an ongoing loop of building, testing, and revising. I used it as an implementation partner, but I remained responsible for deciding what to build, testing whether it worked, and deciding what needed to change.

    1. When the image picker looked right but wasn’t
    UX testing, debugging, working with AI

    Problem:
    Portrait and some landscape images were returning the wrong color when clicked near the edges.

    What I did:
    I tested the app on my own and then cross-checked with Claude Code to investigate what was going wrong and whether it could identify what was wrong. It seemed it would stretch the image in odd ways.

    What I found:
    The click coordinates were being calculated against the “<img>” element's full layout box, while “object-fit: contain” meant the actual image occupied only part of that box. The click math was sampling the wrong location.

    What changed:
    I had Claude Code change the coordinate calculation to account for the actual rendered image rectangle rather than the full element.

    What I learned:
    A visually simple interaction can depend on underlying rendering behavior. Working directly in the browser made it possible to discover that mismatch through testing rather than treating implementation as something that happens after design. I did not want to rely on Claude Code for user testing, or allow development without human review.









    2. When a feature exposed a data-model problem
    Product thinking, data model, feature design

    I knew I wanted to build the option to add another color to an existing saved palette. This would require the application to save the photograph to return to. But the original saved palette did not contain the photograph. The new UI feature revealed a missing relationship in the data model. The palette was saving the output, but not the context to continue working with it.
    The solution became:
    Save palette > store image reference > edit palette > add color > reopen image > pick new color > add to existing palette





    What I learned: Working directly in the code changed how I think about prototyping. Instead of treating implementation as something that happens after design, I could use the working product itself as a design medium, testing interactions and making decisions in context.

    The project also made clear that AI-assisted implementation still needs product direction. Claude can build quickly, but it doesn't know which problems are worth solving or when a feature adds unnecessary complexity.


    Future Features:
    • Specific paint brands - map recipes to the actual paints a painter owns.
    • Paint interaction data - build a richer model of how specific pigments behave when mixed.
    • Guided color adjustment - adjust a starting mix based on hue, temperature, tint, and saturation.


    All photos taken by me