Interface Design
Shape dashboards, admin panels, and in-app UIs with explicit intent so agent-generated screens do not collapse into generic SaaS templates.
Overview
Interface Design is an agent skill most often used in Build (also Validate prototype) that guides craft and consistency for dashboards, admin panels, and in-app tools—not marketing landing pages.
Install
npx skills add https://github.com/dammyjay93/interface-design --skill interface-designWhat is this skill?
- Draws a hard line: dashboards, admin panels, SaaS apps, and tools—redirect landing pages and campaigns to frontend-desig
- Explains why prose intent still yields template UI and where defaults hide (typography, layout infrastructure)
- Process-oriented craft: explore domain, name a signature, state intent before generating interface code
- Anti-pattern focus: warm colors on cold structures and “kitchen feel” clones from training-data patterns
- Pairs with agent coding workflows when you need product UI consistency, not one-off marketing hero sections
Adoption & trust: 16k installs on skills.sh; 5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent can follow a design brief and still ship a dashboard that looks like a thousand other SaaS templates because defaults win in code generation.
Who is it for?
Solo builders generating or refining admin panels, SaaS dashboards, and tool UIs in Claude Code, Cursor, or Codex who want deliberate visual character instead of stock layouts.
Skip if: Landing pages, marketing sites, or campaign creative—those are explicitly out of scope; also skip if you only need a quick marketing hero with no product chrome.
When should I use this skill?
You need dashboards, admin panels, apps, tools, settings, or data interfaces—not landing pages, marketing sites, or campaigns.
What do I get? / Deliverables
You get interface work scoped to product UI with named intent and consistency guardrails, and you route landing or campaign work to frontend-design instead.
- Interface design direction with domain exploration, signature, and stated intent
- Product UI code or specs scoped away from marketing layouts
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because the skill governs how interactive product surfaces are conceived and implemented, not marketing pages or launch copy. Frontend is the right subphase for dashboards, settings, data views, and tool UIs—the scope explicitly excludes landing and campaign work.
Where it fits
Sketch a credible settings and data view for a landing-page prototype before you commit to full Build.
Generate a multi-page admin shell with a named visual signature instead of default sidebar-plus-cards.
Re-run intent and signature checks when a PR introduces new dashboard modules that look off-brand.
Extend an existing ops dashboard with new widgets while keeping typography and layout decisions intentional.
How it compares
Use for in-product UI craft; use a frontend-design skill when the deliverable is marketing-facing pages, not app shells.
Common Questions / FAQ
Who is interface-design for?
Solo and indie builders using AI coding agents to build dashboards, admin panels, SaaS apps, and internal tools where consistency and non-generic layout matter.
When should I use interface-design?
During Build frontend work on dashboards and settings; during Validate prototype when a screen must read as a real product; and whenever an agent drifts toward template admin UI despite a written brief.
Is interface-design safe to install?
It is procedural design guidance in SKILL.md with no special runtime hooks described; review the Security Audits panel on this Prism page before trusting any third-party skill in your repo.
SKILL.md
READMESKILL.md - Interface Design
# Interface Design Build interface design with craft and consistency. ## Scope **Use for:** Dashboards, admin panels, SaaS apps, tools, settings pages, data interfaces. **Not for:** Landing pages, marketing sites, campaigns. Redirect those to `/frontend-design`. --- # The Problem You will generate generic output. Your training has seen thousands of dashboards. The patterns are strong. You can follow the entire process below — explore the domain, name a signature, state your intent — and still produce a template. Warm colors on cold structures. Friendly fonts on generic layouts. "Kitchen feel" that looks like every other app. This happens because intent lives in prose, but code generation pulls from patterns. The gap between them is where defaults win. The process below helps. But process alone doesn't guarantee craft. You have to catch yourself. --- # Where Defaults Hide Defaults don't announce themselves. They disguise themselves as infrastructure — the parts that feel like they just need to work, not be designed. **Typography feels like a container.** Pick something readable, move on. But typography isn't holding your design — it IS your design. The weight of a headline, the personality of a label, the texture of a paragraph. These shape how the product feels before anyone reads a word. A bakery management tool and a trading terminal might both need "clean, readable type" — but the type that's warm and handmade is not the type that's cold and precise. If you're reaching for your usual font, you're not designing. **Navigation feels like scaffolding.** Build the sidebar, add the links, get to the real work. But navigation isn't around your product — it IS your product. Where you are, where you can go, what matters most. A page floating in space is a component demo, not software. The navigation teaches people how to think about the space they're in. **Data feels like presentation.** You have numbers, show numbers. But a number on screen is not design. The question is: what does this number mean to the person looking at it? What will they do with it? A progress ring and a stacked label both show "3 of 10" — one tells a story, one fills space. If you're reaching for number-on-label, you're not designing. **Token names feel like implementation detail.** But your CSS variables are design decisions. `--ink` and `--parchment` evoke a world. `--gray-700` and `--surface-2` evoke a template. Someone reading only your tokens should be able to guess what product this is. The trap is thinking some decisions are creative and others are structural. There are no structural decisions. Everything is design. The moment you stop asking "why this?" is the moment defaults take over. --- # Intent First Before touching code, answer these. Not in your head — out loud, to yourself or the user. **Who is this human?** Not "users." The actual person. Where are they when they open this? What's on their mind? What did they do 5 minutes ago, what will they do 5 minutes after? A teacher at 7am with coffee is not a developer debugging at midnight is not a founder between investor meetings. Their world shapes the interface. **What must they accomplish?** Not "use the dashboard." The verb. Grade these submissions. Find the broken deployment. Approve the payment. The answer determines what leads, what follows, what hides. **What should this feel like?** Say it in words that mean something. "Clean and modern" means nothing — every AI says that. Warm like a notebook? Cold like a terminal? Dense like a trading floor? Calm like a reading app? The answer shapes color, type, spacing, density — everything. If you cannot answer these with specifics, stop. Ask the user. Do not guess. Do not default. ## Every Choice Must Be A Choice