# Interface Intelligence > Understand the real interface problem before deciding on a solution, separating request from intent and evidence from assumption. Use for ambiguous interface requests, major redesigns, unfamiliar products, consequential interaction decisions, or when the proposed UI may not be the real solution. - Skill: `dragoon0x/interface-intelligence` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add dragoon0x/interface-intelligence` - Raw SKILL.md: https://api.skillmd.com/api/skills/dragoon0x/interface-intelligence/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: dragoon0x (https://skillmd.com/u/dragoon0x) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/dragoon0x/interface-intelligence --- # Interface Intelligence ## Mission Understand the interface problem before deciding what the interface should look like. An interface helps a person perceive a situation, decide what matters, act, understand what happened, and recover when reality differs from expectation. ## When to use Use for ambiguous requests, major redesigns, unfamiliar products, consequential interaction decisions, and requests where the proposed UI may not be the real solution. ## Evidence model Separate: - REQUEST: explicitly asked - INTENT: intended outcome - EVIDENCE: directly observed - INFERENCE: reasonable conclusion - ASSUMPTION: unverified dependency - UNKNOWN: information that may change the decision Never present an assumption as fact. ## Interface outcome Define: > When [context], the person needs to [task], so they can [result]. Also identify trigger, frequency, current workaround, failure cost, and success criteria. ## Interface archaeology For an existing product trace: **goal → workflow → surface → component → state → interaction → feedback → persistence** A local visual problem may originate in a higher-level information or state decision. ## Information scent Check whether labels, grouping, hierarchy, and context let users predict what an action will do. Do not add explanatory copy to compensate for weak structure when structure itself can improve. ## Decision surface For every user choice ask: - Is it necessary? - Could a good default remove it? - Can it be deferred? - What happens if it is wrong? Reduce unnecessary decisions without hiding necessary ones. ## Frequency Frequent actions deserve low friction, predictable placement, low latency, and restrained feedback. Rare or high-consequence actions can justify explanation and deliberate pacing. ## Reversibility Easy-to-reverse actions should be fast. Hard-to-reverse actions need clear consequences. Prefer undo when it is safer than confirmation. ## Context preservation When changing surfaces, ask what context the person must reconstruct. Preserve context when it materially reduces cognitive load. ## Alternatives For consequential decisions consider: 1. requested solution 2. simpler solution 3. existing capability 4. different interaction model 5. do nothing Choose based on outcome, not novelty. ## Hard rules - Do not design from a screenshot alone when workflow context exists. - Do not add controls merely because a state exists. - Do not use tooltips as the primary fix for structural discoverability problems. - Do not hide essential actions solely for minimal aesthetics. - Do not introduce a new pattern without checking adjacent patterns. - Do not treat a feature request as proof that the feature is necessary. ## Failure modes ### Noun solving Building the requested sidebar without understanding the navigation problem. ### Screen tunnel vision Optimizing one screen while worsening the surrounding flow. ### Default-state bias Evaluating only the ideal state. ### Aesthetic substitution Improving appearance while leaving the actual usability problem intact. ## Verification Confirm the task, common path, major decisions, assumptions, alternatives, and observable success criteria. ## Reference artifact Use `references/decision-record.md` to record a consequential interface decision with its evidence, alternatives, tradeoffs, and residual uncertainty. ## Completion criteria The interface problem is sufficiently understood that implementation can begin without guessing about the core user outcome. ## Expert Review Protocol ### First pass: understand Before changing anything, identify the actual user outcome, the existing system, the relevant constraints, and the evidence available. Do not begin by choosing a visual treatment. ### Second pass: compare Ask: - What is the simplest credible solution? - What is the strongest alternative? - What does the current solution cost? - What behavior does each option teach the user? - Which decision is easiest to reverse? - Which failure would be most expensive? Choose deliberately. ### Third pass: stress Do not review only the happy path. Apply pressure through: - repetition - interruption - missing content - long content - slow operations - narrow space - large text - keyboard use - touch use - focus changes - error recovery - restoration Use only scenarios that are relevant to the surface. ### Fourth pass: inspect the implementation When code exists, verify that the implementation preserves the interface decision. Look for: - duplicated sources of truth - styling that bypasses the system - state that can become stale - behavior that differs from adjacent components - abstractions that obscure rather than simplify - dependencies that are not earning their cost - performance work performed without evidence ### Fifth pass: critique the result Ask: > If this were shipped tomorrow, what would users notice that the builder has stopped noticing? Look for: - friction - ambiguity - inconsistency - unnecessary movement - weak recovery - hidden state - visual noise - inaccessible behavior - fragile edge cases ### Sixth pass: distinguish polish from substance A useful change improves one or more of: - understanding - speed - confidence - recovery - accessibility - consistency - maintainability If a change improves none of these and only adds decoration, treat it as suspect. ### Seventh pass: verify A claim is complete only when an appropriate form of evidence supports it. Use: - direct interaction - tests - runtime inspection - visual comparison - accessibility checks - performance measurement - source inspection Do not claim a check that did not occur. ### Completion standard Stop when: 1. the intended outcome is achieved 2. important states are handled 3. meaningful failure modes were considered 4. the interface fits its surrounding system 5. important claims are verified 6. remaining imperfections are lower-value than the risk of further change The goal is not maximal polish. The goal is a result that is difficult to improve without changing the underlying decision.