EJ COLINA

RIVAL

CategoryProductUX DesignSystem Design
RoleProduct DesignerUX UI Designer
Rival: the exploration library showing captured user flows

Building a Benchmarking Engine That Cut Our UX Research Time by 80%

Work
UX ResearchPRDTestingPrototypingProduct Design
Tools
FigmaToolToolTool

Rival is a benchmarking and analysis tool that turns any product experience into a structured user flow and a full UX analysis, so you can measure whether something is worth building before you build it.

Its purpose is simple: speed up the slowest, most manual part of product design, UX research and analysis, and make it easier to study how the best UX practices actually apply to whatever you're building.

Rival mark

Problem Statement

Every project I take on begins with research, and that's where I was consistently losing the most time.

Before I can design anything, I usually do the following process.

  • Deep UX research across competing and adjacent products
  • Comparing flows
  • Building customer journeys.
  • Mapping every feature worth considering
The UX mood board in Figma
UX mood board Process

Product Definition

I split the process based on a follow-up of questions.

  • How can I automate the exploration or screen capture while I'm doing the exploration of any web app?
  • How can I use that information that I just took and put it in Figma to visualize what I just made?
  • Is there any type of company that's using something similar to what I need to?

If I could build something that worked like a screen recorder for user flows, capturing screens as I moved through a product, and export and assemble it ready inside of Figma, I'd remove the single most repetitive part of research in one move.

Wireframe of the Rival onboarding flow
Wireframe of the user flow

Mood Board & Research

With the problem defined, I researched how the hard parts had already been solved, so I could reuse proven approaches instead of reinventing them.

I studied products that had cracked adjacent problems and identified the specific patterns worth adapting for Rival:

Mobbin: Interface and the library model

I used Mobbin's UI as the model for a library structure that displays all the user flows and screens.

Mobbin: the Dropbox flow library

Builder.io: Figma bridge

Their Figma HTML open source allows me to know how the component tree could get rendered into real Figma nodes.

Builder.io: Build software with your team and agents

Waalaxy: Permission model

Used to know how all the infrastructure from the platform to web capture works; this helped me create a Chrome extension that works with the platform and then calls the Figma plugin.

Waalaxy: Make LinkedIn your #1 acquisition channel

Loom: Recording UX

Use to know their User experience in mobile devices and know how I can use it in mobile devices

Loom: One video is worth a thousand words

First PRDV1

The first PRD scoped Rival deliberately narrow: prove that capture can become a usable Figma flow. Nothing more.

Functions list

Rival v1: the Who you want to analyze setup screen

How it's built

On export, Rival generated a snippet the designer pasted into the Rival Figma plugin. The plugin then assembled the full user-flow board: every screen, plus how each connected.

I split it this way on purpose: a lightweight capture layer, and a separate Figma plugin that owns visualization.

Keeping those concerns separate meant I could iterate on capture without touching how flows render, and vice versa.

  1. capture layer
  2. snippet
  3. Figma plugin
The first Figma board Rival assembled: three captured screens with their details
The first result from the first test: Rival imports the screen and shows the information about each below.

Design systemShadcn

I chose Shadcn as the foundation because it gave me production-ready, accessible primitives that map directly to real components, which mattered for two reasons.

1) Speed: I could design and build in the same language without reinventing base components.

2) Rival's own outputs: because Rival compares against a component library, building on Shadcn primitives meant the tool and its analysis spoke the same vocabulary.

The Shadcn variable collection in Figma
Figma Shadcn Design System variables

TestingV1

With v1 built, I tested it against exactly one question:

Can it get a real exploration from point A to point B?

What I looked at:

  • Reliability of capture across a full navigation
  • Whether the output was genuinely usable as a research artifact, not just a screenshot dump
  • Whether screens connected in the right order
  • Where the interaction felt fragile or unclear

v1 passed the core test: it captured a flow and delivered it into Figma.

Rival's detail page for a captured exploration
Detail Page screen with all the extracted information.

Decision & Pivot

While testing, I noticed the tool was doing more than taking screenshots. It could detect when a user clicked a button, and where that click led and map that connection into the flow automatically.

If the tool understood behavior, it could do far more than draw a flow, it could analyze one.

The data I was already capturing (actions, transitions, sequence) was exactly the raw material a UX analysis needs.

Testing revealed that v1 had accidentally built the foundation for a UX analysis tool.

Because I'd tested with real explorations rather than mock data, the click-detection behavior showed up during the test.

New PRDV2

Turn captured behavior into real UX analysis and a build/no-build decision, instead of stopping at a flow board in Figma.

Functions list

Clicks and where they lead, not just the screens themselves

Final Version

The designer sets up an exploration (product, type, target Figma file, purpose), runs it, and exports.

The desktop experience covers setup and the exploration view; the flow-visualization lives in the plugin.

The Result

UX research and analysis time dropped by more than 80%. More importantly, the time that's left goes to the part that actually needs a designer, deciding which flow is better and what's worth building, instead of manual assembly.

From a single capture, Rival now answers the question every product decision hinges on: is this worth building?

  • Heuristic Analysis
  • UX Prompt Flows
  • Feature List
  • Customer Journey

Heuristic Analysis

Rival evaluates the captured flow against Nielsen's 10 usability heuristics on a 0–4 severity scale, under a stricter stance I call "Structural Determinism"

  • 01 · Hero Landing

    H8 · Aesthetic and minimalist designSev 2 · Minor

    Hero landing screen presents seven competing feature tabs below primary product tabs, creating excessive navigation density above fold.

    FIX

    Consolidate feature navigation into collapsible accordion or move secondary tabs below hero section to reduce visual competition.

  • 04 · Voice Creation Modal

    H4 · Consistency and standardsSev 1 · Cosmetic

    Close button icon placement alternates between top-right and top-left corners across modal dialogs without consistent positioning logic.

    FIX

    Standardize close button to top-right corner across all modal dialogs following platform conventions for dismiss controls.

  • 06 · Voice Design Dialog

    H5 · Error preventionSev 4 · Catastrophe

    Voice generation executes without confirmation modal, consuming 350 credits per click with no warning of cost or undo mechanism.

    FIX

    Implement confirmation modal before generation stating credit cost and requiring explicit confirmation to prevent accidental depletion.

Need help?

Let’s talk!

efrain.colina20@gmail.com

Austin, Tx