Overview
- The problem
- The admin console needs to accommodate different cloud tiers, service combinations, namespaces, and data states while remaining a coherent product.
- My contribution
- I created the AccelByte library’s foundations, custom components, responsive patterns, and documentation utilities, using Ant Design as the underlying framework.
- The outcome
- A tokenized Figma library with theme and density modes, product-specific component families, reusable page structures, and design-delivery templates.
Problem
The library spans product tiers, namespaces, theme and density choices, data states, responsive compositions, and handoff templates. These contexts shaped the system requirements.
My Role
- Company / product context
- AccelByte · Admin-console design system
- Users
- Designers and engineers working on AccelByte’s console, and the game teams who navigate and manage its services.
- My role & scope
- I created the AccelByte library’s foundations, custom components, responsive patterns, and documentation utilities, using Ant Design as the underlying framework.
- Evidence available
- Original library exports and public documentation. The source Figma library remains private.
Process
I explored theme and density modes, responsive headers, navigation contexts, and populated versus empty data patterns to establish a consistent component model.
Foundations that carry through the system
I organized the foundation into color, dimension, typography, and component collections. The structure carries Ant Design’s token model into the AccelByte library, with brand values and product-specific compositions layered on top.
Light and Dark are color modes. Default and Compact are separate dimension and typography modes. Keeping these decisions separate allows color theme and density to be considered independently, instead of creating a duplicate library for every combination.
Selected values from the Figma foundation| Token | Light / Default | Dark / Compact |
|---|
AccelBlue/6 | #0b6cff | #1f79ff |
|---|
fontFamily | Roboto | SF Pro Text |
|---|
fontSize | 14px | 12px |
|---|
controlHeight | 32px | 28px |
|---|
AccelBlue/6 supplies the primary brand role, which supplies the Button component’s primary color. This alias chain connects the foundation to the component through an explicit semantic role.
- Colors/Base/AccelBlue/6
- Colors/Brand/Primary/colorPrimary
- Components/Button/Global/colorPrimary
Default and Compact also require a deliberate typography decision. The source currently uses Roboto in Default and SF Pro Text in Compact. A handoff should preserve that choice explicitly or reconcile it with the intended platform stack; density is more than reducing every number.
Key Decisions
I built on Ant Design rather than presenting its underlying primitives as my invention. Product-specific navigation and data behavior needed additional patterns. Theme and density are separate decisions so a denser interface does not require a different product language.
Key design decisions
Connect the foundation to the component
Primitive colors feed semantic roles and component tokens through aliases. A theme change can therefore reach the controls that use those values.
Trace a token relationshipModel product context explicitly
Cloud tier, namespace, service combination, and collapsed state are component properties. The navigation family makes those differences inspectable.
Compare the navigation patternsMake exceptions reusable
Populated, empty, and no-results table states share one family. Documentation checklists also bring responsive, feedback, and error scenarios into the design process.
Explore the table states
Final Solution
Foundations connect to configurable product components, complete page structures, exception states, and documentation utilities. Original library exports below show both the reusable model and its intended product context.
Navigation that understands product context
The sidebar family models Foundation, Shared Cloud, and Private Cloud separately. Within those families, properties cover the studio or publisher context, game namespaces, AGS/AMS availability, submenus, and expanded or collapsed presentation.
Original sidebar variants. Their differences are expressed through the component model.The reusable pieces include menu items, namespace selectors, status tags, tooltips, and submenu groups. Default, hover, and selected states are defined at that smaller level, then composed into the tier-specific sidebars. This gives the library a vocabulary for context, rather than a collection of unrelated navigation screens.
- Namespace selection distinguishes where an action takes place.
- Service combinations determine which destinations appear.
- Collapsed variants preserve an alternate navigation presentation.
- Tags distinguish New, Beta, Early Access, and Coming Soon states.
A page structure that adapts
The Page Header brings breadcrumbs, title, status, identifiers, account context, metadata, overview controls, and tabs into one reusable composition. Boolean properties expose optional content, while Desktop, Tablet, and Mobile variants handle the available width.
Switch between the original Figma exports. Each image contains the three responsive variants.On narrower layouts, context moves into additional rows and breadcrumbs contract. The library therefore specifies a change in information arrangement, not simply a smaller desktop header. A related Sections family supports Details or Data Table content, with optional tabs and alerts.
Data patterns beyond the populated table
The custom Data Table combines search, filters, column controls, bulk actions, the table itself, and pagination. Its state model includes Default, Empty, and No Search Results, so teams can inspect how the same surface responds to different data conditions.
Populated, empty, and no-results variants from the same table family.Custom Search adds search and date modes with default and active states. The custom Date Picker composes preset ranges and a calendar, with default, hover, and selected preset cells. These patterns belong to the same task family: narrowing a large body of information into a usable view.
The custom date-picker composition includes reusable range presets.Empty-state illustrations cover situations including no access, network problems, pending transactions, server errors, and search without results. The illustrations provide a shared visual vocabulary; the surrounding copy and recovery action still need to explain the specific situation.
Documentation is part of the system
I created documentation utilities alongside the product components: page and section titles, design links, ticket notes, status variants, item explanations, and a design checklist. These artifacts give design work a repeatable structure for review and handoff.
The source checklist makes expected design coverage visible before handoff.The checklist asks for positive and negative cases, popups, success and error feedback, empty states, permission and network failures, mobile views, reviewed copy, and optimized assets. Those are expectations encoded in the design process, not evidence that every project completed each check.
The ticket-note template provides a place for change descriptions and merge status. Design-link templates distinguish master work, dependencies, and archived designs. Together, they make it easier to explain what a viewer is looking at and where the current work lives.
Outcomes
I delivered an authored Figma library and supporting templates for documentation, design status, and handoff.
Evidence & limitations
The case study documents my design deliverables. Adoption numbers, shipped implementation, and measured efficiency gains have not been established here. Ant Design and the Ant Design System for Figma are credited as the foundation.
A comprehensive library does not by itself prove that teams use it consistently or that code matches it.
What I would measure next
- Use and detachment of the custom components across active product files.
- Design and engineering effort required to add a new page or state.
- Consistency of tokens and component behavior between Figma and implementation.
- Accessibility and task completion across desktop, mobile, and dense data views.
Learnings
- What worked in the design
- Context, states, and documentation are reusable parts of the system, not just visual styling.
- What I would change next
- Audit live instances and detachments, compare Figma to implementation, and measure the effort required to add a real page or state.
Delivery and reflection
The delivered design work connects foundations, product-specific component families, responsive compositions, and documentation within one library. My central design decision was to make context and state reusable alongside appearance.
- A useful admin-system component needs a model for context, optional content, and exceptions.
- Color theme and interface density should be explicit, independently inspectable choices.
- A library needs documentation and handoff material alongside its visual parts.
- A component’s value becomes clearer when its use is connected to a complete product workflow.
Maintaining this system means keeping component descriptions useful, checking property combinations, and reviewing how the library behaves in real product files. The visual library is a foundation for that continuing work.
