Guide for Designers

Everything designers need to know about working with Fidus Design System

Getting Started

Fidus Design System is built for designers who want to create privacy-first, context-aware user experiences. This guide will help you understand our unique approach to UI design and how to work effectively with the design system.

Figma Resources

Coming Soon

We are currently working on Figma component libraries and design templates. These resources will include:

  • Complete component library with variants
  • Design tokens (colors, spacing, typography)
  • Layout templates and grids
  • Icon library
  • Example screens and flows

Check back soon or watch our GitHub repository for updates.

Design Principles

1. Privacy-First Design

Every design decision must prioritize user privacy and control:

  • Make privacy controls prominent and accessible
  • Use clear language to explain data usage
  • Provide granular control over data sharing
  • Default to most private settings
  • Show encryption status visually
Read Privacy UX Guidelines →

2. Context-Aware Design

Design components that adapt to user context, not fixed screens:

  • Think in terms of cards and widgets, not pages
  • Design for multiple presentation modes
  • Consider time, location, and user state
  • Allow components to appear anywhere
  • Design for dynamic relevance
Read AI-Driven UI Guidelines →

3. User Control

Users must always be in control of their experience:

  • Every card or widget must be dismissible
  • Never auto-hide important information
  • Provide clear actions and outcomes
  • Allow users to undo actions
  • Respect user preferences and settings

4. Examples Over Rules

Show what might happen, do not prescribe what always happens:

  • Use language like "might show" or "could appear"
  • Design for flexibility and variation
  • Avoid rigid, predetermined flows
  • Let context determine presentation

Design Tokens

Colors

Our color system is designed for accessibility and clarity:

Primary

Interactive elements

Secondary

Supporting content

Success

Positive actions

Danger

Destructive actions

View full color system →

Spacing

Consistent spacing creates visual harmony and hierarchy:

XS (4px)
SM (8px)
MD (16px)
LG (24px)
XL (32px)
View spacing system →

Typography

Our typography scale ensures readability and hierarchy:

Heading 1

36px / 2.25rem - Page titles

Heading 2

30px / 1.875rem - Section titles

Heading 3

24px / 1.5rem - Subsections

Body Text

16px / 1rem - Primary content

Small Text

14px / 0.875rem - Captions, labels

View typography system →

Component Anatomy

Understanding component structure helps you design consistent, accessible interfaces:

Common Component Parts

  • Container: The outermost wrapper that defines spacing and layout
  • Header: Title, description, and actions
  • Body: Main content area
  • Footer: Actions, metadata, or supplementary information
  • Dismiss Control: X button or swipe gesture for closeable items
  • Status Indicators: Loading, success, error states
See Card component as an example →

Accessibility Guidelines

Designing for accessibility is non-negotiable. All designs must meet WCAG 2.1 Level AA standards:

Color Contrast

Maintain a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Never rely on color alone to convey information.

Keyboard Navigation

All interactive elements must be keyboard accessible. Design visible focus states and logical tab order.

Screen Reader Support

Include descriptive labels, use semantic HTML structure, and provide text alternatives for images and icons.

Touch Targets

Ensure interactive elements are at least 44x44 pixels for comfortable touch interaction.

Read full accessibility guidelines →

Working with Developers

Effective collaboration between designers and developers is key to successful implementation:

Design Handoff

  • Annotate designs with spacing values using design tokens
  • Specify interactive states (hover, active, disabled)
  • Document responsive behavior at different breakpoints
  • Include accessibility requirements
  • Provide example content and edge cases

Communication

  • Use component names from the design system
  • Reference design tokens instead of hard values
  • Collaborate on complex interactions early
  • Review implementations together
  • Iterate based on technical constraints

Testing Together

  • Test implementations across devices and browsers
  • Verify accessibility with screen readers
  • Check keyboard navigation flows
  • Test with real content and edge cases
  • Validate responsive behavior
View developer guide →

Resources

Questions or Feedback?

We welcome feedback from designers using the Fidus Design System. If you have questions, suggestions, or want to contribute to the design system, please reach out.

Learn how to contribute →