← Selected work/Compass Mining

Case study · B2B SaaS · Bitcoin mining

Designing a digital ecosystem for Bitcoin mining operations

Simplifying complex mining, operations, payments and logistics workflows for 25,000+ miners globally, across a customer dashboard and the internal tools behind it.

Role
UI/UX Designer
Timeline
Feb 2025 – Aug 2026
Scope
Product strategy, UX research, UX/UI design, prototyping, design systems, internal tools
Tools
Figma, Figma Make, Claude, Jira, Adobe Creative Suite
Worked with
Product, Engineering, Operations, Facilities, Finance, Logistics
Compass Mining dashboard showing fleet hashrate, miners online, hosting fees and facility status Hover to pause
The same dashboard on mobile

The problem

A physical business behind a digital product

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

Redesigned six product areas end to end

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

Hide the machinery, keep the decision

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.

25,000+miners managed by customers worldwide
6product areas redesigned across the dashboard
2design systems owned: Retool and Minlog
18 mofrom first workflow map to shipped features

The context

Designing across a physical and digital mining ecosystem

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 values
Location
Texas 4 · Rack B12
Performance
104 TH/s
Uptime
99.2%
Downtime
2h 14m this month
Pool
F2Pool · connected
Repair status
No open repairs
Hardware state
Healthy · 3 of 3 hashboards
Financial
$175.80 / mo hosting

A single customer request can travel through

  1. Customer
  2. Support
  3. Operations
  4. Facility
  5. Technician
  6. Parts
  7. Logistics
  8. Finance

The design challenge

How do you make a highly technical operational system simple enough for customers and efficient enough for internal teams?

My role

From workflow maps to shipped interfaces

I worked across the product lifecycle: understanding problems, mapping workflows, interaction design, prototyping, stakeholder alignment and implementation support.

Product design

Customer dashboard and internal tools

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

Owned two, contributed to two

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.

Retool · ownerMinlog · ownerCustomer DashboardSHAMan

AI in my workflow

Faster exploration, sharper assumptions

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.

Claude Figma Make

Selected product work

Six areas of the Compass ecosystem

Chapter 1 · Miner experience

Making mining performance easier to understand

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.

  1. Q1How consistently is my miner running?Uptime
  2. Q2How much downtime has occurred?Downtime
  3. Q3What caused it?Status + cause
  4. Q4How is performance changing?Hashrate trend
  5. Q5Which pool is it using?Pool info

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.”
Miner details on mobile

Chapter 2 · Marketplace

Helping customers sell miners without downtime

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

Minimum, median and maximum for the model, with the customer's price placed on the range

An aggregated sales view adds recent models sold and their prices, so customers price from the market rather than from memory.

Antminer S19j Pro · 104 TH/s
Illustrative prices · try it
Your listing price

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

Clearer workflows for the miner lifecycle

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

Turning a manual, unpredictable process into a structured workflow

Repairs used to run on email and Zendesk threads between customers, Customer Relations and Remote Operations Command (ROC). It was hard for everyone because:

  • ASIC miners contain many component types and configurations.
  • Repair costs vary by component and diagnosis.
  • Some repairs require shipping equipment to a repair centre.
  • The first diagnosis can change after troubleshooting.
  • Outcomes vary: repaired, needs more work, monitoring, redeployed or unrepairable.
  • So the journey is rarely linear.

Design approach

With Product and ROC, I simplified the experience around three customer-facing groups. Everything that happens operationally maps into one of them.

Customer view

What the customer sees

3 states

Needs review

Waiting on the customer: accept or decline a proposed cost, or choose an option for an unrepairable miner.

Active

Moving through its operational journey, with one status and the dates that matter.

Done

Closed repairs, including successful, declined and unsuccessful outcomes.

Behind the scenes

What happens operationally

11 internal states
Cost estimate readyDiagnosis changedUnrepairable · choose option
DiagnosingShipping to repair centreRepair in progressMonitoringRedeployment
RepairedDeclinedUnsuccessful

The key design decision

Group components into categories customers recognise

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.

Fan 6025 · frontHashboard chain 0APW12 PSUControl board v1.6Fan 6025 · rearHashboard chain 1PSU rail faultXilinx FPGATemp sensor (board)Ethernet moduleHashboard chain 2PSU fanFan connectorSD card / firmware
FansPSUsHashboardsControl boards

Illustrative part names

On mobile

Repairs needing review on mobile
Repair details and cost summary on mobile

3.2 Upgrades

Balancing automation with engineering constraints

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

Automated, efficiency-based evaluation

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 expected

What shipped

A human-in-the-loop workflow

Instead of forcing the original solution through, I redesigned the flow so sales managers make the evaluation, and customers still get a simple offer.

  1. Review an upgrade request Sales
  2. Evaluate the miner by model, health and hashrate Sales
  3. Enter the valuation Sales
  4. Create the upgrade offer Sales
  5. Review and accept the offer in the dashboard Customer

Designing around the constraint removed most of the automated evaluation logic while keeping the customer experience simple.

3.3 Miner swaps

Making an operationally complex exchange understandable

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.

Approving miner swaps on mobile

Chapter 4 · Refer & Earn

Balancing transparency with customer privacy

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.

Refer and Earn page with referral code, totals, how it works and a referrals table

Chapter 5 · Autopay

Making recurring payments easier to manage

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.

Adding a card for Autopay on mobile

Chapter 6 · Repair Coverage

Replacing a declining product with a more relevant one

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.

1At contract renewalOffered at the right moment: last year's repair costs show what coverage would have saved.
Contract renewal modal offering Repair Coverage, using last year's repair costs to show potential savings

Reflections

What this work taught me

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.

Operational products should be designed around decisions.

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.

Software often needs to represent the physical world.

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.

Product design is often about connecting systems.

The highest-value work wasn't simply producing individual screens. It was connecting:

Customer needsBusiness requirementsOperational realitiesTechnical constraintsProduct experiences

That became especially important when designing across customer products and internal operational systems.

Other case studies

More work

I turn ideas into captivating designs

Copyright ©2026 The Wej

Email me

I build scalable design systems, optimize features, design new product from scratch, and more.

Let’s build together!

Email me

I turn ideas into captivating designs

Copyright ©2026 The Wej

Email me

I build scalable design systems, optimize features, design new product from scratch, and more.

Let’s build together!

Email me

I turn ideas into captivating designs

Copyright ©2026 The Wej

Email me

I build scalable design systems, optimize features, design new product from scratch, and more.

Let’s build together!

Email me