Skip to content

No-Go’s

A direct reference for design choices Mpalo should not make, grounded in institutional truth, human agency, and domain boundaries.

Do not make a claim look more certain than it is

Mpalo’s ground principle is observable truth. Unknown, unverified, planned, and unavailable behavior must remain distinguishable from current capability.

  • Do not fabricate facts, measurements, implementation status, evidence, or product outcomes.
  • Do not present a planned, research, mock, or contract-stage capability as live behavior.
  • Do not use polish, animation, or confident wording to hide uncertainty or missing evidence.
  • Do not imply a user’s identity, memory, or agency is represented more completely than the system can support.

Do not take meaningful control away from people

  • Do not disguise consequential choices, make recovery unnecessarily difficult, or make a guided path impossible to leave.
  • Do not use urgency, shame, or ambiguity to push a person toward an action.
  • Do not collect or request information without explaining its purpose at the point it matters.
  • Do not make essential information or actions depend only on color, hover, sound, animation, or pointer use.

Do not add visual structure without a reason

Every visual element needs a job. Use spacing, alignment, and surface color to establish hierarchy before adding lines or decoration.

  • Do not wrap ordinary content in cards just to make it look organized.
  • Never use a left-border badge, side stripe, or badge card to label ordinary content. This pattern is a design No-Go. When order matters, use a typographic number beside its content without a box, background, border, or badge container.
  • Do not add borders or separators as a default. Add one only when it carries necessary grouping or interaction information.
  • Do not use an icon where a clear text label is needed, or repeat decorative icons beside every navigation item.
  • Do not use a color, font, token, or component outside its documented domain role without recording why.

Do not flatten the domain hierarchy

  • Do not make public Mpalo feel like a terminal or make expert tools read like marketing pages.
  • Do not copy a domain’s palette or component behavior into another domain by default.
  • Do not let technical density remove human context, or let humanist expression make a technical contract imprecise.
  • Do not present internal or access-controlled material as public developer guidance.

When a proposed design seems to require a no-go, pause and document the user need, evidence, domain, and least harmful alternative before changing the guidance.