No developer left to figure it out alone

Powerful, but on your own

Macrometa is a cloud platform for building fast, global apps and APIs. It could do a lot, but it showed new users very little of it. There was no real onboarding, the interface wasn’t consistent, and support tickets were piling up on the customer success team. People dropped off, and customers left.

Customers said it in their own words:

The messages, in fullReal emails from customers to our team. Switch between them with the tabs.

AccessDocumentationUpdates

And the first screen after logging in didn’t say what to do next:

What the research showed

Four ways in

I led the research myself:

• Support feedback. With the customer success team, I went through what customers had sent to support and documented the common pain points.
• A first-time walkthrough. I used the product as a brand-new user to see the gaps for myself.
• Interviews and a survey with developers, including Macrometa’s own engineers. Developers made up 70% of the company, which made them a useful first group.
• A competitive analysis of onboarding at Fauna, Hasura and Confluent.

Where we stood

Macrometa had a get-started guide, documentation and tutorials. It had no guided landing page, no walkthrough, no onboarding pointers, no templates, and copy that wasn’t clear. Each competitor had most of these.

What developers told us

123

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1Keep guiding after day one. 58% wanted pointers beyond the first visit, not a one-time tour.
2. 2Ask for less at sign-up. 92% would share an email, but only 25% their organisation’s name or size.
3. 3Docs in either place. Two thirds didn’t mind whether docs lived in the console or on a separate site, so the console links to docs where questions come up.

Three insights

Who it was for

Show the way

The product didn’t need more features. It needed to show developers what it could do, and give them something to start from.

A clearer, consistent interface, and a guided start, so no developer has to figure it out alone.

Four principles followed from that:

Part 1 · A clearer product

With our Head of Design, I redesigned the whole platform’s interface. It was the bigger share of the project, and everything in Part 2 is built on it.

1. A layout that groups the work

PrincipleFind your way

The sidebar went from one flat list to a few groups, and the dashboard became something you can read at a glance.

Before

Eleven all-caps links in one flat list, in a dark, dense interface.

Now

A few groups that open when you need them, with the fabric and region you’re working in at the top.

1The new dashboard

123

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1Grouped, not flat. Activity, Data, Compute, Access and Network open when you need them, instead of eleven links at once.
2. 2Locations by name. Active locations are listed by name next to the map, so you don’t have to read pins.
3. 3Is it working right now? Pulse shows the last ten minutes of traffic at a glance.

2. One system, every screen

PrincipleOne calm system

The same patterns run from the simplest list to the most technical tools: clear headings, plain labels, and actions where you expect them.

Before

Plain tables with small type, and each area looking a little different.

Now

Breadcrumbs, tabs, badges and menus that work the same way everywhere.

1The system at workClick a tab to see each screen and the decisions behind it

Your dataQuery editorManaged keysFunction detail

1234

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1Clear wayfinding. A breadcrumb and four tabs keep a collection’s data, indexes, stream and settings together.
2. 2The numbers first. Document count and storage sit at the top, before the table.
3. 3Actions where you expect them. Import and export sit under the main action.
4. 4Row actions on demand. Move and delete appear on a row only when you ask, so the table stays calm.

1234

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1Code that reads like code. Line numbers and syntax colours make queries easy to scan.
2. 2Two languages, one switch. Switch between C8QL and SQL without leaving the editor.
3. 3Parameters your way. Edit parameters as JSON or as a table.
4. 4Clear next steps. Update, Run Query and Clear Results sit in one row under the editor.

1234

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1Security in one group. Users, API keys, managed keys, secrets and connections sit together under Access.
2. 2Filter, don’t scroll. Search plus service, tenant and fabric filters narrow a long list fast.
3. 3Badges you can scan. Each service has its own badge colour.
4. 4Status at a glance. Enabled, disabled and deleting each have a distinct badge.

1234

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1Copy in one click. The name and resource URL each have a copy button.
2. 2Test before you ship. Test Execution sits next to Versions.
3. 3Which version is live. Active and inactive versions are labelled, so the live one is obvious.
4. 4Every version within reach. Activate, download or delete any version from its menu.

