The Hex Code Problem Nobody Talks About Enough
I spent three years building a design system for a healthcare platform where skin tone representation mattered in a way that wasn't just marketing. We hit walls most people don't expect when they talk about digital inclusivity. The problem isn't finding hex codes. The problem is making them work consistently across every screen, skin type, and design context without becoming reductive or visually flattening. Here is what actually happens when you try to build with this seriously. Start with the Fitzpatrick scale. It is still the most practical framework available, despite its limitations. Type 1 through Type 6 covers the range from very fair to very dark skin tones. Each type maps to a handful of hex values that work in digital space. But mapping is where things get complicated fast. A single hex code like #C68642 is not a person. It is an approximation that assumes sRGB color space, a standard monitor, and no ambient lighting interference. On a calibrated display in a design studio, it looks fine. On an employee's phone with a cheap OLED panel and brightness at 60 percent, it looks completely different. This is the first reality check you need before building anything.
I remember working on a project where we needed illustrative characters for a mental health app targeting diverse demographics. We had a palette of fourteen skin tone hex codes derived from the Fitzpatrick scale with adjustments for digital rendering. Everything looked good in Figma. Then QA tested it on actual devices and reported that Type 5 and Type 6 values appeared as muddy brown instead of the warm deep tones we intended. The workaround was not finding better hex values. It was adding a device-specific override layer that adjusted saturation and luminosity based on display capability detection. We used a lightweight JavaScript check that read the user agent and display characteristics, then applied a CSS filter adjustment of roughly +8 percent saturation and -4 percent brightness for darker tones on low-end panels. This cut down the visual mismatch by about 70 percent across our test devices. The deeper issue is that hex codes flatten diversity into six or eight buckets. A person with Type 3 skin who has freckles and a rosacea flare-up does not match any single hex value. A person of South Asian descent might fall between Type 3 and Type 4 depending on region, genetics, and sun exposure. When you reduce this to a dropdown with six options, you are not being inclusive. You are being convenient. There is a difference. What actually works in practice is building a gradient-based system rather than a discrete selection. Instead of #8D5524 or #C68642 or #E0AC69, create a continuous range from light to deep with interpolated values. This gives users something closer to their actual appearance without forcing them into an incorrect category. The technical approach uses HSL color space instead of HEX for the interpolation. Convert your base range to HSL, vary the lightness channel while keeping hue and saturation relatively stable, then convert back to HEX for output. This produces a smoother, more natural distribution of tones.
I found that using a base of about forty-eight interpolated values between the lightest and darkest Fitzpatrick endpoints produced results that 85 percent of testers said felt "close enough" in usability studies. The remaining 15 percent were cases where the person's skin tone had significant variation across their face and body that no single color could represent. In those situations, the system should offer a dual-tone or gradient avatar option rather than forcing a single flat color. Here is a practical set of hex values you can use as a starting point. These are calibrated for standard sRGB displays and represent the six Fitzpatrick types with two variants each for light and deep undertones: Type 1 Cool: #F6D2B7 Type 1 Warm: #F8D5BC Type 2 Cool: #EDBB99 Type 2 Warm: #E8C09B Type 3 Cool: #D4A574 Type 3 Warm: #D19A68 Type 4 Cool: #B8764C Type 4 Warm: #AE7047 Type 5 Cool: #8D5524 Type 5 Warm: #7A4B21 Type 6 Cool: #5C3317 Type 6 Warm: #4A2911
Get the Full Details
None of these values are universal. They are references. If you are building a product that claims inclusivity, the responsibility is not just picking the right colors. It is testing those colors on real hardware from different manufacturers at different brightness levels, in different lighting conditions, with users who actually match those skin tones. I have seen teams skip this step and launch products that looked inclusive in their renders but alienated the very audiences they claimed to serve. One thing nobody mentions is contrast. Darker skin tones paired with dark UI elements create readability disasters. Lighter skin tones next to bright backgrounds can disappear entirely. Always run your palette through a contrast checker against every background color it will appear on. The WCAG 2.1 AA standard requires a 4.5:1 ratio for normal text and 3:1 for large text. Most skin tone hex values fail this test against white backgrounds at Type 5 and Type 6. The solution is not to make the text lighter and lose the aesthetic. It is to add a subtle outline or shadow layer behind text that overlaps skin tones, or to shift the UI background to a mid-tone that provides enough contrast for the full range. Another overlooked detail is the cultural weight of these choices. In some markets, certain skin tone representations carry historical baggage. A palette that works in one region may be received differently in another. I learned this the hard way when a European client loved our initial skin tone palette for an African market campaign until local advisors pointed out that theundertone selections did not reflect the warm golden bases common in West African skin tones. We adjusted by introducing additional warm variants in the Type 4 to Type 6 range, shifting the hue channel roughly +5 degrees toward yellow-orange while maintaining the same lightness values.
If you want a quick reference chart that covers most use cases, the following JSON structure worked well for our team. It includes the hex values, the Fitzpatrick type, undertone classification, and recommended usage constraints: const SKIN_TONES = [ { type: 1, undertone: "cool", hex: "#F6D2B7", max_bg_brightness: 90 }, { type: 1, undertone: "warm", hex: "#F8D5BC", max_bg_brightness: 92 }, { type: 2, undertone: "cool", hex: "#EDBB99", max_bg_brightness: 85 }, { type: 2, undertone: "warm", hex: "#E8C09B", max_bg_brightness: 88 }, { type: 3, undertone: "cool", hex: "#D4A574", max_bg_brightness: 78 }, { type: 3, undertone: "warm", hex: "#D19A68", max_bg_brightness: 80 }, { type: 4, undertone: "cool", hex: "#B8764C", max_bg_brightness: 70 }, { type: 4, undertone: "warm", hex: "#AE7047", max_bg_brightness: 72 }, { type: 5, undertone: "cool", hex: "#8D5524", max_bg_brightness: 55 }, { type: 5, undertone: "warm", hex: "#7A4B21", max_bg_brightness: 58 }, { type: 6, undertone: "cool", hex: "#5C3317", max_bg_brightness: 40 }, { type: 6, undertone: "warm", hex: "#4A2911", max_bg_brightness: 42 } ] The max_bg_brightness field is the highest background luminosity percentage at which the skin tone remains visually distinct and comfortable. Exceed this and the combination starts feeling washed out or harsh depending on the surrounding palette.
There is no perfect solution here. Hex codes will always be an approximation of something infinitely more complex. But treating them with the seriousness they deserve rather than slapping together a rainbow palette and calling it diversity work makes a measurable difference. The difference between a token gesture and actual inclusion is usually in the testing, the iteration, and the willingness to admit when your first set of values was insufficient. If you are starting a project that requires skin tone representation, begin with the gradient approach I described rather than discrete options. Run contrast checks on every background variant. Test on at least three different device types before launch. And pay attention to what actual users say about whether they see themselves represented accurately, not just whether the numbers look right on paper.
