What to share with a UX designer before the kickoff call: a founder's prep checklist
Most kickoff calls waste the first hour catching up on context the founder could have shared upfront. Here's the prep checklist that makes the second hour the most valuable conversation you'll have about your product.
Across the last four years of kickoff calls, the good ones and the bad ones have started in exactly opposite ways.
The good calls open with the founder saying something like, "I sent over the brief on Monday — did the part about our payment constraint make sense?" The first ten minutes are spent on the trade-off sitting underneath that constraint. The next forty are spent arguing through it. By the end of the hour there's a one-page proposal that didn't exist at the start.
The bad calls open with introductions, then "so, tell me about your product." The next forty minutes are spent on context the founder could have shared in a Google Doc the week before. Then the call ends, and a follow-up email arrives a day later saying "let me think about scope and get back to you" — which, in my experience, almost always means I don't actually understand what you're trying to ship yet.
The difference between those two calls isn't talent on either side. It's preparation on one side. A founder who arrives with a sharp written brief gets a sharp kickoff. A founder who arrives with the pitch deck and a vibe gets a discovery session billed as a kickoff.
This post is the checklist I now send to founders before our first paid call. It covers the six things to share, the things you specifically shouldn't share, the three questions to ask back, and what the good and bad versions of the conversation sound like in practice. The framing assumes you've already done the hiring filter — if you haven't, the companion post on hiring your first UX designer covers that ground.
The six things to share before the call
Send these as a single document — Notion, Google Doc, Dropbox Paper, whatever lives in your stack. Not six separate Slack messages. One document. The designer reads it the day before. The call gets the second hour, not the first.
1. The product in one paragraph
Not the pitch deck. Not the landing page copy. The working answer: what does the product do, who is it for, and which user is most important to retain? Three sentences is the right length. The pitch deck is for investors and is calibrated to sound impressive. The working answer is calibrated to be true.
On a recent ecommerce engagement, the founder's one-paragraph version said something like, "We sell hand-painted juttis, mostly to women in Karachi aged 25-40, and the user we most need to retain is the one who buys a second pair within ninety days." That sentence shaped every layout decision that followed. The pitch-deck version of the same product would have run two pages and shaped none of them.
2. The user you're optimising for
Name a real person. Not "millennials." Not "users in general." A specific human who already uses your product, or — if you're pre-launch — the closest analogue you've watched try the workflow.
The designer is going to design for that person. Whether they say so or not, every layout decision is going to be made against a single mental model of who's on the other side of the screen. If you don't pick the person, the designer will pick one for you, and there's a fifty-fifty chance it's not the user you actually need to retain. Picking the user upfront is the cheapest leverage you'll exert all engagement.
3. The one decision you're stuck on
Every founder has one. Should the dashboard be a list or a grid? Should we charge upfront or after the first session? Should onboarding be five screens or one? Should the empty state ask the user to invite teammates or just show a sample? You've been chewing on it for weeks. You haven't told the designer because you assumed the kickoff was for "general context."
Name it in the brief. Get the designer's brain on it from minute zero. The thirty minutes they spend turning it over before the call is the highest-leverage thirty minutes of the engagement.
4. What you've already ruled out and why
Saves the designer from proposing the thing you've already rejected. Three bullets is usually enough. "We tried a swipe-based onboarding and it confused our parent users." "We tried a long-form pricing page and conversion tanked." "We tried a chatbot CTA and the support tickets tripled."
This one founders consistently underestimate. They assume the rejected directions are obvious or embarrassing. They aren't. The reason you rejected them is gold — it's the cheapest user-research the designer is going to get all engagement. A direction tried and abandoned is more useful than ten hypothetical user interviews, because it has an outcome attached.
5. The constraint you can't change
Payment provider you're locked into. Regulatory requirement you can't design around. Existing brand asset the CEO won't let go of. Timeline driven by a board meeting. Engineering stack that rules out certain interaction patterns.
The constraint shapes everything else. A redesign that ignores a hard constraint isn't a redesign — it's a thought experiment that will get rejected at implementation. Name the constraint upfront and the designer's proposals will be grounded in what can ship. Hide it and you'll get a deck full of ideas that look great on Figma and die in the engineering review.
6. What success looks like
A specific number, not a feeling. "Retention from session one to session two goes from 22% to 30%." "Time-to-first-action drops below 90 seconds." "The support tickets about Feature X disappear." "Conversion on the checkout page improves enough to justify the redesign cost within a quarter."
If you can't name the number, the engagement doesn't have a finish line, and "great work" becomes whatever the designer says it is at the end. The number is the trade you and the designer make: in exchange for the budget, they're aiming at this. The number doesn't need to be hit for the engagement to be worth doing. It needs to exist for the engagement to be aimable.
What you don't need to share
This is the counterintuitive half of the checklist.
| Share | Don't share |
|---|---|
| The user you're optimising for | Your existing wireframes or first sketches |
| The decision you're stuck on | Your guess at the final design |
| What you've ruled out and why | Competitor screenshots without context |
| The constraint you can't change | Your full Figma history |
| What success looks like as a number | The pitch deck unless asked |
| The product in one working paragraph | A 40-page brand guideline doc |
The reason you skip your existing wireframes is simple: the designer's job is to bring a fresh frame to your problem. If the first thing they see is your version of the answer, their version anchors to yours. You hired them for the version of the design you couldn't get to on your own. Give them the inputs that produce that version, not your guess at the output.
Show them the outcome you want and the constraints you have. Let them come back with the design. If they want to see your existing work, they'll ask in the call — usually after they've formed a frame of their own. That's the right order.
The three questions to ask the designer before scoping
The flip side of the prep work. While the designer is reading your brief, you should be preparing the three questions that filter whether they're a real partner or a billable headache.
1. "What's the smallest version of this engagement that proves we can work together?"
What you're listening for: an answer that doesn't immediately quote you the full six-week sprint. A real designer can name a one-week or two-week version of the engagement — an audit, a single flow, a focused deliverable — that lets both sides find out whether the working relationship is right before either side is locked in. Designers who can only sell the full package usually do so because they don't have a process that produces value before week four.
2. "Which one part of this would you push back on if I gave you ownership?"
What you're listening for: that they push back on something. Every founder brief has at least one assumption that's worth challenging. A designer who reads your brief and has no pushback either hasn't read it carefully or doesn't think yet. The push-back doesn't need to be confrontational — "I'd want to revisit your assumption that this needs to be a mobile-first experience, because…" is a healthy version. The presence of the pushback is the signal. The absence of it is the red flag.
3. "What did the worst version of this engagement look like the last time you ran it?"
What you're listening for: specificity. Every designer who's been working for more than two years has had an engagement go sideways. The ones who can name why — "the founder kept changing the target user mid-sprint," "I didn't get access to engineering until week five," "we never agreed on what success looked like" — are the ones whose next engagement will go better. Designers who can't name a bad engagement either haven't reflected on theirs, or haven't done enough engagements yet to have a bad one, or are performing for the call.
What good and bad kickoff calls actually sound like
The good kickoff call ends with a one-page proposal that wasn't there at the start. The designer leaves having heard the constraint, the stuck decision, and the success metric — and is able to write back, often within twenty-four hours, with a scoped version of the engagement that says here's what I'd do, here's what I wouldn't do, here's what it costs, here's when you'd have it. That document is sharp because the inputs were sharp.
The bad kickoff call ends with "let me think about scope and get back to you." A week passes. The follow-up email is vague. The proposal, when it arrives, is generic — three packages at three price points, with deliverables that could apply to any product. That's what scope-by-template looks like, and it's what you get when the kickoff call didn't surface anything specific enough to scope against.
You can predict which version you're going to get by the document you sent before the call. The designer is reading the same inputs you wrote down. If those inputs were sharp, the proposal will be sharp. If they weren't, no amount of kickoff-call charisma will rescue the scope.
If you're about to take this call
If you're prepping for a kickoff with me — or with any senior designer — and you'd like a second pair of eyes on your brief before you send it, that's worth a fifteen-minute call. The services page covers what's in scope for the kinds of engagements this prep enables; the contact page has booking. The next available kickoff slot tends to be three to four weeks out, so the brief is worth getting right.
If the prep checklist was useful, the case studies show the kind of work this preparation enables on the other side of the call — including Painted Juttay and Enrichplay, both of which started with founders who came to the kickoff with a written brief, a named constraint, and a stuck decision they wanted argued through. That's the call worth showing up for.
