User experience & branding

Desktop polish looks cosmetic and is anything but: it lives in per-user state, protected association hashes and tattooed layouts. This is how Decolla builds the layer your users actually see.

Why this matters

The desktop is the only part of the estate most users ever see. A device that arrives with Widgets, a Copilot button, Edge claiming every PDF and a Start menu suggesting games does not read as newly provisioned — it reads as unfinished, and it erodes confidence in the whole programme before the user has opened a single application.

It also generates a distinctive class of ticket: low severity, high volume, and irritating out of proportion to its difficulty. "PDFs open in the wrong app", "where did my shortcut go", "what is this news feed" — none of these is an outage, but together they are a steady tax on the service desk. And beneath the cosmetics sits some of the most awkward engineering in Windows client management: nearly all of it lives in per-user state that device-context tooling cannot simply write to.

What a good build does

A competent build treats per-user polish as an engineering problem, not a batch of registry tweaks. Three patterns matter. First, settings every future user should inherit are seeded into the default user profile hive, so new profiles pick them up without fragile user-context scripting. Second, Start and taskbar layout is applied once and then left alone — users may rearrange their own pins — with a paired remediation that clears tattooed layout state when the organisation's layout genuinely changes. Third, file associations go through the supported per-user evaluation route rather than attempting to out-write Windows' protection hash.

Decolla's library items in this section are built on those patterns, and several exist precisely because they are recurring helpdesk fixes — PDF defaults being the canonical example. Every item appears in the written plan with its delivery mechanism and reversibility class before anything runs, and Decolla can roll back its own changes per item. The honest caveats: rollback covers what Decolla changed, not pre-existing user customisation, and some consumer-content suppression policies behave differently across Windows editions — the plan says so rather than pretending otherwise.

Where it bites people

Two failures recur in this area.

File associations that silently do nothing. Windows protects per-user defaults with a hash, so writing ProgId values straight into the registry either fails silently or triggers "an app default was reset" notifications as Windows reverts the change. The supported mechanism is evaluated at sign-in — meaning it fixes the next sign-in, not the session in front of you — and admins routinely conclude the policy "doesn't work" when it simply has not been given a logon to act on.

Layout tattooing. A Start or taskbar layout applied with apply-once semantics writes state that outlives the policy. Update the layout and existing devices keep the old pins indefinitely; remove the policy and the layout stays behind. Without a remediation that detects and clears the tattooed state, every layout revision quietly forks the estate into old-look and new-look devices — which is why Decolla ships the layout and its tattoo-clearing remediation as a pair.

What's in this section (15 items)

Reversibility: auto reverses when unassigned · reverse reversible with a documented step · irreversible flagged before you approve the plan.