Tyler YoungSenior Director of Design

Systems + Practice

I design operations software for work already in motion

The person opening this product already has work underway. A job is in progress. Another starts at ten. A certification is about to expire. An asset is down somewhere else.

I designed the product around that reality: resume the current task first, carry exceptions into navigation, and keep the people, resources, and workflows surrounding the work within reach.

The product and the component system it was built from are both running now.

  • 1Running product
  • 11Component families
  • 69Documented component states
  • 6Token references

Counted from the currently published build.

The workday

The home screen starts with the shift, not the software

The first screen answers four questions before it asks the user to navigate:

  • What am I doing now?
  • What comes next?
  • How much time remains?
  • Is anything blocking the work?

The summary shows three scheduled jobs, one already in progress, five and a half hours remaining, and one certification gap.

The current job receives the most space. It carries the site, start time, equipment, model, workflow, current step, estimated time, and elapsed time. Its actions are equally direct: continue the workflow, request help, or open the surrounding context. Upcoming jobs retain enough information to prepare without competing with the work already underway.

The hierarchy follows the workday: now, next, and what might stop either one.

atheer-next.fly.dev · homeOpen
Inspect how the page separates the current job from upcoming work while keeping time, progress, certification, and support actions visible.

Operational state

Navigation shows what changed before the user opens it

A conventional sidebar tells the user where features live. This one also tells them where attention is required.

Planning warns that a certification expires tomorrow. Forms reports a skipped safety step. Jobs carries a rework flag and its job number. Sessions identifies two people who need guidance. Assets reports both an asset outage and a rising rework rate.

The user can choose a destination based on the work happening inside it, not only the feature’s name.

  • PlanningLindgren cert expires tomorrow
  • FormsSafety step skipped · #4042
  • JobsRework flagged · #4021
  • SessionsLindgren + Reeves need guidance
  • Assets1 asset down at Meridian
  • AssetsRework rate up 40% this week

Status uses shape, not colour alone

Operational status appears in dense places: navigation, job identifiers, headers, and tables. I assigned each primary state a hollow shape.

  • Blocked
  • At risk
  • On track

The same mark can follow an item through the interface. Shape keeps the states distinguishable in greyscale and at small sizes, while leaving colour available for emphasis rather than meaning.

Sidebar · Home activeLive componentOpen in library
The component accepts the active route, labels, subtitles, icons, and status shapes without changing its structure.

Context

Equipment is a junction, not an inventory row

An equipment record is useful only when it connects the object to the work around it. Each equipment card brings together make, model and year, the people assigned to it, the reference material, and the workflows available.

That relationship model supports both preparation and recovery. A technician can identify the equipment, find the correct document, see who knows it, and open the workflow required to continue.

The content varies substantially. One record has two people, two resources, and one workflow. Another has one person, no resource, and nine workflows. The component has to remain coherent across both.

An equipment record is a junction. The equipment itself carries make, model and year. Three things connect to it: people, who knows or owns it; resources, meaning manuals, specifications and safety information; and workflows, the procedures that act on it.

EquipmentCard · defaultLive componentOpen in library
The default state combines equipment identity with the people, documentation, and workflows surrounding it.
  • Many workflowsEquipmentCard · Storybook
    An equipment card whose workflow list runs to nine procedures, with the make, model and people sections keeping their position above it.The card expands to support a larger procedure set without changing the information hierarchy.
  • No imageEquipmentCard · Storybook
    The same equipment card with no photograph, the title and relationship sections closing the gap rather than leaving an empty frame.Removing imagery does not remove the equipment identity or its operational relationships.
  • Certification attachedJobCard · Storybook
    A job card carrying a certification requirement inline, directly beneath the job details it applies to.Certification appears beside the job it affects rather than in a disconnected administrative area.

Finding guidance

Training and reference material use the same operating model

The Training surface is not organised as a course catalogue. It groups guidance into three columns: digital workflows, which are procedures someone can perform; resources, which are material someone can consult; and people, who can help.

Tabs separate Welcome, Job Aids, SOP, and Onboarding content. Filters switch among alphabetical, recent, and unread views.

