@equal-experts/kuat-react 0.2.3 → 0.2.4

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.
@@ -0,0 +1,875 @@
1
+ # Kuat Design System Product & UX Writing Guide
2
+
3
+ ---
4
+ **Version:** 1.0
5
+ **Last Updated:** December 2024
6
+ **Type:** Specialized Guidelines
7
+ **Audience:** UX Writers, Product Designers, Product Managers, Developers
8
+ **Dependencies:** [`content-foundations.md`](./content-foundations.md) (read first)
9
+
10
+ ---
11
+
12
+ ## Prerequisites
13
+
14
+ **⚠️ Important:** You must read [`content-foundations.md`](./content-foundations.md) before using this guide.
15
+
16
+ This guide builds on the universal brand voice principles. It assumes you understand:
17
+ - Core voice principles
18
+ - Universal content principles
19
+ - Audience considerations
20
+ - Common anti-patterns
21
+ - Quality tests
22
+
23
+ ---
24
+
25
+ ## Quick Reference: Product Content at a Glance
26
+
27
+ **Product content is:**
28
+ - Text inside product interfaces
29
+ - Designed to help users complete tasks
30
+ - More concise than marketing content
31
+ - Action-oriented and contextual
32
+ - Tested with real users
33
+
34
+ **Core purpose:** Give users exactly what they need, exactly when they need it, to complete their task successfully.
35
+
36
+ **Tone:** Helpful, concise, action-oriented, respectful
37
+
38
+ ---
39
+
40
+ ## Overview
41
+
42
+ ### What is Product & UX Content?
43
+
44
+ Product & UI content design focuses on the interface text users encounter while using products and services built with the Kuat Design System. This differs from:
45
+ - **Marketing content** (which raises awareness and generates leads)
46
+ - **Help content** (which educates on product use in documentation)
47
+
48
+ Product content is the conversation happening inside the product itself—it's the labels, instructions, errors, confirmations, and feedback that guide users through their tasks.
49
+
50
+ ### Core Purpose
51
+
52
+ **Design content that keeps users focused on completing their tasks** by giving them exactly what they need, exactly when they need it.
53
+
54
+ Users don't read products for enjoyment. They use products to accomplish goals. Our content should:
55
+ - Facilitate task completion
56
+ - Remove friction and confusion
57
+ - Build confidence
58
+ - Prevent errors
59
+ - Help users recover from problems
60
+
61
+ ---
62
+
63
+ ## Product Voice Adaptation
64
+
65
+ While maintaining Kuat Design System foundations, product content requires specific adaptations:
66
+
67
+ ### The Product Voice Formula
68
+
69
+ `[Action] + [Object] + [Benefit if needed]`
70
+
71
+ **Examples:**
72
+ - "Save invoice" (clear action + object)
73
+ - "Save draft" (action + object)
74
+ - "Export to CSV" (action + object + format)
75
+ - "Archive project · Free up space" (action + object · benefit)
76
+
77
+ ### Key Differences from Marketing Content
78
+
79
+ | Aspect | Marketing Content | Product Content |
80
+ |--------|------------------|-----------------|
81
+ | **Purpose** | Persuade, inform, engage | Enable task completion |
82
+ | **Length** | Can be expansive | Must be concise |
83
+ | **Tone** | Can be conversational | Must be action-oriented |
84
+ | **Style** | Storytelling, personality | Direct, functional |
85
+ | **Context** | User chose to read | User is trying to do something |
86
+ | **Emotion** | Can evoke feelings | Must match user's emotional state |
87
+
88
+ ### Product Content Characteristics
89
+
90
+ **More concise:**
91
+ - Every word must earn its place
92
+ - No marketing language or fluff
93
+ - Cut by 50% compared to marketing content
94
+
95
+ **More action-oriented:**
96
+ - Focus on what users can DO
97
+ - Use verb-driven language
98
+ - Make next steps obvious
99
+
100
+ **More contextual:**
101
+ - Appears at moment of need
102
+ - Specific to user's current task
103
+ - Disappears when not relevant
104
+
105
+ **More tested:**
106
+ - Must work in real usage scenarios
107
+ - Based on user behavior, not opinions
108
+ - Continuously improved based on data
109
+
110
+ ---
111
+
112
+ ## Foundational Principles for Product Content
113
+
114
+ ### 1. Understand the Audience in Detail
115
+
116
+ Before writing a single word, deeply understand:
117
+ - **Who** sees this content? (All users? Specific segments? Power users or beginners?)
118
+ - **When** do they see it? (First login? After an error? Mid-workflow?)
119
+ - **What** are they trying to do? (Complete a form? Make a decision? Recover from an error?)
120
+ - **How** are they feeling? (Confident? Frustrated? Confused? In a hurry?)
121
+
122
+ #### Example - GOOD (Detailed Audience Understanding)
123
+
124
+ ```
125
+ Context: Modal shown to users who haven't connected their bank after 14 days
126
+ Audience: Small business owners, 65% first-time accounting software users, often feeling overwhelmed
127
+ Emotional state: Likely confused about whether they're "doing it right"
128
+ Goal: Connect bank account to enable automatic transaction imports
129
+
130
+ Content:
131
+ "Connect your bank to save hours
132
+ Link your business bank account and we'll automatically import your transactions. You'll spend less time on data entry and more time running your business.
133
+
134
+ [Connect bank account] [I'll do this later]"
135
+ ```
136
+
137
+ **Why it's good:**
138
+ - Addresses user's hesitation empathetically
139
+ - States clear benefit ("save hours")
140
+ - Explains what will happen
141
+ - Provides escape hatch without pressure
142
+
143
+ #### Example - BAD (Generic, No Audience Context)
144
+
145
+ ```
146
+ "Bank Connection Available
147
+ You can connect your bank account now.
148
+
149
+ [Connect] [Cancel]"
150
+ ```
151
+
152
+ **Why it's bad:**
153
+ - Doesn't address why it matters to the user
154
+ - Doesn't acknowledge their potential hesitation
155
+ - Technical language without context ("connection")
156
+ - No clear value proposition
157
+ - Doesn't help user make informed decision
158
+
159
+ ---
160
+
161
+ ### 2. Keep Users Focused on Their Task
162
+
163
+ Surface information at the moment of need, not before. Don't make users remember things for later use.
164
+
165
+ #### The "Right Time, Right Place" Rule
166
+
167
+ - Information should appear when it's immediately actionable
168
+ - Avoid "just in case" content that clutters the interface
169
+ - Don't ask users to hold information in working memory
170
+ - Remove information as soon as it's no longer relevant
171
+
172
+ #### Example - GOOD
173
+
174
+ ```
175
+ [User is on "Add Employee" form]
176
+
177
+ Inline help next to "Employment Type" field:
178
+ "Employees receive a W-2. Contractors receive a 1099."
179
+ [More about employee vs. contractor classification]
180
+ ```
181
+
182
+ **Why it's good:**
183
+ - Information appears exactly when needed
184
+ - User can make decision immediately
185
+ - Link available for more detail if needed
186
+ - Doesn't clutter previous or future screens
187
+
188
+ #### Example - BAD
189
+
190
+ ```
191
+ [User lands on Employee Dashboard]
192
+
193
+ Banner at top:
194
+ "Note: When you add employees, remember that employees receive W-2s and contractors receive 1099s. You'll need to know the difference when adding people to your system. Keep this in mind for future reference."
195
+
196
+ [Separate Add Employee page, with no reminder of this information]
197
+ ```
198
+
199
+ **Why it's bad:**
200
+ - Information presented before it's needed
201
+ - Requires user to remember for later (working memory burden)
202
+ - Separated from the decision point
203
+ - Increases cognitive load unnecessarily
204
+ - Not present when actually needed
205
+
206
+ ---
207
+
208
+ ### 3. Get to the Point
209
+
210
+ Humans have 1,440 minutes per day. Don't waste any of them with words that don't carry meaning.
211
+
212
+ #### Conciseness Principles
213
+
214
+ - Lead with the most important information
215
+ - Remove filler words and phrases
216
+ - Use the fewest words that convey meaning clearly
217
+ - Every word should earn its place on screen
218
+ - Front-load information (most important first)
219
+
220
+ #### Common Filler Phrases to Remove
221
+
222
+ ❌ "Please note that..."
223
+ ❌ "At this time..."
224
+ ❌ "In order to..."
225
+ ❌ "You may wish to..."
226
+ ❌ "It appears that..."
227
+ ❌ "We have detected that..."
228
+
229
+ ✅ Just state the information directly
230
+
231
+ #### Example - GOOD
232
+
233
+ ```
234
+ "Your invoice is overdue
235
+ [Client Name] hasn't paid Invoice #1234 ($2,450) due on 15 Nov.
236
+
237
+ [Send reminder] [View invoice]"
238
+ ```
239
+
240
+ **Word count:** 15 words (excluding button labels)
241
+
242
+ **Why it's good:**
243
+ - States problem immediately
244
+ - Provides specific details
245
+ - Clear actions available
246
+ - No unnecessary words
247
+
248
+ #### Example - BAD
249
+
250
+ ```
251
+ "Notification Regarding Outstanding Payment
252
+
253
+ Please be advised that we have detected that one of your invoices appears to be overdue at this time. The invoice in question is Invoice Number 1234 which was issued to [Client Name] in the amount of $2,450.00 and according to our records it was originally due to be paid on November 15th.
254
+
255
+ You may wish to consider the possibility of sending a reminder to your customer about this outstanding amount, or alternatively you could review the invoice to ensure all the details are correct.
256
+
257
+ [Send a reminder to customer] [Review invoice details]"
258
+ ```
259
+
260
+ **Word count:** 93 words (excluding button labels)
261
+
262
+ **Why it's bad:**
263
+ - Takes 6x more words to convey same information
264
+ - Passive voice throughout ("we have detected", "was issued")
265
+ - Unnecessary qualifiers ("appears to be," "may wish to consider")
266
+ - Overly formal tone for user doing task
267
+ - Wordy button labels that repeat content
268
+
269
+ ---
270
+
271
+ ### 4. Work Collaboratively
272
+
273
+ Product content design doesn't happen in isolation. It's integrated with multiple disciplines:
274
+
275
+ #### Collaboration Model
276
+
277
+ **With Interaction Designers:**
278
+ - Work together on user flows
279
+ - Determine component behavior
280
+ - Design information architecture
281
+ - Decide when to use progressive disclosure
282
+
283
+ **With Visual Designers:**
284
+ - Ensure visual hierarchy supports content hierarchy
285
+ - Verify typography accommodates content needs
286
+ - Confirm button text works within button constraints
287
+ - Validate instructional text has adequate spacing
288
+
289
+ **With Product Managers:**
290
+ - Understand business goals
291
+ - Prioritize feature development
292
+ - Define success metrics
293
+ - Balance user needs with business constraints
294
+
295
+ **With Developers:**
296
+ - Understand technical constraints
297
+ - Clarify data structures
298
+ - Design for error conditions
299
+ - Test actual error messages with real failure scenarios
300
+
301
+ **With Researchers:**
302
+ - Test content with real users
303
+ - Understand pain points
304
+ - Validate assumptions
305
+ - Identify friction points
306
+
307
+ **With Legal/Compliance:**
308
+ - Ensure required disclosures meet regulations
309
+ - Find plain English alternatives to legal language
310
+ - Balance compliance with usability
311
+ - Separate legal requirements from user content
312
+
313
+ ---
314
+
315
+ ### 5. Test Everything
316
+
317
+ Your opinions don't matter. User behavior and feedback does.
318
+
319
+ #### Testing Approaches
320
+
321
+ **A/B Testing:**
322
+ - Compare two content variations with real users
323
+ - Use statistically significant sample sizes
324
+ - Measure impact on task completion, errors, satisfaction
325
+ - Ship the version that performs better
326
+
327
+ **Usability Testing:**
328
+ - Watch users attempt tasks with your content
329
+ - Identify where they get confused
330
+ - Note questions they ask
331
+ - Observe where they struggle
332
+
333
+ **Intercept Surveys:**
334
+ - Ask users questions at key moments
335
+ - "Was this helpful?" at end of flows
336
+ - "Did you accomplish what you came to do?"
337
+ - Gather feedback on specific content
338
+
339
+ **Analytics:**
340
+ - Track completion rates
341
+ - Monitor error rates
342
+ - Measure abandonment
343
+ - Identify drop-off points
344
+
345
+ **Comprehension Testing:**
346
+ - Verify users understand key concepts
347
+ - Ask users to explain in their own words
348
+ - Test with users who match audience profile
349
+
350
+ #### Example - GOOD Testing Report
351
+
352
+ ```
353
+ Test: Button label for "Save and continue editing" vs. "Save draft"
354
+ Method: A/B test, 2,000 users per variation, 5 days
355
+ Metric: Click-through rate on button
356
+
357
+ Results:
358
+ - "Save draft": 67% CTR
359
+ - "Save and continue editing": 42% CTR
360
+
361
+ User feedback (exit survey):
362
+ - "Save draft" was clearer about what would happen
363
+ - "Save and continue editing" was confusing - users thought they'd stay on same page
364
+
365
+ Decision: Ship "Save draft"
366
+
367
+ Learning: Users prefer clarity over descriptiveness when the action is simple
368
+ ```
369
+
370
+ **Why it's good:**
371
+ - Proper methodology (A/B test with adequate sample)
372
+ - Clear metrics defined
373
+ - Quantitative data plus qualitative feedback
374
+ - Specific decision made
375
+ - Learning documented for future reference
376
+
377
+ ---
378
+
379
+ ### 6. Make It Accessible
380
+
381
+ Content designers are uniquely positioned to champion accessibility because the UI is expressed in words for screen reader users.
382
+
383
+ #### Accessibility Responsibilities
384
+
385
+ ✅ **Do:**
386
+ - Ensure proper heading hierarchy (H1 → H2 → H3, no skipping)
387
+ - Write descriptive link text (not "click here")
388
+ - Provide alt text for meaningful images
389
+ - Keep form labels clear and persistent
390
+ - Reduce cognitive load through simplicity
391
+ - Ensure error messages are actionable
392
+ - Connect labels to inputs programmatically
393
+ - Provide sufficient color contrast
394
+ - Write content that works without seeing the interface
395
+
396
+ ❌ **Don't:**
397
+ - Rely solely on placeholder text (it disappears)
398
+ - Use color alone to convey information
399
+ - Create error messages that aren't associated with fields
400
+ - Write ambiguous button labels
401
+ - Use jargon without explanation
402
+
403
+ #### Example - GOOD (Accessible)
404
+
405
+ ```html
406
+ <h2>Payment method</h2>
407
+
408
+ <label for="card-number">Card number</label>
409
+ <input id="card-number" type="text" aria-describedby="card-help">
410
+ <span id="card-help">Enter the 16-digit number on your card</span>
411
+
412
+ <label for="expiry">Expiry date</label>
413
+ <input id="expiry" type="text" placeholder="MM/YY" aria-describedby="expiry-help">
414
+ <span id="expiry-help">Month and year format: 03/25</span>
415
+
416
+ [Error state]
417
+ <span role="alert" class="error">
418
+ Card number must be 16 digits
419
+ </span>
420
+ ```
421
+
422
+ **Why it's good:**
423
+ - Proper heading hierarchy
424
+ - Labels explicitly connected to inputs
425
+ - Help text programmatically associated
426
+ - Error message announced to screen readers
427
+ - Placeholder used as example, not label
428
+ - Clear, actionable error message
429
+
430
+ ---
431
+
432
+ ## Product Content Patterns
433
+
434
+ ### Actions (Buttons and Links)
435
+
436
+ Buttons should be clear, concise, and predictable. Users should know exactly what happens when they click.
437
+
438
+ #### Button Label Rules
439
+
440
+ ✅ **Do:**
441
+ - Use verb-driven labels that describe the action
442
+ - Be specific about what happens
443
+ - Keep labels short (1-3 words ideal)
444
+ - Use sentence case (not Title Case or ALL CAPS)
445
+ - Make primary action stand out visually
446
+
447
+ ❌ **Don't:**
448
+ - Use vague labels like "OK" or "Submit"
449
+ - Make labels overly long or explanatory
450
+ - Use ALL CAPS
451
+ - Include instructions in button labels
452
+
453
+ #### Example - GOOD
454
+
455
+ ```
456
+ [Save and close] [Save as draft]
457
+
458
+ [Delete expense] [Cancel]
459
+
460
+ [Send invoice now] [Schedule for later]
461
+
462
+ [Connect bank] [Skip for now]
463
+ ```
464
+
465
+ **Why it's good:**
466
+ - Action verb + object
467
+ - Specific outcome clear
468
+ - Short and scannable
469
+ - Parallel structure
470
+
471
+ #### Example - BAD
472
+
473
+ ```
474
+ [OK] [Cancel]
475
+ (OK is ambiguous - OK to what?)
476
+
477
+ [Yes, I want to proceed with this action]
478
+ (Too wordy - action unclear)
479
+
480
+ [SUBMIT FORM NOW]
481
+ (All caps, not specific, shouty)
482
+
483
+ [Click here to continue]
484
+ (Not action-focused, generic)
485
+ ```
486
+
487
+ ---
488
+
489
+ ### Confirmations
490
+
491
+ Confirmations prevent users from taking actions they might regret.
492
+
493
+ #### When to Use Confirmations
494
+
495
+ ✅ **Use for:**
496
+ - Destructive actions (delete, remove, disconnect)
497
+ - Actions that can't be undone
498
+ - Actions with significant consequences
499
+ - Actions that modify important data
500
+
501
+ ❌ **Don't use for:**
502
+ - Actions that can be undone easily
503
+ - Low-stakes decisions
504
+ - Actions users make frequently
505
+ - Saving or submitting (unless destructive)
506
+
507
+ #### Example - GOOD
508
+
509
+ ```
510
+ Delete client account?
511
+
512
+ This will permanently delete [Client Name] and all associated:
513
+ - Invoices (12)
514
+ - Payments (8)
515
+ - Transaction history
516
+
517
+ You can't undo this action.
518
+
519
+ [Delete permanently] [Cancel]
520
+ ```
521
+
522
+ **Why it's good:**
523
+ - Clear about what's being deleted
524
+ - Specific consequences listed
525
+ - Indicates irreversibility
526
+ - Action button confirms the action
527
+
528
+ #### Example - BAD
529
+
530
+ ```
531
+ Are you sure?
532
+
533
+ Do you really want to do this?
534
+
535
+ [Yes] [No]
536
+ ```
537
+
538
+ **Why it's bad:**
539
+ - Doesn't remind user what "this" is
540
+ - Doesn't explain consequences
541
+ - No indication of reversibility
542
+ - Generic button labels
543
+ - Doesn't help user make informed decision
544
+
545
+ ---
546
+
547
+ ### Empty States
548
+
549
+ Empty states occur when there's no data to display. They're opportunities to guide users toward value.
550
+
551
+ #### Empty State Principles
552
+
553
+ ✅ **Do:**
554
+ - Explain why the state is empty
555
+ - Provide clear next action
556
+ - Make the action easy to take
557
+ - Use positive, encouraging tone
558
+ - Include illustration or icon if helpful
559
+
560
+ ❌ **Don't:**
561
+ - Leave users confused about what happened
562
+ - Make empty states feel like errors
563
+ - Provide action without explanation
564
+ - Use negative or discouraging language
565
+
566
+ #### Example - GOOD
567
+
568
+ ```
569
+ [Illustration of invoice]
570
+
571
+ No invoices yet
572
+
573
+ Create your first invoice to get paid faster. It takes less than 2 minutes.
574
+
575
+ [Create invoice]
576
+
577
+ Or import invoices from [QuickBooks] [Xero] [CSV file]
578
+ ```
579
+
580
+ **Why it's good:**
581
+ - Friendly, encouraging tone
582
+ - Clear next action
583
+ - Time estimate reduces anxiety
584
+ - Alternative paths offered
585
+ - Visual makes it feel intentional, not broken
586
+
587
+ #### Example - BAD
588
+
589
+ ```
590
+ No data available.
591
+ ```
592
+
593
+ **Why it's bad:**
594
+ - Doesn't explain why
595
+ - No guidance on what to do next
596
+ - Feels like an error rather than a starting point
597
+ - Technical language ("data")
598
+ - Discouraging tone
599
+
600
+ ---
601
+
602
+ ### Errors
603
+
604
+ Errors happen. Good error messages help users recover quickly and learn how to avoid the problem in future.
605
+
606
+ #### Error Message Formula
607
+
608
+ ```
609
+ 1. What went wrong (specific)
610
+ 2. Why it happened (if helpful)
611
+ 3. How to fix it (actionable)
612
+ ```
613
+
614
+ #### Error Message Principles
615
+
616
+ ✅ **Do:**
617
+ - Be specific about the problem
618
+ - Use plain language
619
+ - Provide actionable next steps
620
+ - Suggest solutions when possible
621
+ - Take responsibility ("We couldn't save your changes")
622
+ - Show empathy for user's situation
623
+
624
+ ❌ **Don't:**
625
+ - Blame the user
626
+ - Use technical jargon or error codes
627
+ - Be vague about the problem
628
+ - Leave user with no clear next step
629
+ - Use humor (errors frustrate users)
630
+
631
+ #### Example - GOOD
632
+
633
+ ```
634
+ [Error icon] Can't save invoice
635
+
636
+ The customer email "john@example,com" has a comma instead of a period.
637
+
638
+ Fix the email address and try again.
639
+
640
+ [Suggested: john@example.com]
641
+ ```
642
+
643
+ **Why it's good:**
644
+ - States what failed ("Can't save invoice")
645
+ - Identifies specific problem (comma vs period)
646
+ - Shows exact location of error
647
+ - Provides actionable solution
648
+ - Offers automatic correction suggestion
649
+ - Respectful tone (doesn't blame)
650
+
651
+ #### Example - BAD
652
+
653
+ ```
654
+ Error 422: Unprocessable Entity
655
+
656
+ Validation failed for field: customer_email
657
+
658
+ [OK]
659
+ ```
660
+
661
+ **Why it's bad:**
662
+ - Technical error code (meaningless to users)
663
+ - Technical field name (not how users think)
664
+ - Doesn't explain what's actually wrong
665
+ - Doesn't say how to fix it
666
+ - Generic dismissive button
667
+ - No helpful information at all
668
+
669
+ ---
670
+
671
+ ### Fields (Forms)
672
+
673
+ Forms are where users input information. Labels, placeholder text, and help text should work together seamlessly.
674
+
675
+ #### Field Label Rules
676
+
677
+ ✅ **Do:**
678
+ - Always use a label (not just placeholder text)
679
+ - Keep labels short and clear
680
+ - Use sentence case
681
+ - Position labels above fields (most accessible)
682
+ - Make labels persistent (visible while user types)
683
+
684
+ ❌ **Don't:**
685
+ - Use placeholder text as the only label (it disappears)
686
+ - Make labels overly long or explanatory
687
+ - Use Title Case for labels
688
+ - Hide labels on focus
689
+
690
+ #### Example - GOOD
691
+
692
+ ```
693
+ Business name
694
+ [Text input]
695
+
696
+ Industry
697
+ [Dropdown: Select industry...]
698
+ Not sure? We'll use this to suggest expense categories.
699
+
700
+ Email address
701
+ [Text input]
702
+ ```
703
+
704
+ **Why it's good:**
705
+ - Clear, persistent labels
706
+ - Help text where needed, brief
707
+ - Optional context explains benefit
708
+ - Accessible structure
709
+
710
+ #### Example - BAD
711
+
712
+ ```
713
+ [Text input with placeholder: "Enter your business name here..."]
714
+
715
+ [Dropdown with placeholder: "Choose your industry from this list"]
716
+
717
+ [Text input with placeholder: "name@company.com"]
718
+ ```
719
+
720
+ **Why it's bad:**
721
+ - No persistent labels
722
+ - Placeholder text disappears when typing
723
+ - Inaccessible to screen readers
724
+ - Wordy placeholder text
725
+ - Example as placeholder is confusing
726
+
727
+ ---
728
+
729
+ ### Mobile Considerations
730
+
731
+ Mobile requires even more conciseness due to limited screen space.
732
+
733
+ #### Mobile Content Principles
734
+
735
+ - Cut content by 50% compared to desktop
736
+ - Front-load important information
737
+ - Use progressive disclosure extensively
738
+ - Design for thumbs (larger touch targets)
739
+ - Consider one-handed use
740
+ - Test on actual devices (emulators aren't enough)
741
+
742
+ #### Example - GOOD (Mobile)
743
+
744
+ ```
745
+ Invoice #1234
746
+ Status: Unpaid
747
+ Due: Tomorrow
748
+ Amount: $2,450
749
+
750
+ [Send reminder]
751
+ [View details]
752
+ ```
753
+
754
+ **Character count:** ~60 characters
755
+ **Button labels:** 2 words each
756
+
757
+ **Why it's good:**
758
+ - Scannable hierarchy
759
+ - Essential info only
760
+ - Clear actions
761
+ - Touch-friendly buttons
762
+ - Works one-handed
763
+
764
+ ---
765
+
766
+ ## Product Content Checklist
767
+
768
+ Before shipping any product content, verify:
769
+
770
+ **Context and Timing:**
771
+ - [ ] Content appears at the right moment in the user's task
772
+ - [ ] Information is directly relevant to current action
773
+ - [ ] Content disappears when no longer relevant
774
+
775
+ **Clarity and Conciseness:**
776
+ - [ ] Every word carries meaning (no fluff)
777
+ - [ ] Content is as short as possible while remaining clear
778
+ - [ ] Most important information comes first
779
+
780
+ **Usability:**
781
+ - [ ] Users can complete their task without leaving to read help
782
+ - [ ] Button labels describe the action clearly
783
+ - [ ] Form labels are clear and persistent
784
+ - [ ] Error messages explain what happened and how to fix it
785
+
786
+ **Accessibility:**
787
+ - [ ] Content is accessible to screen reader users
788
+ - [ ] Labels programmatically connected to inputs
789
+ - [ ] Error messages associated with fields
790
+ - [ ] Heading hierarchy is logical
791
+ - [ ] Link text is descriptive
792
+
793
+ **Quality:**
794
+ - [ ] No jargon or technical terms without explanation
795
+ - [ ] Tone matches user's emotional state
796
+ - [ ] Content scales for edge cases (very long names, etc.)
797
+ - [ ] Tested with real users in context
798
+
799
+ **Technical:**
800
+ - [ ] Mobile experience is as good as desktop
801
+ - [ ] Content works on smallest supported screen size
802
+ - [ ] All states tested (default, error, loading, success, empty)
803
+ - [ ] Content works with real data (not just lorem ipsum)
804
+
805
+ ---
806
+
807
+ ## Common Product Content Mistakes
808
+
809
+ ### Mistake 1: Explaining the Obvious
810
+
811
+ ❌ "Click the button below to continue to the next screen"
812
+ ✅ [Continue]
813
+
814
+ **Why:** Users know how buttons work
815
+
816
+ ---
817
+
818
+ ### Mistake 2: Using Technical Language
819
+
820
+ ❌ "Authentication failed for endpoint"
821
+ ✅ "We couldn't log you in. Check your email and password."
822
+
823
+ **Why:** Users don't think in technical terms
824
+
825
+ ---
826
+
827
+ ### Mistake 3: Being Vague
828
+
829
+ ❌ "An error occurred"
830
+ ✅ "Your password must be at least 8 characters"
831
+
832
+ **Why:** Specific errors help users fix problems
833
+
834
+ ---
835
+
836
+ ### Mistake 4: Overusing Exclamation Points
837
+
838
+ ❌ "Success! Your invoice has been sent!"
839
+ ✅ "Invoice sent"
840
+
841
+ **Why:** One exclamation point per screen maximum
842
+
843
+ ---
844
+
845
+ ### Mistake 5: Apologizing Unnecessarily
846
+
847
+ ❌ "Sorry, we couldn't find any results"
848
+ ✅ "No results found"
849
+
850
+ **Why:** No results isn't anyone's fault
851
+
852
+ ---
853
+
854
+ ### Mistake 6: Marketing Speak in Product
855
+
856
+ ❌ "Leverage our innovative AI-powered categorization"
857
+ ✅ "Auto-categorize expenses"
858
+
859
+ **Why:** Users want to complete tasks, not read marketing
860
+
861
+ ---
862
+
863
+ ## Additional Resources
864
+
865
+ - **Content Foundations:** See [content-foundations.md](./content-foundations.md) for universal principles
866
+ - **Marketing Content Guide:** See [content-marketing-sales.md](./content-marketing-sales.md) for marketing content
867
+ - **Design System Overview:** See [../design/design-system.md](../design/design-system.md) for design token usage
868
+ - **Component Guidelines:** See [../technical/component-guidelines.md](../technical/component-guidelines.md) for component patterns
869
+
870
+ ---
871
+
872
+ **Remember:** Product content exists to help users accomplish their goals. Be helpful, be concise, be clear. Test with real users. Iterate based on data. When in doubt, cut words and add clarity.
873
+
874
+ For universal principles and quality tests, always reference [`content-foundations.md`](./content-foundations.md).
875
+