ServiceNow UI Builder and Workspaces Requirements Workshop Questions

This workshop guide lists the questions to settle before building UI Builder workspaces. They cover who gets a dedicated workspace, how far users may customise it, interface consistency, navigation, the shared component library, accessibility, and performance and browser support. Each set also names the warning signs to listen for in the answers.

User Interface Strategy and Design Governance

Role Definition and Workspace Structure

The first set of questions focuses on understanding what roles will use ServiceNow and what each role needs to see. Will all IT staff see the same interface, or will incident handlers, problem managers, and change managers each have different workspaces? Will business users see different interfaces than IT staff? How granular should role definition be?

Workspace design should reflect job functions, not just titles. An incident handler needs incident lists, knowledge search, and escalation tools. A change manager needs changes in review, approval workflows, and impact assessment tools. A service catalog user needs catalog items, order history, and status tracking. Each role should have a workspace that surfaces tools they use most frequently and hides tools they do not need.

A related question is whether roles are fixed or flexible. Will users be able to customize their workspace, or are workspaces locked to role definitions? Locked workspaces are consistent and simple to support. Flexible workspaces allow personalization but risk users hiding critical tools and getting lost. A middle ground is: workspaces are role-based (different roles start with different defaults) but users can customize their own view without affecting others.

Another design question is workspace hierarchy. Will there be a default workspace for each user, or multiple workspaces they can switch between? Users who work across multiple functions (an IT manager who also handles vendor relationships) benefit from multiple workspaces. This requires clear navigation and helps users understand which workspace they are in and what tools are available.

The warning sign is too many roles or overlapping roles. If you define thirty roles and users are confused about which role applies to them, role definitions are too granular. Start with broad roles (IT staff, business users, managers) and refine only if specific teams need sufficiently different tools to justify separate workspaces.

Interface Consistency and Design Standards

With multiple customised workspaces, consistency becomes a challenge. Questions about consistency focus on whether there are design standards all workspaces follow, who enforces those standards, and how different workspaces communicate (e.g., if a user navigates from one workspace to another, is the transition clear?). Design standards might cover: color schemes, button placement, navigation patterns, error message format, and icon usage.

A practical approach is: establish a baseline design system with component libraries (buttons, icons, color palettes, text styles). Workspace creators use the library rather than creating custom components. This ensures consistency without requiring extensive review of each workspace. Components should be pre-tested for usability and accessibility.

Navigation patterns deserve special attention. If workspaces have different navigation, users who switch between workspaces get confused. A consistent navigation approach (e.g., always top navigation bar with role selector, always left sidebar with workspace sections) helps users transition smoothly. Similarly, consistent error handling and messaging help users understand what went wrong and how to recover.

Another consistency question is what functionality is exposed where. If the same capability (e.g., creating an incident) exists in multiple workspaces, will users reach it the same way? Duplicating tools in different workspaces creates maintenance burden. Instead, decide whether a tool belongs in a single workspace (incident handler workspace) or if it should be accessible from multiple workspaces.

The warning sign is visual inconsistency across workspaces. If some workspaces use dark themes and others light, some have colored headers and others are plain, some use three-column layouts and others single-column, users perceive them as entirely different systems and get disoriented. Enforce visual consistency through design system enforcement and review.

Navigation and Discoverability

A critical question is how users discover tools and information. Will workspaces have search? Will there be a navigation menu? Breadcrumbs? Tabs? Each approach has trade-offs. Search is powerful but assumes users know what to search for. Navigation menus are predictable but take up space. Breadcrumbs show context but are sometimes confusing.

A related question is onboarding. When a new user joins a workspace, how do they learn about available tools? Will there be guided tours? Help documentation? Training? New users often get lost in unfamiliar interfaces. Built-in guidance reduces initial confusion and accelerates adoption.

Another navigation question is help and support integration. Will each workspace have a help button? Will it link to documentation specific to that workspace? Will it allow users to submit questions or report issues? Good help integration reduces support tickets and improves user satisfaction.

Mobile navigation is often neglected in workspace design. If users will access workspaces on mobile devices, navigation must work on small screens. Small screens do not support complex navigation menus or multiple columns. Simplify mobile workspaces to show only critical tools and information.

The warning sign is navigation menus that are too long or poorly organized. If a navigation menu has twenty items and users cannot find what they need, navigation is failing. Keep menus focused (top eight to ten items) and organized by task rather than alphabetically. Use collapsible sections for less-common options.

Component Library and Reusability

UI Builder allows creating custom components that multiple workspaces can reuse. Questions about components focus on whether reusable components will be created and maintained centrally, or if each workspace builds its own components. Central component libraries ensure consistency and reduce duplication. Workspace-specific components are more flexible but create maintenance overhead.

Common components might include: incident cards, change request forms, approval workflows, dashboard tiles, and navigation patterns. These should be built once with high quality and reused everywhere. Workspace creators should be able to find, understand, and use components easily. Well-organised component libraries with clear documentation accelerate workspace creation.

Another component question is versioning and updates. If a component is used in ten workspaces and the component is updated, do all workspaces automatically get the update? Do they continue using the old version? Automatic updates are risky (updates could break something). Versioning allows workspaces to opt-in to updates when they are ready. However, versioning adds complexity.

Custom components built by workspace creators should be contributed back to the library if they are generally useful. This requires discipline and review. Encourage reuse by highlighting popular components and making it easy to contribute.

The warning sign is component sprawl. If there are two hundred components and no one knows which one to use, components are too granular or poorly organized. Consolidate related components, retire unused components, and ensure components are well-documented and easy to discover.

Accessibility and Inclusive Design

Questions about accessibility focus on whether workspaces meet standards for users with visual, motor, or cognitive disabilities. Will workspaces be keyboard navigable? Will they support screen readers? Will colors have sufficient contrast? Will text be resizable? Accessibility is not just about compliance; it expands who can use ServiceNow effectively.

Accessibility requirements should be non-negotiable for all workspaces. Use the design system to enforce accessibility automatically (components are built to be accessible). Review workspaces for accessibility issues before release. Test with actual users who have disabilities if possible.

Another inclusive design question is multi-language support. Will workspaces display in multiple languages? Will icons and colors mean the same thing across cultures? Will date and time formats be localized? For global organisations, these considerations are important.

Mobile responsiveness is also part of inclusive design. Users with limited ability to use mice or keyboards benefit from touch interfaces and large targets. Design workspaces that work on mobile without requiring a mouse.

The warning sign is accessibility added late or overlooked. Accessible design from the beginning is cheaper than retrofitting accessibility later. Include accessibility reviews in the design and testing process from the start.

Performance and Browser Compatibility

Questions about performance focus on load time, responsiveness, and browser support. Will workspaces load within the target set for them? Will they remain responsive when handling large datasets? Will they work in older browsers, or only modern ones? Performance problems frustrate users and drive adoption down.

Custom components and heavy customisation can hurt performance. Minimise unnecessary animations and visual effects. Load data asynchronously so the workspace is interactive even if some data is still loading. Test performance on realistic user networks (not just office broadband).

Browser compatibility is often underestimated. Some organisations require supporting Internet Explorer (which has complex compatibility quirks). Others support only modern Chrome and Firefox. Clarify expectations and test accordingly. Progressive enhancement (functionality works in older browsers, but some features work only in modern browsers) is a practical approach.

The warning sign is performance that degrades as workspaces become more complex. Regular performance testing helps catch issues early. Set performance targets and measure against them. Allocate time for performance optimisation during development, not as an afterthought.