Service · 02 / Case: Officiti
Design Systems.
Build scalable design systems that ensure consistency across all touchpoints.
Below is a complete, working design system for Officiti, a B2B platform for sharing and booking workspace. It starts from the six colors and Roboto type scale in the original case study, then fixes accessibility gaps and adds tokens, components and patterns based on established UX laws and WCAG 2.2.
- Version
- 1.0
- Platforms
- iOS · Android · Web
- Typeface
- Roboto
- Base grid
- 4 pt
- Standard
- WCAG 2.2 AA
01 · Principles
Six rules every decision is tested against.
Officiti serves working professionals who book desks, rooms and visitors on the go, often one-handed and in a hurry. These principles turn established UX research into constraints that the components below obey.
01
Clear before clever
Every element earns its place. Plain labels, generous space and one focal point per screen.
Aesthetic-Usability · Minimalist design02
Fewer choices, faster decisions
Break booking into short steps and reveal detail progressively. Keep menus to five items or fewer.
Hick's Law · Miller's Law03
Within reach
Primary actions live in the thumb zone with targets of at least 48 px and 8 px between them.
Fitts's Law04
Familiar patterns
Use platform conventions for navigation, forms and pickers so nobody has to learn Officiti first.
Jakob's Law · Consistency05
Always show status
Respond within 400 ms, show progress for anything longer, and confirm every result in words.
Doherty Threshold · Visibility of status06
Accessible by default
Contrast, focus, labels and touch size are built into each token and component, not added later.
WCAG 2.2 AA · Inclusive design02 · Foundations · Color
Same brand, accessible in use.
The original style guide defined six colors. They are kept as the brand identity. Testing them against WCAG showed that several cannot carry text or white labels, so each gets a darker functional variant for text and controls.
Brand colors
Blue#5D6DFF
Red#E8553E
Amber#FFAE02
Ink#2D2D2D
Gray#BDBDBD
Green#89C053
Use brand colors for illustration, highlights, large graphics and date tiles. Use the functional scales below for text, icons and controls.
Functional scales
Primary / action
50#EEF0FF
100#E0E4FF
200#C4CBFF
300#A3ADFF
400#8290FF
500 · brand#5D6DFF
600 · action#4351E8
700 · hover#3A46D1
800 · pressed#2F3AB5
900#232C8C
Danger
50#FDECE8
100#FAD3CB
500 · brand#E8553E
600#C83E2A
700 · text#B5301E
800#8F2415
Success
50#EAF5DD
100#D5EBBB
500 · brand#89C053
600#3F7D1E
700 · text#2F6014
Warning
50#FFF4D6
100#FFE7A8
500 · brand#FFAE02
800 · text#7A5200
Neutral
0#FFFFFF
50#FAFAFA
100#F5F5F5
200#EBEBEB
300#D9D9D9
400 · brand#BDBDBD
500 · border#8A8A8A
600 · muted#6B6B6B
700 · body 2#5C5C5C
800#424242
900 · ink#2D2D2D
What changed from the case study, and why
| Use | Was | Now | Reason |
|---|---|---|---|
| Buttons, links | #5D6DFF | #4351E8 (action-600) | White text on #5D6DFF is 4.12:1, below the 4.5:1 minimum for 14 px text. |
| Error text, destructive | #E8553E | #B5301E text, #C83E2A fill | #E8553E on white is 3.62:1. The darker steps reach 6.17:1 and 5.03:1. |
| Secondary and placeholder text | #BDBDBD | #5C5C5C / #6B6B6B | #BDBDBD on white is 1.88:1 and was hard to read in ticket details. |
| Input borders | Light gray fill only | #8A8A8A 1.5 px border | Controls need 3:1 against the background to be found (WCAG 1.4.11). |
| Text on amber and green | White | Ink #2D2D2D | White on #FFAE02 is 1.86:1 and on #89C053 is 2.16:1. Ink reaches 7.42:1 and 6.38:1. |
| Status meaning | Color only | Color + icon + word | Color alone fails WCAG 1.4.1 and excludes color-blind users. |
Contrast matrix (calculated live)
Normal text needs 4.5:1, large text and UI components 3:1, and AAA text 7:1.
| Pair | Sample | Ratio | AA text | AA large / UI | AAA text |
|---|---|---|---|---|---|
03 · Foundations · Typography
Roboto, tuned for small screens.
Roboto stays as the single typeface. It is designed for mobile, has excellent numerals for times and dates, and ships in every weight the app needs. The original scale is kept and completed, with one change: the 10 px sizes are raised to 11 px because text under 11 px is hard to read on phones.
Aa
Roboto
ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 0123456789
Weights: Regular 400 · Medium 500 · Bold 700. The original "Semibold" maps to Medium 500, the closest Roboto weight.
Display
28 / 36 · Bold
28 / 36 · Bold
Welcome back, Saagar
Title
20 / 28 · Bold
20 / 28 · Bold
Create a meeting
Header
16 / 24 · Bold
16 / 24 · Bold
The spectacle before us was indeed sublime.
Subheader
14 / 20 · Medium
14 / 20 · Medium
The spectacle before us was indeed sublime.
Body / Button
14 / 20 · Regular, Medium
14 / 20 · Regular, Medium
The spectacle before us was indeed sublime.
Label
12 / 16 · Bold
12 / 16 · Bold
The spectacle before us was indeed sublime.
Caption
12 / 16 · Regular
12 / 16 · Regular
The spectacle before us was indeed sublime.
Micro
11 / 14 · Medium (was 10)
11 / 14 · Medium (was 10)
The spectacle before us was indeed sublime.
04 · Foundations · Space, shape, elevation
One 4-point grid, everywhere.
Spacing scale
space-1 · 4
space-2 · 8
space-3 · 12
space-4 · 16
space-5 · 20
space-6 · 24
space-8 · 32
space-10 · 40
space-12 · 48
space-16 · 64
Related items sit closer than unrelated ones (Law of Proximity). Use 8 inside a component, 16 between fields, 24 to 32 between groups.
Touch target
Interactive area is at least 48 × 48 px, even when the visible icon is 24 px. Keep at least 8 px between neighboring targets to prevent mis-taps (Fitts's Law, WCAG 2.5.8).
Radius
sm · 4
buttons, inputs
buttons, inputs
md · 8
cards
cards
lg · 16
sheets
sheets
full
avatars, FAB
avatars, FAB
Elevation
elev-1
cards, inputs
cards, inputs
elev-2
sticky bars, menus
sticky bars, menus
elev-3
dialogs, FAB, toast
dialogs, FAB, toast
05 · Foundations · Iconography
One icon family, drawn on a 24 px grid.
The original set (wifi, visitors, tickets, alerts, notifications, attachments, home, calendar, dropdown, more, support, lock, back) is redrawn as a consistent outline family with a 2 px stroke and round caps, and completed with the icons needed for status, search and scanning.
06 · Foundations · Layout grid
Mobile first, three breakpoints.
| Breakpoint | Width | Columns | Margin | Gutter |
|---|---|---|---|---|
| Mobile | 360 to 767 | 4 | 16 | 16 |
| Tablet | 768 to 1199 | 8 | 24 | 24 |
| Desktop web | 1200 and up | 12, max width 1200 | 32 | 24 |
07 · Foundations · Motion
Fast enough to feel instant.
| Token | Time | Use |
|---|---|---|
| motion-fast | 100 ms | Press, toggle, hover |
| motion-base | 200 ms | Fields, chips, menus |
| motion-slow | 300 ms | Sheets, dialogs, toasts |
Easing is cubic-bezier(.2, 0, 0, 1): quick start, soft landing.
Standard easing
08 · Components
Every component, live and interactive.
These are real, working components built with the tokens above. Tab through them, press them and read the specs. Each states the UX rule behind it.
Buttons
Anatomy. 48 px high on mobile (40 and 32 for dense web tables), 24 px side padding, 4 px radius, label 14/20 Medium.
Hierarchy. One primary button per screen so the main action stands out (Von Restorff). Secondary for alternatives, text for low-risk dismissals.
Labels. Verb plus object: "Book meeting room", never "Submit" or "OK".
States. Default, hover, pressed, focus (3 px ring), disabled, loading. Loading keeps the label and sets
aria-busy.Placement. On mobile, the primary action is full width and anchored at the bottom, inside the thumb zone.
Form fields
Keep it short. Attendees see this in their invite.
States
Default
Focus
Filled
Enter a 10-digit mobile number, for example 9876543210.
Disabled
Labels above, always visible. Placeholders disappear and are low contrast, so they never replace a label (recognition over recall).
Optional, not required. Mark the few optional fields instead of starring most fields. Ask only what is needed (Hick's Law).
Errors. Inline, below the field, with an icon, red text and a fix: "Enter a 10-digit mobile number". Validate on blur, not on every key press.
Specs. 48 px high, 1.5 px #8A8A8A border (3.45:1), 4 px radius, 12 px inside padding, focus ring in action color.
Input help. Use native time and date pickers, autocomplete and correct keyboard types so people type less (Jakob's Law).
Selection controls
Select days
My tickets
Hit area. Each label row is 48 px high, so the entire row is tappable, not only the 22 px box.
Selected state. Filled background plus a checkmark or dot, so it is clear without color. Switches also change their label wording where possible.
Day chips. 40 px circles with 8 px gaps and full-day names for screen readers. Segmented control uses ink (#2D2D2D) for the active tab, as in the original design.
Cards and status
20Dec
Officiti App Demo
SSMMAK+2
Upcoming
22Dec
Wi-Fi not connecting
Resolved
23Dec
Projector needs a cable
Pending
22Dec
Air conditioning too cold
Not resolved
Date tile and status colors
| State | Tile | Text on tile |
|---|---|---|
| Upcoming / info | action-600 | White · 5.86:1 |
| Resolved | green-500 | Ink · 6.38:1 |
| Pending | amber-500 | Ink · 7.42:1 |
| Not resolved | danger-600 | White · 5.03:1 |
Never color alone. Every status pairs its color with an icon and a word, so it is readable in grayscale and by screen readers.
Cards. 8 px radius, 16 px padding, elevation 1. The whole card is one tap target when it opens a detail page.
Hierarchy inside. Title 16 Bold, meta 12 Regular, status 12 Medium. Related facts stay together (Law of Common Region).
Navigation
Bottom tab bar. Four destinations plus a raised scan button. Five items is the upper limit for one-thumb reach and quick decisions (Hick's and Miller's laws).
Scan is always reachable. Scanning a QR code at the door is the most time-critical task, so it sits at the center of the thumb zone in ink (#2D2D2D) and stands out from everything else (Von Restorff, Fitts).
Active tab. Darker color and Bold label. Labels are always shown, at 11/14 Medium.
Top bar. 56 px, back arrow on the left with a 48 px target, centered title. The back arrow always goes to the previous screen (user control and freedom).
Consistent help. Support stays in the same position on every screen (WCAG 3.2.6).
Accessible names. Icon-only controls carry labels such as "Scan QR code" and "Go back".
Feedback and status
Visitors need approval
Guests added after 6 pm are approved by the front desk.
Meeting booked
Conference call room, 22 Dec, 1:00 pm to 3:00 pm.
Room fills up fast
Only 1 meeting room is left for this time.
This time is taken
Board room is booked 1 to 3 pm. Choose another time or room.
Meeting cancelled
No meetings today
Book a room for a call or a catch-up with your team.
Loading skeleton
Progress, step 2 of 3
What
When
Who
Alerts. Icon, bold title and one sentence. The message says what happened and what to do next, in plain language.
Toasts. Confirm reversible actions and offer Undo, staying at least 5 seconds so they can be read and used. Critical errors use inline alerts, not toasts.
Empty states. Explain why it is empty and give the next action, instead of leaving a blank screen.
Skeletons. Shown after 400 ms of waiting. They keep the layout stable and feel faster than a spinner (Doherty Threshold).
Dialogs
Use sparingly. Dialogs interrupt. Use them only for destructive or irreversible actions (error prevention).
Clear choices. Buttons repeat the action in words ("Cancel meeting" and "Keep meeting"), never "Yes" and "No". The safe option gets initial focus.
Behavior. Traps focus, closes with Escape, returns focus to the trigger, and dims the page behind.
09 · Patterns
Components combined into real journeys.
Book a room in three short steps
The original create-meeting screen shows every field at once. Splitting it into three steps lowers the number of decisions on screen (Hick's Law), keeps chunks small (Miller's Law) and shows progress, which encourages completion (goal-gradient effect).
What
When
Who
What
When
Who
Select days
From
To
What
When
Who
Ticket status system
| State | Tile | Icon + word | What it means | Next action |
|---|---|---|---|---|
| Pending | 23 | Pending | Received, waiting for the workspace team. | View details, add a note |
| Resolved | 22 | Resolved | The team marked it done. | Confirm it works or reopen |
| Not resolved | 22 | Not resolved | Member says the problem remains. | Escalate to support |
Visitor access with a QR code
- 1. Add visitor. Name, email, date, time and purpose. Fields already known are prefilled (WCAG 3.3.7, no redundant entry).
- 2. Share the QR code. Visitor receives a code with name, date and time window. It carries a lock icon and expiry so it is clear it is private.
- 3. Scan at the door. The host or front desk scans from the always-visible scan button.
- 4. Check-in confirmed. A clear success state names the visitor and host and closes the loop (Peak-End rule).
Private access code
Saagar Shrestha
Empty, loading, error and success
Empty"No meetings today. Book a room for a call or a catch-up." Explains and offers the next action.
LoadingSkeleton that matches the final layout, shown after 400 ms. No blank screens.
Error"Board room is booked 1 to 3 pm. Choose another time or room." What happened and how to fix it.
Success"Meeting booked. Conference call room, 22 Dec, 1:00 pm." Name the result and offer to add it to the calendar.
Avoid"Nothing here." A dead end with no direction.
AvoidA spinner alone on a white screen for several seconds.
Avoid"Error 409" or "Something went wrong." Blames nobody and helps nobody.
Avoid"Success" with no detail, or a message that disappears in one second.
Writing for the interface
DoUse plain words and active voice: "Book meeting room", "Add visitor". Sentence case. Numerals for numbers and clear dates such as "22 Dec, 1:00 pm".
Don'tUse jargon or vague labels: "Submit", "Proceed", "Utilize", "Ticket ID 0x2F". Never shout in capitals or use only "Yes" and "No" in dialogs.
10 · UX laws map
Where each law shapes the system.
| Law or heuristic | What it says | How Officiti applies it |
|---|---|---|
| Hick's Law | More options mean slower decisions. | Five-item tab bar, three-step booking, one primary button per screen. |
| Miller's Law | Working memory holds a limited number of items. | Forms grouped into short chunks. Ticket details split into labeled sections. |
| Fitts's Law | Bigger, closer targets are faster to hit. | 48 px targets, 8 px gaps, full-width primary buttons at the bottom, scan button at thumb center. |
| Jakob's Law | Users expect familiar patterns. | Bottom tabs, top-left back arrow, native date and time pickers, labels above fields. |
| Doherty Threshold | Responses under about 400 ms keep flow. | 100 to 300 ms motion, skeletons after 400 ms, instant toast confirmation. |
| Von Restorff Effect | The distinct item is remembered. | Ink scan button and the single filled action button stand out from the rest. |
| Proximity and Common Region | Nearby, enclosed items read as related. | 8, 16, 24 spacing steps and cards that group a meeting's details. |
| Aesthetic-Usability Effect | Attractive interfaces feel easier to use. | Consistent radius, spacing and a restrained palette across all components. |
| Goal-Gradient Effect | People try harder as the goal gets closer. | Step progress bar in the booking flow. |
| Peak-End Rule | Experiences are judged by the peak and the end. | Confirmed booking and confirmed check-in states with clear next actions. |
| Postel's Law | Be liberal in what you accept. | Phone and time inputs accept common formats and normalize them. |
| Visibility of system status | Always tell users what is going on. | Loading, success, error and pending states on every async action. |
| Error prevention and recovery | Stop mistakes, then help fix them. | Confirm dialogs for destructive actions, Undo on toasts, inline fixes in error text. |
| Recognition over recall | Show options instead of asking users to remember. | Visible labels, attendee search with avatars, recent rooms listed first. |
11 · Accessibility
Built to WCAG 2.2 AA.
- Text contrast 4.5:1 (3:1 for large text). Enforced by the functional color scales.
- UI contrast 3:1 for input borders, icons and focus rings (WCAG 1.4.11).
- Target size. 48 px minimum interactive area, well above the 24 px AA requirement (2.5.8).
- Keyboard and switch access. Every action reachable in a logical order, no drag-only interactions (2.1.1, 2.5.7).
- Visible focus. 3 px ring with 2 px offset on every interactive element (2.4.7, 2.4.11).
- Labels and names. Visible labels on fields and accessible names on icon-only buttons (1.3.1, 4.1.2).
- Errors identified in text with an icon and a suggested fix, linked with
aria-describedby(3.3.1, 3.3.3). - Not by color alone. Status uses color, icon and words together (1.4.1).
- Zoom and reflow. Layout works at 200% text size and 320 px width without horizontal scroll (1.4.4, 1.4.10).
- Reduced motion. Animations are removed when the user asks for less motion (2.3.3).
- Consistent help. Support stays in the same place on every screen (3.2.6).
- Easy sign-in. Password managers and paste work, and QR sign-in has an alternative (3.3.8).
- Expiring QR codes. Show the expiry time and allow a refresh, so timing is adjustable (2.2.1).
- Redundant entry. Known details such as company and email are prefilled (3.3.7).
12 · Design tokens
One source of truth, ready to ship.
These are the exact custom properties powering every component on this page. They are read straight from this page's stylesheet, so the code below can never drift from what you see. Map the same names to Figma variables and to platform themes.
13 · Governance
Keeping it consistent as it grows.
Figma library structure
- 0 · Cover and changelog
- 1 · Foundations. Color, type, space, radius, elevation, icons, motion.
- 2 · Components. Variants for state, size and type, built with auto layout.
- 3 · Patterns. Booking, tickets, visitor access, states.
- 4 · Templates. Mobile and web page starters.
Naming
Variables.
color/primary/600, space/4, radius/sm, type/bodyComponents.
Button / Primary / Default, Field / Text / ErrorCode.
--color-* or --primary-* tokens and of-* component classes.Contribution process
- 1. Propose. Describe the user problem and where it appears.
- 2. Check reuse. Can an existing component or variant solve it?
- 3. Design and review. Include all states and pass the accessibility checklist above.
- 4. Document. Add usage, specs, do and don't, and the UX rule it follows.
- 5. Release. Publish with a changelog entry and notify design and engineering.
Versioning
Major. Breaking token or API change.
Minor. New component or variant.
Patch. Bug fix or documentation update.
Deprecation. Mark for one minor release before removal.
Next in the roadmap. Dark theme tokens, a date and time picker, a data table for the web admin, and an empty-state illustration set.