Selected work
1 of 5. Michael Wong. michaelwong.eth: i fkin love what you did with this bro.
1 of 9. John Gilman. VP Product and co-founder at Onit: Our team could never have done what you did. I miss working with you guys..
1 of 5. Michael Wong. michaelwong.eth: i fkin love what you did with this bro.
1 of 9. John Gilman. VP Product and co-founder at Onit: Our team could never have done what you did. I miss working with you guys..
I design the complicated parts of products people prefer not to think about. I figure out what to build, test it with real people, and prototype in code because working interactions answer questions faster than static mockups.
When I’m not working, I’m probably kickboxing, swimming, riding a bike, or being humbled by salsa and jiu jitsu.
Building something? Email me at hey@rafaelmedina.meClick to copy.
Most engagements run the same five beats. What changes is how long each one takes: a two-week audit compresses them into ten days, a year of product work loops through them a dozen times.
01
One conversation about the business before anything about the interface: what the product has to do, who it is losing today, and what has to be true in six months for this to have been worth it. I leave with the goal we are designing against and the constraints I have to design inside.
02
I talk to the people who actually use the thing, and read what the product already knows: support threads, session recordings, the last three attempts at this. It is usually a week, and it is the cheapest week in the project, because most of what it produces is a list of things not to build.
03
You see work inside the first two weeks and it is deliberately unfinished. Two or three directions that disagree with each other, so the decision is about which problem we are solving rather than which shade of blue. Polish is cheap once the direction is right and expensive before.
04
Once a direction holds I build it: real components, real data, real states. A working interaction settles questions a static mockup can only argue about, which is how the empty state, the error and the timing get designed instead of discovered in QA.
05
I stay through implementation, reviewing builds, fixing what only shows up on a real device, and leaving your engineers components and rules they can keep building on. The engagement ends when the work is in production, not when the file is tidy.
That is a default, not a template. Reviews happen when there is something worth reviewing rather than because it is Thursday, and I would rather show you something rough on Tuesday than something finished next month.
I take on a small number of client projects alongside my own product work. Three shapes, chosen by how much of the problem is still open when we start.
0 → 1
One designer owning the problem from the first user interview to the shipped screen: discovery, research, UX and UI, and the coded prototypes your engineers build against. The shape of the Matcha rebuild and of BoldVoice.
Monthly
A standing seat on a team with no in-house designer, a few days a week or full time when the roadmap needs it. New surfaces as they come up, review on what your engineers are already building, and a design system that keeps its shape between the two.
1 – 2 weeks
Fixed scope, fixed date. I talk to your users, take apart the product you have today, and come back with a ranked list of what it is costing you and a direction for each one.
Engagements are billed by the week or by the month, not by the deliverable. We start by estimating the scope and how long it will take, and the total follows from that. If you would rather have one number to approve, I quote the whole scope as a single figure and you pay it monthly across a timeline we set before the work starts. Tell me what you are building and roughly when you need it, and I will come back with both.
A sprint or audit runs one to two weeks and ends on a date we agree before it starts. End-to-end product work is measured in months, and how many depends on how much is still open at kickoff. You get that number in the proposal, not in a conversation after we have started.
Yes. I studied computer science and shipped front-end full time for years before I moved into design: React, TypeScript, the CSS and the motion. What is different now is a swarm of agents behind a tight end-to-end suite, which is what lets one person carry the work from the first sketch to production. This site is mine end to end. Your backend is not, and I work next to the engineers who own it.
One person who can make decisions, access to the people who use the product, and about an hour a week. You do not need a spec written first: working out what to build is most of what you would be hiring me for.
A shared Slack or Telegram channel, and reviews when there is something worth reviewing instead of a standing meeting. I am on Atlantic time in Punta Cana, which covers the US East Coast almost exactly and most of the European afternoon.
Email me at hey@rafaelmedina.me, or .