Polly D’Arcy leads the product design organization at Wealthsimple, a company known for its beautiful product, forward-thinking brand, and, as is right there in the name, a relentless commitment to keeping things simple.
But as every good designer (or researcher or product person or engineer) knows: simple is freaking hard! So of course, this, Polly knows.
Polly started at Wealthsimple as a Senior Product Designer working alongside Danielle, and has grown with the company ever since, to her role now as VP of Design. She knows the brand and product inside and out and leads with strong taste; she’s also a great people leader who’s highly strategic, gives direct and honest feedback, and able to see whats around the corner.
These days, like many of us, Polly is rewriting how her team defines and scales taste in a world where everyone can ship, and more can ship than ever. We chatted with her about how she and her team are scaling simplicity.
Below is an edited summary of our conversation.
🎧 You can listen to the full conversation on Apple Podcasts, Spotify, or wherever you get your podcasts.
We discuss:
The two eras of quality challenges at Wealthsimple: how a few years ago their biggest problem was bugs, and now it’s increasingly inconsistent experience
Making a product that feels designed by one person, not five hundred
How to signal conviction, and what to do about the polished AI prototype somebody thought about for five minutes
Why a vision is for pushing people to think bigger, not for predicting where the UI is going
The TASTE.MD file encoding judgment for agents and humans, instead of trying to scale a single designer’s eyes
You’ve been at Wealthsimple for seven years, growing from Senior Product Designer to VP. How has it changed?
When I joined, we were maybe 250 people. Five designers sat together in one little pod as a centralized service team, and Danielle and Marta1 were the researchers. My job looked nothing like it does today, but being an individual contributor first is what’s made me useful as a leader. I know what it’s like to work with engineering, to stay close to customers, to use the product myself.
The middle years were hyper-growth, especially through COVID, and two things happened. Design specialized: we went from designers who’d work on onboarding one day and tax the next to designers embedded on specific teams. And “growth at all costs” meant quality suffered. We didn’t have time to go back and fix things, so the paper cuts piled up. My first real mandate in leadership was to solve that, as a culture and not just a backlog.
Now it’s a different problem. Since January we’re shipping about three times faster. Engineering isn’t the scarce resource anymore, and all of a sudden anyone can ship anything, which is both liberating and sort of terrifying. It makes clear who has great judgment, and how valuable that is. Before, it felt like we couldn’t do all the things we wanted to. Now we can, and the question is whether we should be doing them all at once.
The other thing on my mind is that my job is to make sure our app feels like it was designed by one person, not 500. We’ve asked teams to focus on their own problem and their own customer, which means lots of localized decisions. Each product is great. Zoom out and the connections between them are still a gap.
Wealthsimple’s product is, of course, simple. The first time Dave used it, it was just two steps to set up an account and almost felt too simple. How do you think about that balance?
Back when Danielle and I first worked together, the goal was that a customer could open an account, fund it and start investing within about a day (maybe three, at the time). Now the goal is instant. At most banks you still have to call someone or walk into a branch, and that’s still our edge. But I was at a barbecue recently and heard a new customer say onboarding “only took half an hour,” and my thought was: half an hour is so long. I’m always trying to shave minutes.
But it’s people’s money. We’re serving sophisticated investors and people doing it for the first time, so there’s a real trade-off between making things accessible and making sure people understand what they’re doing.
What did the AI shift actually look like inside your team?
January to March was a fever dream. AI panic, everyone on X (formerly Twitter) saying we’re not doing enough, we’re so behind. So we did what most companies did: got every designer shipping PRs, prototyping, trying every tool that showed up.
A lot of good came out of it. Designers were empowered to fix the small things they saw instead of waiting for a roadmap slot. But at one point engineers said, stop prototyping. Where are the Figmas? How are we supposed to review what we’re building? We’d overcorrected.
The bigger consequence is what I call design drift. When everyone can tweak a component because it doesn’t quite fit their use case, you end up with five different versions of the same modal.
The old quality problem was bugs and jank. The new one is that we have all this beautiful UI, and none of it agrees with itself. That’s us shipping our org chart, and customers will feel it.
Prototypes are everywhere now, and it’s getting harder to tell what’s real. How do you keep critique honest?
We used to say the level of fidelity should represent your level of conviction. Now I’ll see a super polished AI prototype that looks like production, and the person thought about the problem for five minutes. It looks like we’re about to ship it. That’s where judgment and picking the right tool at the right time come in.
To be fair, reviewing work in prototype form makes it more real, and I think we’re having better conversations and the work is getting better. But you have to guide people: this should be more of a wireframe, because we’re not sure about those details yet.
People think leaders are supposed to have answers. How do you reconcile that with the need to adopt AI before we do?
I’ve made peace with that. Yes, we hyper-reacted, and we built tools we didn’t need. But I couldn’t wait three months to decide, and we learned a lot, which led to better tools. You learn by doing.
I was listening to Ina Garten’s new podcast and she quoted J.P. Morgan: go as far as you can see, and when you get there, you’ll be able to see further. That’s my approach to leadership right now. People ask for my vision for the next three years, and that’s not how this works. I don’t have a version of the app we’ll be using in three years, because we might not be using apps. So I try to give people permission to try things and make mistakes.
For me, a vision is more about pushing people to think bigger and understand where the business is going. It isn’t where the UI is going. Maybe we do nothing about a headless future for six months, but it’s important that people are thinking about it.
You can’t scale taste with vision, so what are you trying?
First, the right people. I have a couple of strong principal designers who sit with designers and set the bar by designing together, and having one person who defines our visual language, a creative director for the product, has been incredibly effective. We debated whether a leadership group should do that together. From experience, it doesn’t work. You need one person setting direction, the way a brand has one.
But one person can’t be in every meeting or work with every designer. That’s where TASTE.MD comes in. I think the future of great design is fewer screens and more systems: repeatable patterns that humans and agents can both use. TASTE.MD encodes the aesthetic choices (corner radius, typography, how we use texture and depth) and the decision-making logic behind them. When is motion appropriate? How do we establish hierarchy? When can a brand moment be splashy, and when quiet? Those are decisions designers rehash constantly, and two designers can disagree because it’s subjective. The point is that we make the decision, and you follow it.
It also helps when we design something net new, for a new audience, say. It’s an exercise in exploring, and it keeps the result feeling like Wealthsimple. It’s useful for humans too, because it answers “how do we design here?”, which has always been hard to teach through a design system alone. We update it, see what Claude spits out, and go “ooh, not quite.” And it still takes talented designers with good taste to tell it what to do.
Next to that, I want to rethink how we’re organized. There was a great talk at Figma’s conference about how your org shouldn’t look like a perfectly genetically modified tomato. It should look like the heirloom. I want our most talented people on the architecture of the product (interaction models, the design system, the net new stuff) instead of every team getting equal resource. And we’ve never had a notion of a design-led versus product-led versus engineering-led project. It’s all one process. When does design need to be there from the start to blue-sky, and when can it review later? I’ll probably approach it incrementally.
There’s resistance to designers shipping PRs, and to PMs and engineers designing. Are you seeing that?
From engineers, yes, and they should be nervous. Some of it is complex and needs real review. Through the process we’ve gotten better at knowing what’s appropriate to take on, and when to pause and hand it back to an engineer. Our culture biases toward action, and we’d much rather someone try, fail and fuck something up than not try at all.
It’s messy, though. We have an internal agent in Slack called Compass that lets you ship PRs, and part of building with Claude is that no one can see it. Three people could be working on the same PR and not know. I’d love for it to say, “someone’s working on that, maybe pause.” We’re willing to accept a certain level of chaos.
On PMs prototyping, I love it. It’s more effective to show than tell, and they’re not saying “ship this verbatim,” they’re getting an idea out of their head.
Lightning round
Best leadership advice you’ve received?
Early in this role, a VP of product, Tim, told me that cynicism is not a leadership trait.
Leadership takes a slightly unreasonable amount of optimism: believing people can do better, that the hard problems are solvable, that smooth waters don’t make great sailors.
I felt pretty isolated back then, and having peers say that when I needed to hear it helped a lot. I still go to sleep some nights with no idea how I’ll solve something, but knowing that we will.
Work bestie shout-out?
Two, actually: Tim Kalimov, VP of Product on banking, and John, a VP of front-end engineering. We have a group chat where we process things together. Tim is the cynicism-is-not-a-leadership-trait guy and is so optimistic, a ball of energy. I’ve learned the most from peers leading different teams, because I understand the business through product and how we build through engineering.
Polly’s plugs: If you’re Canadian, go check out Wealthsimple. The team is always hiring designers and writers, and she’d love to meet more people in design, so feel free to hit her up on LinkedIn.
Huge thank you to Polly for sharing what she and her team are working through, in real time and without pretending to have all the answers.
Marta, formerly a researcher at Wealthsimple on Danielle’s team, then on Polly’s team, and now works on Dave’s team at 1Password — hi, Marta! 👋
taste.md is the idea that survives the interview. scaling one designer's taste doesn't work, but writing the judgment down in a file both humans and agents can read is the closest thing to a real answer. design drift at 3x shipping speed is just what happens when everyone tweaks components and nobody owns the whole.
the conviction-to-fidelity rule is the quieter one i like more. most prototypes are built at whatever fidelity was fastest, which means every idea looks equally finished and the feedback lands on the wrong layer.
question for the builders reading: does taste.md live next to the component code, or is it documentation that rots? the location decides whether agents actually read it.
The Compass detail is easy to skim past: if three people can unknowingly work the same PR through an agent, the team pays for the same fix three times and then pays again to reconcile the versions. Agent work needs the same visible claim on a task that a person creates by taking a ticket, otherwise the speed gain leaks out as duplicate effort.