@salesforce/afv-skills 1.53.0 → 1.55.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/skills/dx-org-analyze/README.md +310 -0
- package/skills/dx-org-analyze/SKILL.md +261 -0
- package/skills/dx-org-analyze/references/collection-details.md +88 -0
- package/skills/dx-org-analyze/references/report-format.md +67 -0
- package/skills/dx-org-analyze/scripts/collect_org_data.py +823 -0
- package/skills/dx-org-analyze/scripts/compute_diff.py +1103 -0
- package/skills/dx-org-analyze/scripts/introspect_org.py +436 -0
- package/skills/dx-org-analyze/tests/README.md +46 -0
- package/skills/dx-org-analyze/tests/fixtures/org_a.json +76 -0
- package/skills/dx-org-analyze/tests/fixtures/org_b.json +70 -0
- package/skills/dx-org-analyze/tests/test_compute_diff.sh +284 -0
- package/skills/dx-org-analyze/tests/test_consistency.sh +428 -0
- package/skills/experience-design-validate/SKILL.md +163 -0
- package/skills/experience-design-validate/references/ai.md +54 -0
- package/skills/experience-design-validate/references/components.md +61 -0
- package/skills/experience-design-validate/references/craft.md +158 -0
- package/skills/experience-design-validate/references/data.md +59 -0
- package/skills/experience-design-validate/references/forms-flows.md +57 -0
- package/skills/experience-design-validate/references/interaction.md +53 -0
- package/skills/experience-design-validate/references/navigation.md +51 -0
- package/skills/experience-design-validate/references/performance.md +56 -0
- package/skills/experience-design-validate/references/records.md +60 -0
- package/skills/experience-design-validate/references/responsive.md +48 -0
- package/skills/experience-design-validate/references/scoring-rubric.md +257 -0
- package/skills/experience-design-validate/references/state.md +53 -0
- package/skills/experience-design-validate/references/trust.md +47 -0
- package/skills/experience-design-validate/references/usability.md +35 -0
- package/skills/experience-design-validate/references/visual-system.md +183 -0
- package/skills/service-agentforce-contact-center-coordinate/SKILL.md +170 -0
- package/skills/service-agentforce-contact-center-coordinate/assets/escalation-flow.flow-meta.xml +72 -0
- package/skills/service-agentforce-contact-center-coordinate/assets/omni-flow.flow-meta.xml +85 -0
- package/skills/service-agentforce-contact-center-coordinate/assets/report-template.md +52 -0
- package/skills/service-agentforce-contact-center-coordinate/references/agentforce-prerequisite.md +31 -0
- package/skills/service-agentforce-contact-center-coordinate/references/messaging_channel.md +76 -0
- package/skills/service-agentforce-contact-center-coordinate/references/number_management_api.md +78 -0
- package/skills/service-agentforce-contact-center-coordinate/references/omni-flow-routing.md +74 -0
- package/skills/service-agentforce-contact-center-coordinate/references/setup_summary.md +36 -0
- package/skills/service-agentforce-contact-center-coordinate/references/verification_and_errors.md +42 -0
- package/skills/service-agentforce-contact-center-coordinate/scripts/check-agentforce-prereq.sh +54 -0
- package/skills/service-agentforce-contact-center-coordinate/scripts/create-routing-flows.sh +49 -0
- package/skills/service-agentforce-contact-center-coordinate/scripts/create-voice-agent.sh +73 -0
- package/skills/service-agentforce-contact-center-coordinate/scripts/create-voice-channel.sh +66 -0
- package/skills/service-agentforce-contact-center-coordinate/scripts/fetch-numbers.sh +21 -0
- package/skills/service-agentforce-contact-center-coordinate/scripts/lib.sh +46 -0
- package/skills/service-agentforce-contact-center-coordinate/scripts/prepare-agent-workdir.sh +21 -0
- package/skills/service-agentforce-contact-center-coordinate/scripts/procure-number.sh +24 -0
- package/skills/service-agentforce-contact-center-coordinate/scripts/resolve-acc-queue.sh +27 -0
- package/skills/service-agentforce-contact-center-coordinate/scripts/resolve-channel-line.sh +37 -0
- package/skills/service-agentforce-contact-center-coordinate/scripts/resolve-flow-definition.sh +33 -0
- package/skills/service-agentforce-contact-center-coordinate/scripts/verify-number-live.sh +63 -0
|
@@ -0,0 +1,257 @@
|
|
|
1
|
+
# Scoring Rubric
|
|
2
|
+
|
|
3
|
+
Use this rubric to judge the visual craft of a rendered design across five dimensions. Scores describe only the evidence observed in the declared evidence mode.
|
|
4
|
+
|
|
5
|
+
## Scoring rules
|
|
6
|
+
|
|
7
|
+
Every score must be:
|
|
8
|
+
|
|
9
|
+
- **Evidence-based:** cite specific, visible or directly observed qualities.
|
|
10
|
+
- **Bounded:** do not treat unobserved screens, behavior, states, responsiveness, or performance as good or bad.
|
|
11
|
+
- **Repeatable:** another reviewer should land within one point using the same evidence.
|
|
12
|
+
- **Actionable:** name what the next supported level requires.
|
|
13
|
+
- **Felt:** judge the visible experience, not implementation or intent.
|
|
14
|
+
|
|
15
|
+
### Anchor selection
|
|
16
|
+
|
|
17
|
+
Use the anchors at 2, 4, 6, 8, and 10. For each dimension:
|
|
18
|
+
|
|
19
|
+
1. Determine which criteria are applicable and observable in the declared evidence mode.
|
|
20
|
+
2. Evaluate anchors from 10 downward.
|
|
21
|
+
3. Assign the **highest anchor whose applicable, observable criteria are all fully supported by evidence**.
|
|
22
|
+
4. Assign the odd score above that anchor only when all criteria at the anchor are supported and the evidence clearly exceeds it but does not fully support the next anchor. For example, 7 means all applicable criteria at 6 are supported and some, but not all, applicable criteria at 8 are supported.
|
|
23
|
+
5. Assign 1 only when observed evidence falls below the applicable criteria at anchor 2.
|
|
24
|
+
6. Use `INSUFFICIENT_EVIDENCE` rather than a number when evidence cannot support the applicable dimension. Use `N/A` only when the dimension genuinely does not apply.
|
|
25
|
+
|
|
26
|
+
Do not start from an assumed middle score. Do not average unknowns into a score. When evidence supports multiple anchors, choose the highest fully supported anchor, not the lowest level whose criteria happen to be met.
|
|
27
|
+
|
|
28
|
+
## Scale and visual-craft implication
|
|
29
|
+
|
|
30
|
+
| Score | Level | Visual-craft implication only |
|
|
31
|
+
|---|---|---|
|
|
32
|
+
| 10 | Exceptional | Reference-quality visual craft; suitable to showcase for craft |
|
|
33
|
+
| 9 | Near-exceptional | Visually excellent with trivial polish opportunities |
|
|
34
|
+
| 8 | Strong | Visually ready with minor craft opportunities |
|
|
35
|
+
| **7** | **Good** | **Meets the visual-craft threshold with a minor polish plan** |
|
|
36
|
+
| 6 | Above adequate | Visually functional but craft is uneven |
|
|
37
|
+
| 5 | Adequate | Clear visible friction or roughness remains |
|
|
38
|
+
| 4 | Below standard | Significant craft issues diminish the visible experience |
|
|
39
|
+
| 3 | Poor | Multiple visible craft failures make the design feel rushed |
|
|
40
|
+
| 2 | Very poor | Fundamental visible craft failures require major rework |
|
|
41
|
+
| 1 | Critical | The rendered design feels visually broken or abandoned |
|
|
42
|
+
|
|
43
|
+
These implications do not approve accessibility, functional behavior, security, measured performance, or production release.
|
|
44
|
+
|
|
45
|
+
## Verdict
|
|
46
|
+
|
|
47
|
+
- **PASS:** every applicable dimension is scored and all scores are at least 7.
|
|
48
|
+
- **WARN:** every applicable dimension is scored; at least one is below 7 and none is below 5.
|
|
49
|
+
- **FAIL:** every applicable dimension is scored and at least one is below 5.
|
|
50
|
+
- **LIMITED:** at least one applicable dimension is `INSUFFICIENT_EVIDENCE`. Report supported scores as provisional observations, but do not imply complete visual-craft readiness.
|
|
51
|
+
|
|
52
|
+
`N/A` dimensions do not affect the verdict. If no dimension can be scored, do not issue a Craft Report verdict; follow the `INSUFFICIENT_VISUAL_EVIDENCE` behavior in `SKILL.md` when no rendered pixels exist, or return `LIMITED` with the coverage ledger when pixels exist but support no dimension-level score.
|
|
53
|
+
|
|
54
|
+
## Dimension anchors
|
|
55
|
+
|
|
56
|
+
### Useful
|
|
57
|
+
|
|
58
|
+
Felt question: *Does the visible content earn the space and attention it occupies?*
|
|
59
|
+
|
|
60
|
+
| Anchor | Observable criteria |
|
|
61
|
+
|---|---|
|
|
62
|
+
| 10 | Every visible element appears purposeful; priority and restraint anticipate the user's visible needs; no decorative dead weight competes for attention. |
|
|
63
|
+
| 8 | Core visible goals are well supported; most elements clearly earn their place; only minor tangents remain. |
|
|
64
|
+
| 6 | The visible value is understandable, but some content feels tangential, unfinished, or weakly prioritized. |
|
|
65
|
+
| 4 | Multiple visible elements do not earn their space; clutter obscures the apparent purpose. |
|
|
66
|
+
| 2 | The surface is dominated by content that does not visibly support the apparent core task. |
|
|
67
|
+
|
|
68
|
+
Do not infer whether features meet real user needs from pixels alone. Qualify the score as visible usefulness and flag behavioral assumptions for research.
|
|
69
|
+
|
|
70
|
+
### Usable
|
|
71
|
+
|
|
72
|
+
Felt question: *Does the visible hierarchy make the intended path feel effortless?*
|
|
73
|
+
|
|
74
|
+
| Anchor | Observable criteria |
|
|
75
|
+
|---|---|
|
|
76
|
+
| 10 | The intended path is visually unmistakable; complex structure feels simple; visible affordances prevent likely mistakes. |
|
|
77
|
+
| 8 | Primary actions and next steps are clear with minor hierarchy or affordance gaps. |
|
|
78
|
+
| 6 | The path is discoverable but invites hesitation; some visible actions compete or lack clarity. |
|
|
79
|
+
| 4 | Common visible paths appear confusing, fragmented, or poorly prioritized. |
|
|
80
|
+
| 2 | The rendered surface provides little visible guidance toward a core task. |
|
|
81
|
+
|
|
82
|
+
Static evidence supports visible hierarchy and affordance only, not task completion, recovery behavior, keyboard operation, or observed user success.
|
|
83
|
+
|
|
84
|
+
### Reliable
|
|
85
|
+
|
|
86
|
+
Felt question: *Do the observed states and feedback make the experience feel predictable?*
|
|
87
|
+
|
|
88
|
+
For `DYNAMIC_VISUAL` evidence, use these anchors:
|
|
89
|
+
|
|
90
|
+
| Anchor | Dynamic observable criteria |
|
|
91
|
+
|---|---|
|
|
92
|
+
| 10 | Every directly exercised relevant state and transition is clear, calm, and designed; observed feedback and timing remove uncertainty. |
|
|
93
|
+
| 8 | Major exercised states and feedback are clear; only minor observed edge gaps remain. |
|
|
94
|
+
| 6 | Observed states function but some treatment is generic, ambiguous, or poorly timed. |
|
|
95
|
+
| 4 | Directly observed feedback is missing, contradictory, or visibly brittle. |
|
|
96
|
+
| 2 | Observed behavior leaves the user unable to tell what happened or whether work persisted. |
|
|
97
|
+
|
|
98
|
+
For `STATIC_VISUAL` or `MULTI_VIEW_STATIC` evidence, score only the visible communication of depicted states and consequences:
|
|
99
|
+
|
|
100
|
+
| Anchor | Static observable criteria |
|
|
101
|
+
|---|---|
|
|
102
|
+
| 10 | Every depicted relevant state or consequence is immediately legible, calm, specifically authored, and unambiguous in context. |
|
|
103
|
+
| 8 | Major depicted states and consequences are clear and specifically treated; only minor visual-communication gaps remain. |
|
|
104
|
+
| 6 | Depicted states are identifiable, but some treatment is generic, ambiguous, or weakly prioritized. |
|
|
105
|
+
| 4 | Important depicted state or consequence cues are contradictory, hard to associate, or visually overwhelmed. |
|
|
106
|
+
| 2 | The depicted state leaves the viewer unable to tell what is true, what changed in the captured moment, or which visible action has serious consequences. |
|
|
107
|
+
|
|
108
|
+
Qualify every static Reliable score as **depicted-state visual communication only**. A static score cannot substantiate state coverage, transition behavior, save behavior, feedback timing, persistence, or performance. Use `INSUFFICIENT_EVIDENCE` when no relevant state or consequence is visibly depicted, or when behavior is necessary to score the dimension responsibly.
|
|
109
|
+
|
|
110
|
+
### Coherent
|
|
111
|
+
|
|
112
|
+
Felt question: *Does the visible experience feel like the same hand made it?*
|
|
113
|
+
|
|
114
|
+
| Anchor | Observable criteria |
|
|
115
|
+
|---|---|
|
|
116
|
+
| 10 | Every supplied screen shares one disciplined visual language; variants have clear visible purpose; patterns repeat consistently. |
|
|
117
|
+
| 8 | Core screens are visibly consistent with minor deviations in secondary areas. |
|
|
118
|
+
| 6 | The main visual language is recognizable, but repeated patterns drift. |
|
|
119
|
+
| 4 | Major visible inconsistencies make surfaces feel assembled by separate teams. |
|
|
120
|
+
| 2 | Supplied screens feel like unrelated products with no discernible shared system. |
|
|
121
|
+
|
|
122
|
+
One screenshot may support internal composition coherence, but cross-screen coherence requires multiple screens.
|
|
123
|
+
|
|
124
|
+
### Well-Crafted
|
|
125
|
+
|
|
126
|
+
Felt question: *Does the rendered design feel precise, considered, and delightful?*
|
|
127
|
+
|
|
128
|
+
| Anchor | Observable criteria |
|
|
129
|
+
|---|---|
|
|
130
|
+
| 10 | Every observed detail feels intentional and precise; hierarchy, type, spacing, alignment, color, and any exercised motion work as one quiet whole. |
|
|
131
|
+
| 8 | Execution is visibly strong and consistent with only minor polish opportunities. |
|
|
132
|
+
| 6 | Execution is generally sound but visible alignment, spacing, hierarchy, or state-treatment gaps remain. |
|
|
133
|
+
| 4 | Multiple visible inconsistencies or unfinished treatments make the design feel rough. |
|
|
134
|
+
| 2 | Pervasive visual quality failures make the rendered design feel broken or abandoned. |
|
|
135
|
+
|
|
136
|
+
Do not require motion, responsiveness, dark mode, reduced motion, or unseen states unless they are relevant and directly evidenced.
|
|
137
|
+
|
|
138
|
+
## Coverage and relevance ledger
|
|
139
|
+
|
|
140
|
+
The report must include a ledger before scores. Create one row for every dimension and every reference topic considered.
|
|
141
|
+
|
|
142
|
+
| Field | Allowed content |
|
|
143
|
+
|---|---|
|
|
144
|
+
| `item` | Dimension or reference topic |
|
|
145
|
+
| `relevance` | `APPLICABLE` or `N/A` |
|
|
146
|
+
| `coverage` | `SCORED`, `INSUFFICIENT_EVIDENCE`, or `N/A` |
|
|
147
|
+
| `evidence_mode` | `STATIC_VISUAL`, `MULTI_VIEW_STATIC`, or `DYNAMIC_VISUAL` |
|
|
148
|
+
| `evidence` | Artifact, screen, state, viewport, recording segment, or directly observed action |
|
|
149
|
+
| `reason` | Why it is scored, not applicable, or insufficiently evidenced |
|
|
150
|
+
|
|
151
|
+
`N/A` means the topic is absent or irrelevant. `INSUFFICIENT_EVIDENCE` means it is relevant but not observable. Never collapse these states into `Unknown`, and never invent a score to make the table complete.
|
|
152
|
+
|
|
153
|
+
## Finding severity
|
|
154
|
+
|
|
155
|
+
- **critical:** An observed visual-craft failure blocks comprehension of the primary surface or makes a destructive/high-consequence path visibly unsafe. Address before claiming visual-craft readiness.
|
|
156
|
+
- **major:** A repeated or prominent issue substantially weakens hierarchy, confidence, or task clarity. It materially lowers one or more dimensions.
|
|
157
|
+
- **minor:** A localized issue causes noticeable friction or inconsistency without undermining the primary path.
|
|
158
|
+
- **polish:** A small refinement would improve precision or delight but does not create meaningful confusion.
|
|
159
|
+
|
|
160
|
+
Each finding has one `primary_dimension`, the dimension most directly weakened by the root cause, and zero or more `related_dimensions`. Record the finding once and reference related dimensions rather than duplicating it. If severity could fit multiple levels, use the highest supported severity.
|
|
161
|
+
|
|
162
|
+
## Output discipline
|
|
163
|
+
|
|
164
|
+
- Cap findings at five per dimension.
|
|
165
|
+
- Consolidate a problem seen in three or more places into one finding with a count and representative location.
|
|
166
|
+
- Include zero to five cross-cutting patterns. A pattern must span multiple findings.
|
|
167
|
+
- Include zero to five recommendations, ordered by expected effect on observed visual craft.
|
|
168
|
+
- Do not add findings, patterns, or recommendations merely to fill the schema.
|
|
169
|
+
- Flag recommendations dependent on real-user behavior for usability research.
|
|
170
|
+
- Keep accessibility findings out of this report and route compliance to `experience-accessibility-validate`.
|
|
171
|
+
|
|
172
|
+
## Craft Report schema
|
|
173
|
+
|
|
174
|
+
```text
|
|
175
|
+
scope: visual-craft-only
|
|
176
|
+
verdict: PASS | WARN | FAIL | LIMITED
|
|
177
|
+
evidence_mode: STATIC_VISUAL | MULTI_VIEW_STATIC | DYNAMIC_VISUAL
|
|
178
|
+
evidence_inventory: [artifacts, screens, states, viewports, or recording segments reviewed]
|
|
179
|
+
evidence_limitations: [what this evidence cannot substantiate]
|
|
180
|
+
|
|
181
|
+
first_impressions: [0-3 felt observations recorded before rubric analysis]
|
|
182
|
+
|
|
183
|
+
coverage_relevance_ledger:
|
|
184
|
+
- item: [dimension or reference topic]
|
|
185
|
+
relevance: APPLICABLE | N/A
|
|
186
|
+
coverage: SCORED | INSUFFICIENT_EVIDENCE | N/A
|
|
187
|
+
evidence_mode: [mode]
|
|
188
|
+
evidence: [specific artifact or observation, or none]
|
|
189
|
+
reason: [concise rationale]
|
|
190
|
+
|
|
191
|
+
dimensions:
|
|
192
|
+
- name: Useful | Usable | Reliable | Coherent | Well-Crafted
|
|
193
|
+
score: [1-10] | INSUFFICIENT_EVIDENCE | N/A
|
|
194
|
+
evidence: [specific observed evidence]
|
|
195
|
+
gap_to_next_level: [next fully supportable craft improvement] | N/A
|
|
196
|
+
|
|
197
|
+
findings:
|
|
198
|
+
- severity: critical | major | minor | polish
|
|
199
|
+
primary_dimension: [one dimension]
|
|
200
|
+
related_dimensions: [zero or more other dimensions]
|
|
201
|
+
location: [screen, region, state, viewport, or Figma node; never file:line]
|
|
202
|
+
problem: [visible or directly observed issue]
|
|
203
|
+
why_it_weakens_craft: [design principle and felt effect]
|
|
204
|
+
what_better_looks_like: [improved visible experience]
|
|
205
|
+
fix: [specific design move]
|
|
206
|
+
|
|
207
|
+
cross_cutting_patterns: [0-5 evidence-backed themes]
|
|
208
|
+
recommendations: [0-5 evidence-backed prioritized moves]
|
|
209
|
+
fix_prompt: [self-contained design directive] | OMITTED_NO_ACTIONS
|
|
210
|
+
```
|
|
211
|
+
|
|
212
|
+
The report must state that the verdict indicates visual-craft readiness only and is not an accessibility, functionality, performance, security, or production-release approval.
|
|
213
|
+
|
|
214
|
+
## Comparative schema
|
|
215
|
+
|
|
216
|
+
Preserve the complete individual audit for each design, then add:
|
|
217
|
+
|
|
218
|
+
```text
|
|
219
|
+
comparison_result: A_HIGHER_CRAFT | B_HIGHER_CRAFT | TIE | MIXED
|
|
220
|
+
|
|
221
|
+
designs:
|
|
222
|
+
- id: Design A
|
|
223
|
+
first_impressions: [0-3 observations]
|
|
224
|
+
strongest_visible_move: [evidence-backed strength]
|
|
225
|
+
gaps: [0-5 evidence-backed gaps or INSUFFICIENT_EVIDENCE entries]
|
|
226
|
+
- id: Design B
|
|
227
|
+
first_impressions: [0-3 observations]
|
|
228
|
+
strongest_visible_move: [evidence-backed strength]
|
|
229
|
+
gaps: [0-5 evidence-backed gaps or INSUFFICIENT_EVIDENCE entries]
|
|
230
|
+
|
|
231
|
+
comparison_table:
|
|
232
|
+
- dimension: [dimension]
|
|
233
|
+
design_a: [1-10] | INSUFFICIENT_EVIDENCE | N/A
|
|
234
|
+
design_b: [1-10] | INSUFFICIENT_EVIDENCE | N/A
|
|
235
|
+
outcome: A | B | TIE | NOT_COMPARABLE
|
|
236
|
+
evidence: [why]
|
|
237
|
+
|
|
238
|
+
differentiating_dimensions: [0-5 dimensions]
|
|
239
|
+
craft_moves:
|
|
240
|
+
design_a: [0-5 moves Design A executes better]
|
|
241
|
+
design_b: [0-5 moves Design B executes better]
|
|
242
|
+
borrow_without_copying: [0-5 grounded opportunities]
|
|
243
|
+
```
|
|
244
|
+
|
|
245
|
+
Use `TIE` when supported scores and qualitative evidence are materially equivalent. Use `MIXED` when each design leads in different dimensions or unequal evidence prevents a responsible overall ranking.
|
|
246
|
+
|
|
247
|
+
## Fix prompt
|
|
248
|
+
|
|
249
|
+
Include a fix prompt only when the report has at least one recommendation. It must:
|
|
250
|
+
|
|
251
|
+
- Open with a one-sentence felt goal and a short design brief.
|
|
252
|
+
- List only the report's evidence-backed recommendations, in priority order.
|
|
253
|
+
- Name the affected screen or region and felt outcome for each move.
|
|
254
|
+
- End with verification on fresh rendered evidence and identify dimensions expected to improve.
|
|
255
|
+
- Preserve parts of the design that already work.
|
|
256
|
+
|
|
257
|
+
Use design language, not CSS variables, class names, file paths, or implementation diffs. If there are no actionable recommendations, emit `OMITTED_NO_ACTIONS`.
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
# State Management UX
|
|
2
|
+
|
|
3
|
+
> **Load this reference for `DYNAMIC_VISUAL` evidence of state transitions. Static captures may support critique of a depicted state's visible treatment, but cannot substantiate state coverage, transition behavior, save behavior, recovery, or timing; mark those areas `INSUFFICIENT_EVIDENCE`.**
|
|
4
|
+
|
|
5
|
+
The craft of state is the craft of in-between moments — the loading shimmer, the empty canvas, the recovered failure. A well-crafted product feels considered in these moments: the skeleton matches the layout, the spinner is sized for its container, the empty state has been designed rather than left as blank space, the error feels like part of the product instead of something escaping from the database.
|
|
6
|
+
|
|
7
|
+
## Why this matters
|
|
8
|
+
|
|
9
|
+
Most products are judged on their happy path, but craft reveals itself in the transitions and edge cases. A loading state that shimmers in the exact shape of what's coming feels like a designed product; a generic full-page spinner feels like an unfinished one. An empty state with a thoughtful illustration and a clear next action feels like a host welcoming you in; a blank screen feels like a dead end. When a design is polished in these moments, the product feels alive and tended to. When it isn't, every wait, error, and empty view chips away at trust.
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## Loading
|
|
14
|
+
|
|
15
|
+
- **The indicator matches the wait.** Instant feedback for micro-operations, an inline spinner for short waits, a skeleton for longer ones, real progress for anything substantial. A spinner that flashes for a fraction of a second is worse than silence.
|
|
16
|
+
- **Skeletons mirror the shape of what's coming.** Same dimensions, same item count, same layout. When the real content arrives, nothing shifts.
|
|
17
|
+
- **Progress is honest.** A determinate bar moves with confidence. Fake or jumpy progress trains users to distrust every indicator the product will ever show them.
|
|
18
|
+
- **The page never goes blank between routes.** Navigation lights up the new destination immediately and uses a skeleton or crossfade for the body.
|
|
19
|
+
|
|
20
|
+
## Errors
|
|
21
|
+
|
|
22
|
+
- **Severity matches visual weight.** Inline notes for fields, banners for sections, page-level treatments for global failures. When everything is the same shade of red, nothing reads as urgent.
|
|
23
|
+
- **Errors speak to the user, not the database.** A message names what went wrong and how to recover — never a stack trace, never an opaque code.
|
|
24
|
+
- **Errors don't delete the user's work.** Submission failure preserves every valid field, scrolls to the first problem, and shows how many remain. Reversible mistakes get undo, not pre-confirmation.
|
|
25
|
+
|
|
26
|
+
## Empty
|
|
27
|
+
|
|
28
|
+
- **Empty is designed, not abandoned.** A short, situational headline; a sentence of context; a way forward. Blank space is a defect.
|
|
29
|
+
- **The flavor of empty is communicated.** "Nothing yet" reads differently from "no matches" reads differently from "you don't have access." Empty tables keep their headers.
|
|
30
|
+
|
|
31
|
+
## Offline and Sync
|
|
32
|
+
|
|
33
|
+
- **Offline is a state, not an error.** It's communicated calmly — visible but not alarming, self-removing the moment connectivity returns. Local interactions still feel alive; pending changes are visible. No silent data loss, ever.
|
|
34
|
+
- **Sync is invisible when it works.** Indicators only appear during active syncing, pending changes, or conflicts. Conflicts surface immediately with both values visible. Stale presence is worse than no presence.
|
|
35
|
+
|
|
36
|
+
## Optimism and Long Jobs
|
|
37
|
+
|
|
38
|
+
- **Optimism is reserved for the safe.** Reversible, rarely-failing changes show instantly. Destructive or financial changes don't. Rollback explains itself rather than reverting silently.
|
|
39
|
+
- **Long work doesn't trap the user.** Operations beyond a handful of seconds become jobs the user can navigate away from. Progress, time, and current activity are visible. Completion finds the user wherever they went. Cancellation is always honest about what happens to partial results.
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
## Scoring Guide
|
|
44
|
+
|
|
45
|
+
**Contributes to dimensions: Reliable, Usable**
|
|
46
|
+
|
|
47
|
+
| Score | Criteria |
|
|
48
|
+
|-------|----------|
|
|
49
|
+
| 9-10 | The in-between moments are designed. Loading, errors, empty, offline, sync, and long jobs all feel considered. The product feels tended to even when nothing is happening. |
|
|
50
|
+
| 7-8 | State handling is solid for primary flows with minor gaps at edges. |
|
|
51
|
+
| 5-6 | Generic errors, blank empty states, basic save behavior. The polish drops away outside the happy path. |
|
|
52
|
+
| 3-4 | States unmanaged. Silent failures. Blocking spinners. The product feels brittle. |
|
|
53
|
+
| 1-2 | Lost connection loses work. States show nothing. Trust is broken. |
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
# Trust & Safety
|
|
2
|
+
|
|
3
|
+
> **Skip this reference if the design shows no auth surfaces, no privacy controls, no permission UI, no destructive settings, and no risk-bearing actions.**
|
|
4
|
+
|
|
5
|
+
Craft in trust surfaces is the visual proof that a product takes consequences seriously. It shows up in the placement of a verification icon, the elevation of a danger zone, the restraint of a sensitive-data mask, the calibrated visual weight of a warning versus a critical confirmation. This reference judges the visual treatment of trust signals, the staging of authentication, and the progressive elevation of risk surfaces.
|
|
6
|
+
|
|
7
|
+
## Why this matters
|
|
8
|
+
|
|
9
|
+
Trust is a felt quality, not a feature — and craft is what makes a user feel safe before they read any copy. When craft is high, sensitive moments feel deliberate: the lock icon sits where the eye expects it, the danger zone is visually quarantined from the rest of the settings, warnings escalate in visual weight as stakes increase, and confirmations carry the right amount of friction without theatrics. When craft is low, trust surfaces feel either gaudy (every action a red banner) or careless (a destructive button styled like a save button). The visual register of risk is something users absorb subconsciously — a misstep here is the difference between confidence and unease.
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## Trust Signals
|
|
14
|
+
|
|
15
|
+
- **Visual polish is itself a trust signal.** Misaligned elements, mismatched typography, and broken layouts read as carelessness with everything else — including the user's data.
|
|
16
|
+
- **Verification indicators sit where the eye expects them.** A single recognizable icon, placed consistently across the product, with a quiet explanation on hover.
|
|
17
|
+
- **Sensitive data is masked by default.** A visibility toggle returns it on demand. Showing a credit card number or a phone number unprompted reads as careless.
|
|
18
|
+
|
|
19
|
+
## Authentication
|
|
20
|
+
|
|
21
|
+
- **Login is staged, not stuffed.** Identity first, credential second. A single mega-form for everything reads as bureaucratic.
|
|
22
|
+
- **Password fields are forgiving.** A show/hide toggle and live validation reduce the anxiety of typing into a black box.
|
|
23
|
+
|
|
24
|
+
## Consent
|
|
25
|
+
|
|
26
|
+
- **Cookie banners don't trap the user.** Dismissing without accepting is as easy as accepting. "Essential only" carries the same visual weight as "Accept all." A banner that blocks content until the user accepts reads as coercive.
|
|
27
|
+
|
|
28
|
+
## Risk Communication
|
|
29
|
+
|
|
30
|
+
- **Severity escalates with consequence.** Informational notes, cautionary highlights, warnings that pause the user, and critical confirmations that demand typing — each carries a distinct visual weight. When everything is the same shade of red, nothing reads as urgent.
|
|
31
|
+
- **Warnings appear before the point of no return.** Not after, not during — before. A warning that arrives after the action committed is theater.
|
|
32
|
+
- **The same severity treatment is never used for unequal risks.** When archiving and deleting wear the same warning, the user stops trusting the warnings.
|
|
33
|
+
- **Destructive settings are visually quarantined.** A "danger zone" set apart from ordinary settings — not interleaved with everyday toggles where a misclick is one row away.
|
|
34
|
+
|
|
35
|
+
---
|
|
36
|
+
|
|
37
|
+
## Scoring Guide
|
|
38
|
+
|
|
39
|
+
**Contributes to dimensions: Reliable, Coherent, Well-Crafted**
|
|
40
|
+
|
|
41
|
+
| Score | Criteria |
|
|
42
|
+
|-------|----------|
|
|
43
|
+
| 9-10 | Trust is earned through every interaction. Sensitive moments feel deliberate. Risk is calibrated. The danger zone is unmistakable. |
|
|
44
|
+
| 7-8 | Trust patterns are mostly consistent with minor gaps in disclosure or symmetry. |
|
|
45
|
+
| 5-6 | Bundled consent. Inconsistent warning severity. A few dark patterns. |
|
|
46
|
+
| 3-4 | Dark patterns. Invasive defaults. The product feels indifferent to consequence. |
|
|
47
|
+
| 1-2 | Trust is actively broken. Hidden data collection. Misleading consent. |
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
# Usability
|
|
2
|
+
|
|
3
|
+
> **Skip this reference if the design has no decisions to make, no actions to take, and no flow to navigate — i.e. nothing for craft to make smoother.**
|
|
4
|
+
|
|
5
|
+
Usability craft is the difference between a product that you operate and one that operates with you. It's the visible system status that tells you the save went through, the predictable interaction that lets you trust your muscle memory, the consistent pattern that makes the second use easier than the first. Good usability craft is invisible when it works — you just feel competent. Poor usability craft makes you feel stupid for not knowing where the controls are.
|
|
6
|
+
|
|
7
|
+
## Why this matters
|
|
8
|
+
|
|
9
|
+
Designs win or lose on the small moments of feedback and predictability. When a click produces an immediate visible response, when a state change is announced through motion or color, when consistent patterns mean the user never has to relearn — the product feels responsive and trustworthy. When those moments are missing, every interaction carries doubt: did it work, am I in the right place, is this the same control I used yesterday. Craft here is about respect — respecting the user's time, attention, and prior learning by making the system answer back when spoken to.
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## Feedback and Predictability
|
|
14
|
+
|
|
15
|
+
- **The system answers back when spoken to.** Every action produces a visible response — a state change, a confirmation, a transition — within the moment of the click. Silence reads as broken.
|
|
16
|
+
- **Patterns repeat.** The same kind of action looks and behaves the same across the product. When a "save" feels different on two screens, the user has to relearn instead of trust their muscle memory.
|
|
17
|
+
- **The user's place in the system is always visible.** Where they are, what's selected, what they just did. A page that wipes context after every interaction asks the user to rebuild it constantly.
|
|
18
|
+
- **Edges are designed.** Empty states, errors, loading, and success all feel like part of the same product — not afterthoughts grafted onto the happy path.
|
|
19
|
+
- **Hierarchy matches priority.** What's important looks important. When secondary actions outweigh primary ones visually, the user has to fight the design to do the right thing.
|
|
20
|
+
- **Interactive elements look interactive.** A button that looks like a label, a link that looks like static text, a card that hides a click target — each forces the user to discover by trial.
|
|
21
|
+
- **Simpler is preferred when both work.** Two controls where one would do, three options where two cover the cases — the extras add cognitive load without adding capability.
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
## Scoring Guide
|
|
26
|
+
|
|
27
|
+
**Contributes to dimensions: Usable, Useful, Well-Crafted**
|
|
28
|
+
|
|
29
|
+
| Score | Criteria |
|
|
30
|
+
|-------|----------|
|
|
31
|
+
| 9-10 | Edges are designed. Interactive elements look interactive. Hierarchy matches priority. The product responds to every input with visible craft. |
|
|
32
|
+
| 7-8 | Most flows feel responsive and predictable. Minor gaps in edge-state polish. |
|
|
33
|
+
| 5-6 | Happy path is fine; edges feel unfinished. Some controls don't feel interactive. |
|
|
34
|
+
| 3-4 | Inconsistent feedback. Edge states neglected. Hierarchy fights the user. |
|
|
35
|
+
| 1-2 | No visible system response. Interactions feel unanswered. |
|
|
@@ -0,0 +1,183 @@
|
|
|
1
|
+
# Visual System
|
|
2
|
+
|
|
3
|
+
> **Always load for any visual design. Skip only if the input is purely textual or pre-visual (a wireframe with no visual decisions yet made).**
|
|
4
|
+
|
|
5
|
+
What does the design look like? This reference judges the felt qualities of the visual system — layout, typography, color, surfaces, and visual assets — at the level a designer would discuss them in a critique. Not at the level of CSS variables.
|
|
6
|
+
|
|
7
|
+
## Why this matters
|
|
8
|
+
|
|
9
|
+
The visual system is the voice of the product. It's what users see before they read a word. A coherent visual system feels like one person made it; a fragmented one feels like a committee shipped it. Two designers can have the same layout brief and end up in completely different places — one with a system that feels intentional and quiet, one with a system that feels accumulated and loud.
|
|
10
|
+
|
|
11
|
+
Visual system findings are about *taste applied consistently*. The eye notices when the type sizes don't relate to each other, when the grays are slightly off from each other, when borders happen sometimes and not other times, when icons are different weights, when avatars are different sizes. None of these failures is catastrophic alone. Together, they're what separates "looks pro" from "looks built."
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## Layout
|
|
16
|
+
|
|
17
|
+
### What good layout feels like
|
|
18
|
+
|
|
19
|
+
- **One focal point per screen.** The eye knows where to land first. Everything else is calmer.
|
|
20
|
+
- **Generous whitespace around what matters.** Primary actions and headlines have air around them. Density is reserved for content where users need to compare or scan many items at once.
|
|
21
|
+
- **A consistent rhythm.** The vertical beat of the page is predictable — sections are spaced consistently, and the spacing between a heading and its content is tighter than the spacing between sections.
|
|
22
|
+
- **Aligned, not approximate.** Elements share precise edges, not "near enough" edges. The eye can detect 2-pixel misalignment even when it can't name it.
|
|
23
|
+
- **Density matched to context.** A dev tool earns dense, utilitarian layout. A consumer onboarding screen earns generous breathability. The layout reflects what the product is trying to be.
|
|
24
|
+
|
|
25
|
+
### Felt observations to make
|
|
26
|
+
|
|
27
|
+
- The eye knows where to land within the first second.
|
|
28
|
+
- Primary content is clearly heavier than chrome (toolbars, headers, sidebars).
|
|
29
|
+
- Headings are closer to their content than to the section above.
|
|
30
|
+
- Page margins are equal and don't change between similar pages.
|
|
31
|
+
- Whitespace around primary actions feels deliberate, not accidental.
|
|
32
|
+
- The grid feels consistent — columns don't shift between similar pages.
|
|
33
|
+
- Toolbar heights, sidebar widths, and content margins feel consistent across screens.
|
|
34
|
+
- Sticky headers stay put; scroll position is preserved when navigating away and back.
|
|
35
|
+
|
|
36
|
+
### What weak layout looks like
|
|
37
|
+
|
|
38
|
+
- The eye doesn't know where to start. Multiple things tied for primary.
|
|
39
|
+
- Sections butt up against each other; nothing breathes.
|
|
40
|
+
- Spacing varies subtly between similar screens — same component, different padding.
|
|
41
|
+
- Elements are *almost* aligned (a few pixels off) — looks like a mistake, not a choice.
|
|
42
|
+
- Page margins are uneven; one page has a wide gutter, another has none.
|
|
43
|
+
- Density mismatches the context — a marketing page is dense, a dashboard is sparse.
|
|
44
|
+
|
|
45
|
+
---
|
|
46
|
+
|
|
47
|
+
## Typography
|
|
48
|
+
|
|
49
|
+
### What good typography feels like
|
|
50
|
+
|
|
51
|
+
- **A small set of sizes, used consistently.** The product has 4–6 distinct text sizes that map to clear roles: page heading, section heading, body, label, metadata. Each role has one size. The reader knows what kind of text is what at a glance.
|
|
52
|
+
- **A tight set of weights.** Two or three weights. Bold for headlines, regular for body, perhaps medium for emphasis. Weight isn't sprinkled across the design.
|
|
53
|
+
- **Headlines have presence.** They feel like something to land on, not something to scroll past. The line break is intentional.
|
|
54
|
+
- **Body text is readable.** Lines are at a comfortable length (not edge-to-edge across a wide screen). Line-height is generous enough that reading feels relaxed.
|
|
55
|
+
- **One voice across the product.** The product speaks in one type voice, not three.
|
|
56
|
+
|
|
57
|
+
### Felt observations to make
|
|
58
|
+
|
|
59
|
+
- Type sizes feel like steps in a scale, not arbitrary choices.
|
|
60
|
+
- Headings stand out clearly. The hierarchy is unmistakable.
|
|
61
|
+
- Body text feels comfortable to read at a glance.
|
|
62
|
+
- The number of weights in active use feels small.
|
|
63
|
+
- Numbers in tables align (don't twitch as values change).
|
|
64
|
+
- Truncated text is signaled cleanly with an ellipsis, with full content available on hover or expand.
|
|
65
|
+
- Text doesn't run edge-to-edge across the entire viewport on wide screens.
|
|
66
|
+
|
|
67
|
+
### What weak typography looks like
|
|
68
|
+
|
|
69
|
+
- The product has many sizes that don't relate to each other — 13px, 14px, 15px, 16px all visible.
|
|
70
|
+
- Three or four weights mixed without clear logic.
|
|
71
|
+
- Headings and body text feel similar in weight or size — flat hierarchy.
|
|
72
|
+
- Body text runs the entire width of a wide screen, exhausting to read.
|
|
73
|
+
- Numbers in tables shift position as values change — feels unfinished.
|
|
74
|
+
- Capitalization is inconsistent: "Save Changes" here, "save changes" there, "SAVE" elsewhere.
|
|
75
|
+
|
|
76
|
+
---
|
|
77
|
+
|
|
78
|
+
## Color
|
|
79
|
+
|
|
80
|
+
### What good color feels like
|
|
81
|
+
|
|
82
|
+
- **A small, intentional palette.** The product uses few colors and uses them consistently. Each color earns its place — brand, action, error, success, neutral. Nothing decorative.
|
|
83
|
+
- **Surfaces feel intentional.** Three or four surface tones — page background, card, hover, selected — each visibly distinct. The eye doesn't have to ask "is this a different gray?"
|
|
84
|
+
- **Color signals meaning.** Green is positive, red is negative, the brand color is reserved for primary moments. The mapping is consistent everywhere.
|
|
85
|
+
- **Restraint with accent color.** The brand color appears where it matters — primary actions, key indicators — not as decoration.
|
|
86
|
+
- **Considered dark mode (if present).** Dark mode is its own design, not a color-inverted afterthought.
|
|
87
|
+
|
|
88
|
+
### Felt observations to make
|
|
89
|
+
|
|
90
|
+
- The palette feels tight and disciplined.
|
|
91
|
+
- Surface tones feel distinct from each other — no near-duplicates.
|
|
92
|
+
- The brand or accent color is used sparingly and purposefully.
|
|
93
|
+
- Status colors (positive, negative, warning) are consistent across the product.
|
|
94
|
+
- Dark mode (if present) feels like its own designed surface.
|
|
95
|
+
- Information isn't carried by color alone — pair with icon, label, or position.
|
|
96
|
+
|
|
97
|
+
### What weak color looks like
|
|
98
|
+
|
|
99
|
+
- Many near-identical grays accumulating across surfaces — the eye registers wear.
|
|
100
|
+
- The accent color is everywhere, including decorative uses, so primary actions don't stand out.
|
|
101
|
+
- Status colors flip meaning between views (green meant "complete" here, "ready to start" there).
|
|
102
|
+
- Dark mode looks like a contrast inversion of light mode, not a designed surface.
|
|
103
|
+
- The palette feels accumulated — colors added by different contributors over time.
|
|
104
|
+
|
|
105
|
+
---
|
|
106
|
+
|
|
107
|
+
## Surfaces
|
|
108
|
+
|
|
109
|
+
### What good surfaces feel like
|
|
110
|
+
|
|
111
|
+
- **Cards, panels, modals all feel like one family.** Same border treatment, same radii, same elevation language. A card on one screen is recognizable as a card on another.
|
|
112
|
+
- **Elevation has intent.** When something is lifted (modal, popover, sticky element), the elevation is clear and consistent. Shadows are tasteful, not heavy.
|
|
113
|
+
- **Borders are restrained.** Not every container has a border. When a border appears, it earns its place — separating things that need separating.
|
|
114
|
+
- **Radii are limited.** The product picks one or two corner radii and sticks to them. Cards aren't 4px-rounded in one place and 12px-rounded in another.
|
|
115
|
+
|
|
116
|
+
### Felt observations to make
|
|
117
|
+
|
|
118
|
+
- Cards across the product feel like the same family.
|
|
119
|
+
- Modals and popovers feel like the same family.
|
|
120
|
+
- Borders appear where separation is needed, not as decoration.
|
|
121
|
+
- Shadows are subtle and consistent — same elevation gets the same shadow.
|
|
122
|
+
- Corner radii are consistent within a context.
|
|
123
|
+
|
|
124
|
+
### What weak surfaces look like
|
|
125
|
+
|
|
126
|
+
- Cards on different screens have different radii, different shadows, different border treatments — the family is fragmented.
|
|
127
|
+
- Borders everywhere — every container framed for no reason.
|
|
128
|
+
- Shadows are too heavy or inconsistent — some elements feel like they're floating in front of glass, others feel painted on.
|
|
129
|
+
- A modal looks like a card looks like a popover looks like a panel — no elevation hierarchy.
|
|
130
|
+
|
|
131
|
+
---
|
|
132
|
+
|
|
133
|
+
## Visual Assets
|
|
134
|
+
|
|
135
|
+
### What good visual assets feel like
|
|
136
|
+
|
|
137
|
+
- **Icons are one family.** Same stroke weight, same style (outlined vs filled), same proportions. They look like a set, not a collection.
|
|
138
|
+
- **Icons are sized consistently in the same context.** A toolbar icon is the same size as another toolbar icon.
|
|
139
|
+
- **Imagery has intent.** Photos and illustrations feel chosen, not searched-and-pasted. They support the content, not decorate it.
|
|
140
|
+
- **Avatars are consistent.** Same size, same shape, same fallback treatment.
|
|
141
|
+
- **Empty states have personality.** When the product needs to fill space because there's nothing to show, the design uses the moment — a small illustration, a clear invitation, a personality.
|
|
142
|
+
|
|
143
|
+
### Felt observations to make
|
|
144
|
+
|
|
145
|
+
- Icons feel like a set — consistent stroke weight and style.
|
|
146
|
+
- Icons in similar contexts are similar sizes.
|
|
147
|
+
- Avatars are the same shape (round vs square) across the product.
|
|
148
|
+
- Imagery feels chosen, not generic.
|
|
149
|
+
- Empty states are designed moments, not blank screens with "No items."
|
|
150
|
+
|
|
151
|
+
### What weak visual assets look like
|
|
152
|
+
|
|
153
|
+
- Icons mix outlined and filled styles randomly. Stroke weights vary.
|
|
154
|
+
- Toolbar icons are different sizes from each other.
|
|
155
|
+
- Stock photography that doesn't match the brand voice.
|
|
156
|
+
- Avatars are round in one place, square in another.
|
|
157
|
+
- Empty states are blank, with a generic "No data" string.
|
|
158
|
+
|
|
159
|
+
---
|
|
160
|
+
|
|
161
|
+
## Cross-cutting felt qualities
|
|
162
|
+
|
|
163
|
+
When evaluating the visual system as a whole, ask:
|
|
164
|
+
|
|
165
|
+
- **Does the system feel like it has a point of view?** Or does it feel like an accumulation of contributions?
|
|
166
|
+
- **Could a new contributor extend this system without guessing?** The patterns should be self-documenting.
|
|
167
|
+
- **Does the visual vocabulary feel small?** Disciplined products use few sizes, weights, colors, and shapes — and use them everywhere.
|
|
168
|
+
- **Is anything shouting that doesn't need to?** Bold weights, accent colors, large sizes, and heavy borders should be reserved.
|
|
169
|
+
- **Where does the eye land first? Second? Third?** If you can't answer, hierarchy is broken.
|
|
170
|
+
|
|
171
|
+
---
|
|
172
|
+
|
|
173
|
+
## Scoring Guide
|
|
174
|
+
|
|
175
|
+
**Contributes to dimensions: Well-Crafted, Coherent**
|
|
176
|
+
|
|
177
|
+
| Score | Criteria |
|
|
178
|
+
|-------|----------|
|
|
179
|
+
| 9–10 | The visual system feels disciplined and intentional. Small vocabulary used consistently. Hierarchy is calm; restraint is visible. Surfaces, type, color, and assets all read as one family. The eye lands where it should. |
|
|
180
|
+
| 7–8 | Strong visual system with minor inconsistencies. The discipline is mostly visible; small drift in secondary screens. |
|
|
181
|
+
| 5–6 | Functional but uneven. Some inconsistencies are felt — type sizes drift, surface colors don't quite match, icons are mixed weights. The system reads as accumulated. |
|
|
182
|
+
| 3–4 | Visibly fragmented. Multiple type sizes without logic, color used decoratively, surfaces don't relate, icons from different families. The product feels assembled by different hands. |
|
|
183
|
+
| 1–2 | No visual system. Browser defaults visible; nothing relates to anything else; chaos. |
|