Fleet uptime held by automatic recovery
Moonone is a product I built from zero. The facts and every screen on this page come from the product's own source file, its documentation and the live portal. The research instruments listed below are the ones the project actually ran.
The product
Eight modules, one console.
A cloud platform for monitoring ASIC miners and running mining operations: data centres, hosting providers and mining hotels, from fifty machines to fifty thousand.
Role
Sole designer on the product, end to end
Six years on one platform. I owned every stage below, from the first interview to design QA against production, and no part of it went to another designer.
Team around me1 designerProduct managersEngineersSupportFacility operators
- 01ResearchDesk audit, interviews, shadowing, log analysis
- 02ArchitectureEight modules, their states, the navigation
- 03Design systemTokens, components, patterns
- 04InterfaceEvery screen of the console, from zero
- 05Design QAFigma and production kept in step
Productivity against manual operation
Faster repair from kernel-log analysis
Mining data centres already connected
Real-time monitoring
Hashrate, consumption, temperature and anomalies over the whole fleet as they happen.
Bulk actions
Firmware, reset, reboot and pools applied across tens of thousands of devices at once.
Power scheduling
Schedules per device model, so peak tariff hours cost a plan instead of a night shift.
Task manager
Tasks opened automatically with the fault, the device and its location already filled in.
Kernel-log analysis
System logs read automatically, so a task names the cause rather than the symptom.
Automation
Trigger-based scenarios over fleet events, recovery that runs with nobody on shift.
Staff, roles and audit
Who may do what, and a log of what was actually done, across shifts and client fleets.
Regulatory reporting
The quarterly filing generated from data the platform already holds, not collected by hand.
Research
Five instruments, twelve operators.
Desk audit through to usability testing, on three kinds of site: a data centre with night shifts, a hosting provider invoicing client fleets, and an owner who walks the aisle himself.
Desk research and competitive audit
Semi-structured interviews
On-site shadowing
Alert and kernel-log analysis
Usability tests, two prototype rounds
Screens
Five screens the fleet is run from.
One screen at a time, each with the modal that carries its decision: exported from the product source file, not redrawn for the case.
01 / 05Page
Fleet dashboard
Hashrate against the 24-hour average, a live activity feed, and the whole fleet as one table. Three and a half thousand machines narrowed by state down to a single unit.
- Hashrate 1D / 3D / 1M / 1Y
- Real-time · Avg 24h · Max 24h
- Imported / Unimported
- Active · Lowhash · Overheated · Hanged · Offline
- Sparkline per row
- Pool, worker, uptime, firmware
- Recent activity
02 / 05Page
Task manager
Repair in flight across six columns. Every card carries its index, due date, priority and assignee, so a shift change never loses the thread.
- To do · In progress · On hold
- Review · Blocked · Done
- Index, due date, priority
- Assignee avatar
- Drag between columns
- Empty state per column
- Board / table view
03 / 05Page + modal
Workflow builder
Statuses, transitions, and the fields each transition demands. The operator reshapes the repair process without waiting for a release.
- Canvas of statuses and transitions
- Screen attached per transition
- Field list: required / unique
- Inline new-field form
- Staff, roles, custom fields
- Watchers links and settings
04 / 05Page + popover
Clients
One row per client fleet: machines by state, tasks by kind, bills, and the manager who answers for it. The task bar opens its own breakdown on hover.
- Miners bar by state
- Tasks bar with breakdown
- Basic · Maintenance · Farm
- Service · Logistic
- Bills per client
- Manager and role
- Contact and messenger
05 / 05Page
Facility map
Rooms, racks and shelves drawn as they physically stand. A fault gets an address (room one, rack seven, shelf four) instead of a row number.
- Room → rack → shelf
- Cell colour is device state
- Occupancy 23 / 30 per rack
- Hashrate per rack
- Straight through to the unit
01 / 05
Design system
One Foundations kit under eight modules.
Colour, type, spacing, rhythm, radii, icons and every breakpoint live in a single Foundations library. Each surface the console draws is assembled from it, so a new module arrives looking like the product, and the numbers below are the whole of it.
Colour
#96C79E#E7DB9B#F0B979#E98C86#C9D2DF#3F7BD9
Six roles, and the five fleet states are the only thing allowed to carry hue. A row marker, a status chip and a shelf cell all say Lowhash in the same #E7DB9B.
Typefaces
HashrateFleet overview542.77 Ph/s · 99.7%
One family, Open Sans, in two weights. Headings are 600, body 400, labels 600 uppercase at .12em, and every number is set in the same face with tabular figures, so the hashrate column reads down instead of dancing.
Spacing
A four-point base and seven stops, space-1 through space-7. Nothing sits on a number that is not on the ladder, so a table dense enough for three thousand rows still breathes on a settings page.
Radius
Three steps only (control, card, panel), so nesting never invents a fourth.
Vertical rhythm
One row is 56, compact is 44, the header 44. Everything vertical is a multiple of four, so a table, a board column and a settings form line up without anyone nudging them.
Adaptive
1920144012801024768360
Six widths, and each one is a decision, not a squeeze. The fleet table sheds columns by priority, the sidebar becomes a rail and then a drawer, and the facility map drops to one room per row before it ever asks for a horizontal scroll.
Fleet table
Sparkline cell
Status chip
Bulk toolbar
Filter bar
Task card
Board column
Workflow node
Rack grid cell
Breakdown popover
Form field
Select
Side navigation
Empty state