# Desktop Installer Design

> Use whenever designing, building, or reviewing an app's installer, first-run/onboarding wizard, or uninstaller — Windows (NSIS/Inno/MSIX), macOS (DMG/pkg), or Linux (AppImage/deb/rpm) install flows. Depends on desktop-ui-foundations for tokens and desktop-ui-icons for the app icon. Trigger on "installer," "onboarding wizard," "first-run setup," "DMG background," or "uninstaller."

- Skill: `simply-ehis/desktop-installer-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add simply-ehis/desktop-installer-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/simply-ehis/desktop-installer-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: simply-ehis (https://skillmd.com/u/simply-ehis)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/simply-ehis/desktop-installer-design

---


# Installer & First-Run Design

The installer is the very first interaction anyone has with the app, before the app itself even opens — and it's one of the easiest places to accidentally ship the generic default wizard that came with your packaging tool. It deserves the same intent as everything inside the app.

## Don't ship the packager's default look

NSIS, Inno Setup, `electron-builder`, and `tauri-bundler` all have functional-but-generic default installer chrome. Treat the default as a placeholder, not a finished product:

- Replace default installer icons/banners with the app's own brand art (see `desktop-ui-icons` for how the app icon should be built to scale down cleanly).
- Set the installer window's own accent color / branding to match the in-app palette (see `desktop-ui-color-system`) rather than leaving the tool's default blue.
- Keep the installer's own type and spacing consistent with the token scale used everywhere else in this skill family — an installer that looks like a different product than the app it installs is a jarring first impression.

## Flow — keep it short, and skip steps that don't need a decision

A good installer asks for **only the decisions that actually vary per install**. Every extra screen is a chance for the person to bail before they've even seen the app.

Typical minimal flow:

1. **Welcome** — app name, icon, one line about what it does. No marketing paragraph.
2. **License/EULA** (only if legally required — many indie/open-source apps can skip this screen or fold acceptance into a single checkbox rather than a full screen)
3. **Install location** (default to the platform-standard location; only surface this screen if the user is likely to want to change it — power users appreciate the option, most people don't need to see it)
4. **Progress** — a real, measured progress bar, not an indefinite spinner, since install time is genuinely trackable
5. **Finish** — confirmation, with a "Launch now" checkbox/button, checked by default

Don't add extra screens for things that don't need a choice (a fixed set of components with no meaningful opt-out, for instance) — bundle those in automatically instead of manufacturing a "choose components" screen.

## Platform conventions — don't fight them

- **Windows**: users expect an install wizard (NSIS/Inno) or an MSIX/Store-style silent install. Respect the standard back/next/cancel button placement and the platform's own window chrome for the installer itself — this is one place where *not* using a fully custom title bar is usually the right call, since the installer's job is to feel trustworthy and familiar, not to be a brand showcase.
- **macOS**: the drag-to-Applications-folder DMG pattern is the expected convention — design a custom DMG background (matching the app's brand) showing the app icon with an arrow toward the Applications folder shortcut, sized correctly for the DMG window. Don't replace this with a wizard-style flow; it reads as non-native.
- **Linux**: AppImage needs no install step at all (make sure this is communicated — "just run it," don't build a wizard for a format that doesn't need one); .deb/.rpm should integrate with the system's own package-manager conventions rather than a custom GUI wizard.

## First-run / onboarding wizard (inside the app, after install)

This is a separate concern from the installer itself — it's the first thing the user sees *inside* the app:

- Keep it to the minimum needed to make the app usable — required setup (an initial config, a workspace/folder pick, a login if genuinely required) — not a marketing tour of every feature.
- Make it skippable wherever the app is still usable without completing every step; don't block someone from seeing the actual product behind a mandatory multi-screen tour.
- If there are optional feature highlights, prefer contextual "hey, you can do X here" hints that appear the first time a relevant screen is visited over a dedicated tour sequence up front — this respects that the user came here to use the app, not to be walked through slides about it.
- Reuse the actual in-app components (real buttons, real color tokens) for onboarding UI rather than building bespoke "marketing site" styling for it — a wizard that looks like a different product than the app itself undermines the very first impression it's trying to create.

## Uninstaller

- Should be discoverable through the platform's standard mechanism (Windows "Apps & Features," macOS drag-to-trash or a bundled uninstaller for apps that write outside the .app bundle, Linux package manager) — don't invent a custom uninstall flow the OS doesn't expect.
- Ask before deleting user data/config (projects, settings, cached models) separately from removing the app binary itself — these are very different levels of destructiveness and deserve different confirmation weight (see the destructive-confirmation pattern in `desktop-ui-surfaces-overlays`).

## Accessibility & internationalization

- The installer runs before the app's own UI even loads, often on a freshly set-up machine — use the OS's native installer framework (WiX/MSI on Windows, native `pkg`/notarized installer UI on macOS) rather than a fully custom-drawn wizard, so keyboard access and screen reader support come from the platform instead of being reimplemented from scratch. See `desktop-ui-accessibility-i18n` for the baseline.
- License text, step instructions, and button labels are frequently localized before the app's own in-app strings are — leave real headroom for translated text in step titles and buttons, not a layout sized exactly to the English copy.
- Never bake license or instructional text into an image.

## Review format

| Before | After | Why |
|---|---|---|
| Installer uses the packaging tool's default gray/blue wizard chrome | Custom-branded icon, accent color, and copy matching the in-app palette | The installer is the first impression — generic chrome undercuts everything else |
| Six-screen setup wizard including a "choose components" step with no real optional components | Three screens: welcome → progress → finish, components bundled automatically | Extra decision points with no real choice behind them just add friction before the user sees the app |
| Onboarding tour is a separate set of marketing-styled slides before the app becomes usable | Minimal required setup, then contextual first-use hints inside the real app UI | Reuses real components, respects that the user wants the product, not a pitch for it |