harvey Product Designer Interview: Questions & Prep (2026)

Harvey is building AI tools for law firms and legal departments, helping lawyers work faster on tasks like contract review, legal research, and document drafting. The company currently lists 367 open roles, signalling aggressive hiring across functions including product design.

As of early July 2026, the knok jobradar tracks 393 Product Designer openings across the Indian market. The strongest hiring clusters are in Bangalore (62 open roles), Delhi (33), and Mumbai (13), with smaller pockets in Hyderabad, Pune, and Chennai.

Salary ranges for Product Designers vary by experience level:

The interview process at Harvey typically spans a portfolio review, a design exercise or take-home task, and panel discussions with designers, PMs, and engineers. Candidates report that interviewers focus heavily on reasoning through ambiguous problems, especially those involving AI outputs and expert users like lawyers. This guide covers the questions to expect, how to structure strong answers, and what to do in the week before your interview.

Harvey interviewers typically focus on three themes: designing for expert users, handling AI uncertainty in product decisions, and collaborative judgment under constraint. Here are the questions candidates report most often.

1. Walk us through a project where you had to simplify complex or technical information for a non-technical user.
2. Harvey's users are lawyers with specific, high-stakes workflows. How do you design for expert users rather than general audiences?
3. Tell us about a time you worked closely with an AI or ML team. How did you handle variable or uncertain model outputs in your design?
4. Describe a design decision where you had to choose between surfacing more detail and keeping things simple. How did you decide?
5. How do you approach designing for user trust when the product involves AI-generated content that may sometimes be wrong?
6. Tell us about a time your research led you to push back on a product direction. What happened?
7. Describe how you managed conflicting feedback from engineers, PMs, and business stakeholders in the same project.
8. Walk us through your end-to-end design process on a complex B2B or enterprise product.
9. How do you define and measure success for a design after it ships?
10. Tell us about a design you shipped that did not perform as expected. What did you learn?
11. How do you think about accessibility or inclusion when designing legal or professional software?
12. What does good AI product design look like to you, and where do you see Harvey fitting into that picture?

Q: Walk us through a project where you had to simplify complex technical information for non-technical users.

*Situation:* At my previous company, we built a contract analysis tool that surfaced dozens of clause-level risk flags per document. Early research sessions showed that legal ops users found the volume of flags overwhelming and struggled to know where to start.

*Task:* My task was to redesign the results page so users could quickly identify what needed action without missing anything critical.

*Action:* I ran card-sorting sessions with legal ops users to understand how they naturally grouped risks. Based on that, I proposed a tiered view separating critical flags from lower-priority ones, with a visual hierarchy that matched their mental model. I worked with engineering to ensure the grouping logic used signals the model was already producing, so no additional model work was required.

*Result:* After the redesign launched, usability test participants completed their review tasks noticeably faster, and stakeholders described the new interface as 'much more usable under real working conditions' in the next quarterly review.

---

Q: Tell us about a time you worked with an AI or ML team and had to handle uncertain or variable model outputs in your design.

*Situation:* I was designing a summarisation feature where the model's outputs on certain document types were sometimes incomplete.

*Task:* The PM wanted to ship without any uncertainty signals in the UI. I felt users would lose trust if they encountered poor outputs without context, especially since the feature was positioned as a time-saver.

*Action:* I advocated for a lightweight confidence indicator. I prototyped three versions, from a subtle disclaimer to a more visible confidence badge, and tested them with a small group of target users. A short inline note performed best. I documented the rationale and walked the PM and ML lead through the tradeoffs in a shared design review.

*Result:* We shipped the inline note. No users flagged confusion about output quality in the first month after launch, and the PM acknowledged it was 'the right call'.

---

Q: Tell us about a time you used research to push back on a product direction.

*Situation:* The product team had decided to build a dashboard customization feature. It was scoped, estimated, and almost ready for the sprint.

*Task:* I had heard in several user interviews that customization was not a real pain point. Users were more frustrated by slow load times and confusing navigation. I needed to redirect effort without derailing the team.

*Action:* I put together a short synthesis deck with direct user quotes and a prioritization map showing where design effort would address the problems users had actually named. I presented it at sprint planning and suggested deferring the customization feature to focus on navigation improvements first.

