Work Experience About Contact
← Back to work

Coinbase Cloud Admin

A tool that lets account managers resolve customer requests in minutes instead of days.

Role
Designer
Team
Product Manager, Full Stack Engineer
Scope
0→1, internal tool
Status
Shipped, 2022

The problem

Cloud platform wasn't self-serve, so every customer request went through an account manager who then had to find a PM or engineer to actually do it.

Coinbase Cloud has ~30 account managers handling $30B in customer assets. They help customers set up clusters, move from trial to paying, and take care of requests like renaming a cluster, debugging errors or transferring clusters. However, they couldn't execute any of it so requests got passed on to PMs and engineers to run in their terminals. Turnaround time was in days, led to bad CX, and wasted engineering time.

Constraints. This was urgent, so the ask was to ship quickly and not sweat visual design. The app would also be built in Retool, which the company was piloting for internal tools, so the designs had to fit what Retool could do.

Talking to users

The PRD included two actions, transfer and delete but before starting designs for those flows, I first wanted to see the whole request lifecycle.

What info is in a request? How is a cluster searched for? How is the request handed off between people? I interviewed 3 account managers and put together an end to end flow.

  1. SlackRequest lands from the customer
  2. Cloud consoleLook up the customer on the customers page, copy their org ID
  3. Cloud consoleCtrl+F that ID on the all clusters page
  4. Cloud consoleGo through each match to find the right one
  5. JiraFile a ticket with the cluster details
  6. PM or engineerWait for it to be run, hours to days

What came out of it

It turned out finding the right cluster took up most of the time, the actions were easy to perform. And, this wasn't even included in the PRD.

Customers didn't always give the exact cluster details, so searching for a cluster was difficult. Handoff between tools and people meant information got lost and errors crept in. And renaming a cluster came up way more often than transfer or delete, so I spoke with the PM to prioritize adding it.

  1. SlackRequest lands from the customer
  2. Cloud AdminSearch the customer
  3. Cloud AdminFilter down to the cluster
  4. Cloud AdminOpen it
  5. Cloud AdminRename, transfer or delete

Explorations

I tried a few directions for search and tested them with a couple account managers early.

Search by customer, a query builder, and a split search by cluster or customer. Users liked search by customer because it was straightforward and aligned with the information they had to start with.

Exploration one: a single search field for the customer name and a Search button.
Search by customer
Exploration two: a query builder with a search field, a dropdown to pick cluster name, resource ID or customer, and an add a filter button.
Query builder
Exploration three: search for a cluster name on the left, or search for a customer name with an optional protocol filter on the right.
Split search

The solution

Search a customer, filter down to the cluster, take the action. All in one place.

Find cluster

Search a customer by name and you land on their organization.
Clusters are listed with protocol, network, product and status, and every column filters, so narrowing 87 clusters to one takes a couple of clicks.
Open a cluster and you get its details, history and the actions.

Take action on it

Rename
Transfer
Delete

Implementation

Built by an engineer in Retool, which we were piloting for internal tools. I never got permission to use the app he built, so QA happened through screenshots.

He demoed over Google Meet, I took screenshots of all possible states and marked up notes in Figma. Not ideal, but we needed to ship quickly.

Estimated impact

  • Resolution time went from days → minutes.
  • Zero engineering involvement per request, down from a PM and an engineer each time.
  • Faster turnaround, happier customers.