The same structure also handles sparse and extreme cases. Storybook documents empty columns, many-item columns, and unusually long item names — not only the balanced default.

  • EmptyTrainingColumn · Storybook
    A Job Aids training column with no items, keeping its heading and dividing rule so the column still occupies its place in the row.An empty category preserves the column structure instead of collapsing the page unexpectedly.
  • Many itemsTrainingColumn · Storybook
    A digital workflows column listing procedures alphabetically from Align Impeller Assembly down past Clean Burner Ports, each on its own ruled row.The component supports a long working list without changing its reading order.
  • Long namesTrainingColumn · Storybook
    A training column whose procedure names wrap onto second and third lines, the rows growing to fit rather than truncating the text.Long procedure and resource names are treated as expected content, not an edge case left to implementation.

The system

The component library documents variation, not just defaults

The published Storybook contains sixty-nine component stories across eleven component families, plus six token references.

The useful number is not the total. It is what those stories cover: active, inactive and unselected navigation; jobs in progress and jobs still upcoming; certification attached to work; equipment with many workflows; equipment without imagery; resources that may or may not exist; empty content groups; long names; different border treatments; and five theme palettes.

These are the states where a component system proves whether it can support a product rather than only reproduce its cleanest screen.

  • NavigationSidebar · PageHeader · SubTabBar
  • WorkJobCard · EquipmentCard · PartCard
  • GuidanceTrainingColumn · IconLinkSection · IconLink
  • System controlsPaletteModal · ContextSparkle

The system was designed around the ways content changes, not around one perfect example.

Tokens

Variation stays inside an approved palette

The design system defines shared values for colour, typography, spacing, radii, borders, and shadows.

Its colour model separates stable base values from thematic ones. Primary text, secondary text, page background, surface, status red, and dividers remain consistent. Five palettes then vary the active-navigation background, image mat, highlight, accent, and link colour.

That allows the interface to change character without changing its hierarchy or inventing values component by component.

  • Base systemTypography · spacing · radii · borders · shadows
  • Stable coloursText · page · surface · status · dividers
  • Theme valuesNavigation · image mat · highlight · accent · links
  • PalettesDefault · Warm · Earth · Slate · Dusk
Design System · ColorsLive token referenceOpen in library
Stable base colours sit above five coordinated theme palettes. Each palette changes the same five semantic roles.
  • Warm selectedPaletteModal · Storybook
    The palette control with Warm selected, showing five named palettes as rows of swatches with the chosen one marked.The palette control applies the selected theme through shared semantic values rather than component-specific overrides.

Traceability

Every reusable component began with a product decision

Each documented component traces to a specific node in the design file. The inventory records where it came from and which properties may vary.

A component was added after the product needed it — not because it might become useful later. That kept the library tied to real screens and gave AI-generated implementation a clear boundary.

The chain ran in one direction, in four stages. A design node carried the approved product decision. That became a component: the reusable implementation and its documented variants. Those variants were published as Storybook states, the conditions it has to survive. The component then ran inside a real workflow in the product. The token system sat alongside all four stages as a shared constraint.

If a component had not appeared in a design, it did not belong in the library. If an approved token did not exist, the implementation was not allowed to invent one.

The library constrained what could be generated because every reusable decision had a source.

Engagement

The same principle shaped the project plan

The engagement itself began with a sequencing decision: which product surface should be built first, which should follow, and which should take the remaining phase.

I turned that decision into a small shared application. The client selected the first two surfaces inside the plan. The choices were saved on the server, so everyone opening the link saw the same sequence. It remains set to the client’s selection: landing page first, context engine second.

The implementation was deliberately small — 73 lines of Flask, one table, and persistent storage. Its purpose was not technical sophistication. It was to put the decision where its consequences were visible.

Result

What the engagement left behind

In ninety days, the engagement produced a running operations product, a published component system, a governed design-to-code workflow, and the decision tool used to sequence the work.

The product shows the operating model. Storybook exposes the components and their variation. The token pages show the boundaries they share.

Together, they make the work inspectable beyond the screenshots on this page. The team carried the system forward.

About the public work

The product and component library are running software produced during the engagement.

The equipment, sites, people, jobs, and operational measurements in the public product are invented. They exist to exercise the interface and its component states; they are not customer data or outcomes.

A second surface from the engagement contains a named end customer and dealer-network data. It has not been sanitised and is deliberately not published.