VIEWS Product Designer Interview: Questions, Experience & Prep (2026)

VIEWS currently has 40 open Product Designer roles, making it one of the more active companies hiring designers right now. If you are targeting a Product Designer position at VIEWS, expect a process that typically runs across multiple rounds, covering your portfolio, design thinking, and how you collaborate with product and engineering teams. Candidates report that VIEWS puts strong emphasis on real-world problem solving and how you justify your design decisions with user research and data. This guide covers the questions you are most likely to face, how to answer them well, and what interviewers are actually looking for.

Based on what candidates typically report from product design interviews at companies like VIEWS, here are the questions you should prepare for:

1. Walk me through a project in your portfolio where you had to balance user needs against business constraints.
2. How do you approach user research when you have very limited time or budget?
3. Describe a situation where your design was pushed back by engineering. How did you handle it?
4. How do you decide what to design first when you have multiple user problems on the table?
5. Tell me about a time you used data to change or validate a design decision.
6. How do you work with product managers to define the scope of a feature?
7. Describe your process for running usability tests. What do you do with the findings?
8. Have you ever disagreed with a stakeholder about a design direction? What happened?
9. How do you ensure your designs are accessible to users with different abilities?
10. What does your handoff process to developers look like, and how do you make sure nothing gets lost?
11. How do you measure the success of a design after it ships?
12. Tell me about a time a design you worked on failed or underperformed. What did you learn?

Q: Walk me through a project where you balanced user needs against business constraints.

*Situation:* I was the lead designer on a mobile onboarding flow for a fintech product. User research showed that people wanted a thorough verification process that felt trustworthy, but the business needed onboarding completed quickly to reduce drop-off.

*Task:* My job was to design a flow that met both requirements without making users feel rushed or unsafe.

*Action:* I mapped out every step in the existing flow and categorised each one as 'must-have for trust' or 'nice-to-have.' I ran a quick round of interviews with a small group of target users to find out which steps actually built their confidence and which felt like unnecessary friction. I then proposed a progressive disclosure model: we moved non-critical steps to a post-onboarding checklist, and I worked closely with engineering to make sure the remaining steps loaded quickly.

*Result:* The revised flow launched and, based on product analytics the team reviewed internally, drop-off during onboarding fell significantly. Stakeholders were satisfied that the business metric improved, and users in follow-up interviews reported that the process felt straightforward and trustworthy.

---

Q: Tell me about a time you used data to change a design decision.

*Situation:* We had shipped a new navigation structure for a SaaS dashboard. After a few weeks, the product team noticed that a key feature was being used far less than expected.

*Task:* I needed to figure out if the drop in usage was a design problem and, if so, fix it quickly.

*Action:* I pulled session recordings and heatmaps from our analytics tool and found that users were not discovering the feature because the new navigation buried it several levels deep. I also ran a short unmoderated usability test with a handful of existing users to confirm the hypothesis. With that evidence in hand, I presented two redesign options to the product manager, with estimated development effort for each.

*Result:* We shipped the lighter option within the same sprint. Feature usage recovered, and the exercise became a reference case internally for why we should test navigation changes before full rollout.

---

Q: Describe a time a design you worked on underperformed. What did you learn?

*Situation:* Early in my career I designed a self-serve reporting tool for an internal operations team. I was confident in the solution because I had done a thorough competitive analysis.

*Task:* My goal was to help the ops team generate their own reports without depending on the data team.

*Action:* I designed a drag-and-drop builder, built a prototype, and got sign-off from the product manager. I skipped direct user interviews because I assumed the ops team's workflow was straightforward.

*Result:* After launch, adoption was low. When I finally spoke to the ops team, I learned their mental model for data was completely different from what I had assumed. The biggest lesson I took away: never skip primary research just because a problem seems familiar. I now treat user interviews as a non-negotiable first step, even for internal tools.

The STAR format (Situation, Task, Action, Result) works well for behavioural questions like 'tell me about a time...' Keep Situation and Task brief, spend most of your time on Action (what you specifically did), and always close with a concrete Result, even if the numbers are internal metrics you cannot share publicly.

For portfolio walkthroughs, use the Problem, Process, Decision, Outcome structure. Start with the user problem you were solving, not the visual output. Explain one or two key decisions you made and why, then share the outcome. Interviewers at VIEWS are typically more interested in your reasoning than in polished visuals.

For 'how would you design X' prompts, use a structured thinking-out-loud approach: clarify the goal, define the user, list constraints, sketch a few directions, and then narrow down with a reason. Do not jump straight to a solution. Asking clarifying questions first signals strong product design thinking.

For stakeholder conflict questions, lead with empathy. Show that you first tried to understand the other person's concern before pushing your own view. End with what you agreed on, not who 'won.'

Candidates report that VIEWS interviewers look for a few qualities above everything else.

Clear design reasoning. They want to hear why you made a decision, not just what you made. If you cannot explain the user problem and the trade-off you navigated, the portfolio piece will not land well.

Comfort with ambiguity. Product design roles at VIEWS typically involve working on problems that are not fully defined. Interviewers look for candidates who ask good questions, structure vague problems, and move forward without needing every detail handed to them.

Cross-functional collaboration. VIEWS product designers work closely with product managers and engineers. Expect questions about how you handle disagreements, how you communicate design decisions to non-designers, and how your handoffs work.

Ownership and follow-through. Interviewers want to see that you care about what happens after a design ships. Candidates who can talk about post-launch metrics, user feedback loops, and iteration cycles tend to stand out.

Research-led thinking. Even in fast-moving environments, VIEWS reportedly values designers who ground decisions in user evidence rather than personal taste.

One to two weeks before the interview:

Pick three to four projects from your portfolio that each show a different skill: one that highlights user research, one that shows cross-functional collaboration, one that involves a design system or component work, and one where something went wrong and you recovered. Prepare a short walkthrough for each using the Problem, Process, Decision, Outcome structure.

One week before:

Research VIEWS. Look at their product publicly, identify at least two UX decisions you find interesting, and be ready to discuss them. Candidates who arrive knowing the product make a noticeably better impression.

Prepare answers to the twelve questions listed above. Write them out in STAR format first, then practice saying them aloud until they feel natural, not memorised.

Two to three days before:

Do a mock portfolio walkthrough with a friend or a designer peer. Ask them to interrupt you with questions, because that is what VIEWS interviewers typically do. Practice staying calm and on-structure when interrupted.

Day before:

Review your portfolio one more time. Make sure every case study leads with the user problem in your opening. Prepare two or three thoughtful questions to ask the interviewer about design culture and team structure at VIEWS.

While you are doing all this prep, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you, so you can focus on interview practice rather than manually tracking down listings.

Skipping the user problem. Many candidates open a portfolio piece with 'I designed a dashboard' rather than 'users were struggling to find X.' Start with the problem every time.

Vague STAR answers. Saying 'I worked with the team to improve the design' is not a STAR answer. Specify what you did personally, what decision you made, and what the result was.

Defending every decision. If an interviewer challenges a design choice, candidates who get defensive lose points. Show that you can hold your reasoning lightly, consider new information, and update your view.

Ignoring the business context. Product designers at VIEWS work on products with real commercial goals. Candidates who talk only about user delight without connecting it to business outcomes miss a key signal interviewers look for.

Over-preparing visuals, under-preparing narrative. A beautifully formatted Figma file will not save you if you cannot explain the thinking behind it. Spend more time on your story than on polishing screens.

Not asking questions. Candidates who ask nothing at the end of the interview signal low curiosity. Prepare at least two genuine questions about the team, the product direction, or what success looks like in the role.