Complexity isn't the problem. Unstructured complexity is.
Mining operations are inherently complex. The goal isn't always to hide that complexity, but to organize it around what the user is trying to accomplish.
Case study · B2B SaaS · Bitcoin mining
Simplifying complex mining, operations, payments and logistics workflows for 25,000+ miners globally, across a customer dashboard and the internal tools behind it.
The problem
Every customer action, from a repair to a payout, touched facilities, technicians, parts, shipping and finance. The product had grown feature by feature and exposed that complexity to customers.
What I did
Miner insights, marketplace, fleet management (repairs, upgrades, swaps), referrals, autopay and repair coverage, plus the internal tools and design system the operations teams used.
The approach
Group operational states into a few states customers understand, give them the data they need to decide, and design around engineering constraints instead of in spite of them.
The context
Compass Mining operates across Bitcoin mining, data-center infrastructure, facilities management, customer operations, finance and logistics. That makes the product fundamentally different from a typical SaaS product.
A customer might need to manage miners, monitor performance, change mining pools, track repairs, upgrade hardware, understand invoices, manage marketplace listings and track payouts. Behind each of those, internal teams coordinate facilities, technicians, repairs, parts, shipments, hosting operations, revenue and accounts.
The complexity came from the relationships between these systems.
A single miner carries
Illustrative valuesA single customer request can travel through
The design challenge
How do you make a highly technical operational system simple enough for customers and efficient enough for internal teams?
My role
I worked across the product lifecycle: understanding problems, mapping workflows, interaction design, prototyping, stakeholder alignment and implementation support.
Product design
Owned end-to-end design for features used by customers and by the teams operating their fleets, working closely with Product, ROC and Engineering.
Design systems
I owned the Retool and Minlog design system used by Finance, ROC, Sales, Revenue and Account Management, and collaborated with the Principal Designer on the Customer Dashboard and SHAMan systems.
AI in my workflow
I used Claude for ideation, alternative explorations and pressure-testing product assumptions, and Figma Make to prototype interactions and validate concepts before engineering time was spent.
Selected product work
Chapter 1 · Miner experience
Customers often manage equipment hosted thousands of miles away. They need more than an online or offline status.
The experience had collected extra statuses and data over time and felt fragmented, while useful data that already existed technically wasn't surfaced well.
The redesign
I restructured the page around a clear hierarchy: fleet-level hashrate first, then each miner's status, performance and metadata, uptime and downtime, performance trends and pool information. A new miner detail view adds hashrate trends, monthly performance, connectivity and pool data.
From fleet health to one miner in a few clicks: fleet hashrate first, then miners grouped by model, then a detail panel with hosting terms, pool, hashrate trend and monthly uptime.
From“Here is your mining data.”
To“Here is what is happening, why it matters, and what you can investigate or do next.”
Chapter 2 · Marketplace
Selling a hosted miner used to mean moving it out of the facility before listing it elsewhere. The Marketplace MVP let customers list miners that keep hashing until they sell.
The next step was a proper place to manage listings and see past sales.
Then a pricing problem surfaced. Customers anchored their price to what they originally paid, even though miner values fall as more efficient hardware reaches the market.
Market-price guidance
An aggregated sales view adds recent models sold and their prices, so customers price from the market rather than from memory.
21% above the median. Listings priced this high tend to sit longer.
Listing in one flow: choose miners, see the market range for each model, set a price for all or one by one, and review what you'll receive before listing.
Chapter 3 · Fleet management
Fleet Management became the central place for customers to manage miners through their lifecycle: repairs, swaps, upgrades, retirements and contract renewals.
These weren't simple create-and-edit workflows. Each event carried its own operational states, costs, dependencies and teams.
My focus was making these lifecycle events understandable and actionable without exposing operational complexity customers didn't need.
3.1 Repairs
Repairs used to run on email and Zendesk threads between customers, Customer Relations and Remote Operations Command (ROC). It was hard for everyone because:
Design approach
With Product and ROC, I simplified the experience around three customer-facing groups. Everything that happens operationally maps into one of them.
Waiting on the customer: accept or decline a proposed cost, or choose an option for an unrepairable miner.
Moving through its operational journey, with one status and the dates that matter.
Closed repairs, including successful, declined and unsuccessful outcomes.
The key design decision
Rather than exposing every underlying hardware component and operational exception, I grouped repair components into four broad categories. Customers keep what they need to decide on a repair, without implementation-level detail.
Bulk actions and a dedicated repair-invoice experience completed the flow, covering the different payment scenarios a repair can create.
Illustrative part names
On mobile
3.2 Upgrades
Older miners become less economically viable as newer, more efficient models arrive and mining difficulty changes. The upgrade process was manual, with Customer Support, Sales, Data and DevOps all involved.
First design
A model would decide which miners qualified for an upgrade and calculate the offer automatically. I designed both the customer experience and the internal tooling around it.
Engineering review: SQL and evaluation logic far costlier than expectedWhat shipped
Instead of forcing the original solution through, I redesigned the flow so sales managers make the evaluation, and customers still get a simple offer.
Designing around the constraint removed most of the automated evaluation logic while keeping the customer experience simple.
3.3 Miner swaps
A swap replaces a customer's miner with a similar one of similar performance. It's needed when a facility relocation or a repair would otherwise cause downtime. Swaps used to happen through internal processes, including manually changing pool configurations. I designed a customer-facing flow that explains the proposed change and lets customers review it before it's finalised.
Chapter 4 · Refer & Earn
Customers and affiliates earn rewards from successful referrals. The purchase amount matters because it sets the reward.
Showing both the buyer's identity and what they spent raised a real privacy concern. I used pseudonymous identities, so referrers see the purchase and reward they need without seeing who the referred customer is.
Chapter 5 · Autopay
Hosting invoices recur, and late payment means fees. Autopay had drifted from the newer design system and had new requirements to absorb.
I redesigned it in the current product language and made it more flexible: more ways to pay (ACH, debit and credit card), and control over which invoices pay automatically. The first version only covered hosting fees.
Chapter 6 · Repair Coverage
The Protection Plan covered theft, weather, water and fire, risks that mattered early on. Better operations and infrastructure had since reduced them, and adoption declined.
One pain point remained: unexpected repair costs. Rather than maintain a product that no longer converted, we repurposed the idea. Repair Coverage covers eligible repair costs during the coverage period and replaced the legacy plan.
Coverage touched several existing journeys, so it couldn't be a standalone screen. The real challenge was making a new capability feel native to existing workflows.
Reflections
Mining operations are inherently complex. The goal isn't always to hide that complexity, but to organize it around what the user is trying to accomplish.
A dashboard can expose hundreds of data points, but the more useful question is:
What decision does the user need to make with this information?
That principle influenced how I structured both customer-facing dashboards and internal operational tools.
Facilities, containers, racks, miners, parts, shipments, and inventory exist as physical relationships. Good operational software needs to reproduce those relationships in a way that makes sense digitally.
The highest-value work wasn't simply producing individual screens. It was connecting:
That became especially important when designing across customer products and internal operational systems.
Other case studies










