1  # Design Principles: 10 Core Decision Framework
  2  
  3  > **Load when:** Design reviews, principle conflicts, tradeoff decisions, need to explain design reasoning
  4  > **Skip when:** Simple execution, clear specs, no judgment needed
  5  > **Why it matters:** Provides consistent decision framework, resolves principle conflicts, builds design judgment
  6  > **Typical failure it prevents:** Subjective guessing, unable to explain decisions, not knowing how to choose when principles conflict
  7  
  8  The 10 core principles are cc-design's decision framework. They are not rules, they are judgment tools. When facing choices, use principles to guide decisions.
  9  
 10  ---
 11  
 12  ## cc-design's 10 Core Principles
 13  
 14  ### 1. Clarity Over Beauty
 15  
 16  **Principle:** If you must choose between clarity and beauty, choose clarity.
 17  
 18  **Reasoning:**
 19  - Design's primary goal is to convey information, not to decorate
 20  - Users come to complete tasks, not to admire design
 21  - Beautiful but unclear = failed design
 22  
 23  **Application:**
 24  - **Font size**: Readability > visual compactness (minimum 14px body text)
 25  - **Contrast**: Information hierarchy > visual harmony (sufficient contrast ratio)
 26  - **Whitespace**: Reading rhythm > space efficiency (prefer more whitespace)
 27  - **Animation**: Functional feedback > visual showmanship (purposeful animation)
 28  
 29  **Exception:**
 30  - Brand expression designs (art posters, concept showcases)
 31  - Emotion-priority scenarios (emotional design)
 32  - But even in exceptions, ensure basic readability
 33  
 34  **Test:**
 35  - Can users find core information within 3 seconds?
 36  - Is information hierarchy immediately clear?
 37  - Is it still usable without decoration?
 38  
 39  ---
 40  
 41  ### 2. Context Over Convention
 42  
 43  **Principle:** User's design system > general best practices.
 44  
 45  **Reasoning:**
 46  - Consistency is more important than "correctness"
 47  - User's existing system is their context
 48  - Cost of breaking consistency > benefit of local optimization
 49  
 50  **Application:**
 51  - **Read codebase first**: Copy user's hex/px values, don't guess
 52  - **Follow naming**: If user calls it `primary-blue`, use that name
 53  - **Keep patterns**: If user uses cards, keep using cards
 54  - **Respect specs**: Don't argue with "Material Design says it should be this way"
 55  
 56  **Exception:**
 57  - User's system clearly violates usability (e.g., 12px body text, 3:1 contrast ratio)
 58  - User explicitly requests system improvements
 59  - But suggest first, change only after agreement
 60  
 61  **Test:**
 62  - Does this design fit harmoniously into the user's product?
 63  - Can the user recognize this as their style?
 64  - Does it reuse the user's tokens and components?
 65  
 66  ---
 67  
 68  ### 3. Problem Definition Over Solutions
 69  
 70  **Principle:** Ask "why" first, then "how".
 71  
 72  **Reasoning:**
 73  - Without goal definition, there's no real design, only decoration
 74  - Wrong problem definition → correct execution is still failure
 75  - Problem definition determines evaluation criteria
 76  
 77  **Application:**
 78  - **P1 principle**: Ask questions in batch for new tasks, don't jump in
 79  - **Junior Designer Mode**: Write assumptions before code
 80  - **Before each design answer**: What problem? For whom? Success criteria?
 81  - **Reject vague briefs**: "Make a nice dashboard" → clarify what data to show
 82  
 83  **Exception:**
 84  - Clear small changes ("change button to blue")
 85  - User has provided detailed brief
 86  - But even in exceptions, confirm understanding
 87  
 88  **Test:**
 89  - Can you explain the core problem in one sentence?
 90  - Can you describe target users and scenarios?
 91  - Are there clear success metrics?
 92  
 93  ---
 94  
 95  ### 4. Validation Over Assumptions
 96  
 97  **Principle:** Validate with data and testing, don't rely on intuition.
 98  
 99  **Reasoning:**
