MetricWorks: Getting the Scope Right
Data mapping, permissions, and experiment configuration for a marketing intelligence platform.
How do you let a marketer configure a statistically valid experiment without a data scientist in the room?
- Product Design
- UX Flows
- UI
- Design System
- Prototyping
MetricWorks is a marketing intelligence platform for CMOs and growth teams at mobile gaming and app companies. It lets you run experiments across multiple products, channels, and countries simultaneously, then tells you which combinations actually drive revenue. The kind of thing that normally takes a team of data scientists, MetricWorks puts into a dashboard.
- Role
- Product Designer, sole designer
- Timeline
- 12 months
- Team
- CEO, CTO, Software Engineer, Sales Manager (8-person company)
- Tools
- Problem Definition
No designer had ever opened this product
When I touched the product for the first time, the only people who had worked on this were data scientists and software engineers. There wasn’t a design system, component library, or Figma file of what existed.
Every action in the platform defines a boundary
All the structure was working with a hierarchy base of org, app, channels, experiments, and countries. It was important to keep the same structure without breaking anything in the backend or complicating it on the UX side.
- Exploration
I rebuilt the entire existing product in Figma before designing anything new
Every screen, every state, documented as a baseline. Unglamorous, but you can’t improve what you can’t see.
Around 9-10 user flows were mapped beforehand.
- Information Architecture
We defined a multi-tenant setup order to make the process a standard for how to use the platform
The idea was to create a setup of layers that allows a step-by-step order, so the user is never overwhelmed. The process works like this: the user defines the org, then defines its apps and who reaches them, then gets the data clean, runs tests, and scopes by country. Most B2B products with this shape land there because it’s correct.
- Core Flows
These run in the order a customer meets them. Each one narrows the scope the next one operates inside.
User access setup hierarchy.
Once an admin creates an org and an App, he can proceed to add members to manage it based on permissions. In this case, the admin can add members at two levels: org level (he adds members and picks which app those members belong to) and App level (he adds members inside a specific App).
Mapping the data
One frequent issue with clients was data matching. Users come with data with different naming conventions that don't match MetricWorks' data, so we use a system similar to HubSpot's so the user can pair their data with MetricWorks' data by name.
Creating an experiment
Using the master sidebar component, the user can go and create experiments and set them up by creation date, platform, country, channel, and max and min spend (Org, platform store, and Experiment ID aren't changeable for the user and are unique when he is creating the experiment).
Choosing a control group
A user can create what we call synthetic controls: fake or "synthetic" twins of a treated market, built by combining multiple untreated control markets with optimized weights. The user can even add the countries he wants to include in the whitelist and, in the blacklist, those he doesn’t want involved.
After setting up an experiment, the user can navigate faster using the monitor sidebar, which allows him to check the version of the data, experiments, and imports of one app faster.
- Design Decisions
We focused on structuring the design as a hierarchy, always making every setup based on the sidebar, input, and column design.
Just these 3 components are the core tools of the entire system, since every action reacts to them.
- Sidebar
Sidebar component structure
Function Name: Purpose of the setup
Content setup
Save or cancel the process.
Sidebar Variants
They adapt depending on the job
- Input components
We use a single master input that adapts based on the requirement and its states.
Every single area is a variable, so the same component can be adapted multiple times for multiple purposes.
- Columns
All the main business revolves around data; it is key to maintain a waterfall structure.
Changes depend on the hierarchy level.
If the user wants to add a member to an org, he can go to the edit of that org and also the apps where those members will be.
But if he tries to do the same clicking in the edit of any app, he will find the input App disabled (since he’s working at that moment at the second level, in this case, the App level).
Waterfall structure
Edit at the org level.
Edit at the app level.
Edit at the member level.
- Constraints
Time was very limited. Most of the design was made under pressure, with no time for complete research and testing.
We didn’t have time to actually do a complete design cycle; we couldn’t do deep research on other competitors, or testing.
We shipped 3 features every 2 weeks, and we saw the updates in real time.
We didn’t have time to build a real design system, so we used a Relume template instead.
This was the trade-off for shipping fast using just a custom Relume template and a few base components, with 3 main ones carrying the structure.
- Final Design
We finished more than 12 user flows and a completely new component restructure
After that work the company closed a raise, kept operating, and has deals with companies like Adways.
- What I would do differently
Have the time to do good, deep research about the product first, have more references, learn more about design systems and components, and test after every cycle.
My biggest regret is that I took this job without knowing anything about design systems; I just used a Relume component library and master component to get the job done.
Even the Figma file had issues: no tokens, no variants for errors, only happy paths. And of course the UX wasn’t my best, because I was attached to not changing the structure or colors.
If I could do it again, I would definitely implement a design system from day one, do deep research on competitors and how they resolve the problem, build the variants and states, and test every single one to see where the flags are and improve it.