ServiceNow UI Builder and Workspaces Best Practices

This guide sets out six practices for designing UI Builder workspaces. Each one gives the reason, what good looks like and what to avoid, covering task-focused screens, load speed, accessibility, testing before deployment, governance and monitoring usage over time.

Best Practice 1: Design for Your Users, Not for Perfection

Reason: overly polished, complex UIs are hard to use and expensive to build. Keep designs simple and focused on user needs. Good design is: clear (users understand what to do without instructions), fast (pages load quickly), and accessible (works for users with different abilities). The reason is this improves adoption and reduces support burden.

What good looks like: a workspace for field technicians shows the next job at the top, key details (address, contact), and action buttons (“Start Job”, “Complete Job”) below. No extra fields, no confusing navigation. A technician can work efficiently with one hand while holding a device.

What to avoid: trying to replicate desktop UI on mobile, or cramming too much data into one screen. Use progressive disclosure: show essential info first, details on secondary screens or on-demand.

Best Practice 2: Invest in Performance From Day One

Reason: slow UIs frustrate users and reduce adoption. A workspace that takes 5 seconds to load is acceptable in an office but awful on a mobile device. Performance must be designed in, not added later.

What good looks like: workspaces load quickly. Data fields that may be slow to compute (related records counts, aggregations) are loaded asynchronously after the main UI is ready. Searches and filters return results rapidly. What to avoid: loading all related data upfront, loading data from multiple external systems sequentially (they should load in parallel), or running complex calculations on page load.

Actions to take: profile your workspace (use browser dev tools to time load) and set a target agreed with the team. Test with real data volume. Optimize: add indexes to frequently-queried fields, cache data where possible, and load secondary data asynchronously.

Best Practice 3: Ensure Accessibility for All Users

Reason: accessibility makes your UI usable for people with disabilities (color blindness, vision loss, hearing loss, mobility issues) and also improves usability for everyone (clear labels, logical navigation). It is also a legal requirement (ADA, WCAG standards).

What good looks like: form labels are associated with input fields (not just visual). Color is not the only indicator (use icons or text too). Keyboard navigation works (you can tab through fields and submit forms without a mouse). Focus indicators show which field you are in.

What to avoid: using only colors to show errors or status (red/green color-blind users cannot distinguish), tiny text, images without alt text, autoplay audio or video (users may not be able to turn it off).

Actions to take: follow WCAG 2.1 guidelines (AA level is standard). Test with a screen reader (some users rely on text-to-speech). Ensure color contrast is sufficient (foreground and background colors are different enough). Have real users with disabilities test your UI.

Best Practice 4: Version and Test Before Deploying

Reason: UI changes can break workflows or reduce productivity. A workspace redesign that looked good in dev might confuse users in production. Testing with real users before go-live catches these issues.

What good looks like: you design a new workspace, build it in a dev environment, test it with 3-5 representative users (not developers, actual end users), gather feedback, iterate, then deploy. The process balances thoroughness with velocity. What to avoid: deploying to all users immediately and then learning users hate the new layout. Reverting or re-designing after full rollout is expensive.

Actions to take: use ServiceNow’s dev/test/prod environments. Build in dev, test in test (with a copy of production data), deploy to prod. For major redesigns, do a beta: roll out to a pilot group of users for a week, gather feedback, refine, then full rollout.

Best Practice 5: Establish Governance and Ownership

Reason: without governance, workspaces become inconsistent (different teams design UI differently), duplicative (multiple teams build similar UIs), or orphaned (no one owns them, so they become outdated). Governance ensures quality and prevents waste.

What good looks like: a UI governance board defines standards (naming, design patterns, color palette). Teams build within those guidelines, using shared components (buttons, forms) for consistency. Changes to existing workspaces require approval. Workspaces are inventoried: who owns it, which teams use it, when was it last updated?

What to avoid: letting each team design independently (inconsistent experience), allowing unlimited customization (hard to maintain), or having no clear ownership (workspaces become stale).

