Product · Design
Simple for users. Powerful for administrators.
The design principles and the design system behind the Office Unbound interface concepts: what everyday users see, what administrators see, and the shared components both are built from.
Project status These are design decisions for concepts. They will be revised through usability testing before any interface is built.
Principles
Each screen is checked against these before anything else.
- Familiar first
- Someone who has used Outlook or Microsoft 365 should find mail, the calendar and their files without training: folders on the left, a list, a reading pane, a ribbon-like toolbar only where a document needs one.
- Progressive disclosure
- Common actions are visible; advanced ones are one step away, in a menu or a details panel. Nothing is removed for power users; it is placed where it does not crowd everyone else.
- One clear primary action
- Each view has one obvious next step (New message, New event, Upload), styled as the only primary button on screen.
- No decorative dashboards
- The home view shows what needs the person today: meetings, messages that need a reply, recent files. No charts without a decision behind them, and no metrics without context.
- Administration kept apart
- Everyday navigation holds only everyday destinations. Administration is reached from the app switcher or profile menu, and opens its own console with its own navigation.
- Say what will happen
- Destructive and irreversible actions name their consequence and ask for confirmation. Long-running work (sync, migration, updates) always shows its state and what to do next.
- Accessible by default
- Target WCAG 2.2 AA: text contrast of at least 4.5:1, full keyboard operation, visible focus, labels on every control, respect for reduced-motion settings, no meaning carried by color alone.
The everyday workspace
A compact rail holds the core destinations, in the same order on every screen. On phones it becomes a bottom bar with the five most-used destinations and a More menu.
- Home
- Calendar
- Contacts
- Files
- Documents
- Chat
- Meetings
- Calls
Top bar
Product mark, the current application, one search box across mail, files, people and chat, then help, notifications and the profile menu. The app switcher in the top bar is where administrators find the admin console.
Light and dark
Both modes use the same tokens with different values, so components need no separate dark design. The mode follows the operating system unless the person chooses one. Concepts are drawn in light mode first.
Design system
The tokens and components the concepts are built from. One set serves both the workspace and the administration console, so a table, a dialog or a status label behaves the same everywhere.
Color
- Navy
#14243ATop bar, primary text on light surfaces - Canvas
#FBFAF7Application background - Side
#F4F2EDRail and folder panes - Line
#E3DFD6Dividers and borders - Copper
#A9481FPrimary action, current item, unread - Teal
#2D6A68Links and secondary emphasis - Selection
#E4EBF2Selected rows and items - Success
#2F6E47Healthy, verified, complete - Warning
#8A5A0ENeeds attention, pending - Error
#A3362AFailed, blocked, destructive
Status colors are always paired with an icon or a word, so they are never the only signal.
Type
- Interface
- IBM Plex Sans, 13–15px in dense views such as mail lists, 16px for reading.
- Data and codes
- IBM Plex Mono for record values, IDs, versions and DNS records.
- Weights
- 400 for text, 500 for labels and unread items, 600 for headings. No light weights at small sizes.
Spacing and shape
- Spacing
- A 4px base: 4, 8, 12, 16, 24, 32. Dense lists use 8–12; settings pages use 16–24.
- Radius
- 6px for controls, 8px for panels and windows, full round only for avatars and counts.
- Icons
- One outline set on a 20px grid with a 1.5px stroke, always with a text label or an accessible name.
Components and states
| Component | Variants | States to design |
|---|---|---|
| Navigation | Rail, bottom bar, admin side navigation, breadcrumbs, tabs | Current, hover, focus, badge count |
| Buttons | Primary, secondary, quiet, destructive, icon-only with label | Hover, focus, pressed, disabled, busy |
| Forms | Text, select, toggle, checkbox, radio, search, date and time | Empty, filled, invalid with message, read-only |
| Tables and lists | Message list, file list, admin tables with filters | Selected, unread, sorted, empty, loading |
| Dialogs | Confirmation, form, wizard step | Default, destructive confirmation, error |
| Notifications | Inline message, toast, notification list, banner | Information, success, warning, error |
| Status labels | Health, verification, approval, migration state | OK, pending, needs attention, failed |
| Page states | Empty, loading, error, offline, permission denied | Each with a next step, never a blank panel |
Responsive behavior
Concepts are drawn at 1440×900 for desktop and 390×844 for phones, then checked at the widths in between.
- Wide desktop
- Three panes: folders, list, reading pane or details.
- Laptop and tablet
- Two panes; the folder pane collapses behind a button.
- Phone
- One pane at a time, a bottom bar, touch targets of at least 44px, primary action within thumb reach.
- Admin console
- Tables collapse to labeled cards on narrow screens; destructive actions stay behind a confirmation.
Help test the design
Usability testing with real users will change these concepts. Register to take part when early builds exist.