Every admin project rebuilds the same layer: sign-in, layout, tables, trees, notifications, settings, empty states and error states. The results differ in colour, spacing and interaction detail, and the cost of keeping them consistent grows with every new page.
We folded that layer into one reusable baseline and released it under the MIT licence: admin-design, the standard admin design and implementation extracted from the Runlume platform frontend.
What it covers
- Theme and semantic tokens: colour goes through semantic utility classes only, with six preset palettes combining with base and theme colours, and light and dark modes following automatically.
- Three app shells: sidebar navigation, top plus sidebar, and top navigation. Sidebar width, radius, page transitions and the order of header actions are all adjustable.
- Nine component pages: basic controls, forms and pickers, data display, feedback and overlays, navigation and flows, metrics and charts, icons, theme and settings, and standard pages. The gallery doubles as documentation and as the acceptance surface.
- Standard page types: dashboard, list, detail, settings, notification centre, sign-in, registration and password recovery.
- Chinese and English out of the box, keyboard access and accessibility switches, plus the same command palette search the docs site uses.
Three entry points
- Landing page and project overview: adesign.runlume.app
- Documentation, including component notes and engineering conventions: adoc.runlume.app
- Live demo with two test accounts that hold different permissions: ago.runlume.app
- Source code and issues: github.com/runlume/admin-design
Who it is for, and where the boundary is
It suits teams building their own admin who do not want to write the interface a second time from scratch: copy the repository, rename the package.json entry, swap the menu and brand assets, and point the sample data at your own API.
It contains the design and interaction layer only: no business APIs, no authentication implementation, no permission model and no business rules. Sample data lives in memory and resets on refresh. Capabilities such as identity, uploads, tree dragging and lazy loading are injected through props, so connecting a real service means replacing the callback rather than editing the component.