← All work

Case study · Robotics · Enterprise tooling

A factory line for drones, in the browser.

Brane's Design Factory turns a vehicle request into a buildable spec: requesters describe the mission, engineers assemble compatible parts, and admins keep the teams moving. One system, three very different users.

01 · Context & business problem

Requirements lived in meetings. Builds lived in spreadsheets.

Configuring an unmanned vehicle, from drones to boats to quadrupeds, meant emails, tribal knowledge, and part lists that went stale before the first prototype.

  • Requesters spoke missions, engineers spoke motors. Nothing translated between them.
  • Compatibility was memory. Whether an ESC matched a motor lived in someone's head.
  • Weight budgets broke late. All-up-weight problems surfaced at assembly, the most expensive possible moment.

02 · My role & constraints

UX for three users who never meet.

I designed the end-to-end flows for all three roles: requester, propulsion engineer, and admin, plus the modular design system underneath.

  • The requester knows the mission, not the hardware. The interface had to accept mission language and translate it.
  • The engineer needs constraints enforced, not suggested. A polite warning is not enough when physics is the reviewer.
  • The admin needs teams, permissions, and progress at a glance, without ever touching a spec.
  • The catalog kept growing. Drones first, but the same system had to hold boats, quadrupeds, and submarines without a redesign.
  • Engineering data was the truth source. Every compatibility verdict on screen had to trace back to a real parts database, so the UI could never promise what the workshop could not build.

03 · Discovery

I followed one request from email to airframe.

Before designing anything, I traced how a single vehicle request actually moved through the factory. It was sobering.

  • The request arrived as prose. A paragraph of mission intent that an engineer had to decode into components.
  • The parts list lived in a spreadsheet that forked every time someone saved a copy. Nobody could say which version was current.
  • Compatibility checks happened in heads. Whether an ESC matched a motor depended on who was in the room that day.
  • Weight failures surfaced at assembly, after parts were ordered. The most expensive place to discover a 200 gram problem.

The design brief wrote itself: move every one of those failure points from the workshop into the interface, where fixing them costs a click instead of a part.

04 · Architecture & flows

From mission to machine, one ladder at a time.

The core idea: turn "build me a drone" into a sequence of small, checkable decisions, and never let an incompatible one through.

05 · Key decisions & tradeoffs

Constraints as a feature, not a fence.

Three calls shaped the product. Each one had a real alternative that lost for a reason.

  • Verdicts on part cards, not error modals. The alternative was validating the build at the end. Rejected: late errors are exactly the spreadsheet problem we were replacing.
  • Incompatible parts go quiet, not red. We considered showing everything with error states. Filtering incompatible parts out of view keeps the engineer choosing among winners instead of dodging losers. The tradeoff: an engineer might wonder where a part went, so a filter note says how many were hidden and why.
  • The weight budget travels with the ladder. A summary page at the end would have been simpler to build. Instead the A.U.W table follows every step, because a budget you see only at checkout is a bill, not a budget.
  • Requesters never see part numbers. The questionnaire mirrors their choices back in mission language on the Confirm Specifications rail. The tradeoff is a translation layer we had to maintain, and it was worth it: requesters stopped needing an engineer to fill in a form.

06 · What shipped & what it proves

One system, three experts, zero translation meetings.

Design Factory shipped as Brane's internal requirements-to-build tool. Outcomes stayed inside the factory walls, so I will not dress them in numbers. What the work itself demonstrates:

  • I can design for expertise I do not have. Propulsion engineers accepted verdicts from a screen because the system respected how they actually judge parts.
  • I can make one design system serve opposite temperaments: a guided, friendly questionnaire and a dense, uncompromising build ladder, without either feeling borrowed.
  • I design for the failure case first. The A.U.W banner exists because the most expensive moment in the old process was the one nobody had designed.

07 · What I would do differently

Prototype the weight math first.

The A.U.W reconciliation table became the heart of the product, but it arrived in the second design pass, after engineers kept sketching weight budgets on paper next to the screen. The artifact users improvise is the feature they needed first; I now look for it in week one.