MBX Flux

The main challenge was translating a highly technical control process into a clear, usable interface — one that could be understood and operated under pressure, with many parameters active at once.

Researchers, engineers and lab technicians working with magnetic field systems need precise, real-time control. They need to see live values, adjust parameters and respond to system states quickly — sometimes while the system is already running. There is little room for confusion.

The interface also had to function within a limited screen area. MBX Flux does not always run full-screen. The layout needed to be compact enough to share the display with other applications, while still giving users a complete picture of the system at a glance.

Before MBX Flux, the system was operated through a console. There was no dedicated graphical interface. Parameters were set through commands, system state was hard to read at a glance, and safety feedback was not structured in a way that supported real-time operation.

The new GUI brought everything into one view: key actions, live values, control modes, system status and safety feedback. Users could now see the full state of the system, make changes directly and respond to warnings — without switching between contexts or interpreting raw console output.

Designing this interface from scratch meant making decisions about information hierarchy, layout density and interaction patterns without an existing visual reference. The closest analogues were HMI and industrial control interfaces — which informed the decision to use a dark theme and compact, information-dense layout.

Rather than organising the layout by feature category, the interface is structured around what users need to act on first. System status and current state are immediately visible. Control modes, parameters and live values are grouped around the operations users perform most frequently.

The layout supports a one-screen control model where nothing is hidden behind navigation. Everything required to operate the system — status, activation, field control, live readbacks and safety indicators — is present on a single view, arranged by operational priority rather than product logic.

This approach reflects how users actually work with the system: they orient quickly, make adjustments and monitor the result. The interface is designed to support that loop without adding friction.

Users adjust values, switch between control modes and monitor the system while it is running. Interactions need to be fast and predictable. In a technical environment where the system is actively operating, a slow or ambiguous interface response is not just inconvenient — it can be costly.

Compact parameter groups, numeric inputs and steppers allow precise value changes without excessive interface friction. Controls remain persistent and accessible regardless of the current system state. Status indicators and live values update in real time, keeping users informed without requiring them to navigate away from the primary control area.

Interaction patterns are consistent and predictable throughout. Users working quickly cannot afford to re-learn where things are or how they behave between sessions.

The system supports several field control modes — including current-based control, field-based control, field and gradient control, and rotating field. Each mode changes which parameters are relevant and how the system behaves.

The goal was not to simplify the system by hiding this complexity, but to organise it so expert users could control it with more clarity, speed and safety.

Mode selection is visible and accessible from the primary control area. Parameter groups adapt to the selected mode, surfacing what is relevant without removing access to the full control set. Users working in one mode do not see irrelevant controls cluttering the interface — but switching is immediate when the workflow requires it.

Safety is central to how MBX Flux communicates. The interface uses a structured feedback hierarchy to surface warnings and critical events at the right level of urgency — without interrupting the workflow when it is not necessary.

Warning states are shown as non-blocking banners. They inform the user without stopping the operation, allowing the user to assess the situation and respond appropriately while remaining in control of the system.

Critical states trigger a modal. This communicates an automatic current cut-off — a system action taken to prevent equipment damage. The modal requires explicit acknowledgement, because the event is not informational: the system has acted, and the user needs to understand why before continuing.

Live current and temperature readings, safety limit indicators and system state visibility are maintained throughout, giving users a continuous read on how the system is behaving.

Gamepad control is an optional advanced interaction mode — useful in specific operational contexts, but not required for every user or every session. Including it within the main control screen would have added complexity for users who do not need it.

The gamepad configuration flow is designed as a separate screen. Users who want to use controller input can select a connected gamepad, choose from presets, create custom mappings and test the configuration before applying it. The flow is self-contained and does not affect the primary interface for users who do not use it.

This approach keeps the main control view clean and focused, while making advanced interaction fully accessible to users who need it.

Each design decision in MBX Flux traces back to a specific operational requirement or constraint. The mapping below shows how the structure of the interface was shaped by the context it needed to serve.

Rather than creating a separate component library or design system from scratch, the interface was shaped directly in Figma Make. Make became the primary source of truth for the UI — allowing rapid iteration, real visual output and a tangible foundation for stakeholder review.

Key screens were extracted from Make for presentation, sign-off and annotation. The developer then used the Make-generated code as a strong starting point for the final UI implementation, which accelerated the build phase and reduced friction between design and development.

AI-assisted prototyping allowed me to explore interface directions faster, validate the structure with the stakeholder and provide a more tangible foundation for development. It also meant the handoff was not limited to static files — the generated code carried the design intent directly into the implementation.

Key screens from the final interface include the main one-screen control view, live field visualisation, field control mode switching, warning and critical state feedback, and the gamepad mapping configuration flow.