Actions to take: establish a design system (shared components and patterns) that teams use. Create a UI governance checklist: before deploying a workspace, verify it follows standards, has been tested, and has an assigned owner. Conduct quarterly reviews: is the workspace still active and maintained?

Best Practice 6: Monitor Usage and Iterate

Reason: users will tell you if a UI is working (by using it) or not (by working around it or complaining). Monitoring usage and gathering feedback lets you continuously improve.

What good looks like: you have analytics on your workspace (how many users, how often, which features are used most). You have a feedback channel (survey, form) where users can report issues or suggest improvements. You respond to feedback: the most requested feature is built into the next update.

What to avoid: building a workspace and assuming it is correct, or ignoring user feedback because you think you know better.

Actions to take: track usage metrics (users per day, features used, error rates). Gather feedback quarterly via survey or feedback form. Review and prioritize feedback. Implement high-value, low-effort changes quickly (improves user perception). Communicate changes to users: “Based on feedback, we added a ‘quick filter’ button to reduce clicks.”

Keep each screen built around one primary task

A screen that tries to be a dashboard, a form and a reporting tool at once often serves none of those well. Pick the single task the main user group performs most often on the screen, and place that task at the top with its data and actions in reach. Secondary material can sit one step away. The test is simple to state: a person who arrives at the screen should know at a glance what to do first.

Bind each component to one named source

When a component reads from several sources at once, the cause of a wrong value becomes hard to find. Give each component one source, name the source after the data it returns, and write down the filter it applies. A reviewer can then trace a number on the screen back to a single query without opening the whole page. Shared sources are fine when several components genuinely need the same data, provided the name makes that shared purpose clear. The dashboard explanation covers how a dashboard combines widgets, which is the reporting side of the same question.

Review contrast and keyboard order during the build

Accessibility problems found at the end of a build are expensive, because the fixes touch layout that has already been approved. Check color contrast on each new color as it is chosen, and tab through every screen once a section is complete. If a control cannot be reached or a status is conveyed by color alone, fix it at that point. Those two checks often catch the issues that users with assistive technology meet first.

Write down the purpose of each workspace before it is built

A short purpose statement is the cheapest governance tool available. It names the group, the task and the decision the screen supports. Future changes can then be judged against that statement, and a request that does not fit it can be declined with a reason rather than debated from scratch. The statement should fit in two sentences, and it should be stored next to the workspace where its owner can update it.

Record what was deliberately left out

Every workspace omits things on purpose: a report that stays in the classic view, a field kept off mobile, a rarely used action removed. Recording those omissions with a reason prevents the same request returning every quarter. A short list in the workspace notes is enough, and it saves a great deal of repeated discussion when a new team member asks why something is missing.

Release changes in small batches

A release that changes one thing is easy to test and easy to reverse. A release that changes many things needs a long test cycle and a long argument about which change caused a fault. Group changes by the screen they affect, release one group at a time, and watch the usage data for a short period before the next group goes out.

A checklist before publishing any change

1. Confirm the change matches the purpose statement for the workspace, or that the statement has been updated first.
2. Check that each new component has one named source and a recorded filter.
3. Run a keyboard pass and a contrast check on every changed screen.
4. Test the change with an account from each affected group, using a realistic amount of data.
5. Note the change, the reason and the reversal steps in the workspace’s change record before publishing.

How the habits show up in practice

Questions teams ask about these habits

Are these habits too much for a small workspace?

The purpose statement and the omissions list take little time. The keyboard and contrast checks take longer, but they are worth doing on a small screen because small screens are often used under pressure. Scale the rest to the size of the change.

Who should enforce the checklist?

The workspace owner, with a second person who did not build the change. Self-review tends to miss the same things the builder missed.

What if a user asks for a feature that contradicts the purpose statement?

Explain the statement, record the request and decide with the owner whether the statement should change. Changing the statement is a legitimate outcome, but it should be a deliberate decision rather than the side effect of a single request.

How often should the purpose statement be reviewed?

When the task changes, when the group changes or when usage data shows people doing something the statement does not describe. A fixed review date is a useful backstop, though the triggers above matter more.

The broader view of who approves changes is in the governance model for these workspaces.