100  - Designer's "feeling" is often wrong
101  - Unvalidated assumptions = risk
102  - Validation is the only way to learn and improve
103  
104  **Application:**
105  - **P0 principle**: Fact validation (brand, product, pricing, technology)
106  - **Three-phase validation**: Structure → Visual → Excellence
107  - **Pre-screenshot checks**: Console errors, responsive, real content
108  - **Pre-delivery testing**: Core flow, edge cases, different devices
109  
110  **Exception:**
111  - Time-constrained prototyping (but label assumptions)
112  - Exploratory design (but clarify it's exploration)
113  - But validate assumptions as soon as possible
114  
115  **Test:**
116  - Is this design based on facts or assumptions?
117  - Have assumptions been validated?
118  - Is there data supporting key decisions?
119  
120  ---
121  
122  ### 5. System Over Local
123  
124  **Principle:** Overall consistency > local optimization.
125  
126  **Reasoning:**
127  - Locally brilliant but globally chaotic = failed design
128  - System thinking reduces cognitive load
129  - Consistency builds trust and predictability
130  
131  **Application:**
132  - **Spacing scale**: 4/8/12/16/24/32/48/64, not random values
133  - **Type scale**: 1.25 ratio, not arbitrary font sizes
134  - **Font weights**: 2-3 weights, not 5
135  - **Colors**: 2-3 primary colors, not a rainbow
136  - **Components**: Reuse existing components, don't redesign every time
137  
138  **Exception:**
139  - Clear visual focus (hero section) can break rules
140  - Brand showcase needs special treatment
141  - But have clear reasoning and document the exception
142  
143  **Test:**
144  - Does this design use system tokens?
145  - Is it consistent with other pages?
146  - If copied 10 times, would it become chaotic?
147  
148  ---
149  
150  ### 6. Content Over Form
151  
152  **Principle:** Organize content first, then design form.
153  
154  **Reasoning:**
155  - Form serves content, not the other way around
156  - Content determines structure and visuals
157  - Form without content = empty visual games
158  
159  **Application:**
160  - **Information architecture first**: Filter, group, sequence
161  - **Then visual design**: Use visuals to express information hierarchy
162  - **Don't force fit**: Don't break content to fit bento grid
163  - **No filler content**: No content = no placeholder
164  
165  **Exception:**
166  - Brand expression designs (form is the content)
167  - Visual exploration phase (but fill in real content soon)
168  - But clarify it's an exception
169  
170  **Test:**
171  - Is content organized?
172  - Does form serve content?
173  - Does form have meaning without content?
174  
175  ---
176  
177  ### 7. Subtraction Over Addition
178  
179  **Principle:** Remove what you can, don't pile on.
180  
181  **Reasoning:**
182  - Every element adds cognitive load
183  - Less is more
184  - Removing is the hardest design decision
185  
186  **Application:**
187  - **No filler content**: No actual content = no placeholder
188  - **Remove decoration**: Elements that don't carry information can be removed
189  - **Whitespace > filling**: Prefer more whitespace, don't stuff everything in
190  - **One focus per screen**: Don't try to show everything on one screen
191  
192  **Exception:**
193  - Designs requiring richness (e-commerce, media)
194  - Brand-required decorative elements
195  - But ensure core information is not affected
196  
197  **Test:**
198  - Does every element have a clear purpose?
199  - Would removing it affect understanding?
200  - Are there unnecessary decorations?
201  
202  ---
203  
204  ### 8. Natural Over Flashy
205  
206  **Principle:** Interaction should follow intuition, don't design for cool factor.
207  
208  **Reasoning:**
209  - Users don't care about your technology, only about completing tasks
210  - Natural interaction = users don't notice the interaction
211  - Flashiness increases learning cost
212  
213  **Application:**
214  - **Buttons in expected places**: Don't change basic patterns for innovation
215  - **Timely clear feedback**: Don't use complex animations to delay feedback
216  - **Don't overdo animation**: Animation serves function, not showmanship
217  - **Follow platform norms**: iOS uses iOS patterns, Web uses Web patterns
218  
219  **Exception:**
220  - Brand showcase animations (but can't affect core functionality)
221  - Innovative products (but reduce learning cost)
222  - But ensure basic usability
223  
224  **Test:**
225  - Can a first-time user guess how to operate?
226  - Does animation have a clear functional purpose?
227  - Does it follow platform norms?
228  
229  ---
230  
231  ### 9. Consistency Over Innovation
232  
233  **Principle:** Follow platform norms and user habits.
234  
235  **Reasoning:**
236  - Consistency reduces learning cost
237  - User habits are precious assets
238  - Innovation needs sufficient justification
239  
240  **Application:**
241  - **iOS uses iOS norms**: Don't use Material Design on iOS
242  - **Web uses Web conventions**: Links are blue and underlined, buttons are solid
243  - **Don't reinvent navigation**: Users know top-left is back
244  - **Maintain internal consistency**: Keep consistency within same product
245  
246  **Exception:**
247  - Clear brand differentiation needs
248  - Innovation significantly improves experience
249  - But reduce learning cost, provide guidance
250  
251  **Test:**
252  - Does this design follow platform norms?
253  - Is it consistent with user habits?
254  - Does the innovation have sufficient justification?
255  
256  ---
257  
258  ### 10. Scalability Over Perfection
259  
260  **Principle:** Design should work long-term, not just be perfect now.
261  
262  **Reasoning:**
263  - Design is a system, not an artwork
264  - Perfect but unscalable = technical debt
265  - Scalability is long-term value
266  
267  **Application:**
268  - **Build design system**: Tokens, components, specs
269  - **Use CSS variables**: Don't hardcode values
270  - **Component thinking**: Reusable, composable
271  - **Document**: Record decisions and rules
272  
273  **Exception:**
274  - One-off marketing pages (but still consider reuse)
275  - Quick prototypes (but label temporary solutions)
276  - But systematize as soon as possible
277  
278  **Test:**
279  - Can this design be reused?
280  - Can it scale to other scenarios?
281  - Are there clear rules?
282  
283  ---
284  
285  ## Principle Priority
286  
287  When principles conflict, follow this order:
288  
289  1. **Clarity** > Beauty
290  2. **Context** > Convention
291  3. **Problem Definition** > Solutions
292  4. **Validation** > Assumptions
293  5. **System** > Local
294  6. **Content** > Form
295  7. **Subtraction** > Addition
296  8. **Natural** > Flashy
297  9. **Consistency** > Innovation
298  10. **Scalability** > Perfection
299  
300  **Note:** This is not absolute; judge based on specific situations.
301  
302  ---
303  
304  ## Principle Conflict Case Studies
305  
306  ### Case 1: Clarity vs Beauty
307  
308  **Scenario:** Large title looks beautiful, but information hierarchy is unclear
309  
310  **Conflict:**
311  - Beauty: 48px large title has strong visual impact
312  - Clarity: Title too large, body text relatively too small, hierarchy unclear
313  
314  **Decision:** Reduce title to 32px, ensure hierarchy clarity
315  
316  **Reasoning:** Principle 1 (Clarity > Beauty)
317  
318  ---
319  
320  ### Case 2: Context vs Convention
321  
322  **Scenario:** User's system uses 12px body text, but best practice is 14px
323  
324  **Conflict:**
325  - Context: Keep 12px to maintain consistency
326  - Convention: 14px has better readability
327  
328  **Decision:** Suggest improvement first; if user insists, keep 12px
329  
330  **Reasoning:** Principle 2 (Context > Convention), but suggest improvements
331  
332  ---
333  
334  ### Case 3: System vs Local
335  
336  **Scenario:** 12px works better for this page, but system uses 14px
337  
338  **Conflict:**
339  - Local: 12px is more visually compact on this page
340  - System: 14px is the system standard
341  
342  **Decision:** Keep 14px, maintain system consistency
343  
344  **Reasoning:** Principle 5 (System > Local)
345  
346  ---
347  
348  ### Case 4: Brand vs Interaction
349  
350  **Scenario:** Brand requires special font, but readability is poor
351  
352  **Conflict:**
353  - Brand: Special font embodies brand personality
354  - Interaction: Poor readability affects usage
355  
356  **Decision:** Use brand font for titles, readable font for body text
357  
358  **Reasoning:** Principle 1 (Clarity > Beauty) + Principle 8 (Natural > Flashy)
359  
360  ---
361  
362  ### Case 5: Innovation vs Consistency
363  
364  **Scenario:** Want to use new navigation pattern, but users are accustomed to traditional
365  
366  **Conflict:**
367  - Innovation: New pattern is more efficient
368  - Consistency: Users are familiar with traditional pattern
369  
370  **Decision:** If new pattern significantly improves experience, innovate but provide guidance
371  
372  **Reasoning:** Principle 9 (Consistency > Innovation), but has exceptions
373  
374  ---
375  
376  ## Design Decision Framework
377  
378  When facing design decisions, follow these steps:
379  
380  ### 1. Clarify the Problem
381  
382  **Ask:** What problem does this decision solve?
383  
384  **Check:** Principle 3 (Problem Definition > Solutions)
385  
386  ---
387  
388  ### 2. Check Context
389  
390  **Ask:** Are there contextual constraints?
391  
392  **Check:**
393  - User's design system
394  - Platform norms
395  - Brand requirements
396  - Technical limitations
397  
398  **Apply:** Principle 2 (Context > Convention)
399  
400  ---
401  
402  ### 3. Evaluate Clarity
403  
404  **Ask:** Is it clear?
405  
406  **Check:**
407  - Is information hierarchy clear
408  - Can users understand quickly
409  - Is there ambiguity
410  
411  **Apply:** Principle 1 (Clarity > Beauty)
412  
413  ---
414  
415  ### 4. Check Consistency
416  
417  **Ask:** Is it consistent?
418  
419  **Check:**
420  - Consistent with other parts of the system
421  - Consistent with platform norms
422  - Consistent with user habits
423  
424  **Apply:** Principle 5 (System > Local) + Principle 9 (Consistency > Innovation)
425  
426  ---
427  
428  ### 5. Validate Assumptions
429  
430  **Ask:** Is it verifiable?
431  
432  **Check:**
433  - Based on facts or assumptions
434  - Have assumptions been validated
435  - Is there data support
436  
437  **Apply:** Principle 4 (Validation > Assumptions)
438  
439  ---
440  
441  ### 6. Consider Scalability
442  
443  **Ask:** Is it scalable?
444  
445  **Check:**
446  - Can it be reused
447  - Can it scale to other scenarios
448  - Are there clear rules
449  
450  **Apply:** Principle 10 (Scalability > Perfection)
451  
452  ---
453  
454  ## Conditions for Breaking Principles
455  
456  Principles are not rules; they can be broken, but must satisfy:
457  
458  ### 1. Goal Layer Explicitly Requires
459  
460  **Examples:**
461  - Goal is "brand showcase" → Brand > Interaction
462  - Goal is "visual impact" → Visual > Information
463  - Goal is "innovative experience" → Innovation > Consistency
464  
465  **Prerequisite:** Goal layer has clear justification
466  
467  ---
468  
469  ### 2. Sufficient Reasoning
470  
471  **Examples:**
472  - Breaking consistency: Because this scenario is special, consistency would reduce experience
473  - Breaking system: Because this is a visual focus, needs special treatment
474  - Breaking convention: Because innovation significantly improves efficiency
475  
476  **Prerequisite:** Can clearly explain why the break is needed
477  
478  ---
479  
480  ### 3. Understanding Consequences
481  
482  **Examples:**
483  - Breaking consistency → Increases learning cost
484  - Breaking system → Increases maintenance cost
485  - Breaking convention → Requires user education
486  
487  **Prerequisite:** After weighing, determined to be worth it
488  
489  ---
490  
491  ### 4. Documenting Why
492  
493  **Examples:**
494  - Record in code comments
495  - Explain in design documentation
496  - Mark as exception in design system
497  
498  **Prerequisite:** Let future self and team understand
499  
500  ---
501  
502  ## Relationship to Other Documents
503  
504  - **design-philosophy.md**: Philosophical foundation of principles
505  - **design-thinking-framework.md**: Application of principles in the 8-layer framework
506  - **design-excellence.md**: Embodiment of principles in visual design
507  - **content-guidelines.md**: Rules of principles in content design
508  - **SKILL.md P0/P1/P2**: Operationalization of principles
509  
510  ---
511  
512  ## Remember
513  
514  1. **10 Principles**: Clarity, Context, Problem Definition, Validation, System, Content, Subtraction, Natural, Consistency, Scalability
515  2. **Priority**: Clarity > Context > Problem Definition > Validation > System > Content > Subtraction > Natural > Consistency > Scalability
516  3. **Decision Framework**: Problem → Context → Clarity → Consistency → Validation → Scalability
517  4. **Breaking Conditions**: Goal requires + Sufficient reasoning + Understanding consequences + Documentation
518  5. **Principles are not rules**: They are judgment tools, not rigid regulations
519  
520  **Principles guide judgment, judgment builds intuition.**