*Result:* The team agreed to deprioritize the feature for that quarter. The following research sessions showed users responding more positively to the navigation changes, and the PM credited the pivot as 'one of the better calls we made that cycle'.

For behavioral questions, use the STAR structure: Situation (brief context), Task (your specific role or goal), Action (what you did and why, with enough detail to show your thinking), Result (what changed, and what you learned). Keep Situation and Task short. Spend most of your time on Action and Result.

For portfolio walkthroughs, follow this arc: the problem you were handed, the research method you chose and why, the key insight that shifted your direction, the design decisions you made and the tradeoffs you weighed, and the outcome or what you would change now. Harvey interviewers typically want to hear how you handle ambiguity, so name the moments where you did not have a clear answer and explain how you moved forward anyway.

For 'how do you think about X' questions, lead with a principle, back it with a concrete example from your work, and name the tradeoff you had to navigate. Avoid abstract answers. Interviewers at AI product companies typically care more about your judgment under uncertainty than about whether you follow a specific named process.

For design exercises, prioritize showing your thinking over visual polish. Narrate your assumptions, explain what you would validate with users before finalising, and flag the tradeoffs in your solution. A well-reasoned rough prototype typically outperforms a polished design with no visible reasoning.

Harvey interviewers are typically evaluating three things.

Ability to design for expert users. Lawyers are not casual users. They have deep domain knowledge, high-stakes work, and very little patience for interfaces that slow them down. Interviewers want evidence that you understand how expert users think differently from general audiences, and that you can design workflows that respect that expertise rather than oversimplifying it.

Comfort with AI uncertainty. Harvey's core product involves AI-generated outputs that are powerful but not always perfect. Interviewers want to see that you have thought seriously about how to represent uncertainty, build user trust, and design graceful failure states. Candidates who do not address the 'what happens when the AI is wrong' question tend not to advance past the portfolio stage.

Cross-functional collaboration and constructive pushback. Product designers at Harvey work closely with engineers, ML researchers, and legal domain experts. Interviewers look for evidence that you can absorb technical constraints, synthesize diverse feedback, and advocate clearly for the user even when it means slowing down or changing direction. They want to see that you push back with evidence, not just instinct.

One to two weeks before the interview:

1. Study Harvey's product as deeply as you can using publicly available materials. Look at demos, LinkedIn posts from their design and product team, and press coverage about how their features work.
2. Prepare three or four portfolio case studies. At least one should involve AI-generated content, complex data, or enterprise workflows. Practice telling each one in under ten minutes.
3. Research the legal tech space broadly. Understand what problems Harvey's users face that existing tools do not solve well.

In the week before:

1. Practice your case studies out loud, not just in your head. Time yourself and cut anything that does not serve the story.
2. Prepare five or six thoughtful questions for your interviewers. Ask about how design decisions get made, what the feedback loop looks like after launch, and how the design team works with the ML team.
3. If you receive a design exercise or take-home brief, focus on showing your reasoning clearly. Harvey interviewers typically value how you think through the problem over how the final design looks.

On the day:

1. In every answer, connect your design decisions back to user impact or business outcome. Avoid answers that stop at 'I designed the interface' without explaining what changed as a result.

Showing only visual polish. Sharing screens of finished designs without explaining the problem, the constraints, or the decisions behind them tells interviewers very little. Walk through your thinking, not just the output.

Vague outcomes. Saying 'users responded positively' or 'it improved the experience' without supporting evidence is weak. Use direct user quotes, usability test observations, or any qualitative signals from your research, even if you do not have hard metrics.

Skipping the failure stories. Candidates who present only successful projects can come across as inexperienced or unaware of how design actually works. Have at least one honest story about a project that did not go as planned and what you learned from it.

Ignoring the AI layer. Candidates who treat Harvey like a standard enterprise software company miss what makes the role distinctive. Be ready to talk about how you have thought about AI outputs, uncertainty, or model limitations in your design work, even briefly.

Not asking questions. Leaving no time for questions, or asking only generic ones, signals low engagement. Specific, thoughtful questions about the team's design process or product challenges leave a much stronger impression.