Nine years, one studio: first hire to department director

A map was easy. The mission was not.

It was clear early that the system had to be map-based. The harder problem was defining the core entity — the mission — since every user saw it, and defined it, from a different perspective.

So it got taken apart. Everything anyone called part of a mission was collected, then sorted until it stopped resisting: two kinds of thing, each with its own small set of verbs. That split became the layers menu, the tools rail and the contacts menu — the analysis is the navigation.

Eleven screens, from the core surface to an honest first draft

The full set walks the system from its core surface through the menus and panels that support it, and ends where the process actually ended — on a sketch that was expected to change.

A design system built to hold the complexity

Coloring and styling this system was a challenge on its own — not only because of the amount of detail, but because of the customization required for its many different users. One example: users have five categories for classifying an aircraft, multiplied across every type of force a user might need to view.

The result is a full design system — icon library, components, dark and light variants — built to hold that complexity.

Four questions, one new entity

Research combined user interviews, on-site observations, and analysis of the artifacts officers were already using — their Excel sheets, emails and PowerPoint decks. That surfaced a taxonomy of the existing process, built around Platform and Mission, which I reframed as four questions: What, Who, When, and How-and-where.

The questions resolved into a new taxonomy — Request, Platform, Time, Mission — bound together by a new Reconnaissance event, which also carried the approval chain and captured the officers' dialogue, solving the secondary problems along the way.

The two surfaces, the two roles, and the test that followed

Selected from the full flow: the missions bank and the timeline that bind to it, the map the officer plans on, and — in the design's own annotations — what each of Buttercup's two officer roles actually needed from it.

A calendar with multiple perspectives

Research meant visiting the squadrons, interviewing many users, and learning their Excel sheets and documents directly. It became clear the system to design was a calendar with multiple perspectives: four types of calendar event represented on it, with each screen serving every user but acting as the main workspace for some.

The working surface, and what it opens onto

Eight pages from the v1 flow: the two grids every view resolves into — month and week — the two ways to read a week (staffing, or a Gantt bar), and the panels a day's work actually runs through — a new event, the inbox, the day itself.

A light system, in the color code squadrons already knew

The first stage set the working surface — the Gantt, switchable between day, week and month. The redesign that followed is where the visual system got built: dozens of icons drawn, fonts and colors selected, on a light theme that kept the color code users were already used to — the one piece of the old workflow worth carrying forward.

Twelve screens, and who each one is for

The shipped (v2) generation, walked scale by scale — month, week, staffing, Gantt, day — with the design's own callouts naming which of the six personas each screen is a primary workspace for, and which a secondary one.