In a design system, why define surface and background color roles such as page, raised, overlay, scrim and inverse rather than one background color?

## What surface roles are Every foreground color in an interface sits on something. **Surface and background roles** name those grounds: the **page background** (the canvas behind everything), the **surface** (cards, rows and panels that sit on the page), the **raised or overlay surface** (menus, sheets and side panels drawn above other content), the **scrim** (a dimming layer placed behind an overlay or over imagery) and the **inverse surface** (a deliberately opposite ground for a small, high-attention element). A functional palette defines each of these as a role with its own value, rather than letting everything default to one background color. ## Why one background color is not enough - **Hierarchy needs grounds.** A streaming home screen has a page, rows of title tiles, a details panel that slides over the rows, and a menu that opens over the panel. If all of them share one color, the only way to separate them is borders and shadows everywhere. - **Foreground roles are only correct relative to a ground.** A text or status color is legible or not depending on what it sits on. When surfaces are roles, the system can publish which content roles are approved on which surface roles, and every approved pair has been checked once. - **Surfaces change as a set.** When the product is themed or given a high-contrast mode, surfaces are the roles that move most; defining them as roles lets a theme change their values without every screen being redesigned. How that remapping works belongs to the theming branch; the palette's job is to supply the roles. ## Surfaces meet status roles Status roles usually come in at least two strengths: | Strength | Used for | Paired with | |---|---|---| | **Strong status** | Icons, small indicators, a bold fill that carries the status | A content color designed to sit on that strong fill | | **Subtle status container** | A pale tinted background behind a message or a row | Its own text and icon color, darker than the strong status | The reason for the pairing is simple: the strong error red that works as an icon on the page background is often too close in value to a pale red container to be readable on it. Defining the container and its content together means a team building a failed-payment message cannot accidentally put strong red text on a pink ground. The container role is a surface role with a meaning attached, so it follows the same rule as every other surface: it comes with the content roles allowed on it. ## The streaming player: content with no fixed ground A video player is the hardest surface case. Playback controls, the progress bar and subtitles float over video frames that could be a night sky one second and a snowfield the next. There is no background color to check against, so the system introduces a **scrim role**: a translucent dark or light layer, often a gradient at the top or bottom of the frame, between the video and the controls. The scrim turns an unpredictable ground into a predictable one, and the control colors are then checked against the scrim at its lightest point over the brightest plausible frame. The same idea applies to text over poster art in a TV row and to a details sheet over a paused frame. Common practice is to treat any imagery as an unknown ground and never place content colors directly on it. ## Designing the surface set 1. Start from the page background and decide how many distinct grounds the product genuinely needs; many products manage with three to five, not a dozen. 2. Give each surface role a clear purpose and a fixed place in the stacking order: page, surface, raised, overlay. 3. For each surface role, list the content roles approved on it: text, secondary text, icons, status, focus ring. 4. Add a scrim role wherever content sits on imagery or video. 5. Keep the inverse surface for small elements, because a large inverse area reads as a different product. ## What stays elsewhere How surfaces get lighter to show elevation in a dark palette belongs to dark-palette design; shadows belong to the elevation scale; and the exact contrast steps between content and surface belong to accessible pairings. The functional palette's contribution is the **roles themselves** and the rule that every foreground is defined relative to one of them. That rule is what lets a TV team and a web team build different screens from the same set of approved combinations, and still produce interfaces that read as one product.