Skillz SDK Theming.

Research.

The audit started by treating the API like a design system with external users. Good tokens should communicate scope: what surface they affect, which state they belong to, and whether they are safe defaults or advanced overrides. Several Skillz parameters did that well. Others relied on description text, internal naming habits, or manual testing to reveal their purpose. The research question became: can a partner developer understand the theming model from the six-block structure alone? The answer was no. Parameter names, block placement, descriptions, and rendered behavior were carrying different parts of the same contract.

• tertiaryTextColor used a semantic label without a stable component scope
• accentColor controlled multiple surfaces with no documented precedence or hierarchy
• secondaryDividerColor appeared as a naming collision inside the parameter set
• mainColor was modified by a hardcoded opacity layer after developer input

“The audit identified eight parameters where the token name, description, and rendered behavior did not align with a developer's likely mental model.”

Process.

I built the audit around traceability. Every parameter received a numbered marker, then each marker was placed directly on screenshots of the SDK running inside real games. The goal was to connect the configuration API to visible product surfaces: lobby cards, tournament headers, match states, prize rows, CTAs, dividers, and background treatments. If a parameter could not be located in any tested screen state, it stayed in the audit as an unresolved token, not an omission. That distinction mattered. A parameter can exist in the API, accept input, and still fail as documentation if no one can tell where it renders.

• Sequential audit index covering all 77 parameters, not just the obvious visual tokens
• Annotated screenshots connecting tokens to lobby, match, prize, store, and end-state surfaces
• Unlocated-token register for parameters that accepted input but had no confirmed screen surface
• Cross-game validation across five live titles to catch context-dependent behavior

What the Audit Found.

The mapping surfaced four product-level issues. First, eight real Artwork parameters—including Ticketz Prize Image, Ticketz Prize Background Color, and Bracketed Event Prize Image—accepted values but had no confirmed marker on any tested screen. They were settable and documented, but visually unverifiable. Second, Cash Prize Background Color appeared as a necessary slot on the audit map but did not exist in the API at all; every other currency exposed both an image and a background color. Third, hardcoded opacity rules changed developer-supplied colors after input. Fourth, bracketed Ticketz tournaments had no dedicated image or background parameters.

• Precedence issue: hardcoded opacity modified developer-supplied colors without feedback
• Documentation gap: eight real parameters had no confirmed rendered surface across five games
• API gap: Cash Prize Background Color was absent even though every other currency exposed the slot
• Taxonomy gap: bracketed Ticketz lacked dedicated prize image and background parameters

Auditing the Six.

The six blocks were already present in the developer console; the audit tested whether that structure held. The counts made the first failure visible: Core Colors contained 10 parameters, Accent 9, Buttons 5, Text 8, Artwork 14, and Advanced 31. Advanced alone held 40% of the API, making it a catch-all rather than a meaningful category. The second failure was conceptual. Text held eight role-based colors, while Advanced held seven more text colors organized around content such as Cash, Ticketz, Medals, and Error states. That may reflect a useful distinction between semantic roles and content-specific values, but the console never named the principle. The audit documented the split so developers could find values without treating block names as a complete map.

• Core Colors 10 · Accent 9 · Buttons 5 · Text 8 · Artwork 14 · Advanced 31
• Advanced contained 40% of all parameters and functioned as a catch-all
• Text held role-based colors; Advanced held seven content-specific text colors
• The role-versus-content distinction was real but undocumented

Stress-Tested Across Five Live Games.

The existing grouping had to work outside a clean design file. I audited it across five live games with different palettes, art direction, content density, and contrast problems. That made the test closer to partner reality: developers are rarely theming an empty SDK; they are placing a tournament product layer over an existing visual system. Pool Payday was the hardest case because its branded artwork carried a lot of texture and color. If the taxonomy held there, it would likely hold for simpler games. The stress test confirmed which blocks stayed coherent and where documentation needed to warn about surface collisions.

• Pool Payday: dense branded artwork and high risk of tournament-layer legibility loss
• Warzone Idle: dark UI requiring stronger contrast guidance
• Solitaire Grand Harvest: warm palette where artwork could bleed into SDK chrome
• Game 4: control case for validating accent-token isolation
• Game 5: typography-heavy case for testing text-color hierarchy

Blur or Overlay.

Background treatment was not just visual polish; it changed the readability contract between the host game and the SDK. Blur preserved game context, but it also let busy art, strong color, and motion compete with tournament content. Overlay gave the SDK a controlled contrast field and made prize, lobby, and CTA surfaces easier to validate. The audit documented both treatments across the five games so the recommendation was contextual: use blur when the host art stays quiet behind the UI; default to overlay when legibility and brand consistency matter more than environmental continuity.

• Blur: preserves game context but requires low-noise artwork and stronger contrast QA
• Overlay: creates a stable color field, improves readability, and works as the safer default

Reflection.