Part 2 · A guided start

I led onboarding and activation: how developers arrive, what they see first, and how they get to something working.

3. A clear way in

PrincipleShow the way

Sign-up became the first place the product explains itself, for people who arrive on their own and for teammates who are invited.

Before

A small login card, with sign-up as a link underneath.

Now

A free account that leads with what you can build, asks for little, and lets you sign up with GitHub or Google.

1Getting inClick a tab to see each way in, and the decisions behind it

Sign upInvited

1234

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1Why it’s worth it, first. The left side says what you can build, and how fast, before asking for anything.
2. 2Only what’s needed. Domain, email and password. Our survey showed most developers will share an email, but few their organisation.
3. 3Sign up with what you use. GitHub and Google skip the form.
4. 4No card needed. Instant access to the playground, with no credit card.

1234

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1Who invited you. The invite names the account you’re joining.
2. 2One button. A single Create an account button, with a plain link as a fallback.
3. 3Help is one reply away. Reply to the email or contact support.
4. 4New here? People who’ve never heard of Macrometa can learn more first.

4. A first visit with a next step

PrincipleShow the way

New users now land on a welcome with a short intro, a video, and three places to start. A survey answer asked for “a brief video of key capabilities”, and the welcome has one. We went through two iterations, each testing the quickest way to a developer’s first win. The first offered three paths: build a collection, start from a blueprint, or talk to us. The second, which we landed on, points to a quickstart guide, developer tools and tutorials.

1The welcome, in two iterationsClick a tab to compare the first and second iteration

First iterationSecond iteration

1234

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1The platform in one line. A short intro says what Macrometa’s network does.
2. 2A video for the curious. A three-and-a-half-minute intro, as a survey answer asked for.
3. 3Three ways to start. Create a collection, start from a blueprint, or get in touch.
4. 4Help, always visible. Support is one link away.

123

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1Three ways to learn. The cards became Quickstart Guide, Developer Tools and Tutorials.
2. 2Code-first, if you prefer. Developer Tools points to the CLI, SDKs and libraries.
3. 3Start to finish. Tutorials are complete exercises for common use cases.

5. Never a blank page

PrincipleStart from something

Creating a collection became a guided path: an empty state that teaches, plain-language choices, and sample datasets to start from. 85% of users adopted templates, because one click added a working sample to whatever they were creating.

Before

A form of required fields in database terms, with only small info icons for help.

Now

Choose a type in plain words, start from a sample dataset in one click, and find the docs right where the question comes up.

1Creating a collectionClick a tab to follow the flow, and see the decisions behind each step

Empty stateChoose a typeSample dataMore samplesName and options

123

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1An empty screen that teaches. A one-line explanation and one clear action, instead of an empty table.
2. 2Learn without leaving. Intro to Collections, Developer Tools and Sample Apps sit right below.
3. 3Docs in the same corner. The docs button sits in the same place on every page.

123

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1Choose by what it does. Each type has a one-line description in plain words.
2. 2Bring the tools you know. Redis and Dynamo modes say they work with the SDKs developers already use.
3. 3Not sure? Learn first. A link explains the types and data models.

12

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1A step, not a dead end. The breadcrumb shows where you are, and the way back.
2. 2Start with realistic data. Samples like e-commerce transactions create a working collection in one click.

1

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1The same pattern for every type. Key-value collections get their own samples.

123

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1Rules before mistakes. Naming rules sit under the field, so errors are avoided, not reported.
2. 2Options, explained. Each option has an info icon that explains it in place.
3. 3Help in context. A link to key-value docs, right where the question comes up.

Developers who stay

I tested key interactions with 15 developers across experience levels before launch. After six months of use, product analytics and the customer success team showed the change:

User satisfaction rose 50%, and sales leads rose 57%. Macrometa made $2M in revenue that year, and better onboarding was part of that story: marketing promoted the new flow to bring people in.

What this project shows about how I work

No developer should have to figure it out alone.