Decoding the PennyLane Design Case Study: A Live Simulation for Product Designers

Recently, I had the opportunity to observe a live design case study simulation with Yasmina and Alice, Product Designers at PennyLane. This session provided invaluable insights into PennyLane's expectations for product design candidates, focusing on their thought process, methodology, and collaborative approach rather than just the final solution.

Yasmina, a Product Designer with 6-7 years of experience who joined PennyLane over 4 years ago, shared her perspective from having conducted many interviews. Alice, who joined PennyLane 8 months ago and has 8 years of experience, offered a fresh perspective on the recruitment process. It's worth noting that PennyLane doesn't necessarily seek candidates with a background in fintech or accounting; these skills are learned on the job.

PennyLane's Product Team & Hiring Philosophy

PennyLane is a 6-year-old B2B SaaS platform for accounting and financial management, enabling collaboration between companies and accounting professionals. The company has over 1000 employees and approximately 35 product squads.

The product design team currently comprises around 50 designers (individual contributors and managers) and expects to grow to 60 by the end of the year. The team is structured by "Tracks," which are large thematic areas like accounting or financial services management.

PennyLane looks for "full-stack designers" capable of handling the entire product lifecycle:

• Discovery
• Roadmap management and challenging Product Managers (PMs)
• Delivery
• Impact measurement

They value a diversity of profiles and experiences within the team. While primarily seeking senior profiles, they are exploring opening positions for junior designers.

The 5-Step Recruitment Process & Case Study Focus

PennyLane's recruitment process typically involves five stages. Today's session focused on the "Case Study" stage, which is often eliminatory. In each stage, candidates usually meet two people.

During the case study, PennyLane assesses a mix of hard and soft skills. It's crucial to understand that they are looking to understand your reasoning, methodology, and decision-making process much more than the final solution.

What PennyLane Evaluates:

• Soft Skills:
  • Communication: Clarity, storytelling, ability to engage the audience.
  • Collaboration: How you work with various stakeholders within the squad and track.
• Hard Skills:
  • Methodology: The approach you put in place.
  • Argumentation: How you justify your choices.
  • Problem Framing: How well you define and scope the problem.
  • Data Usage: How you leverage qualitative and quantitative data.
  • Craft: Design execution (though not the primary focus).

"What we're really looking to understand is your reasoning, your methodology, the way you make decisions, much more than the final solution that will be proposed during the case study."

The Case Study Exercise: A Live Roleplay

The session simulated a case study interview, with Yasmina as the interviewer and Alice as the candidate. The brief is typically sent a few days to a week in advance via email, along with Figma screens containing initial information. It's a fictional subject, not a real PennyLane project.

The Fictional Brief: AS Rashield

The case study revolves around "AS Rashield," a B2B SaaS platform in a similar universe to PennyLane, designed to help companies manage access to internal tools (e.g., Jira, GitHub, Salesforce).

The Core Problem: Improve the flow for requesting and approving tool access. How to ensure the right person gets access to the right tools? The brief includes qualitative data and verbatim user feedback. Candidates are asked to improve the existing flow and screens.

Alice's Approach: A Candidate's Perspective

Alice presented her case study, demonstrating a senior designer's thought process.

1. Introduction & Context Setting

Alice began by introducing the project context and user benefits.

• Problem Statement:
  • Requester side: "waiting times of several days."
  • Approver side: "validations on permissions they had difficulty interpreting."
• Objective: Reduce waiting time for requesters and restore approver confidence, thereby reducing security risks.
• Acknowledging Data Limitations: Alice clearly stated that she didn't have access to users or analytics (a common scenario in case studies) and explained how she would compensate by focusing on the brief and external research.

"What's really interesting in this first approach is that both the title and the tagline of the project show the direction she's taking... She doesn't just give a generic title; she puts herself in the shoes of the product designer and immediately involves us in her methodology." "She also explains how she circumvents these constraints, and that immediately gives a very senior posture because, in real life, we can also have difficulties accessing users or tracking that isn't in place."

2. User Voice & Data Analysis

Alice strategically used user verbatim and quantitative data from the brief to build her argument.

