imikailoby Synthesis of Form — structural UI/UX method
Design is achieving fit between form (the interface) and context (everything the interface must answer to). Fit cannot be observed directly — only misfits can. So the method works negatively: hunt misfits, map how they interact, fix them piecemeal.
Run the steps in order whether architecting new UI or critiquing existing UI; when architecting, step 2's misfits are anticipated rather than observed.
1. Name the ensemble
Write down both halves before judging anything — the design object is never the form alone, always the ensemble:
- Form: screens, components, information architecture, interaction patterns, visual system, microcopy.
- Context: user goals and tasks, usage situations (device, environment, interruptions, time pressure), user characteristics (expertise, impairments, domain language), business and technical constraints.
Done when: someone reading the two lists could tell what would count as a failure.
2. Enumerate misfits
A misfit is a concrete point of stress in the ensemble — never "bad design" in the abstract. Every misfit names a form element AND the context condition it fails under: "the save action (form) is undiscoverable under time pressure on mobile (context)".
Sweep each category:
| Misfit | Stress |
|---|---|
| Conceptual | labels or model clash with users' mental model |
| Affordance | interactive reads as static, or static as interactive |
| Feedback | state changes invisible → repeat actions, doubt |
| Spatial | targets outside comfortable reach or scan zones |
| Temporal | latency or motion fights the task's tempo |
| Continuity | flow breaks working memory — screen-hopping, lost state |
Phrase every requirement functionally, never structurally: "user must identify the primary action within ~1s", not "the button must be big and blue" — structural phrasing smuggles a form decision into the problem statement and forecloses better forms.
Done when: every complaint, hunch, or requirement is either converted to a misfit (form element + context condition) or explicitly discarded as taste.
3. Map the misfit network
Misfits interact: fixing one moves others (fewer steps → more load per step; confirmation dialogs → expert friction; bolder CTA → brand clash). For each misfit, list which others a fix would plausibly ease or worsen. The clusters that emerge (navigation, input, feedback, …) are the real subsystems of the problem — regardless of how the codebase or the org chart divides it.
Done when: each misfit has its interaction edges listed and the clusters are named.
4. Decompose and design per cluster
Design each cluster semi-independently: dense misfit interactions inside a cluster, few across. For each cluster produce a diagram — the minimal structural idea that resolves the cluster's misfits simultaneously (Alexander's diagram is the ancestor of the design pattern). Cross-cluster edges that remain get an explicit contract (e.g., one set of timing/priority rules for notifications, shared by every flow that emits them).
Done when: every misfit belongs to exactly one cluster's diagram, and every cross-cluster edge has a stated contract.
5. Semilattice check
Real usage overlaps: the same screen serves multiple tasks, and search, deep links, recents, and shortcuts legitimately cut across the hierarchy. A structure forced into a strict tree is a misfit generator ("A City is Not a Tree"). Verify: overlaps that match real behavior are supported and signposted; overlaps that exist only because the hierarchy leaked are removed.
6. Fix piecemeal
Order fixes by misfit severity; take the smallest change that resolves the worst misfit. After each fix, re-check its network edges for induced misfits before moving on. Recommend a redesign only when a whole cluster's misfits share one structural cause. Each fix carries its own observation plan (metric, session replay, user check) so the loop closes on evidence.
7. Wholeness pass
Fit that survives the checklist can still feel wrong. Walk the primary task end to end once and ask: calm or stressful? coherent or scattered? does repetition build familiarity and trust? A "passes the checklist but feels off" is a misfit you have not yet named — return to step 2 with it; never override the feeling with the checklist.
Pairs with laws-of-ux: that skill judges individual elements with psychology heuristics; this one structures the whole ensemble. Fire both on substantial UI work.