Stripe Internship | Summer 2026
Redesigning Stripe’s compliance cards to help platform operators identify regulatory risk and know where to act first.
Timeline
Summer 2026
My Role
Product Strategy, Research Synthesis, Interaction Design, Systems Thinking, AI-Assisted Exploration, Prototyping
THE OPPORTUNITY
The cards were built for one ORR. Then one became many.
When Compliance Hub was initially created, most platforms were dealing with one major ORR at a time.
In that world, the simple cards worked well enough. An operator could see Europe, click into it, then use the detail page to understand account status, migration progress, payment volume, requirements and timelines.
The cards were also understood internally as a relatively lightweight starting point that would eventually need more attention.
Then the product environment changed. Europe was active. Brazil was being introduced. Singapore was coming next. Operators could now be responsible for multiple ORRs at different lifecycle stages at the same time.
The old model no longer scaled.
Quick Context
ORR = Onboarding Requirement Refresh
When regulations change in a region, Stripe may need platforms to collect new or updated information from their connected accounts. An ORR is how Stripe manages that update.
Stripe Connect lets platforms such as marketplaces and SaaS businesses manage payments for networks of connected accounts.
Compliance Hub gives the teams operating those platforms a place to monitor compliance activity across their connected accounts
Original Compliance Hub: Requirement updates appeared as simple region rows. Details are only avaliable
The Challenge
How might we surface just enough information to help operators prioritize, without recreating the detail page inside every card?
PROCESS
AI gave me breadth before I had clarity.
The ORR detail page contained dozens of signals I could theoretically bring into the overview.
Migration percentage. Status. Restricted accounts. Payment volume. Requirements. Trends. Deadlines. Badges.
I used Claude early to explore alternative card structures and information hierarchies quickly, producing roughly a dozen initial explorations.
When I brought the explorations into my team critique, the most useful feedback wasn’t about which layout looked best. It was that I was exploring before I had clearly defined a direction.
I then, reframed the work around two questions that an operator should be able to answer::
- Does this ORR need my attention?
- If yes, which do I act on first?
Key decison: I stopped optimizing for progress and started optimizing for action.
One of my favorite early directions used segmented progress bars to show how many accounts had migrated, were approaching restriction or were already restricted.
I liked how quickly the visualization communicated completion.
How far along are we?
But it answered:
When the more important question was,
A platform could be mostly migrated and still have an important group of active accounts approaching restriction.
Where can I still intervene?
Successfully migrated accounts no longer require intervention. Restricted-soon accounts do.
Thus, Restricted soon became the primary signal.
The segmented bars also became harder to scan when repeated across several ORRs. Multiple colors and legends introduced another layer of interpretation, something I had already flagged in my explorations.
FINAL
Every signal had to answer a different question.
Once I prioritized actionable risk, the rest of the card became an exercise in restraint. Each signal needed to help an operator understand either where to act, why it mattered, or what was driving the risk.
TAKEAWAYS
Understand the user’s needs
This is one of the first things we learn as designers but defining what the card needed to help operators decide made it much easier to determine which information actually deserved space.
Explore with direction
I learned that broad exploration is most useful once the problem and decision criteria are clear, otherwise more options can just create more noise.
Using AI
This was my first time using AI throughout a real product-design project, and it showed me how useful it can be for exploring faster while still relying on research, critique, constraints, and judgment to choose what survives.
The 12 weeks I spent at Stripe were incredible. I’m especially grateful to my manager Aishwari Vaidya for being so supportive, patient, and generous with her guidance throughout the summer. I learned so much from having the space to ask questions, share unfinished work, and grow into the role.
Thank you as well to the rest of my team and to my fellow interns for making the summer such a memorable one.
And a special shoutout to Efan Song, who was such a constant source of support throughout the internship. Having another design intern to learn alongside, talk things through with, and lean on made the experience that much better. ❤️
Lets connect!
Resume
Stripe Internship | Summer 2026
Redesigning Stripe’s compliance cards to help platform operators identify regulatory risk and know where to act first.
Timeline
Summer 2026
My Role
Product Strategy, Research Synthesis, Interaction Design, Systems Thinking, AI-Assisted Exploration, Prototyping
THE OPPORTUNITY
The cards were built for one ORR. Then one became many.
When Compliance Hub was initially created, most platforms were dealing with one major ORR at a time.
In that world, the simple cards worked well enough. An operator could see Europe, click into it, then use the detail page to understand account status, migration progress, payment volume, requirements and timelines.
The cards were also understood internally as a relatively lightweight starting point that would eventually need more attention.
Then the product environment changed. Europe was active. Brazil was being introduced. Singapore was coming next. Operators could now be responsible for multiple ORRs at different lifecycle stages at the same time.
The old model no longer scaled.
Quick Context
ORR = Onboarding Requirement Refresh
When regulations change in a region, Stripe may need platforms to collect new or updated information from their connected accounts. An ORR is how Stripe manages that update.
Stripe Connect lets platforms such as marketplaces and SaaS businesses manage payments for networks of connected accounts.
Compliance Hub gives the teams operating those platforms a place to monitor compliance activity across their connected accounts
Original Compliance Hub: Requirement updates appeared as simple region rows. Details are only avaliable
The Challenge
How might we surface just enough information to help operators prioritize, without recreating the detail page inside every card?
PROCESS
AI gave me breadth before I had clarity.
The ORR detail page contained dozens of signals I could theoretically bring into the overview.
Migration percentage. Status. Restricted accounts. Payment volume. Requirements. Trends. Deadlines. Badges.
I used Claude early to explore alternative card structures and information hierarchies quickly, producing roughly a dozen initial explorations.
When I brought the explorations into my team critique, the most useful feedback wasn’t about which layout looked best. It was that I was exploring before I had clearly defined a direction.
I then, reframed the work around two questions that an operator should be able to answer::
- Does this ORR need my attention?
- If yes, which do I act on first?
Key decison: I stopped optimizing for progress and started optimizing for action.
One of my favorite early directions used segmented progress bars to show how many accounts had migrated, were approaching restriction or were already restricted.
I liked how quickly the visualization communicated completion.
How far along are we?
But it answered:
When the more important question was,
Where can I still intervene?
A platform could be mostly migrated and still have an important group of active accounts approaching restriction.
Successfully migrated accounts no longer require intervention. Restricted-soon accounts do.
Thus, Restricted soon became the primary signal.
The segmented bars also became harder to scan when repeated across several ORRs. Multiple colors and legends introduced another layer of interpretation, something I had already flagged in my explorations.
FINAL
Europe
Every signal had to answer a different question.
Once I prioritized actionable risk, the rest of the card became an exercise in restraint. Each signal needed to help an operator understand either where to act, why it mattered, or what was driving the risk.
Key decison: I stopped optimizing for progress and started optimizing for action.
Most platforms were unlikely to manage more than two or three ORRs at once, but I designed the experience to remain usable with up to six.
I liked how quickly the visualization communicated completion.
TAKEAWAYS
Understand the user’s needs
This is one of the first things we learn as designers but defining what the card needed to help operators decide made it much easier to determine which information actually deserved space.
Explore with direction
I learned that broad exploration is most useful once the problem and decision criteria are clear, otherwise more options can just create more noise.
Using AI
This was my first time using AI throughout a real product-design project, and it showed me how useful it can be for exploring faster while still relying on research, critique, constraints, and judgment to choose what survives.
The 12 weeks I spent at Stripe were incredible. I’m especially grateful to my manager Aishwari Vaidya for being so supportive, patient, and generous with her guidance throughout the summer. I learned so much from having the space to ask questions, share unfinished work, and grow into the role.
Thank you as well to the rest of my team and to my fellow interns for making the summer such a memorable one.
And a special shoutout to Efan Song, who was such a constant source of support throughout the internship. Having another design intern to learn alongside, talk things through with, and lean on made the experience that much better. ❤️
Lets connect!
Resume
Stripe Internship | Summer 2026
Redesigning Stripe’s compliance cards to help platform operators identify regulatory risk and know where to act first.
Timeline
Summer 2026
My Role
Product Strategy, Research Synthesis, Interaction Design, Systems Thinking, AI-Assisted Exploration, Prototyping
THE OPPORTUNITY
The cards were built for one ORR. Then one became many.
When Compliance Hub was initially created, most platforms were dealing with one major ORR at a time.
In that world, the simple cards worked well enough. An operator could see Europe, click into it, then use the detail page to understand account status, migration progress, payment volume, requirements and timelines.
The cards were also understood internally as a relatively lightweight starting point that would eventually need more attention.
Then the product environment changed. Europe was active. Brazil was being introduced. Singapore was coming next. Operators could now be responsible for multiple ORRs at different lifecycle stages at the same time.
The old model no longer scaled.
Quick Context
ORR = Onboarding Requirement Refresh
When regulations change in a region, Stripe may need platforms to collect new or updated information from their connected accounts. An ORR is how Stripe manages that update.
Stripe Connect lets platforms such as marketplaces and SaaS businesses manage payments for networks of connected accounts.
Compliance Hub gives the teams operating those platforms a place to monitor compliance activity across their connected accounts
Original Compliance Hub: Requirement updates appeared as simple region rows. Operators had to open each ORR to understand its state
The Challenge
How might we surface just enough information to help operators prioritize, without recreating the detail page inside every card?
PROCESS
AI gave me breadth before I had clarity.
The ORR detail page contained dozens of signals I could theoretically bring into the overview.
Migration percentage. Status. Restricted accounts. Payment volume. Requirements. Trends. Deadlines. Badges.
I used Claude early to explore alternative card structures and information hierarchies quickly, producing roughly a dozen initial explorations.
When I brought the explorations into my team critique, the most useful feedback wasn’t about which layout looked best. It was that I was exploring before I had clearly defined a direction.
I then, reframed the work around two questions that an operator should be able to answer::
- Does this ORR need my attention?
- If yes, which do I act on first?
Key decision: I stopped optimizing for progress and started optimizing for action.
One of my favorite early directions used segmented progress bars to show how many accounts had migrated, were approaching restriction or were already restricted.
I liked how quickly the visualization communicated completion.
But it answered:
How far along are we?
When the more important question was,
Where can I still intervene?
A platform could be mostly migrated and still have an important group of active accounts approaching restriction.
Successfully migrated accounts no longer require intervention. Restricted-soon accounts do.
Thus, Restricted soon became the primary signal.
The segmented bars also became harder to scan when repeated across several ORRs. Multiple colors and legends introduced another layer of interpretation, something I had already flagged in my explorations.
FINAL
Europe
Every signal had to answer a different question.
Once I prioritized actionable risk, the rest of the card became an exercise in restraint. Each signal needed to help an operator understand either where to act, why it mattered, or what was driving the risk.
I designed for multiple ORRS.
Most platforms were unlikely to manage more than two or three ORRs at once, but I designed the experience to remain usable with up to six.
I liked how quickly the visualization communicated completion.
TAKEAWAYS
Understand the user’s needs
This is one of the first things we learn as designers but defining what the card needed to help operators decide made it much easier to determine which information actually deserved space.
Explore with direction
I learned that broad exploration is most useful once the problem and decision criteria are clear, otherwise more options can just create more noise.
Using AI
This was my first time using AI throughout a real product-design project, and it showed me how useful it can be for exploring faster while still relying on research, critique, constraints, and judgment to choose what survives.
The 12 weeks I spent at Stripe were incredible. I’m especially grateful to my manager Aishwari Vaidya for being so supportive, patient, and generous with her guidance throughout the summer. I learned so much from having the space to ask questions, share unfinished work, and grow into the role.
Thank you as well to the rest of my team and to my fellow interns for making the summer such a memorable one.
And a special shoutout to Efan Song, who was such a constant source of support throughout the internship. Having another design intern to learn alongside, talk things through with, and lean on made the experience that much better. ❤️
Lets connect!
Resume