Documents – Page 18 – Memorres Information Center

Template: Visual Language One-Pager (for Non-Designers)

Purpose

To provide a single-page summary of the product’s visual language so non-designers can quickly align on style, tone, and consistency without digging into Figma or long guidelines.

Visual Language Summary Template

Category	Definition	Sample Entry
Primary Colors	Core brand and action colors	Primary Blue `#3B82F6` (buttons, links) Secondary Indigo `#6366F1` (support actions) Neutral Gray `#6B7280` (backgrounds, borders)
Typography	Font families and hierarchy	Inter – Regular (Body) Inter – SemiBold (Headings) Base size: 16px Headline: 32px
Spacing & Layout	How spacing is applied	8px base unit 24px between cards 64px between sections
Buttons	Primary vs. secondary vs. tertiary styles	Primary: Filled Blue Secondary: Outline Gray Tertiary: Text-only
Cards & Blocks	How content modules are styled	White background, 12px radius, subtle shadow
Icons & Illustrations	Style guidance	Stroke icons, 24px, consistent line weight Flat, minimal illustrations
Feedback Styles	How success/error/warning/info states look	Success = Green (#10B981) + check icon Error = Red (#EF4444) + alert icon
Tone & Emotion	The “feel” of the product	Clear, modern, approachable, professional

Usage Notes

Share this one-pager in project kickoffs and handoff docs.
Keep language simple, non-technical → audience is PMs, devs, clients.
Update only when core tokens/visual rules change.
Export as PDF or a lightweight slide for distribution.

Outcome: Non-designers gain instant clarity on product visuals → reducing back-and-forth and ensuring consistent implementation across teams.

Checklist: Component Consistency

Purpose

To ensure that every component in the design system is clean, reusable, and consistent with tokens, naming, and states before being published or shared.

Component Consistency Checklist

Item	Check	Status (☑/✗)	Notes
Naming	Component follows UI naming convention (Doc 4.4)
Variants	All required variants exist (Primary/Secondary/Tertiary etc.)
States	All interaction states included (Default, Hover, Active, Disabled, Error)
Tokens	Uses defined tokens (spacing, color, typography, radius) from Visual Token Sheet (Doc 4.1)
Resizing Rules	Component resizes correctly across layouts
Constraints	Figma constraints/auto-layout applied properly
Properties	Component properties (size, icon placement) are parameterized
Consistency	Matches style mapping rules (Doc 4.3)
Accessibility	Meets WCAG AA contrast and tap size
Documentation	Component Documentation Template (Doc 4.6) completed
Review	Peer review completed
Approval	Design Lead sign-off

Usage Notes

This checklist must be completed before publishing to the shared library.
For each major project, audit critical components monthly.
Store filled checklists in the Design System → Component QA folder.

Outcome: Components remain clean, standardized, and reusable, reducing duplication and ensuring dev-ready consistency.

Template: Component Documentation

Purpose

To capture detailed specifications of a UI component including structure, behavior, and variants, ensuring consistency across design and development.

Table – Component Documentation Template

Field	Description	Sample Entry
Component Name	Functional, structured name of the component	`Button/Primary/Large`
Purpose	Why this component exists, what problem it solves	“Primary action button used for key CTAs”
Category	UI system grouping	Buttons → Actions
Variants	Types/styles available	Primary, Secondary, Tertiary
States	Interaction states	Default, Hover, Active, Disabled, Error
Properties	Customization parameters	Size: Small/Medium/Large Icon: Left/Right/None
Tokens Applied	Which tokens are used	`Color-Primary`, `Radius-Small`, `Font-Button-Text`
Usage Guidelines	Do’s & Don’ts of usage	Do: Use one Primary per screen Don’t: Stack multiple CTAs
Dependencies	Linked patterns/components	Relies on spacing tokens + grid system
Example Screens	Where this component is applied	Landing Page Hero CTA, Dashboard Actions
Notes & Annotations	Additional instructions for dev/QA	“Hover state must meet WCAG AA contrast”

Usage Notes

Each component must have a completed documentation sheet before being added to shared libraries.
Store all component docs in the Design System → Component Docs folder.
Updates must be logged in Component Review Log (EPIC 10.8).

Outcome: Every component is self-explanatory and traceable, reducing confusion across design, dev, and QA teams.

SOP: Building & Managing a Component Design System

1. Purpose

To define the process for creating, organizing, and maintaining a component-based design system that ensures consistency, scalability, and developer alignment across all projects.

2. Scope

Applies to all UI components, patterns, and tokens.
Covers new builds, updates, and shared libraries.
Used by designers, leads, and design ops.

3. Step-by-Step Process

Stage A – Setup & Foundation

Define Tokens First
- Use Visual Token Reference Sheet (Doc 4.1).
- Lock colors, spacing, typography before components.
Component Categories
- Buttons, Inputs, Cards, Modals, Navigation, Alerts, Icons.
- Create a folder/page structure in Figma for each.
Naming Conventions
- Apply UI Element Naming Guide (Doc 4.4).

Stage B – Building Components

Start with Primitives
- Base elements: Button, Input, Checkbox, Dropdown.
- Add states: Default, Hover, Active, Disabled, Error.
Create Variants
- Use Figma Variants to group related states.
- Example: Button → {Primary, Secondary, Tertiary} × {Default, Hover, Disabled}.
Document Properties
- Add resizing rules, padding, constraints.
- Annotate usage (do’s/don’ts) in Component Documentation Template (Doc 4.6).

Stage C – Maintenance & Hygiene

Weekly Library Check
- Remove duplicates, unused frames.
- Verify tokens are applied correctly.
Component Reviews
- Major updates → log in Component Review Log (Doc 10.8).
- Approvals via Design Lead.
Version Control
- Use version tags (v1.0, v1.1).
- Maintain changelog for transparency.

Stage D – Sharing & Collaboration

Publish Libraries
- Push approved components into shared libraries.
- Designers must always use published versions, not local copies.
Cross-Team Sync
- Sync with dev → export tokens/components in JSON or Storybook.
- Run monthly design-dev sync to review usage gaps.

4. Roles & Responsibilities

Designer Assigned → Build/update components as per brief.
Peer Designer → Review for consistency.
Design Lead → Approve before library publishing.
Dev Lead → Validate dev feasibility for advanced components.

5. Governance

No new components may bypass this SOP.
Unapproved edits to shared libraries = rollback.
Regular audits → report to Delivery Head.

Guide: UI Element Naming & Structuring Conventions

Purpose

To define rules for naming, grouping, and structuring UI elements in design libraries, so multiple designers can collaborate without breaking consistency or confusing developers.

1. Naming Conventions

Component Type	Naming Rule	Example
Buttons	`[Type]/[Size]/[State]`	`Button/Primary/Large/Disabled`
Form Fields	`[Type]/[Variant]/[State]`	`Input/Text/Error`
Cards	`Card/[Context]/[Variant]`	`Card/Pricing/Featured`
Icons	`Icon/[Action]`	`Icon/Download`
Modals	`Modal/[Purpose]`	`Modal/DeleteConfirmation`
Alerts	`Alert/[Type]`	`Alert/Success`

Rules:

Always use PascalCase or kebab-case (never random mixes).
Keep names functional, not decorative (use Button/Primary not BlueButton).
States (Hover, Active, Disabled, Error) must always be explicit.

2. File & Layer Structuring

Top-Level Pages in Figma:
1. Foundations (tokens, colors, typography)
2. Components (buttons, inputs, cards)
3. Screens (wireframes, flows, UI screens)
4. Archive (unused/old versions)
Within a Component:
- Frame Naming: Component/Variant/State
- Layer Naming:
  - Buttons: Icon_Left, Label, Background
  - Inputs: Label, Input_Field, Helper_Text, Error_Message
- Group by function, not visuals.

3. Versioning & Variants

Variants should be stored as a single component set (not multiple copies).
Example: Button component contains Primary, Secondary, Tertiary variants → each with states (Default, Hover, Disabled).
Major changes must use version tags: v1.0, v1.1.

4. Do’s & Don’ts

Do:

Keep names short but descriptive.
Follow same convention across all files and projects.
Include state/variant in naming.

Don’t:

Use vague names like Final_Button, Copy of Input.
Mix languages (Btn, Bouton).
Duplicate components for each state — always use variants.

5. Example – Button Library in Figma

Button/
   ├── Primary/
   │     ├── Default
   │     ├── Hover
   │     ├── Disabled
   ├── Secondary/
   │     ├── Default
   │     ├── Hover
   │     ├── Disabled
   └── Tertiary/
         ├── Default
         ├── Hover

6. Governance

Design Lead reviews the library weekly for naming consistency.
QA checks names before handoff to dev.
Violations → rollback or fix before merging into the master library.

Outcome: UI elements stay organized, scalable, and developer-friendly, enabling faster collaboration and reducing design system chaos.

Framework: UI Style Mapping Framework

Purpose

To provide a structured system for styling UI elements (components, actions, states) by mapping them into consistent visual weight categories — ensuring scalability and brand alignment.

Style Mapping Model

Element Type	Style Tier	Definition	Usage Example	Notes
Buttons	Primary	High-visibility action (1 per screen)	“Book Demo,” “Save Project”	Always high contrast, filled style
	Secondary	Supportive actions	“Cancel,” “Learn More”	Outlined/ghost buttons, lower emphasis
	Tertiary	Inline, low-priority actions	“Edit,” “More Options”	Icon-only, text links
Form Fields	Default	Standard inputs	Name, email fields	Neutral border + placeholder
	Highlighted	Focus/active state	Email field when user types	Accent border, subtle glow
	Error	Invalid input	Wrong email format	Red border + inline error message
Cards/Blocks	Primary	Core content blocks	Pricing cards, feature highlights	Use stronger background + shadow
	Secondary	Supporting info	Notifications, side blocks	Light outline or subtle background
Text Styles	Heading	Primary headers	H1/H2 sections	Use font-heading tokens
	Body	Main copy	Paragraphs, form instructions	Base font tokens
	Helper	Secondary/annotation	Footnotes, hints	Small, muted tone
Alerts & Feedback	Success	Confirmation messages	“Project saved successfully”	Green tone + check icon
	Error	Critical issues	“Payment failed”	Red tone + alert icon
	Warning	Non-blocking risks	“Unsaved changes”	Yellow tone + icon
	Info	Neutral updates	“New version available”	Blue tone + info icon

Implementation Rules

One Primary Action per screen — avoid multiple competing CTAs.
Style tiers must cascade — never use primary button + primary card together without spacing hierarchy.
Use tokens from Visual Token Reference Sheet (Doc 4.1) for all colors/spacing.
Accessibility check — contrast ratios must meet WCAG AA.
Consistency across platforms — mobile, web, and dashboard must use same mapping.

Example Mapping – SaaS Dashboard Screen

Primary Button: “Create Project” (blue filled)
Secondary Button: “Cancel” (outline grey)
Card (Primary): Active projects (white bg, shadow)
Card (Secondary): Recent activity (light bg, no shadow)
Alert: “Project saved successfully” (green success banner)

Usage Notes

Apply during wireframe → UI transition.
Keep style mapping documented in Figma component library.
Review in Design QA (EPIC 6) for consistency.

Template: Typography & Layout Grid Sheet

Purpose

To define typography styles (fonts, sizes, line heights) and layout grids (columns, gutters, containers) that form the foundation of all UI design.

Table 1 – Typography System

Style	Font Family	Size	Weight	Line Height	Usage Example
H1	Inter / SemiBold	32px	600	40px	Page headlines, hero sections
H2	Inter / SemiBold	24px	600	32px	Section headers
H3	Inter / Medium	20px	500	28px	Sub-headers, card titles
Body-Base	Inter / Regular	16px	400	24px	Standard text paragraphs
Body-Small	Inter / Regular	14px	400	20px	Secondary text, helper copy
Caption	Inter / Regular	12px	400	16px	Labels, annotations
Button-Text	Inter / Medium	16px	500	20px	Primary/secondary buttons
Link	Inter / Medium	16px	500	20px	Inline links, navigation items

Table 2 – Layout Grid System

Screen Type	Grid Columns	Gutter Width	Container Width	Notes
Desktop (≥1440px)	12	24px	1140px	Central container with wide margins
Laptop (≥1024px)	12	20px	960px	Flexible layouts for dashboards
Tablet (≥768px)	8	20px	720px	Compact layouts, maintain readability
Mobile (≤375px)	4	16px	Fluid (100%)	Stack content vertically

Table 3 – Alignment & Spacing

Element	Rule	Example
Section Spacing	64px between sections (desktop), 40px (mobile)	Between hero & features section
Component Spacing	24px between components	Card to card, form fields
Inside Blocks	16px padding	Inside cards, modals
Navigation	Always aligned to grid start	Sidebar in dashboards
Responsive Breaks	Elements reflow at defined breakpoints	3 cards → 2 (tablet) → 1 (mobile)

Usage Notes

Apply these styles consistently in Figma using text + grid styles.
Do not create arbitrary sizes; always stick to defined tokens.
Use rem/em equivalents in dev handoff (for scalability).
Update this sheet only when system-wide changes are required.

Template: Visual Token Reference Sheet

Purpose

To document all base tokens (spacing, typography, color, radius, shadows, etc.) that act as the single source of truth for both designers and developers. Tokens ensure consistency, scalability, and easy updates across projects.

Table – Visual Tokens

Token Category	Token Name	Value	Usage Example	Notes
Spacing	Space-1	4px	Small icon padding	Base unit, multiples only
	Space-2	8px	Gaps between form fields	Used across mobile & desktop
	Space-3	16px	Card padding	Default block padding
	Space-4	24px	Section spacing	For larger content blocks
	Space-5	32px	Between modules	Desktop preferred spacing
Typography	Font-Primary	Inter, Regular	Body text	Web/app default
	Font-Heading	Inter, SemiBold	H1–H3	Keep hierarchy consistent
	Font-Size-Base	16px	Paragraph text	Minimum readable size
	Font-Size-Large	20px	Sub-headings	Used for emphasis
	Font-Size-XL	32px	H1 headlines	Landing pages, hero text
Color	Color-Primary	#3B82F6	Primary CTAs	Accessible contrast AA
	Color-Secondary	#6366F1	Secondary CTAs	For supportive actions
	Color-Success	#10B981	Success messages	Confirmations
	Color-Error	#EF4444	Error states	Validation fails
	Color-Warning	#F59E0B	Warnings, alerts	Not for critical errors
	Color-Background	#FFFFFF	Page background	Default light theme
	Color-Text	#111827	Primary text	87% opacity for readability
Radius & Shadows	Radius-Small	4px	Buttons, inputs	Default rounding
	Radius-Large	12px	Cards, modals	Friendly, modern look
	Shadow-1	0 1px 2px rgba(0,0,0,0.05)	Card shadows	Subtle depth
	Shadow-2	0 4px 6px rgba(0,0,0,0.1)	Modal shadows	Elevated depth

Usage Notes

Tokens must be applied consistently in all wireframes and UI files.
Never hardcode values (e.g., “#3B82F6” directly) — always use token name (Color-Primary).
Updates in token sheet → propagate across entire design system.
Export tokens into dev handoff tools (Figma Variables, Style Dictionary, JSON exports).

Guide: Planning Cross-Device Wireframes (Web/Mobile/Desktop)

Purpose

To provide a structured method for designing responsive wireframes that adapt across desktop, tablet, and mobile while maintaining consistency, usability, and system logic.

1. Why This Matters

Users interact on multiple devices → poor adaptation = frustration.
Designing only for desktop → broken mobile experiences.
This guide ensures consistency, readability, and efficiency across all breakpoints.

2. Step-by-Step Planning

Step 1 – Define Breakpoints

Desktop (≥1440px): 12-column grid.
Tablet (≥768px): 8-column grid.
Mobile (≤375px): 4-column grid.
Always start with Desktop + Mobile, then refine Tablet.

Step 2 – Prioritize Content

Ask: “What’s essential for mobile vs. what can collapse?”
Use content hierarchy mapping:
- Must-have → Always visible.
- Nice-to-have → Collapsible or hidden behind menus.

Step 3 – Adapt Layouts

Desktop → Horizontal spread (cards in rows, sidebars).
Tablet → Compact two-column layouts.
Mobile → Vertical stacking (one-column, prioritized CTAs).

Step 4 – Preserve CTA Visibility

Ensure primary CTA is visible without scrolling on all devices.
Avoid burying CTAs in collapsed menus.

Step 5 – Plan Navigation

Desktop → Top bar / sidebar.
Tablet → Collapsible sidebar / hamburger.
Mobile → Bottom nav (max 5 items) or hamburger menu.

Step 6 – Validate Interaction Zones

Mobile → Minimum 44px tap targets.
Tablet → Finger-friendly spacing, avoid hover-only elements.
Desktop → Can allow hover states, but must degrade gracefully for touch.

3. Best Practices

Do:

Design mobile-first for clarity, then scale up.
Test with real content lengths (not lorem ipsum).
Use consistent iconography and patterns.

Don’t:

Shrink desktop → scale to mobile (leads to broken UI).
Overcrowd mobile with all desktop features.
Rely only on hover interactions.

4. Quick Example

Landing Page:

Desktop → Hero left text + right image + CTA.
Tablet → Stack hero text over image, CTA centered.
Mobile → Hero text → CTA → image below.

Dashboard:

Desktop → Sidebar + content grid.
Tablet → Collapsible sidebar + 2-column grid.
Mobile → Bottom nav + single column list.

5. Usage Notes

Plan all breakpoints during wireframe stage — don’t leave for UI polish.
Annotate differences clearly in Wireframe Specification Template (Doc 3.3).
Validate with Grid & Spacing Rulesheet (Doc 3.5).

Template: Multi-State Wireframe Planner

Purpose

To plan and document all interaction states for each screen, ensuring user flows remain predictable and resilient.

Table – Multi-State Wireframe Planner

Screen ID	Screen Name	State Type	Wireframe Reference	System Behavior	Notes / Design Intent
WF1	Dashboard	Empty	Wireframe – Empty Dashboard	Shows blank state	Provide CTA: “Create First Project” with illustration
WF1	Dashboard	Loading	Wireframe – Loading Dashboard	Fetch projects from API	Use skeleton loaders, not spinners
WF1	Dashboard	Success	Wireframe – Project Dashboard	Show project list	Default to most recent project
WF1	Dashboard	Error	Wireframe – Error State	API timeout / failure	Show error message + “Retry” button
WF1	Dashboard	Permission	Wireframe – Restricted Dashboard	User lacks access	Show lock icon + message: “Ask admin for access”
WF2	Booking Form	Empty	Wireframe – Blank Form	No inputs yet	Placeholder text only
WF2	Booking Form	Loading	Wireframe – Processing Submission	Waiting for backend response	Show progress indicator
WF2	Booking Form	Success	Wireframe – Confirmation	Form submitted successfully	Show confirmation + calendar link
WF2	Booking Form	Error	Wireframe – Invalid Input	Validation fails	Highlight fields with inline error messages

Usage Notes

Each screen must have at least 3 states: Empty, Success, Error.
For data-driven screens, include Loading and Permission states.
States should be documented in this sheet + visualized as wireframes in Figma.
Keep notes precise — devs should know exactly what happens.