One Design Standard for Every Admin Screen
Our platform has dozens of modules, each with list pages, editing forms, settings screens, dashboards and dialogs. If each module were designed independently, people would face a different layout, a different save button and a different way of confirming deletions every time they moved between areas. The platform would feel like a collection of separate tools rather than one product.
To prevent that, we maintain a single admin interface design standard that every new screen and every redesign must follow. Here is what it covers and how we apply it.
A reference module, not just a document
Standards written only in prose are easy to interpret differently. So our standard points to a real reference: a module that was redesigned to the standard and accepted as the model for everything else. Its dashboard, list pages, editing forms, settings, calendar and dialogs show what "done" looks like.
When someone redesigns another module, they compare against the reference, not against their memory of a document.
What the standard requires
Some of the key elements:
- Full use of available width. Content uses the space available instead of sitting in a narrow column on a wide screen.
- Grouped, labeled forms. Related fields are grouped in sections with clear headings and helpful descriptions, rather than one long stack of inputs.
- Sticky save actions. On long forms, the save and create buttons stay visible, so people do not scroll to the bottom to find them.
- Clear confirmations. Dialogs explain what an action will do and whether it can be undone.
- Light and dark modes. Every screen works in both, using shared color tokens rather than one-off colors.
- Keyboard focus. Every interactive element shows a clear focus indicator and can be reached without a mouse.
- Phone layouts. Rows, forms and dialogs adapt to small screens instead of overflowing.
The whole module, not just the front page
A common shortcut in redesigns is to polish the main list page and leave the rest. Our standard counts that as incomplete. A module redesign covers every page in it: internal pages, settings, action dialogs and phone layouts. A beautiful index page that leads to an old-style editing form is still an inconsistent experience.
Work in sections, not in one long page
Many admin areas contain several related pages: a dashboard, lists of records, settings and reports. Our standard groups them behind a clear section menu at the top of the area, so people can move between related pages without hunting through the main navigation. The main navigation stays short and stable, while each area organizes its own pages in a predictable way.
This also helps on phones, where long sidebars are awkward. A compact section menu adapts to a small screen far better than a deep tree of links.
Empty states and errors are part of the design
A screen is not only what it looks like when it is full of data. New accounts see empty lists. Failed actions show errors. Slow actions show progress. Our standard treats those states as part of the design: an empty list explains what belongs there and how to add the first item, errors say what happened and what to do next, and progress is shown honestly rather than with a spinner that never ends. Those moments are often where people decide whether software is trustworthy. You can read more about honest messaging in failing closed.
Shared building blocks
Consistency is easiest when screens share code. Our admin screens use a shared presentation layer and a shared compiled theme, so spacing, typography and colors come from one place. When the shared pieces improve, every screen that uses them improves too.
Some things never change in a redesign
A visual redesign must not quietly change how a module works. Our standard is explicit that redesigns preserve existing fields and workflows, permissions, data boundaries between accounts, file storage, billing behavior and each customer's own public website branding. Styling work is styling work; behavior changes need their own decisions and their own review.
Evidence that it was done
When a module is redesigned, the work includes screenshots from the deployed platform at desktop and phone sizes, in light and dark modes, plus a record of what was covered and any known gaps. That evidence is kept with the module's handoff, so anyone can see the actual result rather than relying on a description.
Plain language on every screen
The standard also covers words. Screens describe what a feature does, what access it needs and what it costs, in plain language. Internal labels, such as project phase numbers or team names, never appear to customers. We expand on that in why customers never see our internal labels.
Frequently asked questions
Why do all VoVo admin screens look similar?
They follow one design standard, so people can move between modules without relearning layouts, buttons and confirmations.
Does a redesign change how a feature works?
No. Redesigns preserve fields, workflows, permissions and data rules. Behavior changes are handled as separate, deliberate decisions.
Do admin screens work on phones?
Yes. The standard requires every screen, including dialogs and forms, to adapt to phone-sized screens.
Comments (0)
No comments yet. Be the first to share your thoughts!