Smartdesign Design authority / v1.0
Checklist

The shared standard

Interfaces with
intent.

Smartdesign is a practical design language for people and agents building products together. It keeps interfaces clear, consistent, accessible, and appropriate to the work.

02

The problem

AI can produce a polished interface before it understands the person using it.

Without an authority to guide decisions, speed turns into sameness. Decoration substitutes for hierarchy. More UI fills the space. A technically complete interface can still make the important thing harder to find.

Without a systemWith Smartdesign
Familiar patterns by default

Every product starts to resemble the last one.

Context before convention

Use the existing product and the user's goal to choose the pattern.

Chrome as a substitute for hierarchy

Cards, effects, and labels compete for attention.

Hierarchy does the work

Typography, spacing, and color establish what matters first.

Happy path only

Loading, errors, focus, and small screens arrive as surprises.

States are part of the design

Every relevant state is considered before the work is complete.

03

Principles

01

Intent first

Understand the user's actual workflow before adding structure, style, or motion.

02

Minimal chrome

Remove redundant headings, subtitles, cards, and decoration. Every element needs a job.

03

Visual restraint

Do not reach for gradients, glow, glass, or animation to replace clear communication.

04

Accessible by default

Use semantic HTML, visible focus, labels, contrast, and responsive behavior from the start.

05

Use what exists

Prefer existing components, tokens, actions, and state architecture over parallel systems.

06

Errors stay visible

Never turn a failed action into an empty state or a successful-looking result.

04

States are design

Default
Disabled
Loading
Success

A state should tell the truth.

Feedback is not decoration. It tells people what happened, what is happening, and what they can do next.

05

Final check

Before shipping, ask better questions.

  • Does this solve the user's actual problem?
  • Can every interaction be completed with a keyboard?
  • Are loading, empty, error, success, and disabled states handled?
  • Did we reuse the existing system instead of inventing another one?
  • Can anything visible be removed without reducing usability?