THE CHALLENGE
01
Make the brand usable
Translate Acelab’s identity into surfaces, content hierarchy and action patterns that work in everyday product screens.
02
Make decisions reusable
Separate raw values from the roles they serve, so designers can choose by intent rather than remember individual colors.
03
Make behavior explicit
Describe variants, states and platform adaptations clearly enough for design and engineering to work from the same intent.
THE GOAL
Create a unified Acelab experience that teams could consistently design, build and extend.
WHAT CHANGED
A Slab
Brand
Semantic roles
Components & states
Materials Hub
Shared product patterns
Ask Ace
Sources, feedback and recovery
Revit add-in
Adapted to the host workspace
WHAT COMES NEXT
01
Align names
Figma ↔ implementation
02
Clarify usage
Patterns + guidance
03
Review in context
Web + Ask Ace + Revit
THE APPROACH
Practical UI provided a useful starting point. My work was to turn it into Acelab’s product language: keeping reusable building blocks while defining the brand, semantic roles, component guidance and patterns the product needed.
A SLAB / WHAT I SHAPED
Brand & foundations
Acelab colors, typography, spacing and semantic intent.
Components & states
Action hierarchy, variants, feedback and usage guidance.
Product adaptations
Patterns for Materials Hub, Ask Ace and the Revit add-in.
PRACTICAL UI / STARTING POINT
Reusable UI building blocks and an initial library structure.
The key balance was retaining useful structure while making A Slab specific enough for Acelab. One brand could remain recognizable across different tasks and environments.
COLOR ROLE / PRIMARY ACTION
Apply
Aa Shared type scale · spacing rhythm
01 / FOUNDATIONS
Define meaning once.
Shared color, type and spacing roles give components a consistent foundation.
Apply
Cancel
View details →
02 / ACTION HIERARCHY
Make importance visible.
Primary, secondary and quiet actions communicate what to do next.
◌ Searching products
No files found here.
Ace couldn’t read the files.
Try again →
03 / COMPONENT STATES
Design beyond the default.
Loading, empty and interrupted states use the same component language.
LIGHT
✓ Selected
Apply
REVIT / DARK
✓ Selected
Apply
04 / PLATFORM ADAPTATION
Adapt the surface. Keep the intent.
Shared action and selection patterns carry across light, dark and Revit contexts.
Illustrative pattern examples reconstructed from A Slab source screens.
Brand / Light / 1000
#067A4F
Light-mode brand primitive
Brand / Dark / 1000
#8FCEB7
Dark-mode brand primitive
Warm grey / 700
#2E3035
Strong text in the light theme
Inter, with responsive modes
The Figma collection defines Desktop and Mobile values. Heading 2 changes from 32 to 28; paragraph text stays at 16 with a 24 line height.
Aa A shared type language
A shared spacing rhythm
The spacing collection contains both spacing and corner-radius values. The visible scale includes 4, 8, 12, 16, 24 and 32.
4
8
12
16
24
32
Values inspected in the A Slab Figma Drafts file. Examples are rebuilt as editable Framer layers.
A Slab supports one Acelab brand across different contexts. Primitive colors hold the palette; semantic roles describe how those colors are used. Light and dark modes change the mapping while keeping the role understandable.
The palette
176 primitive variables contain the source colors, including Acelab’s brand scale and warm neutrals.
The roles
86 semantic variables organize colors into Text, Stroke, Icon, Fill, Background and Chart, with Light and Dark modes.
SAME ROLE / DIFFERENT THEME MAPPING
LIGHT
Readable content
Warm grey / 700
DARK
Readable content
Base / White
6 collections · 324 variables
176 primitives · 86 semantic colors · 8 theme · 27 spacing · 22 typography · 5 motion.
One file, several kinds of decisions
This is the current Drafts-file inventory. The separate published-library analytics capture uses a different scope.
Designers can choose a role such as Strong text or Focus stroke, then evaluate how it behaves in the relevant mode. The structure makes intent easier to carry into implementation.
We use the 100 naming style, which helped us to make sure that these components help in access accessibility, and for easy scaling up the design system.
SOURCE EXAMPLE / Token names connect design intent to implementation.
The source file groups semantic colors by the element they affect: Text, Stroke, Icon, Fill, Background and Chart. Within those groups, names such as Strong, Weak, Selected, Focus and Disabled communicate purpose instead of exposing only a raw color.
Type / action importance
Primary, Secondary and Tertiary describe the relative importance of an action.
Tone / meaning
Brand, Neutral, Destructive and Inverse adapt that hierarchy to the context.
State / feedback
Default, hover, press, focus and disabled treatments keep the interaction legible as it changes.
Size / density
Size variants let the component fit different layouts while preserving its hierarchy.
IN THE FIGMA FILE
Default → Hover → Press
The component set includes Hover and Press transitions to the corresponding variants. The state model is part of the component definition.
ACCESSIBILITY & QUALITY
This current review combines calculated color checks with an implementation test plan. The aim is to make labels readable, focus visible, errors understandable and component behavior usable beyond a mouse.
FAIL / 1.80:1
White label on mint
Label
An intentionally constructed failure shows why swapping the fill alone is insufficient.
#FFFFFF on #8FCEB7
PASS / 7.34:1
Dark label on mint
Label
Pairing the mint fill with dark text keeps the label readable.
#2E3035 on #8FCEB7
These checks apply verified A Slab palette values to the proposed input specimen. A passing pair is a color result, not a completed accessibility audit.
Body label
#2E3035 / #FFFFFF
13.20:1 · target 4.5:1 · Pass
Helper text
#5E5F61 / #FFFFFF
6.39:1 · target 4.5:1 · Pass
Control boundary
#91908F / #FFFFFF
3.19:1 · target 3:1 · Pass
Focus indicator
#067A4F / #FFFFFF
5.38:1 · target 3:1 · Pass
Error message
#C73A3A / #FFFFFF
5.13:1 · target 4.5:1 · Pass
Error boundary
#D26161 / #FFFFFF
3.73:1 · target 3:1 · Pass
Normal text uses a 4.5:1 target; meaningful control boundaries and focus indicators use 3:1. The error border is an 80% red composited over white.
FOCUS / VISUAL SPECIMEN
Apply
Know where you are
Keep focus visible during keyboard use; test that surrounding content does not hide it.
ERROR / VISUAL SPECIMEN
Project name (required)
Enter a project name
! Enter a project name to continue.
Explain the correction
Identify the field and describe the error in text, with a clear next step.
REFLOW / VISUAL SPECIMEN
Project name for the selected specification
Project A
Let content reflow
Test long labels and enlarged text at 320 CSS px. Preserve essential two-dimensional content where needed.
IMPLEMENTATION CHECKS / NOT YET EXECUTED
What engineering should verify
The visual specs are the starting point. This flow translates them into implementation checks for keyboard use, semantic wiring, responsive behavior, and assistive-technology feedback.
01
start
Navigate
Tab order follows the task flow and every control works without a mouse.
02
check
Name
Inputs have labels, helper text, error text, and invalid state wired together.
03
check
Reflow
The same pattern survives 320px width, larger text, and target-size checks.
04
check
Announce
Progress, success, and error states are exposed without disruptive focus jumps.
What the visual review can show
Color pairs meet the intended thresholds, focus is visibly distinct, and error states include both color and message cues.
→
What implementation must prove
Keyboard behavior, screen-reader relationships, responsive reflow, target sizes, and async status messages still need live testing.
Files and Schedule cards show the same state model in different content: progress, useful results, a meaningful empty state and an interrupted step with recovery.
Clarify the intent
Shared names and component guidance connect the Figma decisions to the implementation discussion.
Specify the behavior
Named states, annotated edge cases and acceptance criteria make the component more than a static screen.
Review in context
The Revit project includes build reviews with E-Verse, connecting design intent to the add-in’s host constraints.
The Revit source screens use dark surfaces, compact mapping rows and mint actions. The integration carries Acelab’s action hierarchy and selection patterns into that context while allowing the presentation to change.
The comparison below is an editable reconstruction from the Revit mapping screens. It illustrates visual adaptation; it does not imply the browser and add-in share a code implementation.
MAINTENANCE & OWNERSHIP
A Slab needs clear ownership after components enter product work. The Revit kit already documents who approves changes, where new foundations belong and how changes are recorded.
PROPOSED WORKFLOW / ACROSS THE SYSTEM
01
Product feedback
Capture
Describe the need
Bring a missing state, repeated pattern or naming mismatch into review.
02
Reuse
Extend
Add
Review
Choose the right change
Check whether to reuse, extend or add, with design and engineering.
03
Default
Focus
Error
Validate
Check it in context
Review states, themes, content and accessibility in the affected environments.
04
Change note
Release
Explain what changed
Update the library and guidance; tell consumers what needs attention.
Feedback from product use feeds the next update.
This diagram proposes a wider operating loop. It is not presented as an already-established Acelab release process.
DOCUMENTED IN THE REVIT KIT
D
E
Named ownership
The kit identifies a design approver and an engineering consumer for implementation.
Foundations first
When a token is missing, the kit directs the change into foundations before component use.
Changelog
A visible change record
The kit asks for every change to be logged on the Changelog page.
View the kit’s working rules ↗
PROPOSED RELEASE HANDOFF
Change
What changed + why
Scope
Affected components + consumers
Owner
Design + engineering review
Evidence
States + checks + usage guidance
Plan the transition
When a change replaces an existing pattern, identify the replacement, explain what consuming teams need to update and agree how the old version will be retired.
Replacement identified
Guidance shared
Old pattern retired
This handoff format is a suggested next step for ongoing maintenance, rather than a historical release record.
ADOPTION & EVIDENCE
The published-library captures show component use in design work. They provide an adoption signal alongside the product examples, while keeping design-library activity separate from customer outcomes.
3
teams
Library overview
18,198
component inserts
Displayed 30-day analytics
1,467
Button inserts
30 days · Button row
0
Button detaches
30 days · Button row
228 library components · 140 variables · 33 styles
Button inventory: 320 variants · 69,183 total instances. Instances are not unique people.
Library overview
30-day analytics
The overview reports 3 teams; the analytics view lists 1 team. No growth baseline is shown. Earlier inventory counts use a different scope and are not combined with this snapshot.
