Aydınlatma metni yükleniyor…
Choosing website colours is not simply a matter of placing several attractive swatches next to one another. Colour affects whether text can be read, whether an action can be recognised, whether error and success states can be distinguished, and whether the brand remains coherent across pages. A useful palette is therefore a system of named roles and usage rules, not a loose collection of hex values.
This guide does not promise a universal answer to “which colour converts best?” It provides a shared decision record for designers, content owners and developers. Colour alone does not guarantee trust, revenue, rankings or conversion. Outcomes still depend on the offer, content, user need, interaction design and technical implementation.
Define interface roles before selecting a palette
Start by listing the roles that the interface needs: page background, raised surface, primary text, secondary text, border, primary action, secondary action, link, keyboard focus, error, warning, success and disabled states. A single brand colour may not safely serve every one of these roles.
Functional names make implementation more durable. Tokens such as action-primary, text-link and focus-ring retain their meaning if the exact shade later changes. The design file, CSS variables and component library should use the same vocabulary so that a visual decision does not become an undocumented developer guess.
A brand colour is not automatically an interface colour
A shade that works well in a logo may not provide enough contrast for small text or a button background. The answer is not necessarily to abandon the brand colour. Define lighter and darker variants, neutral surfaces and approved text pairings. The core shade can remain prominent in suitable accents while an accessible variant performs the functional role.
Test the palette on at least three contexts: a light surface, a dark surface and an image or video. Text placed over imagery needs a repeatable overlay, shadow or solid backing rule. “Choose a suitable photograph” is not a reliable system because the content will change.
Measure contrast rather than judging it by eye
The WCAG 2.2 explanations use a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. Meaningful graphical objects and visual information required to identify user-interface components are also considered against a 3:1 threshold in relevant cases. See the W3C guidance for minimum text contrast and non-text contrast.
These ratios are a baseline, not the entire review. Thin type, low screen brightness, sunlight and differences in colour perception can still make an interface difficult to use. Combine automated measurement with checks on representative devices and at browser zoom.
Do not communicate information through colour alone
A red border without an error message, a green dot without a label or a colour-only required-field indicator can remove information for some users. The W3C explanation of use of colour requires colour not to be the only visual means of conveying information in the covered situations.
Pair colour with text, an icon, a pattern, an underline or a clear position. A form error should include an explicit message near the affected field. Links need a distinguishable treatment appropriate to their context. Data visualisations should identify series through labels or patterns as well as hue.
Treat interaction states as part of the palette
A button has more than a default colour. It can have hover, keyboard focus, pressed, selected, loading and disabled states. If these states are absent from the system, teams tend to invent shades page by page and consistency erodes.
The keyboard focus indicator must remain visible on both light and dark surroundings. A disabled component should not merely look faint; it must behave as unavailable and, where necessary, explain why the action cannot be completed.
The Kumsal colour-system matrix
Record each colour role through five fields:
| Field | Decision question | Acceptance evidence |
|---|---|---|
| Role | What job does this colour perform? | One unambiguous role name |
| Pairing | Which surface or text colour accompanies it? | An approved colour pair |
| State | Is it default, focus, error or another state? | Component-state list |
| Accessibility | How is the meaning expressed without colour? | Text, icon or pattern |
| Verification | Where and how was it tested? | Tool result and device check |
Including this matrix in the design handover gives developers the intent as well as the colour value. Use it with the professional web-design quality guide, the UI design guide and the UX design guide to connect colour decisions with broader acceptance criteria.
Do not treat colour meanings as universal rules
Claims such as “blue creates trust” or “red makes people buy” are not sufficient design evidence. Perception varies with culture, sector, surrounding colours, copy and component context. The same red may indicate an error in a form, emphasis in a campaign panel or the primary identity of a brand.
Test the context rather than assuming a universal meaning. Is the primary action distinguishable from secondary actions? Does a warning differ from success through wording and structure as well as hue? Do non-colour cues retain the meaning on localised pages? Representative task testing can inform the decision, but its result should not be presented as a universal colour-psychology law.
Test what happens when content changes
A colour system must survive real content, not only ideal design-file examples. A long button label, a two-line heading, a missing image, a new campaign card or a table added by an editor can alter the hierarchy. In a CMS, giving editors approved semantic roles and components is safer than exposing unrestricted colour selection.
Review at least one form, list, detail page, campaign component and system message during handover. When a theme or brand update changes a token, repeat automated contrast checks and include critical components in visual regression review. This turns the palette into a maintainable system rather than a one-off presentation.
Example colour-system acceptance scenario
Consider a proposal form with a primary button, link, required field, error and success message. Its acceptance record identifies the default and focus states, text-and-surface pairing, measured contrast and non-colour cue for each component. Complete the form with a keyboard, trigger an error, check the relationship between the message and field, and confirm that success is described explicitly rather than shown only as a green panel.
The scenario evaluates whether the system supports a real task, not whether individual swatches look attractive. The same method can be applied to basket, account, filtering and administration workflows.
Implementation and test checklist
- List interface roles before selecting shades.
- Define approved pairings for light and dark surfaces.
- Measure text and non-text contrast.
- Add a second signal for errors, success, warnings and selection.
- Design hover, focus, active and disabled states.
- Check important pages on real devices at high and low brightness.
- Complete critical forms with a keyboard.
- Keep design tokens and code variables aligned.
A successful colour system makes the brand recognisable without obscuring content or interaction. It moves the discussion from preference to roles, measurable thresholds, states and verification evidence.