Insights
Decide what the designer must own at your stage, read portfolios for decisions, use a live or paid exercise and interview with a rubric. To hire a product designer for a SaaS product, first decide which product decisions the person will own at your stage, because that decides the profile, not the job title.
To hire a product designer for a SaaS product, first decide which product decisions the person will own at your stage, because that decides the profile, not the job title. Then judge candidates on how they made decisions: read portfolios for evidence and constraints rather than polish, replace unpaid spec work with a case-study walkthrough or a paid exercise on an invented problem, and run the same structured interview with a scoring rubric for everyone. After the offer, onboard them into the product before you give them a first project.
This guide is for a founder or product leader hiring a first or next designer in-house. It covers what the role owns, which profile fits which stage, how to read a portfolio, the exercise, interview questions and the first weeks. It ends with when a studio is the better first step, and Tcules is one of those, so that section is a disclosed alternative rather than a neutral one.
What a product designer owns in a SaaS product
Titles vary (product designer, UX designer, UI/UX designer, interaction designer), so define the role by what it owns. In a SaaS product, a product designer can be expected to own five things:
- The product model before the screens. Which objects exist (accounts, workspaces, records, plans), which roles can see and do what, and which states each thing can be in. Many of the hard SaaS problems live here: permissions, admin settings, plan limits, bulk actions, empty and error states.
- Evidence for decisions. Talking to customers, reading support tickets and usage data, and testing a prototype when a decision is uncertain enough to be worth testing.
- Interaction and interface. Flows, hierarchy, content and visual execution that hold up with real data, not just the demo account.
- The system. Components and rules that let the product stay consistent as more people build it. GitLab's public job description, for example, expects its product designers to contribute to its Pajamas design system and review merge requests, giving feedback on implementation choices.
- Carrying the work into the build. Answering the questions that only appear once engineers meet real data, and checking what ships against what was intended.
A UI designer or visual designer covers part of the third item. A UX researcher covers much of the second. A brand or marketing designer covers none of the five in depth. If you need the whole list, you are hiring a product designer; if you need only one item, say so in the job description, because a candidate who reads "product designer" will expect to own decisions, and one who reads "UI designer" will not.
Which profile fits your stage
A long-standing piece of advice is that a first designer should be a generalist. In 2015, Julie Zhuo, then a director of product design at Facebook, described a startup's first designers as needing to be "great jacks-of-all-trades" who understand product strategy as well as interaction and visual design. That is a sound default for a first hire, but the right generalist still differs by stage:
| Your stage | What the product needs from design | Profile to look for | Warning sign in a candidate |
|---|---|---|---|
| Before a first serious release | Decide what the product is, for whom, and what the first release leaves out | Senior generalist who has shaped a product from an unclear brief, comfortable with research and fast prototyping | Only shows finished interfaces for products someone else had already defined |
| Early customers, unproven retention | Find where new accounts stall and fix activation, the core workflow and admin basics | Senior generalist with evidence habits: talks to users, reads analytics, tests before redesigning | Proposes a visual refresh before asking what the data shows |
| Growing product, several engineering teams | Keep the product coherent as more people ship into it | Designer who has worked inside a design system and with engineers on implementation detail | Has only worked alone, or only on greenfield projects |
| Established product with long-standing customers | Change workflows people depend on without breaking their habits | Designer with experience of complex or enterprise workflows and of releasing change gradually | Treats existing users' workarounds as noise rather than information |
Two judgements follow from the table. First, your first designer needs to be more senior than later ones, because nobody in-house can review their work or give them a brief. Second, if you cannot yet say which row you are in, or the design work is a bounded project rather than a steady flow of decisions, a full-time hire may be premature; the last section covers that case.
How to read a portfolio for product thinking, not polish
A portfolio is a set of finished outcomes, edited for effect. What you need from it is evidence of how the person reasons. Zhuo's checklist reads each piece for the idea, its usability and its craft, and she treats seeing the candidate walk through the work in person as a priority. For a SaaS hire, open each case study with these questions:
- What was the problem, and who decided it was the problem? A strong case study separates the brief they were given from what they found.
- What evidence changed the direction? Look for a moment where research, data or a test made them drop an idea. A case study in which every early idea survived is a weak signal.
- Which constraints shaped it? Technical limits, legacy customers, compliance, a deadline. Work with no visible constraints tells you little about how they will handle yours.
- Beyond the happy path, what did they design? Permissions, empty states, errors, bulk actions, a user with fifty records instead of three. SaaS products are full of these.
- What was their part, and what was the team's? Ask them to name the decisions they made themselves.
- What happened after it shipped? Did they stay through implementation, and do they know whether it worked?
Treat some things as neutral rather than positive: polished visuals of unsolicited redesigns of famous apps (no constraints, no users), marketing websites presented as product work, and long process diagrams that could belong to any project. None of them disqualify a candidate; they just do not answer the questions above.
A practical exercise instead of unpaid spec work
Some companies ask designers to redesign part of the company's own product as a take-home task. That is spec work in all but name: AIGA, the professional association for design, defines spec work as work done before an engagement in anticipation of being paid and warns that clients risk compromised quality, because little time or thought can go into it, which leaves out research, consideration of alternatives and testing of prototypes. Strong candidates with other options may also decline it. Three formats give you better signal:
| Format | What it shows | Cost to the candidate | When to use it |
|---|---|---|---|
| Case-study walkthrough | How they reasoned on real past work, under your questioning | Low: the work already exists | Always. GitLab's published process includes a walkthrough of a portfolio case study of about 30 minutes and lists no take-home task |
| Live working session on an invented problem | How they break down an unclear problem and which questions they ask first | One interview slot | When you want to see thinking in real time; keep it to framing and sketching, not finished screens |
| Paid, time-boxed take-home on an invented problem | How they work alone over a longer stretch | Bounded hours that you pay for | When the role needs independent work and the walkthrough left a real doubt |
Whichever format you choose, write the problem in a domain next to yours but not your product, state the time you expect, say in writing that you will not use the output, and score it against the same rubric as the interviews. Set expectations about what an exercise adds, too. In a re-analysis of earlier meta-analyses of selection methods, Sackett and colleagues (2022) estimated the average validity of work sample tests at .33 and of structured interviews at .42. Those figures average many kinds of jobs rather than design roles, and the interview figure varies widely from study to study, so they are neighbouring evidence, but they suggest that a bespoke exercise is not automatically better than a well-run interview and should not replace one.
Interview questions, and what a good answer shows
The same re-analysis put unstructured interviews at .19, less than half the structured figure. Structure here means what Google's re:Work guide describes: the same questions for every candidate, planned follow-ups, notes taken during the interview and a shared rubric for scoring answers. Put a product owner and an engineer on the panel, because the designer will work most closely with both. If this is your first designer, borrow an experienced designer you trust to assess craft, since nobody else in the room can.
| Question | What a good answer shows |
|---|---|
| Tell me about a decision on this project that evidence changed. | They treat research and data as inputs to decisions, not as decoration |
| Tell me about a time an engineer said a design could not be built as drawn. What happened next? | They negotiate within constraints and know where the design could flex |
| Which feature or idea did you argue to cut, and why? | Product judgement, and the confidence to say no |
| How have you designed for users who can see or do different things, such as admins and members? | Comfort with the permissions and roles that multi-user SaaS products carry |
| How do you decide when a prototype is real enough to test? | Proportion: they match the fidelity to the uncertainty |
| What did you measure after release, and what did you learn? | They follow work past hand-off |
| Where do you use AI tools in your work, and how do you check what they produce? | A clear boundary between generated material and accepted decisions |
| Look at our sign-up and first session. What would you want to find out before changing anything? | They ask questions before proposing a redesign |
| If you had two more months on that project, what would you have done differently? | Self-critique; this is one of Zhuo's own questions |
Score each answer against the rubric straight after the interview, before the panel compares notes, so the first strong opinion in the room does not set everyone else's.
Onboarding the hire into the product
A designer who does not understand the product risks redesigning the parts that look worst rather than the parts that matter most. Prepare these before the first day:
- Access to the product as each role sees it, with realistic data: an admin account, a member account and, where you can, a large account.
- The evidence you already have: analytics, support tickets, sales call notes or recordings, churn reasons and any past research.
- One named decision owner who can answer "do we do this?" without a committee.
- An engineer to pair with, so the designer learns early which constraints are real and which are habits.
In the first weeks, ask the designer to use the product end to end in each role, sit in on support and sales conversations, and write down the product model as it actually is: objects, roles, states and the places where they contradict each other. A checklist such as our SaaS UX audit checklist can structure that first pass. Agree early where design decisions will be recorded, so the reasoning outlives the meeting.
Choose the first real project for its decision rather than its visibility: a problem where design can change what gets built, small enough to ship with engineering. Avoid making a full redesign the first assignment; if a redesign is genuinely needed, our guide on redesigning a live SaaS product without losing users covers how to stage it.
When a studio is the better first step
A hire is the better choice when design decisions arrive continuously and the value comes from context building up in one person over time. A studio can be the better first step when:
- you cannot yet say which row of the stage table you are in, and need the product shaped before you know the role;
- the work needs research, interaction, a design system and front-end skills at once, which is a lot to ask of one hire;
- the work is a bounded project, such as a first release or a single difficult workflow, rather than a steady flow;
- you need design moving while a search runs.
The trade-off is that knowledge built by an outside team can leave with it unless you keep the product judgement in-house and require the reasoning to be written down; our article on outsourcing UX design without losing product knowledge covers how. The two routes can also run in sequence: a studio settles the first product decisions, and the hire inherits a product model and a record of why it looks the way it does.
Tcules is a digital product design studio creating ambitious new software products and making established ones better, with a particular focus on SaaS. Our engagements can start as a bounded audit or assessment, a product decision or capability, a 0-to-1 product slice, an embedded continuing responsibility, or end-to-end design and software delivery. See how Tcules works with product teams.