raven-mcp 1.0.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.
Files changed (35) hide show
  1. package/LICENSE +21 -0
  2. package/README.md +72 -0
  3. package/dist/index.d.ts +2 -0
  4. package/dist/index.js +629 -0
  5. package/dist/index.js.map +1 -0
  6. package/package.json +51 -0
  7. package/src/data/business/growth.json +48 -0
  8. package/src/data/business/metrics.json +48 -0
  9. package/src/data/business/monetization.json +56 -0
  10. package/src/data/business/onboarding.json +48 -0
  11. package/src/data/business/retention.json +48 -0
  12. package/src/data/patterns/cta.json +51 -0
  13. package/src/data/patterns/dashboard.json +51 -0
  14. package/src/data/patterns/empty-states.json +42 -0
  15. package/src/data/patterns/error-states.json +51 -0
  16. package/src/data/patterns/forms.json +53 -0
  17. package/src/data/patterns/landing-page.json +51 -0
  18. package/src/data/patterns/loading-states.json +51 -0
  19. package/src/data/patterns/mobile-conversion.json +51 -0
  20. package/src/data/patterns/modals-dialogs.json +51 -0
  21. package/src/data/patterns/navigation.json +50 -0
  22. package/src/data/patterns/pricing-page.json +59 -0
  23. package/src/data/patterns/signup-flow.json +52 -0
  24. package/src/data/patterns/social-proof.json +49 -0
  25. package/src/data/principles/accessibility.json +151 -0
  26. package/src/data/principles/color-theory.json +100 -0
  27. package/src/data/principles/d4d.json +113 -0
  28. package/src/data/principles/gestalt.json +129 -0
  29. package/src/data/principles/laws-of-ux.json +490 -0
  30. package/src/data/principles/mobile-ux.json +126 -0
  31. package/src/data/principles/nielsen-heuristics.json +258 -0
  32. package/src/data/principles/typography.json +117 -0
  33. package/src/data/tokens/registry.json +67 -0
  34. package/src/data/tokens/systems/linear.json +134 -0
  35. package/src/data/tokens/systems/stripe.json +147 -0