• Key User Verbatim: An approver states they receive "10 to 15 per day, all similar, and ultimately approves to clear the queue."
• Interpretation: The word "vider" (to clear) suggests mental overload, where the approver seeks to complete the task rather than make the best decision, leading to "approval by default."
• Quantitative Data Link:
  • 28% abandonment at step 2 (role selection).
  • 33% of justifications are empty or one-word.
• Conclusion: "One-third of these justifications are unusable. Consequently, a quarter of these requesters drop off, which isn't just cosmetic friction. These are strong signals that the flow's architecture discourages its own completion."

"Alice highlights user verbatim as the primary reason for the subject's interest, but she also immediately links it to quantitative data. Little by little, she leads us in her direction. It's part of her storytelling to mix quanti and quali and draw a lesson from it." "This shows how she used and sorted the data provided to immediately bring understanding, which is really what we look for in data usage."

3. Competitive Benchmark

Alice included a competitive analysis, an often-skipped but valuable step.

• Observation: Mature competitors consistently display three levels of information: a risk level, a recommended decision, and a clear explanation of what the role permits.
• Principle: This aligns with "recognition rather than recall," presenting information directly to users instead of making them reconstruct meaning from memory.
• Gap Analysis: AstraShield offers none of these, representing "a competitive delay."

"What's interesting in her benchmark, which is a step we don't always see, is that she not only states 'I did a benchmark, others do this, you do that,' but she clearly explains her analysis. She provides insights from her analysis without losing her audience... She brings clarity to this analysis, draws lessons from it, and also business insights, showing that she considers this aspect in her thinking, which is also what we expect from a designer at PennyLane."

4. Reframing the Problem & Design Angle

Alice moved beyond a surface-level problem statement to identify the core issue.

• Initial Problem: Approvers validate without context; requesters submit without confidence. Optimizing this alone would lead to a "better form but not necessarily a better decision."
• Real Problem to Solve: The user's actual task is not just "processing a request" but "making a reliable decision in very little time."
• Design Focus: "I will therefore design for the moment of decision. What information, where, in what form, for whom, and the 30-second limit I set is not a formula, it's a kind of explicit mental budget that will filter all my design decisions."

"She doesn't settle for a classic, sometimes forced 'how might we' problem framing. Instead, she precisely describes the problem raised by the brief... But she goes even further by highlighting the real problem to solve: how to enable people accepting requests to make a quick decision... This is again proof of seniority, showing that she didn't just stick to the surface problem given by the brief, but really dug deep to the core issue."

5. Hypotheses & Prioritization

Alice clearly outlined two hypotheses and their strategic prioritization for implementation.

• Hypothesis 1: Context Problem

  • Solution: More information at the relevant moment.
  • Measurement: Shorten "time to decision."
  • Direction: Enhance existing roles with clear descriptions and previews.
  • Implementation Strategy: Proposed as V1 – "integrated context on the line," identified as "high impact and low effort." This is the "least costly bet to test the most structural hypothesis."

• Hypothesis 2: Justification Urgency

  • Solution: Help users associate urgency with their decision.
  • Measurement: Look at completed fields with generic options.
  • Direction: Attribute a score based on usage history and role sensitivity (using machine learning).
  • Implementation Strategy: Deferred to V2 ("automated score"). This "assumes a volume of qualified data that we don't have at the start," so building it now would be "over-investing in sophisticated things before validating the need."

"Prioritization is often missed... It's crucial for us to be able to demonstrate that there are several solutions to the same problem, and especially how and why we ultimately choose one solution over another based on impact and effort... This strategy is an extremely important aspect of our daily lives at PennyLane: being able to challenge roadmaps, prioritize, and question a solution or even a problem posed by PMs."

6. Solution Presentation

Alice presented her solutions by contrasting the initial state with her proposed changes, highlighting the UX, UI, and UX writing impact.

• Initial State: Role is too technical, justification illegible, approver has no context.
• Proposed Solution (V1 - Approver View):
  • On the same line, without interaction: Risk level, recommendation, role, and possible actions are displayed clearly.
  • Justification is structured and linked to a ticket.
  • Visual weight is indexed on the risk of the element.
