Styling

Styling the Platform

The platform can be made to look like your organisation rather than like software.

Where to find it

Architect Panel → Styling:

• Fonts — the typefaces available
• Logo — your logo and its variants

Architect Panel → Configuration:

• Site Settings — wider appearance settings

Why it matters

For anything customer-facing, unbranded software reads as a third-party system and reduces trust — people are reasonably cautious about entering details into something that does not look like the organisation they are dealing with.

Internally it matters less, though familiarity still helps adoption.

An application is not a website

The distinction that should govern every decision here. A marketing site is designed to impress; an application is used for hours by people trying to finish a task.

Styling that looks striking on a landing page — heavy colour, low-contrast type, generous whitespace pushing content below the fold — makes an application slower to use every single day. Restraint is not blandness; it is respect for the people using it.

Contrast is not negotiable

Brand colours are frequently chosen for print or for a website's accent use, and applied as body text they can be genuinely hard to read. Pale grey on white is the classic.

Check text contrast against its background and fix it where it fails, even where that means departing from the brand palette. Somebody who cannot read the screen cannot use the system, and that is not a preference.

Use brand colour sparingly

As an accent — the header, a primary button, a highlight. Applied to everything, it stops being a brand and becomes noise, and it competes with the colours doing real work like status indicators.

Leave status colours alone

Red, amber and green mean something to users. Recolouring them to fit a brand palette costs you a signal people already understand, in exchange for consistency nobody asked for.

Test on the devices people use

Including a phone, and including one of the older machines your organisation actually runs. Styling that assumes a large modern screen fails quietly for the people worst placed to work around it.

Change it rarely

Users build muscle memory. A restyle that moves or recolours familiar things costs everybody a few days of hesitation, so it should be worth that — and worth announcing.

Worked example

An organisation applies its logo, header colour and typeface, keeping body text near-black on white and leaving status colours untouched. Contrast was checked before rollout, which caught the brand's mid-grey being unreadable as body text on the older screens in one office.

Recommendations

• Style for daily use, not for first impressions.
• Check contrast and depart from the palette where it fails.
• Keep brand colour as an accent.
• Leave status colours alone.

Colours and Fonts

Colours and typefaces are the two things most organisations want to change first.

Where to find it

Architect Panel → Styling:

• Fonts — the available typefaces

Architect Panel → Configuration:

• Site Settings — appearance settings

Fonts: legibility first

A brand typeface chosen for headlines is often poor at fourteen pixels in a dense table. Test your font where it will actually be read — a form, a list of two hundred rows — not on a heading.

If it fails there, use it for headings and something plainer for body text. That is a normal and defensible arrangement.

Numbers need care

An application shows a lot of numbers in columns. A typeface whose digits vary in width makes columns ragged and harder to compare; one where the figure one and the letter l are indistinguishable causes real errors in references.

Check digits specifically — it is not something you notice in prose.

Do not shrink text to fit more in

Tempting on dense screens and it excludes people. If a screen needs smaller text to work, the screen has too much on it.

Colours: start with the smallest change

Header, primary buttons, links. That is usually enough to make the platform feel like yours, and it leaves the rest of the interface doing its job.

Check every state

A colour set for a button also affects it when hovered, focused and disabled. The states people forget are focus — which matters enormously for keyboard users — and disabled, which is frequently left at a contrast nobody can read.

The focus indicator must be visible

It is how somebody navigating by keyboard knows where they are. Styling that removes or weakens it makes the application unusable without a mouse, and it is one of the most common accessibility failures introduced by branding.

Do not rely on colour for meaning

The rule that recurs throughout the platform. Whatever palette you apply, anything conveying state needs a label or an icon alongside it.

Test with real content and real users

An empty form looks fine in any colour scheme. A form with validation errors, a long list, a table of numbers and a disabled button is where problems appear — and somebody other than you should look at it.

Roll out visibly

Tell people before you change how the system looks. A restyle arriving unannounced generates support calls from people who think something has broken.

Worked example

An organisation applies its typeface to headings only, keeping a plainer face for body text after the brand font proved hard to read in dense tables. Header and primary buttons take the brand colour; focus outlines are left prominent. The change was announced a week ahead and generated no support calls.

Recommendations

• Test the font in a dense table, not on a heading.
• Check digits for width and ambiguity.
• Never weaken the focus indicator.
• Announce a restyle before it lands.