Designing the tool I would want to use.
How I'd shape the product, the flow, and the first impression.
Shared by Renato, May 26
SCROLL TO EXPLORE
01 // Quick wins for our Product Manager ICP
Strong UX design means being able to design for anyone who needs the product, not just people who think like you. Engineers, founders, PMs, owners. They all have different mental models, different goals, and different definitions of what "working well" means.
My approach
I approached this audit by setting aside how I would use UX Pilot and spending time understanding how Marcus would. He's not a designer. He thinks in requirements, features, and meetings.
My job was to understand his world well enough to identify where the product serves him and where it could serve him better.
Current Flow
Write PRD
↓
Open UX Pilot
↓
Paste PRD
↓
Generate
↓
Share
What the product already does well
The building blocks are there. PRD import, reference uploads, flow generation. These are exactly the right features for a PM who works the way Marcus does. The capability exists. The problem is that it's buried in a product that speaks designer language throughout. A PM landing on UX Pilot today would have to discover PRD import by accident.
There's no path through the product that says "got a PRD and a folder of competitor research? Start here." Having a capability and surfacing it for the right person are two different things, and right now UX Pilot does the first without doing the second.
Where it falls short
The reference upload stops short. Marcus can upload screenshots and references, which is right. But the product treats every generation as a greenfield design problem. Marcus is almost never building from scratch, he's adding a notifications centre, a data panel, a new settings flow to a product that already exists. The reference upload needs to work as a product context signal, not just visual inspiration. Right now, what gets generated could belong to any product. It should look like it belongs to his.
There's no path through the product that says "got a PRD and a folder of competitor research? Start here." Having a capability and surfacing it for the right person are two different things, and right now UX Pilot does the first without doing the second.
1 //
The flow output is not packaged for a meeting. Flow generation exists and it's good. But the output is a design artifact. What Marcus needs is a sprint planning artifact. PMs at companies of Marcus's size are almost never building from scratch. They're adding one focused feature to a product that already exists: a notifications centre, a data panel, a new settings flow. He needs to show his team where the feature sits within the existing product, how a user gets to it, and how it connects to what's already there. And he needs to share that before the meeting starts, not export to Figma and build a presentation first.
2 //
Sharing is built for designers, not meetings. Export to Figma or code to GitHub are steps in a designer's or developer's workflow. For Marcus they're friction. He needs a URL, viewable without an account, pasteable into a Linear ticket in thirty seconds.
3 //
The context disappears at every handover. Marcus comes to the tool with real context: research he's done, competitor products he's looked at, patterns he's identified, reasons for decisions he's made. None of that travels with the output. The designer who refines the screens doesn't know why certain patterns were chosen. The developer who builds it has no rationale to refer back to. Every handover restarts the briefing process from scratch.
Some quick wins
Some quick and simple things that could improve the PM flow. Please take a look at my onboarding flow in the below section to see this.
1-2 days
Shareable preview URL
Host a view-only link requiring no account. Marcus pastes it into Linear before the meeting starts. No change to generation, no new features. Just make the output leave the product in a format he can actually use.
1-2 days
Upload your existing product as context
Marcus can already upload screenshots. Repositioning this as "upload your existing product" so the generation matches the UI patterns already there this means fewer revision rounds and an output that looks like it belongs in his product, not a generic wireframe. A framing change, not an engineering one.
1-2 days
PM onboarding path
The role-branching I designed in Prompt 2 surfaces PRD import, reference uploads, and flow generation at sign-up for a PM. No new features needed. Just a different path through what already exists.
1-2 weeks
Sprint planning packaging on flow exports
Name and frame the flow output as a sprint artifact, not a design file. Sequenced screens with a title, a description, and a shareable link. A framing and copy change, not an engineering one.
What actually matters vs nice-to-have
What matters is whether Marcus can walk into a sprint planning session with something credible enough to get a decision made. Visual polish is not his problem. That's what the designer is for. He needs something that communicates the feature clearly enough for his team to say yes. The designer makes it production-ready once they have.
Load-bearing
Shareable preview URL
Existing product as context upload
PM onboarding path
Sprint planning export format
Nice-to-have
Native Jira / Linear integration
Advanced brand matching
Template library for PMs
02 // Onboarding Redesign FTUX
The brief: Redesign the onboarding flow from sign-up to first design output, for a designer at a 50+ person company.
The problem I found: Most onboarding flows optimise for completion, not comprehension. Users finish the steps and still don't understand what the product does or why it's different. For a tool as genuinely powerful as UX Pilot, that's a missed opportunity, the product itself is the best argument for using it.
My approach: Cut everything that doesn't move the user closer to their first real output. Make that output the magic moment. Don't pretend the journey is the same for a designer with a Figma file and a PM who's never opened one.
Step 1
Design thinking - User flow.
The core principle behind this flow was: get the user to their first real output as fast as possible, without deceiving them along the way.
I branched step 2 by role because a designer and a PM (for example) have fundamentally different toolchains. Routing a PM through a Figma OAuth screen could be both confusing and also pointless if its not in their toolkit.
For designers, I framed the Figma connection as a value unlock rather than a setup task: the copy leads with what they gain, not what they're configuring.
The skip option remains, but with honest consequences ("I'll generate in a default style, not your brand") rather than a passive "skip for now", so users understand the trade-off at the point of decision, not after a disappointing first output.
The prompt screen at step 3 deliberately mirrors the product's chat interface, meaning onboarding teaches the UI pattern while being the UI pattern, with no context-switching required.
The loading state uses three named steps rather than a spinner, which builds anticipation and implicitly explains how the product works.
The " ✨ magic moment ✨" isn't a results screen.
It's the product workspace itself, with the first generated design already open inside it. Users land in the tool, not in front of it.
Onboarding flow
01 // Sign-up
Reduce every possible step
Google & SSO as the primary action, email as the fallback. No password field on the first screen. Email verification is deferred, don't gate entry at the front door! Get the user to the magic moment first, verify later. Auto-create the workspace in the background
Defer email verification
auto-create workspace
02 // Role + product type
Chips only, no form fields
Two questions, chip-based, no form fields. What's your role, and what are you building?
These two answers do all the work. They pre-fill the prompt in step 3 and determine which path step 2 takes. Nothing else is needed here.
2 questions max
drives the branch
😖 I don't know why these arrows are cutting off in Framer, And I'm on a time crunch!
Path A - Designer
Connect your Figma?
For designers: connect Figma via OAuth, upload a screenshot, or continue without it.
The skip option stays but the copy is honest. "I'll generate in a default style, not your brand."
unlocks on-brand generation
Skippable
The case for making it required (or near-required): The Figma connection is the magic for designers.
Without it, UX Pilot generates generic outputs, which is fine for a PM but undersells the product completely to a designer. If a designer at a 50-person company sees a plain, un-branded result in their first session, they'll assume that's all it does. The magic moment (S5) loses most of its power.
Path B - PM / Founder / Other
Show us what you’re building
For PMs and founders: paste a URL, upload a screenshot, describe it, or pick a template. No Figma assumption, no Figma language.
Zero figma assumption
As we have little time I won’t be expanding out on this flow
05 // What’s next, one action, role aware
Don't show all features. Surface ONE logical next step prominently
One action, not a feature tour. The next step is role-aware and logical. A designer who just generated their first screen sees "Generate the next screen in this flow" not a grid of every feature the product has. Surface the one thing most likely to create a second magic moment, and seed retention without making it feel like onboarding.
retention seeds
not a feature tour
03 // First prompt
Pre-filled, never blank!
Never blank. The prompt is pre-filled based on role and product type, fully editable. A designer building a web app sees "A dashboard styled to match my Figma design system." They can change it, but they never have to start from nothing.
NO BLANK PROMPT STATES
ROLE-AWARE PREFILL
✨
04 // Magic Moment!
The design appears. It looks real. It looks like their product.
One action, no feature tour, no tooltips. Let them sit with it.
Path A - Designer
key decisions
Here's where the thinking got interesting.
Onboarding design looks simple from the outside. Get someone signed up, show them what the product does, get out of the way! But the details are where it gets hard. Who are they, what do they already have, and how do you make the first output feel like it was made for them, not just made?
🌳
Role branching at step 2, not step 1
The insight isn't just that designers and PMs are different users. It's that the divergence only matters at the point of tool connection, not before. Everyone comes through the same front door, then the flow branches exactly where it becomes relevant. That felt like the more considered call.
😇
Honest skipping
Most products let you skip onboarding steps and quietly deliver a worse experience, hoping you won't notice. I wanted this flow to tell you upfront what you're opting into. It protects the product's credibility and actually motivates Figma connection more effectively than hiding the difference would.
✨
The magic moment is the workspace, not a result
Landing inside the tool with a design already open is fundamentally different from a "your design is ready, click here" screen. One makes you a user. The other makes you feel like a collaborator.
💥
The prompt screen is the product
Using the actual chat interface for the first prompt wasn't a stylistic choice. It was deliberate. The onboarding teaches the mental model while being the mental model. No tutorial layer that gets thrown away the moment you're done with it.
📘
The loading state tells a story
Three named steps instead of a spinner. Each one shows what the product is actually doing, which means by the time the design appears, you already understand why it looks the way it does.
Quick tangent…!
The UX Pilot's Brand
UX Pilot's marketing palette is bold and intentional. Deep indigo, electric purple, lime. It has real personality and it works exactly where it's designed to work: in hero sections, campaign assets, the first impression (I really love it and it was so fun to have even a short time experimenting with it! ).
But…… it isn't a UI palette. The two near-black purples have no mid-range between them, so you can't build surfaces, borders, and disabled states without inventing colors that don't exist in the system.
The lime green (#C7FF01) fails WCAG contrast on every background in the set, so it can't carry interactive affordance.
And the electric purple (#8959FF) is a single mid-tone with no tonal scale, no hover state, no pressed state, no way to communicate hierarchy through the same hue.
So… I built one :)
Still a work in progress. I mainly concentrated on primitives so that I could do the exploratory work on the interface. A deep dive into the primary brand colours would be needed - adding colour variants, like hover states etc.
Interface Primitives
An 11-stop neutral scale built from scratch. The cool blue undertone through every stop echoes the brand without carrying its drama into every surface. Dark end for canvases and panels, light end for backgrounds and inputs. Full range for states, hierarchy, and borders.
Primary Palette
Bold, expressive, built for impact. It works exactly where it's designed to work. But it has no mid-range, no tonal scale, and the lime fails WCAG contrast on every background in the set. You can't build a UI system from it. They would be incorporated into the main interface as highlights.
The interface should never be the most interesting thing on screen.
There's also a deliberate hierarchy at play here. UX Pilot is a canvas for designers to produce work in. That means restraint isn't a limitation of the palette, it's the point. The neutrals do their job and step back. The design the user just generated takes focus. Us designers are tricky beasts, any colour can through us off, we need a simple palette that doesn't get in the way.
The meat 🍖
The screens
The wireframes translated into high fidelity, following the main designer path: sign-up through to first design output. Each screen is built on the interface palette with some primaries added for punch. The Figma-connected flow as the primary scenario.
Swipe through to see the full sequence.
Notes:
I ran out of time to finish off all of the screens.
Shared by Chloe, May 26!
Thank you
Thank you so much for sharing the brief and for taking the time to look through this. I really enjoyed the process. UX Pilot is a genuinely interesting product to dig into, and having a real persona to design against made the audit feel purposeful rather than hypothetical.
This covers two parts of the brief: a PM-focused audit of the current product, and a redesigned onboarding flow built for a designer at a 50+ person company. It's a work in progress and I ran out of time on a few of the screens, but the thinking and decision-making behind each stage is all there.
I'd love to talk through any of it in more detail and am happy to walk you through the reasoning behind specific decisions if that would be useful.
chloe Angharad Eardley // submission for lead product designer at UX Pilot, may 26