• Proposed Solution (Requester Flow - Reducing 4 steps to 3):
  • Step 1: Choose Tool
    • From scrolling list to catalogue of 32 tools with search and intelligent default choices (based on team type, most requested).
    • Real logos instead of generic icons for immediate recognition.
  • Step 2: Choose Role
    • From a dropdown with 20+ entries to a selector with search and filtering (reducing decision time).
  • Step 3: Justify and Submit (fusion of old steps 3 & 4)
    • Five predefined motifs replace the empty justification field.
    • A minimal counter encourages precision.
• Net Effect: Risk exposed before submission, roles become intelligible, justification is faster to read.

"She could have simply guided us through her Figma and provided a voiceover, but she chose to highlight the most important steps and emphasize the UX, UI, and UX writing impact... This not only makes the solution sensible but also conveys a sense of depth in her proposal, mastery, and clarity."

7. Validation & Impact Measurement

Alice detailed her validation strategy, defining specific testing methods, validation criteria, and success metrics.

• Pre-Implementation Validation:

  • Method: Unmoderated user tests with 8-10 participants using prototypes.
  • Validation Criteria: 80% of participants complete approval in less than 25 seconds without help, and the risk badge is spontaneously noticed.
  • Invalidation Criteria: Under 60% completion or systematic confusion of the risk badge, requiring redesign.

• Post-Implementation Validation (in production):

  • Method: A/B testing with real data.
  • Validation Criteria: Over 10 percentage point increase in completion at Step 2 (the critical step) without regression in submission rate.
  • Invalidation Criteria: Regression of more than two percentage points.

• Defining Positive Impact Metrics:

  • From Brief:
    • Abandonment at Step 2: From 28% to <10%.
    • Empty justifications: From 33% to <10%.
  • Added Metric (not in brief, but proposed):
    • Median approval time: Establish a baseline in week 1, target a 50% reduction in 90 days.

"This is extremely interesting and shows a real level of experience and seniority: she precisely describes the testing method she would use... She defines thresholds beforehand that would guarantee whether to proceed with this solution or whether to go back and work on it. And then, regarding the measure of project success, she not only reuses data from the brief but also offers a strong opinion on what she imagines is possible... but she also proposes a metric not in the brief, which she considers important."

8. Collaboration Strategy

Alice outlined how she would integrate her work into a collaborative framework with stakeholders.

• Key Rituals:
  • Weekly syncs with PMs: To facilitate early arbitration and document decisions in writing.
  • Short, asynchronous videos for developers: To document solutions, user flows, and prototypes more comprehensively than text.
  • Design System alignment checks: To prevent design-to-code discrepancies.
  • Progressive deployment with QA: Close monitoring in the first weeks post-release.

"Alice allows us to concretely project how she would work and collaborate with stakeholders. This is incredibly valuable... it helps de-risk the question of fit... By showing how you collaborate with your main stakeholders, interviewers can project: 'Okay, my daily life with this designer, or if this person joined the team, it could look like this.' And that removes ambiguity, which is quite key in the choices we make as interviewers and recruiters."

9. Learnings & Retrospective

Alice concluded by summarizing her key takeaways from the project, demonstrating self-reflection and growth mindset.