@@ -0,0 +1,490 @@
1
+ [
2
+ {
3
+ "id": "aesthetic-usability-effect",
4
+ "name": "Aesthetic-Usability Effect",
5
+ "category": "laws-of-ux",
6
+ "summary": "Users often perceive aesthetically pleasing design as design that's more usable.",
7
+ "description": "Attractive things work better — or at least users believe they do. An aesthetically pleasing interface creates a positive emotional response that makes users more tolerant of minor usability issues. This effect can mask usability problems during testing, so beautiful designs need rigorous usability testing. The takeaway: visual polish is not superficial — it directly impacts perceived usability and trust.",
8
+ "implications": [
9
+ "Invest in visual polish — it directly impacts perceived usability",
10
+ "Beautiful designs need MORE usability testing, not less (the effect masks problems)",
11
+ "Use visual design to build trust, especially for financial and health products",
12
+ "First impressions are formed in 50ms — aesthetic quality drives them"
13
+ ],
14
+ "violations": [
15
+ "Functional but visually outdated interface that erodes user trust",
16
+ "Beautiful prototype that passes testing but has hidden usability issues",
17
+ "Assuming good functionality compensates for poor visual design"
18
+ ],
19
+ "applies_to": ["visual-design", "trust", "branding", "landing-page", "first-impression"],
20
+ "sources": ["https://lawsofux.com/aesthetic-usability-effect/"]
21
+ },
22
+ {
23
+ "id": "doherty-threshold",
24
+ "name": "Doherty Threshold",
25
+ "category": "laws-of-ux",
26
+ "summary": "Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other.",
27
+ "description": "Research by Walter Doherty and Ahrvind Thadani at IBM showed that when system response time drops below 400 milliseconds, users enter a state of flow. Above this threshold, attention wanders and errors increase. The practical implication: perceived performance matters as much as actual performance. Use optimistic UI, skeleton screens, and progressive loading to keep interactions feeling instant.",
28
+ "implications": [
29
+ "Target <400ms response time for all interactions",
30
+ "Use optimistic UI updates — show the result before the server confirms",
31
+ "Show skeleton screens or shimmer placeholders during loading",
32
+ "Use animations (150-300ms) to make transitions feel smooth, not slow",
33
+ "Preload content the user is likely to need next",
34
+ "Use progressive loading — show content as it arrives, not all at once"
35
+ ],
36
+ "violations": [
37
+ "Full-page spinner for 2+ seconds on every navigation",
38
+ "Waiting for server confirmation before showing any UI update",
39
+ "No loading state — interface freezes while waiting for data",
40
+ "Animations longer than 400ms that feel sluggish"
41
+ ],
42
+ "applies_to": ["performance", "loading", "animation", "feedback", "optimistic-ui"],
43
+ "sources": ["https://lawsofux.com/doherty-threshold/"]
44
+ },
45
+ {
46
+ "id": "fitts-law",
47
+ "name": "Fitts's Law",
48
+ "category": "laws-of-ux",
49
+ "summary": "The time to acquire a target is a function of the distance to and size of the target.",
50
+ "description": "Formulated by Paul Fitts in 1954, this law states that the time to move to a target is logarithmically related to the distance divided by the target width. Larger, closer targets are faster to click. Screen edges and corners are effectively infinite-width targets (the cursor stops there). This has profound implications for button sizing, placement, and touch target design.",
51
+ "implications": [
52
+ "Make primary action buttons large and prominent",
53
+ "Place important actions near the user's current focus area",
54
+ "Use minimum 44x44px touch targets on mobile (Apple HIG), 48x48dp (Material)",
55
+ "Leverage screen edges and corners for frequently used controls",
56
+ "Group related actions together to reduce cursor travel distance",
57
+ "Make destructive actions small and far from primary actions",
58
+ "Consider right-click context menus to bring actions to the cursor"
59
+ ],
60
+ "violations": [
61
+ "Tiny close buttons on modals (12x12px)",
62
+ "Important CTAs far from the form fields they relate to",
63
+ "Touch targets smaller than 44px on mobile",
64
+ "Actions requiring precise cursor placement (thin borders, small checkboxes)",
65
+ "Critical actions placed in corners far from content"
66
+ ],
67
+ "applies_to": ["buttons", "navigation", "forms", "mobile", "cta", "touch-targets"],
68
+ "sources": ["https://lawsofux.com/fittss-law/"]
69
+ },
70
+ {
71
+ "id": "goal-gradient-effect",
72
+ "name": "Goal-Gradient Effect",
73
+ "category": "laws-of-ux",
74
+ "summary": "The tendency to approach a goal increases with proximity to the goal.",
75
+ "description": "People are more motivated to complete a task when they can see they're close to finishing. This is why progress bars, step indicators, and completion percentages work. The classic example: coffee loyalty cards pre-stamped with 2 of 12 stamps get completed faster than blank 10-of-10 cards. In UX, this means showing progress, breaking tasks into visible steps, and giving users a sense of advancement.",
76
+ "implications": [
77
+ "Show progress indicators on multi-step flows",
78
+ "Start users with some progress already completed (profile 20% complete)",
79
+ "Break long forms into smaller, numbered steps",
80
+ "Show completion percentage on profiles and onboarding",
81
+ "Use checklists that users can visibly check off",
82
+ "Celebrate milestones and completions with visual feedback"
83
+ ],
84
+ "violations": [
85
+ "Multi-step process with no indication of how many steps remain",
86
+ "Long form with no progress indicator",
87
+ "Onboarding that feels endless with no sense of how close the user is to done",
88
+ "No celebration or acknowledgment when a task is completed"
89
+ ],
90
+ "applies_to": ["onboarding", "forms", "progress", "gamification", "checkout", "signup"],
91
+ "sources": ["https://lawsofux.com/goal-gradient-effect/"]
92
+ },
93
+ {
94
+ "id": "hicks-law",
95
+ "name": "Hick's Law",
96
+ "category": "laws-of-ux",
97
+ "summary": "The time it takes to make a decision increases with the number and complexity of choices.",
98
+ "description": "Described by William Edmund Hick and Ray Hyman, this law quantifies the relationship between choices and decision time. More options = longer decision time = higher abandonment risk. This doesn't mean removing all choices — it means structuring them. Progressive disclosure, smart defaults, and categorization all help manage complexity without removing functionality.",
99
+ "implications": [
100
+ "Limit navigation items to 7±2 top-level options",
101
+ "Use progressive disclosure to reveal options as needed",
102
+ "Highlight a recommended option in pricing and feature selections",
103
+ "Break complex decisions into smaller sequential choices",
104
+ "Use smart defaults to reduce the number of decisions users must make",
105
+ "Categorize and group options to reduce perceived complexity",
106
+ "Consider a search/filter for lists with 15+ items"
107
+ ],
108
+ "violations": [
109
+ "Mega-menus with 50+ uncategorized options",
110
+ "Pricing page with 6+ plans and no recommended option",
111
+ "Settings page with 100+ toggles all visible at once",
112
+ "Dropdown with 200 unsearchable options",
113
+ "Homepage with 10+ competing CTAs"
114
+ ],
115
+ "applies_to": ["navigation", "pricing", "forms", "settings", "menus", "cta", "decision-making"],
116
+ "sources": ["https://lawsofux.com/hicks-law/"]
117
+ },
118
+ {
119
+ "id": "jakobs-law",
120
+ "name": "Jakob's Law",
121
+ "category": "laws-of-ux",
122
+ "summary": "Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.",
123
+ "description": "Named after Jakob Nielsen, this law recognizes that users build mental models from their cumulative experience across all digital products. When you deviate from established conventions, you force users to learn new patterns, increasing cognitive load and error rates. Innovation is good, but it should build on familiar foundations. Use common patterns and innovate on top of them, not instead of them.",
124
+ "implications": [
125
+ "Follow platform conventions for common interactions (navigation, search, forms)",
126
+ "Place the logo in the top-left, linking to the homepage",
127
+ "Put search in the top-right or center of the header",
128
+ "Use standard e-commerce checkout patterns",
129
+ "Follow OS conventions for native apps (iOS HIG, Material Design)",
130
+ "Innovate on value proposition, not on basic interaction patterns",
131
+ "When you must break convention, provide clear affordances and guidance"
132
+ ],
133
+ "violations": [
134
+ "Custom navigation patterns that don't match any standard app",
135
+ "Non-standard scroll behavior (horizontal scrolling for content, scroll hijacking)",
136
+ "Creative but confusing form layouts (labels inside inputs that don't float)",
137
+ "Bottom navigation on desktop or top tabs on mobile",
138
+ "Non-standard gestures for common actions"
139
+ ],
140
+ "applies_to": ["navigation", "layout", "forms", "conventions", "patterns", "mobile"],
141
+ "sources": ["https://lawsofux.com/jakobs-law/"]
142
+ },
143
+ {
144
+ "id": "law-of-common-region",
145
+ "name": "Law of Common Region",
146
+ "category": "laws-of-ux",
147
+ "summary": "Elements tend to be perceived into groups if they are sharing an area with a clearly defined boundary.",
148
+ "description": "A Gestalt principle stating that elements within a shared visual boundary are perceived as a group. Cards, panels, sections with borders, and background colors all create regions. This is fundamental to information architecture — grouping related content visually communicates structure without requiring labels. It's one of the strongest grouping cues available.",
149
+ "implications": [
150
+ "Use cards to group related information",
151
+ "Apply subtle background colors to delineate sections",
152
+ "Use borders or dividers to separate distinct groups",
153
+ "Ensure form field groups are visually contained",
154
+ "Use whitespace between regions to reinforce boundaries",
155
+ "Apply consistent styling to similar regions (all feature cards look alike)"
156
+ ],
157
+ "violations": [
158
+ "Related form fields that span different visual regions",
159
+ "Dashboard widgets with no visual separation",
160
+ "Content sections with no background or border differentiation",
161
+ "Mixed content types in the same visual container"
162
+ ],
163
+ "applies_to": ["layout", "cards", "forms", "grouping", "information-architecture"],
164
+ "sources": ["https://lawsofux.com/law-of-common-region/"]
165
+ },
166
+ {
167
+ "id": "law-of-proximity",
168
+ "name": "Law of Proximity",
169
+ "category": "laws-of-ux",
170
+ "summary": "Objects that are near, or proximate to each other, tend to be grouped together.",
171
+ "description": "The most fundamental Gestalt principle in UI design. Spatial proximity is the strongest cue for grouping. Elements placed close together are perceived as related. This applies to form labels and inputs, navigation items, action buttons, and content sections. The space BETWEEN groups should always be larger than the space WITHIN groups.",
172
+ "implications": [
173
+ "Place labels close to their corresponding form fields",
174
+ "Group related actions together (Save, Cancel)",
175
+ "Use more space between groups than within groups",
176
+ "Place helper text immediately below the field it describes",
177
+ "Keep navigation items for the same section visually close",
178
+ "Separate unrelated actions with significant whitespace"
179
+ ],
180
+ "violations": [
181
+ "Form label equidistant between two fields — unclear which it belongs to",
182
+ "Helper text so far below a field it looks like a standalone paragraph",
183
+ "Action buttons scattered across a page instead of grouped",
184
+ "Equal spacing between all elements — no grouping communicated"
185
+ ],
186
+ "applies_to": ["layout", "forms", "spacing", "grouping", "typography", "buttons"],
187
+ "sources": ["https://lawsofux.com/law-of-proximity/"]
188
+ },
189
+ {
190
+ "id": "law-of-pragnanz",
191
+ "name": "Law of Pragnanz",
192
+ "category": "laws-of-ux",
193
+ "summary": "People will perceive and interpret ambiguous or complex images as the simplest form possible, because it is the interpretation that requires the least cognitive effort.",
194
+ "description": "Also known as the Law of Simplicity or the Law of Good Figure. The human brain prefers simple, regular, orderly forms. Complex layouts are mentally reorganized into simpler patterns. This means interfaces should align with how the brain naturally simplifies — use regular grids, consistent spacing, clear hierarchies, and predictable layouts. Complexity creates cognitive friction.",
195
+ "implications": [
196
+ "Use consistent grid systems for layout",
197
+ "Align elements to create visual order",
198
+ "Simplify complex data with clear visual hierarchy",
199
+ "Use regular, predictable spacing patterns",
200
+ "Reduce visual noise — fewer borders, shadows, and decorative elements",
201
+ "Group related information into simple, recognizable shapes (rectangles, cards)"
202
+ ],
203
+ "violations": [
204
+ "Misaligned elements that create visual tension",
205
+ "Inconsistent spacing that makes the layout feel chaotic",
206
+ "Complex infographics with no clear reading order",
207
+ "Overlapping elements that create ambiguous boundaries",
208
+ "Too many different visual treatments on one page"
209
+ ],
210
+ "applies_to": ["layout", "grid", "visual-design", "simplicity", "hierarchy"],
211
+ "sources": ["https://lawsofux.com/law-of-pragnanz/"]
212
+ },
213
+ {
214
+ "id": "law-of-similarity",
215
+ "name": "Law of Similarity",
216
+ "category": "laws-of-ux",
217
+ "summary": "The human eye tends to perceive similar elements in a design as a complete picture, shape, or group, even if those elements are separated.",
218
+ "description": "Elements that look alike are perceived as related or having the same function. Similarity can be expressed through color, shape, size, texture, or orientation. In UI design, this means all buttons that do similar things should look similar. All cards representing the same type of content should share visual treatment. Breaking similarity signals that something is different or special.",
219
+ "implications": [
220
+ "Make all interactive elements of the same type visually consistent",
221
+ "Use the same card style for the same type of content",
222
+ "Differentiate primary vs secondary actions through visual weight",
223
+ "Use color coding consistently to indicate status or category",
224
+ "Apply consistent icon styles (outline, filled, or glyph — pick one)",
225
+ "Break similarity intentionally to draw attention to special items"
226
+ ],
227
+ "violations": [
228
+ "Buttons with the same function styled differently on different pages",
229
+ "Using the same color for both interactive and decorative elements",
230
+ "Cards with inconsistent layouts for the same content type",
231
+ "Interactive elements that look like non-interactive ones (and vice versa)"
232
+ ],
233
+ "applies_to": ["buttons", "cards", "icons", "consistency", "visual-design", "color"],
234
+ "sources": ["https://lawsofux.com/law-of-similarity/"]
235
+ },
236
+ {
237
+ "id": "law-of-uniform-connectedness",
238
+ "name": "Law of Uniform Connectedness",
239
+ "category": "laws-of-ux",
240
+ "summary": "Elements that are visually connected are perceived as more related than elements with no connection.",
241
+ "description": "Visual connections — lines, arrows, color-coded backgrounds, or shared containers — create the strongest grouping perception, even overriding proximity and similarity. In UI, this applies to step indicators connected by lines, grouped inputs in fieldsets, timeline designs, and flow diagrams. Connecting elements visually communicates sequence and relationship.",
242
+ "implications": [
243
+ "Connect step indicators with lines to show sequence",
244
+ "Use borders or shared backgrounds for fieldsets and form groups",
245
+ "Apply connecting lines in timeline and flow visualizations",
246
+ "Use color bands or bars to connect related items across a layout",
247
+ "Connect data points in charts with lines to show trends"
248
+ ],
249
+ "violations": [
250
+ "Step indicators as isolated dots with no connecting line",
251
+ "Related metrics displayed as disconnected cards with no visual link",
252
+ "Timeline with no connecting line between events",
253
+ "Flow diagram where connections are implied but not drawn"
254
+ ],
255
+ "applies_to": ["progress", "timelines", "charts", "grouping", "flows", "steps"],
256
+ "sources": ["https://lawsofux.com/law-of-uniform-connectedness/"]
257
+ },
258
+ {
259
+ "id": "millers-law",
260
+ "name": "Miller's Law",
261
+ "category": "laws-of-ux",
262
+ "summary": "The average person can only keep 7 (plus or minus 2) items in their working memory.",
263
+ "description": "George Miller's 1956 paper established that human short-term memory holds approximately 7±2 chunks of information. This doesn't mean every menu should have 7 items — it means interfaces should not require users to hold many items in memory simultaneously. Chunking (grouping information into meaningful units), progressive disclosure, and persistent displays reduce memory demands.",
264
+ "implications": [
265
+ "Chunk information into meaningful groups of 3-5 items",
266
+ "Don't require users to remember information from one page to use on another",
267
+ "Keep navigation categories to ~7 top-level items",
268
+ "Show relevant context inline rather than requiring memory",
269
+ "Use step indicators in multi-step flows to offload memory",
270
+ "Organize long lists into categorized, scannable sections"
271
+ ],
272
+ "violations": [
273
+ "Requiring users to remember a code from page 1 to enter on page 3",
274
+ "15+ item navigation with no grouping",
275
+ "Complex comparison requiring users to mentally hold features from scrolled-past options",
276
+ "Phone numbers displayed as raw 10-digit strings without grouping"
277
+ ],
278
+ "applies_to": ["navigation", "forms", "information-architecture", "content", "memory"],
279
+ "sources": ["https://lawsofux.com/millers-law/"]
280
+ },
281
+ {
282
+ "id": "occams-razor",
283
+ "name": "Occam's Razor",
284
+ "category": "laws-of-ux",
285
+ "summary": "Among competing hypotheses that predict equally well, the one with the fewest assumptions should be selected.",
286
+ "description": "In design, Occam's Razor means choosing the simplest solution that adequately solves the problem. Don't add features, screens, or options unless they earn their complexity. Every element in a UI should justify its existence. If two designs solve the problem equally well, the simpler one is better — it's faster to build, easier to maintain, and less likely to confuse users.",
287
+ "implications": [
288
+ "Start with the simplest possible solution and add complexity only when needed",
289
+ "Remove features and options that don't serve core user goals",
290
+ "Prefer single-purpose interfaces over multi-function Swiss army knives",
291
+ "Question every field on a form — is it truly necessary?",
292
+ "Reduce steps in workflows — can any be combined or eliminated?",
293
+ "Default to showing less, with options to show more"
294
+ ],
295
+ "violations": [
296
+ "Adding a settings page when smart defaults would work",
297
+ "Building a complex permissions system for a 5-person team app",
298
+ "10-step onboarding when 3 steps would achieve the same activation",
299
+ "Feature-packed UI that tries to serve every possible use case"
300
+ ],
301
+ "applies_to": ["simplicity", "features", "forms", "onboarding", "settings", "complexity"],
302
+ "sources": ["https://lawsofux.com/occams-razor/"]
303
+ },
304
+ {
305
+ "id": "pareto-principle",
306
+ "name": "Pareto Principle",
307
+ "category": "laws-of-ux",
308
+ "summary": "The Pareto principle states that, for many events, roughly 80% of the effects come from 20% of the causes.",
309
+ "description": "In product design, approximately 80% of users use only 20% of features. 80% of errors come from 20% of issues. 80% of revenue comes from 20% of customers. Focus design effort on the critical 20% — the core workflows, the most common tasks, the most valuable user segments. Don't spread attention evenly across all features; optimize for the vital few.",
310
+ "implications": [
311
+ "Identify and optimize the top 20% most-used features",
312
+ "Design for the most common use case first, then accommodate edge cases",
313
+ "Fix the 20% of bugs that cause 80% of user complaints",
314
+ "Focus onboarding on the features that drive 80% of value",
315
+ "Use analytics to identify which features and flows matter most",
316
+ "Don't give equal design attention to rarely-used admin screens and core workflows"
317
+ ],
318
+ "violations": [
319
+ "Equal design investment in all features regardless of usage",
320
+ "Optimizing edge cases before the core flow is solid",
321
+ "Spending weeks on admin UI while the signup funnel leaks",
322
+ "Feature parity with competitors on features nobody uses"
323
+ ],
324
+ "applies_to": ["prioritization", "features", "analytics", "design-investment", "product-strategy"],
325
+ "sources": ["https://lawsofux.com/pareto-principle/"]
326
+ },
327
+ {
328
+ "id": "parkinsons-law",
329
+ "name": "Parkinson's Law",
330
+ "category": "laws-of-ux",
331
+ "summary": "Any task will inflate until all of the available time is spent.",
332
+ "description": "Cyril Northcote Parkinson observed that work expands to fill the time available for its completion. In UX, this means that giving users too much time, space, or flexibility often leads to worse outcomes, not better ones. Constrained design — shorter forms, tighter deadlines, limited text areas — often produces better results. This also applies to design process: timeboxing decisions prevents over-analysis.",
333
+ "implications": [
334
+ "Set appropriate constraints on inputs (character limits, field counts)",
335
+ "Use timeboxing for design decisions — don't let analysis expand forever",
336
+ "Shorter forms get completed more often than long ones",
337
+ "Limited-time offers and urgency create action (use ethically)",
338
+ "Constrain text areas to encourage conciseness",
339
+ "Break large tasks into smaller, time-bounded chunks"
340
+ ],
341
+ "violations": [
342
+ "Unlimited text areas that encourage novels instead of summaries",
343
+ "Open-ended questionnaires with no indication of expected length",
344
+ "Infinite scroll that encourages endless browsing instead of action"
345
+ ],
346
+ "applies_to": ["forms", "time", "constraints", "productivity", "input-design"],
347
+ "sources": ["https://lawsofux.com/parkinsons-law/"]
348
+ },
349
+ {
350
+ "id": "peak-end-rule",
351
+ "name": "Peak-End Rule",
352
+ "category": "laws-of-ux",
353
+ "summary": "People judge an experience largely based on how they felt at its most intense point and at its end, rather than based on the sum or average of every moment of the experience.",
354
+ "description": "Discovered by Daniel Kahneman, this principle means that users remember the best (or worst) moment of an experience and the final moment. Two practical implications: (1) create a delightful peak moment in every flow, and (2) end every interaction on a positive note. A painful middle is forgiven if the peak is delightful and the ending is satisfying.",
355
+ "implications": [
356
+ "Design a delightful 'peak moment' in key user flows (celebration, surprise, achievement)",
357
+ "End flows positively — confirmation pages, success messages, next steps",
358
+ "Invest in the last step of any process (checkout confirmation, welcome screen)",
359
+ "Front-load pain (complex setup) and end with delight (immediate value)",
360
+ "Avoid ending on error states — always provide a recovery path",
361
+ "Celebrate milestones and completions with animations or encouraging copy"
362
+ ],
363
+ "violations": [
364
+ "Checkout flow that ends with a bland 'Order placed' text",
365
+ "Onboarding that ends with a blank dashboard instead of guided first action",
366
+ "Error as the last thing a user sees before leaving",
367
+ "No celebration or positive reinforcement after completing a task"
368
+ ],
369
+ "applies_to": ["onboarding", "checkout", "success-states", "delight", "emotions", "cta"],
370
+ "sources": ["https://lawsofux.com/peak-end-rule/"]
371
+ },
372
+ {
373
+ "id": "postels-law",
374
+ "name": "Postel's Law",
375
+ "category": "laws-of-ux",
376
+ "summary": "Be liberal in what you accept, and conservative in what you send.",
377
+ "description": "Originally a principle of network protocol design by Jon Postel, applied to UX it means: accept input in many formats (phone numbers with or without dashes, dates in various formats) but display output in a consistent, well-formatted way. Be forgiving of user input variations while maintaining strict output quality. This reduces errors and frustration.",
378
+ "implications": [
379
+ "Accept multiple input formats (phone: (555) 123-4567, 5551234567, 555-123-4567)",
380
+ "Auto-format inputs to a standard display format",
381
+ "Don't reject input for minor formatting differences",
382
+ "Be permissive with search queries — handle typos, partial matches",
383
+ "Display output in a consistent, well-formatted manner",
384
+ "Trim whitespace, fix capitalization, handle edge cases gracefully"
385
+ ],
386
+ "violations": [
387
+ "Rejecting a phone number because it includes dashes",
388
+ "Requiring exact date format instead of accepting natural language dates",
389
+ "Case-sensitive search or login fields",
390
+ "Rejecting a credit card number with spaces",
391
+ "Email validation that rejects valid but unusual addresses"
392
+ ],
393
+ "applies_to": ["forms", "validation", "inputs", "search", "error-prevention"],
394
+ "sources": ["https://lawsofux.com/postels-law/"]
395
+ },
396
+ {
397
+ "id": "serial-position-effect",
398
+ "name": "Serial Position Effect",
399
+ "category": "laws-of-ux",
400
+ "summary": "Users have a propensity to best remember the first and last items in a series.",
401
+ "description": "Composed of two effects: the primacy effect (better recall of first items) and recency effect (better recall of last items). In UI, this means the most important items should be placed first or last in a list, navigation, or set of options. The middle items receive the least attention. This directly impacts navigation design, feature lists, and content ordering.",
402
+ "implications": [
403
+ "Place the most important navigation items first and last",
404
+ "Put key features at the beginning and end of feature lists",
405
+ "In bottom navigation (mobile), place primary actions at the edges",
406
+ "Start and end presentations/onboarding with the most important information",
407
+ "Place the most valuable options at the beginning and end of dropdowns",
408
+ "Use the middle positions for secondary or less critical items"
409
+ ],
410
+ "violations": [
411
+ "Most important navigation buried in the middle of the menu",
412
+ "Key features listed in the middle of a long feature comparison",
413
+ "Primary mobile tab bar actions in center positions",
414
+ "Burying the most compelling pricing feature mid-list"
415
+ ],
416
+ "applies_to": ["navigation", "lists", "mobile", "content-order", "information-architecture"],
417
+ "sources": ["https://lawsofux.com/serial-position-effect/"]
418
+ },
419
+ {
420
+ "id": "teslers-law",
421
+ "name": "Tesler's Law",
422
+ "category": "laws-of-ux",
423
+ "summary": "Tesler's Law, also known as The Law of Conservation of Complexity, states that for any system there is a certain amount of complexity which cannot be reduced.",
424
+ "description": "Larry Tesler argued that every application has an inherent amount of irreducible complexity. The question is: who bears that complexity — the user or the system? Good design absorbs complexity on the system side so users don't have to deal with it. Smart defaults, auto-detection, and intelligent preprocessing all shift complexity from user to system.",
425
+ "implications": [
426
+ "Absorb complexity on the system side whenever possible",
427
+ "Use smart defaults that work for 80% of users",
428
+ "Auto-detect settings when possible (timezone, language, currency)",
429
+ "Don't expose system architecture to end users",
430
+ "Use progressive disclosure to hide complexity until it's needed",
431
+ "Invest engineering time to simplify the user experience, not just the code"
432
+ ],
433
+ "violations": [
434
+ "Exposing configuration that could be auto-detected",
435
+ "Requiring users to understand technical concepts to use the product",
436
+ "Making users manually set timezone, locale, or date format",
437
+ "Showing raw API responses or database field names in the UI",
438
+ "Requiring manual data transformation that could be automated"
439
+ ],
440
+ "applies_to": ["simplicity", "settings", "onboarding", "automation", "complexity-management"],
441
+ "sources": ["https://lawsofux.com/teslers-law/"]
442
+ },
443
+ {
444
+ "id": "von-restorff-effect",
445
+ "name": "Von Restorff Effect",
446
+ "category": "laws-of-ux",
447
+ "summary": "The Von Restorff effect, also known as The Isolation Effect, predicts that when multiple similar objects are present, the one that differs from the rest is most likely to be remembered.",
448
+ "description": "Hedwig von Restorff discovered that distinctive items in a group are better remembered. In UI design, this is the foundation of visual hierarchy — the element that's different gets noticed first. Use this for CTAs, featured pricing plans, important alerts, and any element that needs to stand out. But use sparingly — if everything is highlighted, nothing is.",
449
+ "implications": [
450
+ "Make the primary CTA visually distinct from surrounding elements",
451
+ "Highlight the recommended pricing plan with a different color or badge",
452
+ "Use visual contrast to draw attention to important alerts and notifications",
453
+ "Make the most important metric on a dashboard visually prominent",
454
+ "Use color, size, or weight to distinguish key information",
455
+ "Reserve distinctive styling for truly important elements — overuse destroys the effect"
456
+ ],
457
+ "violations": [
458
+ "All pricing plans styled identically with no recommended option highlighted",
459
+ "Every element on the page demanding attention equally",
460
+ "CTAs that blend into the page design",
461
+ "Using highlight colors so frequently they lose meaning",
462
+ "Important alerts styled the same as informational messages"
463
+ ],
464
+ "applies_to": ["cta", "pricing", "hierarchy", "alerts", "visual-design", "emphasis"],
465
+ "sources": ["https://lawsofux.com/von-restorff-effect/"]
466
+ },
467
+ {
468
+ "id": "zeigarnik-effect",
469
+ "name": "Zeigarnik Effect",
470
+ "category": "laws-of-ux",
471
+ "summary": "People remember uncompleted or interrupted tasks better than completed tasks.",
472
+ "description": "Bluma Zeigarnik discovered that incomplete tasks create a state of cognitive tension that keeps them in memory. In UX, this powers engagement mechanics: progress bars, incomplete profiles, unfinished tutorials, and streak counters all leverage this effect. Users are drawn to complete what they've started. Use ethically — this can be manipulative (dark patterns) or helpful (onboarding nudges).",
473
+ "implications": [
474
+ "Show profile completion percentages to encourage finishing setup",
475
+ "Use progress bars on multi-step flows to create completion motivation",
476
+ "Break onboarding into visible steps that show what's left",
477
+ "Send reminders about abandoned carts, drafts, or incomplete actions",
478
+ "Use streaks and chains to encourage habitual engagement",
479
+ "Save progress so users can return to incomplete tasks easily"
480
+ ],
481
+ "violations": [
482
+ "No save state for partially completed forms",
483
+ "Onboarding with no visible progress or completion indicator",
484
+ "Abandoning the user after they start a task with no way to return",
485
+ "Using this effect manipulatively (fake urgency, artificial scarcity)"
486
+ ],
487
+ "applies_to": ["onboarding", "engagement", "gamification", "progress", "retention", "forms"],
488
+ "sources": ["https://lawsofux.com/zeigarnik-effect/"]
489
+ }
490
+ ]
@@ -0,0 +1,126 @@
1
+ [
2
+ {
3
+ "id": "thumb-zone",
4
+ "name": "Thumb Zone Design",
5
+ "category": "mobile-ux",
6
+ "summary": "Design for one-handed use — the most important actions should be in the natural thumb reach zone.",
7
+ "description": "Steven Hoober's research shows that 49% of people use their phone with one hand. The 'thumb zone' — the easy, natural reach area — is an arc from the bottom-center to the middle of the screen. Top corners and far edges are hard to reach. Primary actions (compose, send, navigate) should be in the easy zone. Secondary actions (settings, edit, delete) can be in stretch zones. This is why bottom navigation, floating action buttons, and bottom sheets are standard mobile patterns.",
8
+ "implications": [
9
+ "Place primary actions in the bottom third of the screen",
10
+ "Use bottom navigation instead of top hamburger menus",
11
+ "Bottom sheets for action menus and selections",
12
+ "Floating action button (FAB) in bottom-right for the primary action",
13
+ "Avoid placing frequent actions in the top-left corner",
14
+ "Pull-to-refresh works because it uses the natural thumb zone",
15
+ "Consider swipe gestures for common actions (swipe to delete, archive)"
16
+ ],
17
+ "violations": [
18
+ "Primary navigation only in the top-left hamburger menu",
19
+ "Important CTAs in the top corners of the screen",
20
+ "Action sheets that appear at the top of the screen",
21
+ "Requiring two-handed operation for core tasks",
22
+ "Small targets in the top corners (back button < 44px)"
23
+ ],
24
+ "applies_to": ["mobile", "navigation", "buttons", "touch-targets", "layout"],
25
+ "sources": ["https://www.smashingmagazine.com/2016/09/the-thumb-zone-designing-for-mobile-users/"]
26
+ },
27
+ {
28
+ "id": "touch-targets",
29
+ "name": "Touch Target Sizing",
30
+ "category": "mobile-ux",
31
+ "summary": "Interactive elements must be at least 44x44 points with adequate spacing between targets.",
32
+ "description": "The average adult fingertip is 10mm wide (about 44px at 160dpi). Apple HIG requires 44pt minimum, Material Design requires 48dp, and WCAG 2.2 requires at least 24px with spacing. Touch targets can be larger than the visual element — use padding to extend the tap area. Adjacent targets need at least 8px spacing to prevent mis-taps. This is the most commonly violated mobile UX guideline.",
33
+ "implications": [
34
+ "Minimum 44x44pt (Apple) or 48x48dp (Material) for touch targets",
35
+ "At least 8px spacing between adjacent touch targets",
36
+ "Extend tap area with padding even when the visual element is small",
37
+ "Inline links need adequate line-height for tapping (min 48px line-height)",
38
+ "List items used as navigation: full-width tap target, min 48px height",
39
+ "Icon buttons: icon can be 24px but tap target should be 44px+",
40
+ "Test on real devices — simulator clicks are more precise than fingers"
41
+ ],
42
+ "violations": [
43
+ "24px icon buttons with no extended tap area",
44
+ "Dense tables with small tap targets on mobile",
45
+ "Text links with tight line-height — nearly impossible to tap accurately",
46
+ "Adjacent buttons touching with no spacing — frequent mis-taps",
47
+ "Checkbox/radio inputs at native browser size (13px)"
48
+ ],
49
+ "applies_to": ["mobile", "buttons", "links", "forms", "touch-targets", "lists"],
50
+ "sources": ["https://developer.apple.com/design/human-interface-guidelines/buttons"]
51
+ },
52
+ {
53
+ "id": "bottom-sheet-pattern",
54
+ "name": "Bottom Sheet Pattern",
55
+ "category": "mobile-ux",
56
+ "summary": "Bottom sheets are the mobile-native way to present actions, selections, and supplementary content.",
57
+ "description": "Bottom sheets slide up from the bottom of the screen, appearing in the natural thumb zone. They replace desktop patterns like dropdowns, popovers, and modals for mobile. Modal bottom sheets block the content behind them (with a scrim). Persistent bottom sheets stay visible alongside content (like Google Maps). Standard bottom sheets have a drag handle, snap to peek/half/full heights, and dismiss by swiping down.",
58
+ "implications": [
59
+ "Use instead of desktop dropdown menus on mobile",
60
+ "Include a visible drag handle at the top",
61
+ "Support swipe-to-dismiss (swipe down)",
62
+ "Snap to predefined heights: peek (25%), half (50%), full (85-90%)",
63
+ "Modal bottom sheets: add a scrim behind, tap-outside-to-dismiss",
64
+ "Content should be scrollable within the sheet when expanded",
65
+ "Place the most common action at the top of the sheet content"
66
+ ],
67
+ "violations": [
68
+ "Desktop-style dropdown menus on mobile — too small, wrong position",
69
+ "Full-screen modals for simple selections (date, filter, action)",
70
+ "Bottom sheet without drag handle — unclear dismissal method",
71
+ "Bottom sheet covering the full screen with no way to see context behind"
72
+ ],
73
+ "applies_to": ["mobile", "modals", "menus", "actions", "navigation", "selection"],
74
+ "sources": ["https://m3.material.io/components/bottom-sheets/overview"]
75
+ },
76
+ {
77
+ "id": "mobile-forms",
78
+ "name": "Mobile Form Design",
79
+ "category": "mobile-ux",
80
+ "summary": "Mobile forms must minimize typing, use appropriate keyboards, and handle the virtual keyboard gracefully.",
81
+ "description": "Typing on mobile is slow and error-prone. Every form field is a friction point. Use the right input type to trigger the right keyboard (email, tel, number, url). Prefer selection over typing (pickers, segmented controls, switches). Auto-fill everything possible. Single-column layout only — multi-column forms break on mobile. The form should scroll smoothly when the keyboard appears, keeping the active field visible.",
82
+ "implications": [
83
+ "Use appropriate input types: email, tel, number, url, search",
84
+ "Set autocomplete attributes for auto-fill (name, email, address, cc-number)",
85
+ "Single-column layout only — never multi-column on mobile",
86
+ "Replace text inputs with pickers, toggles, and segmented controls where possible",
87
+ "Labels above inputs (not inline/floating for mobile — they shrink to unreadable sizes)",
88
+ "Active field must be visible above the virtual keyboard",
89
+ "Place the submit button above the fold or make it sticky at the bottom"
90
+ ],
91
+ "violations": [
92
+ "Email field without inputmode='email' — shows default keyboard",
93
+ "Multi-column form layout on mobile — fields too narrow",
94
+ "Phone field without inputmode='tel' — shows full keyboard",
95
+ "Form that doesn't scroll when keyboard appears — active field hidden",
96
+ "No autocomplete attributes — user must type everything manually"
97
+ ],
98
+ "applies_to": ["mobile", "forms", "inputs", "keyboards", "validation"],
99
+ "sources": ["https://web.dev/learn/forms/"]
100
+ },
101
+ {
102
+ "id": "mobile-navigation",
103
+ "name": "Mobile Navigation Patterns",
104
+ "category": "mobile-ux",
105
+ "summary": "Mobile navigation should prioritize the thumb zone and minimize the number of taps to reach key content.",
106
+ "description": "Bottom tab bars are the gold standard for mobile apps with 3-5 top-level destinations. Hamburger menus hide navigation and reduce discoverability — use only when you have 5+ sections or navigation is secondary. Tab bars should show icons + labels (not icon-only), highlight the active tab, and be persistent across screens. For deep hierarchies, use stack navigation with a clear back button.",
107
+ "implications": [
108
+ "Bottom tab bar for 3-5 primary destinations (iOS tab bar, Material bottom nav)",
109
+ "Always show icon + label on tab items (icon-only reduces discoverability 50%)",
110
+ "Hamburger menu only for 5+ sections or when navigation is secondary",
111
+ "Stack navigation with clear back button for hierarchical content",
112
+ "Search should be prominent — top of screen or dedicated tab",
113
+ "Maximum 2-3 taps to reach any key content",
114
+ "Persistent navigation — don't hide it on scroll (or at least show on scroll-up)"
115
+ ],
116
+ "violations": [
117
+ "Hamburger menu as the only navigation with 3 items — should be a tab bar",
118
+ "Icon-only tab bar with no labels — low discoverability",
119
+ "More than 5 items in the bottom tab bar — too many to tap accurately",
120
+ "Navigation hidden on scroll with no way to bring it back",
121
+ "Deep navigation hierarchy requiring 4+ taps to reach content"
122
+ ],
123
+ "applies_to": ["mobile", "navigation", "tabs", "menus", "information-architecture"],
124
+ "sources": ["https://developer.apple.com/design/human-interface-guidelines/tab-bars"]
125
+ }
126
+ ]