Archives: Documents

Purpose

To help designers adopt a developer-first mindset while creating UI designs — ensuring handoff clarity, reduced rework, and faster builds.

1. Why Dev Thinking Matters

• Designers often over-design or create visuals that devs can’t implement efficiently.
• Developers end up guessing missing states, interactions, or tokens.
• “Dev Thinking” = designing as if you will code it yourself → practical, systematic, scalable.

2. Core Principles

1. Design with Components, Not Screens
   • Think in reusable building blocks (buttons, cards, modals).
   • If a component can’t be reused → devs write duplicate code.
2. Tokens, Not Pixels
   • Always apply tokens for color, spacing, and typography (Doc 4.1).
   • Never hardcode values — updates must cascade globally.
3. Document States & Behaviors
   • Every UI element must have Default, Hover, Active, Disabled, Error, and Success.
   • Add notes like: “Hover darkens 10%, Disabled = cursor not-allowed.”
4. Respect Grids & Breakpoints
   • Follow Grid & Spacing Rulesheet (Doc 3.5).
   • Test designs at Desktop, Tablet, and Mobile breakpoints.
5. Prioritize Performance
   • Avoid oversized images/videos.
   • Use SVG icons instead of PNGs where possible.
   • Keep animation subtle, performant.
6. Predict Dev Questions
   • Before handoff, ask:
     • “What happens when API fails?”
     • “What does error state look like?”
     • “How should responsive layout reflow?”

3. Practical Examples

Bad Design → Dev Pain

• Designer uses unique button style for every screen.
• Dev must code 5 different buttons = wasted time.

Good Design → Dev Thinking

• Designer reuses Button/Primary from library.
• Dev writes one button component = reusable everywhere.

4. Dos & Don’ts

Do:

• Reuse design system components.
• Annotate all interactions & transitions.
• Test screens at multiple resolutions.
• Share designs early with devs for feasibility.

Don’t:

• Export one-off colors (#123456) outside tokens.
• Leave states undefined.
• Overcrowd mobile screens with desktop parity.
• Deliver designs without accessibility in mind.

5. Handoff Checklist (Quick Dev Thinking Test)

Tokens applied correctly

Component reused (not duplicated)

All states included

Responsive variants ready

Interactions annotated

Accessibility covered

File naming consistent

1. Purpose

To provide a structured approach for adapting UI designs across multiple device types — Desktop, Tablet, and Mobile — ensuring readability, usability, and consistency without creating redundant work.

2. Why This Matters

• Users don’t care about your design file — they care about smooth experience across devices.
• A layout that works on desktop often breaks on mobile if not intentionally designed.
• Without viewport-specific planning, devs make assumptions → results in inconsistent product delivery.

3. Step-by-Step Process

Step 1 – Identify Core Breakpoints

• Desktop: ≥1440px (12-column grid)
• Laptop: ≥1024px (12-column grid, narrower container)
• Tablet: ≥768px (8-column grid)
• Mobile: ≤375px (4-column grid)

Always start with Desktop + Mobile → refine Tablet as middle ground.

Step 2 – Prioritize Content

• Run a Content Priority Exercise:
  • Must-Have → Always visible (hero text, primary CTA, nav).
  • Secondary → Can collapse or move (testimonials, side info).
  • Optional → Hide in mobile (background visuals, decorative blocks).
• Ask: “If user only has 20 seconds on a mobile screen, what do they see?”

Step 3 – Adapt Layouts by Viewport

• Desktop:
  • Multi-column layouts (cards, sidebars).
  • Rich visuals allowed.
• Tablet:
  • Collapse multi-columns → 2 columns max.
  • Sidebar → collapsible or hidden under menu.
• Mobile:
  • One-column vertical stacking.
  • Prioritize CTA placement above the fold.
  • Replace sidebars with bottom nav or hamburger.

Step 4 – Adjust Components Responsively

• Buttons → Full-width on mobile, inline on desktop.
• Cards → Row of 3 (desktop) → Row of 2 (tablet) → Single stacked (mobile).
• Tables → Convert into stacked list for mobile.
• Forms → Inline fields → stacked vertically.

Step 5 – Validate Interaction Zones

• Minimum tap target = 44px (mobile).
• Avoid hover-only interactions (mobile doesn’t have hover).
• Keep critical actions thumb-friendly (bottom third of screen).

Step 6 – Check Visual Hierarchy

• Headlines should scale down, not truncate awkwardly.
• CTA buttons remain visually dominant on every viewport.
• Don’t let mobile become “mini desktop” → restructure content.

4. Practical Example

Landing Page Hero Section

• Desktop: Headline (left), Illustration (right), CTA under text.
• Tablet: Headline stacked on top of illustration, CTA centered below.
• Mobile: Headline → CTA → Illustration (full width).

Dashboard Navigation

• Desktop: Sidebar (left) + content (right).
• Tablet: Collapsible sidebar + 2-column grid.
• Mobile: Bottom nav (max 5 items) + single column list.

5. Do’s & Don’ts

Do:

• Use progressive disclosure — show essentials, hide complexity on mobile.
• Plan responsiveness at wireframe stage, not UI polish stage.
• Annotate responsive behaviors clearly for devs.

Don’t:

• Shrink desktop → scale → call it “mobile.”
• Force parity of features across devices if context doesn’t require it.
• Let mobile overflow with hidden scrollbars or micro-text.

6. Usage Notes

• Apply this guide alongside Grid & Spacing Rulesheet (Doc 3.5).
• Test mockups with real content lengths (not lorem ipsum).
• Validate final designs in actual device frames during review.

Purpose

To establish principles and practices for building visual systems (tokens, components, patterns) that remain consistent, flexible, and future-proof as products grow across platforms and teams.

2. Core Principles of Scalable Systems

1. Tokenization
   • Define spacing, colors, typography as tokens.
   • Never hardcode styles in components.
   • Tokens make global updates simple (e.g., change brand color once → updates everywhere).
2. Modularity
   • Design UI in reusable blocks: cards, lists, banners, forms.
   • Each block should be independent but combinable.
3. Variants & States
   • Components must include Default, Hover, Active, Disabled, Error, Success.
   • States avoid dev guesswork and prevent UI bugs.
4. Responsive Flexibility
   • Components should adapt across desktop, tablet, mobile using defined grids.
   • Avoid one-off “desktop-only” or “mobile-only” patterns.
5. Governance
   • Shared library + review process (weekly hygiene checks).
   • Clear ownership: Design Lead approves before publishing.
   • Audit for duplication monthly.

3. Scaling in Practice

At 1–2 Designers

• Focus on tokens + basic components.
• Document everything in Figma styles.

At 5+ Designers

• Formalize Component Library with categories.
• Use naming conventions (Doc 4.4).
• Introduce peer review for new components.

At Cross-Functional Scale (10+ designers + devs)

• Export tokens to dev environments (Storybook, Style Dictionary).
• Use Contribution Model (EPIC 10.9) → defines who can add/modify components.
• Run monthly design–dev syncs to review usage gaps.

4. Do’s & Don’ts

Do:

• Think in systems, not screens.
• Build once, reuse everywhere.
• Document components with clear usage guidelines.

Don’t:

• Create duplicates for every minor variation.
• Over-design with too many token layers.
• Allow “rogue” edits to shared libraries.

5. Example – Scalable Button System

• Button (Base Component) → defines padding, text style, border radius.
• Variants: Primary, Secondary, Tertiary.
• States: Default, Hover, Active, Disabled.
• Responsive Behavior: Full-width on mobile, fixed-width on desktop.
• Token Linkage: Color-Primary, Radius-Small, Font-Button.

Result → Any update (e.g., new brand color) auto-applies to all buttons across products.

6. Usage Notes

• Apply system-first thinking at the wireframe-to-UI stage.
• Run system audits quarterly to ensure scalability.
• Keep the Visual Language One-Pager (Doc 4.8) updated for non-designers.