• "Less is often more" (Le plus est souvent l'ennemi du bien): For approvers, adding more options would have been detrimental. The focus should be on removing and clarifying, not just adding new features.
• Design with constraints: Redesigning role taxonomies controlled by external company structures would be costly with little result. It was better to design around this constraint.
• Early stakeholder collaboration: Involves people more in the solution and reveals technical/business blockers early on.

"Learnings, even on a case study, we can learn things. It's always quite interesting to see. It also helps understand what grabs the candidates' attention, to open discussion on these learnings, to see their appetite for personal growth... these are bonus points during the interview."

Key Takeaways for Candidates (from PennyLane)

Yasmina and Alice summarized their key advice for candidates based on their experience:

• Help us project your thinking: Explain your methodology, how you construct hypotheses even without user access.
• Justify your positions: Be able to defend your choices.
• Figma Hand-off Quality: PennyLane uses Figma extensively. Show well-structured and organized Figma files.
• Don't Forget UX Writing: Pay attention to the copy; it's a critical part of the user experience.
• React to Feedback Constructively: Demonstrate a collaborative, building posture, not a defensive one.

"We generally ask you to help us project into your thinking, your methodology. Even if you don't have access to users, tell us how you would do it, how your hypotheses are built, etc. That's ultimately what matters most."

Q&A Highlights: Deeper Dive into PennyLane's Culture

The session concluded with a Q&A, offering further insights into PennyLane's internal practices and expectations.

AI Integration at PennyLane

• AI is increasingly integrated into daily workflows, from Notion-based documentation queries to rapidly iterating on solutions.
• There's a structured approach to help product teams gain AI proficiency.
• However, designers are not expected to "ship code" or completely abandon traditional tools like Figma, especially for a large-scale company.

Estimating Gains in Case Studies

• Alice emphasized that experience and familiarity with metrics (acquisition funnels, retention) help.
• When data is lacking, clearly state assumptions as hypotheses that would be validated in reality.
• Connect proposed measurements to broader squad or company objectives. The "what" to measure is often clear; the "how much" might be an estimate. The logic behind the measurement is crucial.

Case Study Preparation Time

• The case study is sent about a week in advance.
• PennyLane advises against spending excessive time (e.g., 20+ hours) on it, as it's not meant to consume an entire weekend.
• Prioritization is key: showing too much, even if well-done, can suggest poor prioritization. Focus on what has the most impact.

Using Non-Figma Tools & AI

• Using tools like Claude or other advanced prototyping tools is becoming more common and accepted.
• Such tools can be particularly effective for communicating complex micro-interactions that are hard to convey in static Figma mockups.
• The advice is to use good judgment: don't abandon Figma entirely if it's the core workflow, but leverage other tools for specific needs.

The PennyLane Design System

• PennyLane provides its design system to candidates, so they don't have to build components from scratch. The focus is on problem-solving, not component creation.

The Product Designer Role at PennyLane

• Designers have significant "ownership and autonomy" within their squads.
• They operate within a "Troika" structure alongside the Product Manager (PM) and Engineering Manager (EM), making decisions at the same level.
• This role requires a business-oriented mindset, strong justification skills, and the ability to challenge PM proposals. It's not solely craft-focused.
• The "Shape Up" methodology (adapted to their needs) influences their project cycles and rituals, requiring designers to engage in "vision-building" for future semesters.

PennyLane's Expectations vs. Other Scale-ups

• Expectations at PennyLane are high but are perceived as aligned with the real-world demands of the role.
• This is common for scale-ups, especially those operating with a "trio" model (PM, Designer, EM) where designers need to be proficient in discussions across various disciplines.
• The complexity of their B2B SaaS product in the accounting domain also necessitates a higher level of rigor and understanding.

Internal Domain Experts

• PennyLane integrates "domain specialists" (qualified accountants, chartered accountants) into product teams.
• These experts provide valuable feedback, challenge solutions, and help upskill the teams.
• Easy access to user communities for feedback and testing is also a significant advantage.

Actionable Takeaways for Aspiring Product Designers

Based on this deep dive into PennyLane's design case study process, here are some actionable tips:

• Beyond the Solution: Focus intently on articulating how you arrived at your solution. Your reasoning, methodology, and decision-making process are paramount.
• Strategic Problem Framing: Don't just rehash the given problem. Dig deeper to identify the core user and business problem you are truly solving.
• Data-Driven Storytelling: Weave qualitative and quantitative data into a compelling narrative that supports your analysis and proposed solutions. Explain why certain data points are significant.
• Prioritize and Justify: Always present multiple solution directions and clearly explain your prioritization based on impact, effort, and strategic fit.
• Comprehensive Validation: Detail your testing methods (e.g., user tests, A/B tests), define clear validation/invalidation criteria, and set measurable success metrics (both those provided in the brief and new, relevant ones you propose).
• Collaborative Mindset: Show how you would work with PMs, engineers, and other stakeholders. Outline specific rituals or communication strategies.
• Reflect and Learn: Conclude with genuine learnings from the case study, demonstrating a growth mindset and ability to extract insights from any project.
• Figma Excellence: While creativity is key, ensure your Figma file is well-structured, organized, and includes attention to UX writing.
• Embrace Constraints: Show how you design with existing constraints (technical, business, organizational) rather than trying to bypass them unrealistically.