Enterprise Design System
One system for every way to see a Schedule
Linarc 3.0 unifies four fundamentally different project views — a spreadsheet scheduler, a Gantt, a Kanban board, and a work-breakdown structure — into a single, coherent component language for construction teams.
Role
Product Designer
Timeline
2026 - 3 months
Team
2 designers
Platform
Web · Figma · Tokens
Scheduler · Gantt view — illustrative
W1
W2
W3
W4
W5
W6
W7
W8
W9
W10
W11
W12
Site prep & survey
CP
Foundation pour
CP
Structural steel
CP
MEP rough-in
Envelope & glazing
CP
Interior fit-out
Overview
What Linarc 3.0 set out to fix.
Linarc is a construction-management platform where crews plan, schedule, and track jobsite work. By 2.x, each planning view had drifted into its own visual and interaction dialect — the Gantt, the scheduler grid, and the boards looked and behaved like three different products. 3.0 rebuilt them on one shared foundation so a task, a status, or an assignee means the same thing everywhere.
The problem
Four views, four dialects.
A spreadsheet scheduler, a Gantt, a Kanban board and a WBS tree each carry different data structures — rows, time-bars, cards, and nested nodes — yet users move between them constantly on the same project. When the same task looked and behaved differently in each, people lost trust and re-learned the interface every time they switched. The core design problem: make the shared concepts identical and let only the layout change.
Inconsistent status language
Colors and labels for the same status differed across views, so “done” looked different in the Gantt than on the board.
Divergent interactions
Editing a task took a different gesture in each view — no shared model for select, drag, or inline edit.
Foundations
The layer everything inherits.
Tokens, type, spacing, grid and theming — deliberately kept lean, because in a data-dense product the foundation earns its keep by being invisible and consistent, not expressive. Density scale and a strict 8-px rhythm mattered more here than a big palette.
Density as a first-class token
Row height, padding and font-size shift together via one density setting — critical for fitting long schedules on screen.
Composition
One atom, four contexts.
The clearest proof of a system: a single task component carries the same status dot, name, assignee, and dates everywhere — the four views just re-arrange it. Get this atom right and every template inherits consistency for free.
Critical · W4
JM
Ref 04 · The atom
Status dot, task name, assignee and date form one component with fixed semantics. Below: the same atom rendered natively in each of the four templates — nothing about its meaning changes, only its arrangement.
Scheduler · row
Foundation pour
Structural steel
MEP rough-in
Gantt · bar
Kanban · card
Foundation pour
Structural steel
WBS · node
▸
1.0 Superstructure
└ 1.1
Foundation pour
└ 1.1.1 Rebar set
The templates
Four views.
The hard decisions in each.
Each template is where the system meets a genuinely different data-visualization problem.
Scheduler
Spreadsheet grid for planning
Gantt
Time-bars & dependencies
Kanban
Status flow & swimlanes
WBS
Nested breakdown & roll-ups
5.1 · Template
Scheduler — the spreadsheet
A familiar grid that has to hold hundreds of rows without feeling like a wall of data. The wins here are keyboard-first editing and legible density.
Virtualized rows
Only visible rows render, so a 500-line schedule scrolls at 60fps without layout thrash.
Sticky columns + frozen header
Task name and dates stay pinned while metadata columns scroll horizontally.
Empty & error states
A first-run empty grid invites the first task instead of showing a blank sheet.
5.2 · Template
Gantt — time on a grid
The signature view. Bars, dependencies and the critical path have to stay readable from a one-week zoom to a full-project overview.
Zoom levels: day / week / month
Bar detail and axis labels re-flow per zoom so density stays constant across scales.
Critical path in signal only
Colour is reserved — the critical path is the one thing allowed to use the accent, so it always reads first.
Drag to reschedule
Dragging a bar moves dates and re-draws dependent arrows live, with snap-to-day.
5.3 · Template
Kanban — status flow
The same task as a movable card. The design work is in swimlanes, WIP limits and making drag targets obvious without clutter.
Swimlanes by phase or crew
One toggle re-groups the board without changing the card component itself.
Card = the shared atom
The Kanban card is the same task component from §04, restyled for a vertical stack.
Drop-target affordance
Columns show an insertion line and dim siblings so the drop point is never ambiguous.
5.4 · Template
WBS — the breakdown tree
Nested work packages with roll-ups. The challenge is deep hierarchy that stays scannable, plus totals that aggregate up the tree.
Indentation & guide lines
Consistent indent steps plus subtle guide rails keep depth readable past four levels.
Roll-up aggregation
Parent rows summarise child dates, progress and cost — recalculated on collapse/expand.
Collapse / expand
Whole branches fold with animated height and a persisted expansion state per user.
Governance & impact
Documented and adopted.
A system only counts if teams actually build on it. 3.0 shipped with usage docs, dev handoff specs and a contribution model.
Documentation
Usage guidelines, do/don’t examples and density rules published alongside every component.
Dev handoff
Tokens mapped 1:1 to code, so the Gantt bar in Figma is the Gantt bar in production.
Governance
A lightweight contribution & review model kept the four views from drifting apart again.
@crafted by Thani
Get in touch: thanigaivasan97@gmail.com