Dear Danielle,

As people leaders, often above all else, our priority is to ensure there’s stability on the team. We want people to stay for as long as possible. Durable team structure, enduring relationships, institutional knowledge and context, team dynamics and culture, peer retention: the list of benefits goes on.

Stability can also be quite beneficial politically. When everything changes but you, you and your team become the constant in the business. You become the go-to for said institutional knowledge and context. Stakeholders rely on you for continuity, an underrated yet critical component for the business when UX is the one team that focuses on driving customer empathy above all else.

Over the years I’ve enjoyed being that constant. But I’ve come to realize the stability I was protecting wasn’t always for my team. Sometimes it was for me.

The level of comfort and safety that comes with this stability can be dangerous. We fall into old routines, habits and worse yet, complacency. We tell ourselves “don’t fix what’s not broken.” The problem with this adage is that we often mistake comfort and stability for effectiveness. We prioritize the comforts of individuals and our own teams over what’s actually right for the people, the product and the business.

Picture someone who’s been on your team for years. They’re great at their job, everyone relies on them, and yet they’ve quietly hit a ceiling. They know it and you know it. The easy move is of course to keep them. They’re reliable, they know everything, and losing them would hurt.

And that’s exactly why keeping them can be the wrong call.

My hot take is this: keeping people on the team for the sake of comfort and stability is a selfish thing to do for a leader.

Instead of sitting in the comfort zone with the rest of the team, we as leaders should be actively encouraging and acting on change. That means coaching at both the individual and team level, encouraging people to explore other options when there’s no longer a fit, or simply when that’s the best path for their long-term career growth.

For the cynics out there: this isn’t about triggering change for the sake of it, or about managing people out. It’s about being honest with people sooner than is comfortable. As hard as it is, being a leader often means being the one to start the tough conversation.

The practical and human side of change isn’t lost on me. When people leave, leaders have the not-so-fun task of figuring out backfill plans, hiring, onboarding new people, etc. None of it trivial. For individuals, leaving a known role, team and culture is scary! You have to build everything from the ground up again, rebuild relationships, re-establish credibility, and integrate into an existing team and company culture that you have to learn. But fear isn’t the right reason to not do something, especially when there is a clear upside.

There are no formulas for this. But a few questions can help tell the difference between stability and stagnation, so you know when it’s the right time to think about change.

If you are a people leader, some questions to ask yourself are:

• Am I keeping this person because they’re good for the team, or because they’re good for me?

• When did I last have an honest career conversation with each person, not just a performance one?

• Do I have the right talent mix on the team to get to where we want to go?

If you are an IC, some questions to ask yourself are:

• Am I aligned with the company and product vision, and do I see a path for where we are going?

• Can I continue to grow on this path?

• Can I upskill myself or realign my skillset to help the team and company get there?

At the end of the day, we are all human. Our natural instinct is to resist change, whether that’s our own or around us, so we prioritize safety and comfort, even when we know it’s time for a change. Yes, change is uncomfortable, but it’s the only way for us to grow in the long term: for the individual involved, for the team and for the business.

When these changes happen, you’ll likely feel two things at once. Sad, because change is emotional. And genuinely happy, because someone you care about is finally betting on themselves.

From feeling optimistic about the future,

Dave

Dear Danielle,

Our teams are constantly being asked to do more. Do more, and faster. Do more, and better. Do more, with less.

This is especially true now in the1 age of AI. The expectation for knowledge workers is that with the help of AI, we can and should do more, and do it faster, better, and with fewer resources.

And so today, I want to share a success story: the research team at 1Password. Over the past year, we’ve taken full advantage of the AI tools at our disposal, embraced injecting AI into our workflows, and have since sped up our end-to-end research workflow by as much as 50%.

Yes, you read that right. 50%.

In concrete terms, this means we’re helping speed up the overall PDLC. We’re shortening the upfront discovery windows, getting in front of customers sooner, and bringing their feedback back faster, which gives our product, design and engineering partners more opportunities to iterate on our features.

So how did we do it? Not with one magic tool (unless one considers AI to be magic), but with an iterative system, built one step at a time.

Here’s exactly how we approached it, in five steps: audit, assess, build, measure, and re-focus. I’ll walk you through the four questions we asked before touching a single AI tool (surprise, the first one isn’t actually about AI at all!), the custom agent that took the “where’s that study?” pings off our researchers’ plates, the exec dashboard that asks “Are we building the right things?”, our before-and-after workflow maps, and why we’ve refused to speed up certain part of our process.

Read more

Dear Dave,

I’ve always loved writing. On several occasions, my father had the privilege of reading my lengthy, elaborate childhood novels, which I left in the kitchen for him to review, and yes, there would be a quiz. I’ve been documenting my emotional weather reports extensively in journals for as long as I’ve known how to write. And of course, here we are, on my Substack, another in a long string of blogs.

Some of that writing was straight off the dome —1 my journals are for an audience of zero. The goal is just to get it out, and leave it on the page.

A good edit, on the other hand, can be transformative.

I’m not just saying this because I’m married to an editor2. Editing is just as much a part of writing, even if they’re distinct acts: to write is to process an idea — to produce an essay, you have to essayer3 — and to edit is to prepare that idea to be processed by others as well as possible, nipping and tucking, building and clarifying. Editing is thinking.

I’m hardly the first person to say that “AI slop”4 is a problem in the tech industry, but the text itself isn’t so much the problem. The problem is when people share it unedited; it’s like doing a Google search and sending out a link to the results page. Where’s the brain?

Recently, I spoke about this in front of a room of colleagues, and the response was tellingly passionate. One tactic I described was to kill your AI darlings5: “Writing with AI is a great way to save your own time, and a great way to waste everyone else’s.”

I put forward an idea I’ve seen floating around lately: as a guideline, it should take longer to make something than it does to consume it. AI is great for helping structure and refine your thoughts. Even if you start with AI-generated content for speed, it’s not worth sharing wholesale — a thoughtful edit is what makes it worth anyone’s time.

Our voices, our words, and of course what we build are how our judgement shows up. The opportunity to edit, refine, and iterate to produce something better, clearer, sharper — it’s in everything we do. So when I say kill your AI darlings, I mean it broadly: with what you write, what you say, what you design and build.

Because editing is an act of caring: considering your audience, reflecting on what truly matters to tell them, and deciding what’s a waste of precious time in a world full of distractions.

From a long day at the em-dash refinery,

Danielle.

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.

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.

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.

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.

Dear Danielle,

I turned 40 last week!

I’d like to think it’s not that big of a deal (?), but it’s also a number that makes me pause and reflect, and puts a lot of things into perspective. Over the years, I’ve picked up plenty of advice from past managers and mentors, wisdom from family and friends, insights from books and articles, and lessons crystallized from experience. Slowly, they became principles I try my best to live by and use to guide my day-to-day decision making.

Some of these are about career. Some are about leadership. All of them are about how we can show up as better leaders and humans.

1. Everything that’s a dichotomy is actually a spectrum. Almost nothing is as black and white as it seems.

2. Hold multiple truths, even when they overlap or conflict with each other.

3. Have a backbone. People won’t always agree with you, but they will respect you for standing up for what you believe in.

4. When I was younger, like everyone else, I wanted to fit in and be the same as everyone else. But the older I get, the more I’ve learned to double down and embrace my “gimmick.” So develop and own your brand. Be known for something. Lean into what makes you you.

5. Consistency beats motivation every time. Show up the same way daily, weekly, monthly, yearly.

6. As a leader, it’s imperative that you get your own house in order before judging others.

7. Be the person in the room who asks follow-up questions and pushes for details. Nuance and context matter.

8. As a people leader, you’ll find yourself settling arguments and resolving conflicts a lot. You’ll be tempted to pick sides, especially when it involves one of your own. But remember, the truth is almost always somewhere in the middle. Take the time to hear what the other side has to say. It’ll surprise you more often than not.

9. Related: one of my favourite lines at work is “It takes two hands to clap.” When something goes awry, it’s almost never the fault of a single party. Similarly, when you need to build something together, you need the other party to meet you halfway.

10. “I don’t know” is a perfectly valid response. But your next sentence needs to be “Let me look into it and get back to you.”

11. Not responding, used sparingly, is also a perfectly good tactic. Used thoughtfully, it trains others to make decisions on their own.

12. Honesty and transparency never fail. The truth is the easiest thing to remember.

13. Work with the best data you have at the moment. Iterate when the data changes.

14. Resulting bias is real. It’s great to want to learn from wins and mistakes, but don’t go back and question a decision just because it didn’t go your way. Learn and move on.

15. If you have nothing constructive to add, say nothing.

16. Spend time building rapport with your people. I mean, really spend time. That time is what builds trust and deep relationships. One day you’re going to have that tough conversation, and you can’t have it without that foundation.

17. If you see a spill, pick up a mop, even if it isn’t your job. Have extreme ownership.

18. Don’t let your job get in the way of your career.

19. A little bit meta, but I’ll end with this one: find your inner voice. Develop a set of principles you can adhere to that guide your day-to-day decision making, principles that align with your values as a person and as a leader. It’ll make your day-to-day operating much easier.

My older daughter Jojo said to me last week, “Daddy have you thought about how a year is just one really long day?” So...

From pondering whether I’ve just had a really, really long day so far,

Dave

Ricardo Vázquez is a playful person. His infectious, optimistic energy is a hallmark of his leadership. It’s no surprise he wanted to talk to us about the role of play in creativity — and what happens to that spirit with AI in the mix always ready to give you the straight and narrow answer.

After his time at Shopify, Ricardo and Danielle worked together at Wealthsimple; more recently he’s led design teams at Dropbox and now Stripe, where his team is working on what a payments company can become beyond payments.

Alongside all this, Ricardo has a playful two-year-old at home who keeps him busy, and full of imagination.

Below is an edited summary of our conversation.

We discuss:

• Why quality and craft have almost nothing to do with pixels

• The difference between a system that exploits and a system that explores, and why AI defaults to the former

• How to lead a team through that tension without just telling people to “be more creative”

• Why so many of us have lost the ability to sketch, and what to do about it

• What a two-year-old can teach you about where invention actually comes from

What does quality mean to you?

In tech right now there’s a gigantic movement toward craft, taste and quality, and I believe quality extends well beyond the pixels. Beyond the border radius, beyond visual depth. It extends into the definition of the problem: who are we solving this for, why are we solving it, and have we diverged as much as we need to? There’s craft in what gets left in a sketchbook, or in a meeting room, or in a jam between two people.

A loading state that loads quickly is quality, too. I’m on a bit of a crusade to mature my own understanding of it, and I usually end up talking about everything except the micro-interactions.

Stripe’s made several acquisitions. How do you hold the quality bar when different products come together?

At Stripe, my group is working to invert the value proposition. Stripe is famous for processing payments, but our users have other jobs to be done. Say the three of us own a bookshop. Sure, we process payments, but we also have vendors all over the world to pay, and money sitting in several currencies. And with stablecoins finally maturing into something usable, we’re building a brand-new banking rail. It sounds like just financial technology, but there’s endless creativity in abstracting that complexity away.

The hardest thing I did at Dropbox was bring three brands into one. Everyone asks what you keep and what you let go, and I think that’s the second question. The first is the job-to-be-done, from the user’s point of view. If an acquisition is treated as a side benefit, or as a separate product under one flag, you miss the chance to find its home in someone’s end-to-end journey. Once you know where it helps, you know which IP, which interactions, which environment to carry over.

The most successful we got was when we stopped thinking of two playgrounds. It was one, and our job was to work out which corners to lengthen.

It also takes patience. And that’s where I think play is at risk right now.

Say more about that. Why is play at risk?

There’s a paediatrician, Donald Winnicott, who described play as a child taking a sample of their dream potential and pressing it into reality. Two worlds touching. That’s where new things come from. It takes courage and patience, and as adults we narrow. We’re trained to focus on what’s relevant today, and that closes the door a little more each time.

We’ve always offloaded small jobs to tools. A calculator, a map. But we stayed in the driver’s seat. We checked the work and steered. AI is different. Researchers have coined a term for what we risk doing with it: cognitive surrendering. You accept the machine’s reasoning wholesale, with no challenge and no verification. Used that way, AI is the most powerful system of exploitation we’ve ever built. It gives you the fastest answer, the safest answer, the one that already exists.

Think about the last time you played with AI and it felt magical, when you were in flow. I’d guess it’s seldom. Now think about the last book that made you cry on the train. Those aren’t the same experience. But I don’t think this is fate. It’s a choice.

As a leader, how do you protect that choice on a team with real deadlines?

By admitting that efficiency isn’t free. Its side effect is tunnel vision, and a velocity culture prunes exactly the wasteful wandering creativity runs on. You can’t fix that by telling people to play more, because play needs a container and it needs time. So I frame the work as an adventure, sometimes literally a hero’s journey. Exploration is expected, not something you quietly sneak in. And I measure discovery differently from delivery, because you can’t put a velocity number on exploration.

The real risk is a designer who is exploring but stuck, diverging without converging. What I listen for is the why. If someone can tell me why they’re chasing something, even when the how is still messy, that isn’t stuck. It’s motion. Stuck is motion with no why.

What about the opposite problem? A lot of us have stopped sketching. Starting a rough idea feels vulnerable, and everything now starts in high fidelity.

I’d love for us to get back to more analog ways of working. I don’t think we’re there yet. I bought coloured pencils the other day, but that isn’t a scalable path for designers.

It starts with psychological safety. I have a toddler, and he’s my best teacher. He doesn’t see boundaries. He sees opportunity, and he doesn’t fear failure. Imagine bringing even a little of that into daily work. But it takes a leader going first: “I tried this, it didn’t work, and gosh, did I learn something.” Little by little you build a culture that celebrates the path someone took regardless of the destination.

Second, I don’t want to fight the fact that people start in AI now. That’s the movement. Think of AI as a doorway. The key you use determines which world you walk into. If the key is “just give me the solution, build the prototype, go,” you get one room. I want a different key. I built a Claude Skill called PlayPartner. It isn’t there to think for you; the why stays yours. It’s there to hand you a hundred maybes so you can go hunting for the one that surprises you. It’s the difference between shooting hoops alone and having one more person on the court.

As leaders, we’re always telling people what not to do. Where does invention actually come from?

Kids marvel at the mundane. My two-year-old will open the dishwasher and slide the rack back and forth, just watching the rail move. I used to close a tap so that exactly one drop fell. We nudge people out of that: “don’t waste time on that, go create something.” I try to lean into it instead, by rewarding mimicry.

There’s a woman, Windy Chen, who left Google for a sabbatical with one goal: tie a new knot every day for a year. At first she mimicked. She mined every knot book and guide she could find. Somewhere in there, she stopped asking existing knots for answers and started inventing ones that had never existed. She never went back to tech. She’s an artist now, with rope installations around the world.

It’s the Steal Like an Artist idea. Copy first, then invent on top of it.

Lightning round

Best leadership advice you’ve received?

Two years into my career I had a serious case of overconfidence. I’d just joined FreshBooks, and one of the first things I did was submit a PR changing the link colour on the landing page from that Microsoft-95 blue to something nicer, because obviously I was right. Casey, the director of product, said: “Great, your environment works. Now bring me research showing users need this.” I was baffled. A few weeks in, I told him I wasn’t sure it was the right place for me. He said, “Tomorrow, leave your ego at the door.” and walked away. It reframed my early career. I became a designer who observes first and asks why before offering the answer.

Work bestie shout-out?

Toby Negele, a designer at Shopify. We partnered on reimagining point of sale from opposite ends of the spectrum: he lived in the technical detail, I lived in the storytelling and bringing teams along. He listened to metal, I listened to Broadway. It worked, and he’s a dear friend now.

Anything to plug?

My star project right now is raising a human being. But my plug is this: read. Buy a book and submerge yourself in a world someone else wrote. Don’t read a PRD, for God’s sake.

Thank you, Ricardo, for reminding us to have fun and leave our egos at the door! You can find Ricardo on LinkedIn.

Dear Dave,

In my last post I wrote about how a vision is a chapter in the story of a product —1 perhaps lofty and intimidating to start, but its helpful to remember that they’re not the final word.

In this much anticipated squeakquel, or second chapter more appropriately, I wanted to go a layer deeper into what makes a vision effective, and some of the tactics I’ve seen work well.

Qualities of a good vision

A good vision is visionary

This may seem painfully obvious, but many visions put forward a vision of the future that’s only a day away. A vision is necessary to change direction, not to define the chapter we’re in today. It couldn’t exist today with the product as-is. It’s not just building new features: a strong vision drives the product in a new direction that will require a meaningful gear shift to achieve. It tells a story about what the product can become for users — solving new problems we didn’t know we could, or in novel and unexpected ways. This matters because a vision needs to be ambitious — otherwise its just an idea, which is always nice, but any product team worth its salt wants its direction to be trailblazing.

It’s evidence-based but highly opinionated

A good vision is grounded in customer research and data. But those things can point us in multiple directions. A strong vision is controversial — other visions are possible, but we choose this one, and the vision articulates why, and persuades you to agree. This matters because a vision is only as good as the evidence that underpins it, and because it’s a stance, by definition, it has to drive towards a single clear path, not describe several options.

It’s concise and memorable

A lot of work goes into a vision, but what you need to consume to get it should be limited and sticky. It should probably, in all seriousness, have a snappy tagline or title people can refer to. It is a simple enough direction to be summarized, even if there’s plenty of content to go through if you want to go deeper. None of this works if the audience can’t hold onto it, and the audience for vision work is likely wide and busy. To be relevant and enduring, the vision has to be easy to describe and recall.

A spectrum of vision artefacts

Next I want to share a non-exhaustive list of common vision artefacts, in no particular order, to show what this blobby-feeling thing actually looks like. All of these can work, and all can fall flat. And often they’re best used in combination with each other.

Prototypes

While visions prototypes increasingly proliferate thanks to our friend AI2, they rarely pass the visionary bar — often falling into the trap of showing a collection of new features we could build, rather than a true direction.

Still, prototypes can be incredibly powerful because they are the epitome of ‘show rather than tell’. They can be highly persuasive for executives, but team members may look at them with skepticism. Voice-over or embedded storytelling is critical to ground everyone in reality with an artefact that looks so real — and to make clear you’re not trying to ship this exactly, but in this direction, which can breed confusion at all levels.

Documents and decks3

There remains a place for tried and true handcrafted words in vision work; this enables you to articulate the principles and frameworks that should drive the chapter ahead in vivid detail, and to get into the evidence behind them. And with agentic design, documents in particular can serve as useful tools to enable AI tools to work towards your vision, too. Words are back in style and more powerful than ever!

But, though they enable you to be precise in theory, words are open to vast interpretation and misunderstanding, by humans and agents. They also frequently require people to read things; some people will do this, but many will not4.

Especially for a vision generated by a UX team, it’s rare that these will do on their own for humans without being accompanied by visuals, but when the narrative is complex, requires technical detail or this is the best approach for your audience, the key element here is to be concise5 and clear, even though the format invites you to do the opposite.

Product vignettes

A version of a deck in practice; by product vignettes, I mean a story told through moments in time in a product. This is particularly useful to convey how product usage could change over time — on day one, the user does X; on day 30, they do Y. This approach is more emotional, leaning into storytelling and showing the role of a product in users’ lives.

Often we use wireframes here or product illustrations rather than real UI, focusing on specific evolutions and how they impact user behaviour.

This is compelling, but risks feeling ‘fluffy’. Technical leaders think it sounds lovely, but don’t know what to make of it in reality; it doesn’t provide as clear or detailed of a path from here to there. This might be intentional, but will mean getting buy-in might take a lot of clarifying around what exactly we’re looking at, and what comes next.

A last word to the wise

An important caveat on all of the above: when I was getting married a good friend gave me the advice that “the seating chart will tell you what to do” — meaning how to arrange your people amongst your tables will become clear as you go.

This struck me as true well beyond this context — your vision work will tell you what to do, i.e. what form your vision should take. First and foremost, go with what you are hearing from the people who will consume it. Treat the vision itself as a product; the people who use it are the ones who will tell you if its working; and as far as the agents who consume it, you’ll need systems to evaluate that yourself!

Either way, the work isn’t done when you share the thing — its how vision becomes reality, whether and how the chapter you’ve written get codified in the experience and influences what comes next.

From gazing into the future, thinking life could be a breeze,

Danielle.

Meet our boss!

In this very special edition of Dear Danielle & Dave & Friends, we sit down with Matt Davey, Chief Experience Officer at 1Password, and the person who has to put up with our antics daily at work.

Matt says the three of us are like “peanut butter, jelly and mustard” (not derogatory?). We think this makes for a pretty great combo — and this conversation will give you a glimpse not only into Matt’s point-of-view, but also into how the three of us lead together.

Matt has led the user experience team for a whopping 14 years. We are both part of the org he’s spent over a decade building alongside cycling through his many eclectic hobbies for much briefer stints, such as printmaking, radio, chocolate-making, 3D printing, biking, and surely many more. He also cohosts 1Password’s security podcast, Random but Memorable, and has his own excellent blog on design & leadership.

Recently Matt went viral on LinkedIn with the AI maturity model he developed to assess UX maturity in the age of AI (which was subsequently expanded by Jakob Nielsen - no big deal). We had a conversation with him about just that, hiring, and much more.

Below is an edited summary of our conversation. This is a longer ep with lots more in the pod, including clues to the blog title, so be sure to listen!

We discuss:

• Why AI has raised the floor of design work without yet raising the ceiling

• The art-to-science hiring philosophy behind our team, and why AI is making the middle of that spectrum fall out

• Why his viral design maturity model isn’t a career ladder

• His long-standing allergy to frameworks, and why he built one anyway

• What it actually takes to lead a team through “full steam ahead” when nobody’s sure the ground will hold

You’ve built our team around the idea of a spectrum, from the art side of design to the science side. How has AI changed that?

I’ve always thought about design as a spectrum — there’s a playful, art-driven end and a more rigorous, science-driven end: the behavioural loops, the IA, the strategic “we’re building this to solve that” side. AI has basically made the middle of that spectrum fall out, because you can now go so much deeper into one side or the other. If you really enjoy the behavioural loop side, nudging users toward something, figuring out the flow of information, you can now do that with quantities of data you’ve never been able to deal with before. And the same is true on the other end — you can lean all the way into becoming a front-end developer while still holding design as a craft. I don’t think you can do both anymore, and honestly, I’m not sure you ever really could.

When I’m hiring, I look for the thing that makes someone’s face light up when they talk about one specific part of the job. I think almost everyone great on our team has one of those things, and we try to give them as many problems shaped like that as we can. Going deeper into AI has mostly just made people go deeper into one area of that spectrum, rather than smoothing everyone into the same shape.

There’s a real risk there too, though — that AI just makes everyone competent at everything and nobody exceptional at anything. How do you coach people to double down on what makes them distinct?

AI has definitely raised the floor. It hasn’t yet raised the ceiling in everyone’s hands. I think where people end up specializing versus smoothing out comes down to expectations. If you care about interaction design and getting something finessed and perfect, and then you go to content design and just accept whatever the model gives you, that’s the split — some people are using it to get better at the ten percent that’s genuinely hard, and some are using it to cover everything at a mediocre level. Both are happening. But the really great work comes from people using it to move that last ten percent, not to try to do it all.

That does mean staying flexible about what you think you’re hiring for. I’ve changed my mind about what we’re looking for more times than I can count, because a great person shows up who lights up over something completely different than the role on paper. You’ll regret filling the hole. You won’t regret hiring someone great, even if they don’t perfectly fit the shape you had in mind.

Your AI design maturity model went viral in design circles. What do you think it was about it that resonated?

Honestly, I almost didn’t post it. I was going to keep it just for us to use as a reference. I ended up sharing it because another VP asked how I was thinking about our AI adoption, and I sketched something rough in FigJam — here’s roughly where we are, here’s where I’d like to be. Having that basis for a conversation, even if the model itself is wrong, turned out to be one of the more useful things I’ve done.

I think it landed because so much of the AI-and-design conversation has been relentlessly negative — “AI can make a rectangle, we’re done,” “PMs can prototype now, that’s us finished.” It’s not nuanced, and it doesn’t give anyone anywhere to stand. The model gave people a place to say, here’s roughly where we are, here’s where we want to go. It resonated because it was a way out of the doom spiral, not because it was right.

Share Dear Danielle and Dave

You’ve said before that you hate frameworks — and yet here you are, having built one. How do you square that?

I really do hate frameworks, if I’m honest. I understand why we need career ladders, why we need some objectivity in measurement. But a sports team is probably the better analogy — you can have the best chess pieces on the board and still lose, because the outcome is judgment, constantly, not just the individual pieces. That’s why the one thing I didn’t want the maturity model to be was a career ladder or an expectation placed on an individual. It’s a level above that. If someone doesn’t do well, it could be the tooling around them, the maturity of the team, the delivery process — none of that is necessarily on the person. Frameworks tend to fail because they assume everyone is in the same place, skilled in different ways but played in exactly the same position.

What’s your advice to leaders trying to convey confidence to their teams right now, when so much is genuinely uncertain?

Part of me wonders if I’m the wrong person to ask, because I probably went into this with something verging on overconfidence. I ran when I probably should have jogged. But I think that’s what the moment required — if the person leading the charge isn’t confident, everyone else just defaults to “this seems bad, let’s avoid it.” We ran an offsite where we asked people to ship something to production, and the wave of emotions in that room was real — panic at eighty percent of the day gone, then euphoria once things started working.

I think the job of a leader here is to have an opinion, grounded in something real, and to actually push forward with it rather than adjusting constantly, because constant adjustment doesn’t build anyone else’s confidence. But I was careful not to turn that into a scoreboard — I originally wanted to track who’d shipped a PR and who hadn’t, and I’m glad I didn’t. Everyone’s learning curve with these tools is different. It’s on leadership to prove the tools are useful and show how, and then get out of the way.

Lightning round

Best leadership advice you’ve ever received?

The problem with getting advice after being in a role this long is that every piece of it was really good for one specific era, one specific scale, and none of it ages well. So the best advice I’ve ever gotten is: start again. Break down your role and rebuild it as often as you need to, because anything you hold onto too tightly slowly deteriorates — a critique format, a team newsletter, anything. Throw out advice the moment it stops working.

Who’s a work bestie who’s helped you along the way?

Our colleague at 1Password Matt O’Leary. He’s an incredible soundboard — optimistic when you need him to be, but never a false positive, so you always know when he actually means it.

Huge thank you to Matt for joining us and sharing some truly wise words; and we’re not just saying that because he is our boss, we swear!

Matt’s building a trivia game called Cloakword, where you’re given an article with the title redacted and have to guess it from the clues. It’s free to play, though he’s kind of hoping it doesn’t go too viral, on account of the API bill.

Dear reader,

We’re heading to a company offsite in a couple of weeks, so we’re taking a wee little break from writing and publishing until we’re back. In the meantime, we’d like to share some of our favourites from the archive, in case you missed them the first time around.

Happy reading! See y’all back here in a couple of weeks!

This one is our absolute favourite and best post by far. Danielle wrote about the difference between speed and momentum — and why momentum, not just speed, is what actually builds trust and buy-in with stakeholders. Danielle will actually be bringing this topic as a workshop to this year's Elevate Festival. If you're in the area, be sure to check it out!

Leading a team through AI change means balancing two audiences: your reports and your fellow leaders above you. Danielle wrote about learning to sit with her own conflicted feelings, and why honesty, transparency, and genuine (not toxic) optimism are what actually help a team find its footing.

There’s been a lot of going on this year in and out of work. It can feel like a lot, overwhelmlly so. Dave wrote about the mindset of breaking problems that seem too large to tackle into smaller chunks so they are more manageable and feel more solvable.

AI has genuinely helped so many of us solve problems in ways we weren’t able to before. But it’s taken something away too — the apprenticeship-style grind that quietly built our judgment. Dave wrote about what that means for the juniors coming up now, and what we owe them.

Brooke came onto our podcast and talked about how change management is the defining challenge in tech. That is especially true now as every company is going through this AI transformation, and many are dealing with the fallout as a result of that. Brooke shared with us the lessons she’s learnt manaing change as a people leader throughout her career.

Tino came to us with something many of us have been observing in this age of AI: AI is making teams skip the alignment work, and the functional culturew we have worked so hard to build as UX leaders, might be part of the problem. Tino shared his thoughts on the root causes and what might leaders do to start addressing the problems.

From practicing “whiz wit” in front of the mirror,

Danielle and Dave

Share Dear Danielle and Dave

Dear Danielle,

Lately I’ve been thinking a lot about the artifacts we make for internal stakeholders, and whether we’re applying the usability rigour we apply to the products we ship to external customers.

Collectively as a product, design and engineering org, we obsess over who our customers are, what they need, what competitive products they already use, and how we can solve their challenges better. We painstakingly test and retest concepts and prototypes to make sure the product is highly usable, study what messages resonate, and partner with our Marketing and GTM friends to devise a plan that makes it all stick in market, all in the hopes of finding that ever-so-elusive product/market fit for new features that propel us to the next level of growth.

Yet we don’t apply that same care when we make artifacts for internal use. Many teams still view artifacts as outputs to send out for people to read, instead of products we ship for people to use. Even the language we use, artifacts, sounds inactive, whereas a product is something someone else has to actually use, and use well, for it to have done its job.

Share Dear Danielle and Dave

Take personas as an example. Everywhere I’ve worked, there are two main “target consumers” for personas. Managers and ICs treat them as a detailed instruction manual, build work off them and rely on them to steer roadmap direction. These folks need the details. Then there’s leadership: the directors and VP-and-above folks who just want the headline. They want a high-level understanding of who these personas are, enough to remember a thing or two and speak to them with confidence. Nothing more, nothing less.

Yet most research teams make one single version, built for one audience’s use case and consumption style. Most personas are incredibly dense infographics with accompanying documents that feel like academic research papers. The usability leaves a lot to be desired.

In many ways, AI has worsened this problem. We can now vibe-code a slide, a doc, a dashboard in the time it used to take to write an outline. That’s been genuinely helpful in so many cases. But most of the people building these things were never trained to think about usability, hierarchy, or who’s actually going to read this and how. With AI, more people can create artifacts faster than ever, but the audience-awareness our job still demands didn’t scale with it.

I’m not advocating for weeks and months of usability research on “onboarding_flow_dashboard_v5_final_final,” or a full-fledged GTM motion so every person in the org can recite the marketing copy. But a version of that thinking, scaled down, would go a long way: who is this actually for, what’s the one thing they need to walk away knowing, is this the right format for how they’ll consume it, and is now the right time to send it or is it competing with six other things in the chaotic land that already is Slack?

We UXers already know how to build something a customer trusts enough to come back to; the people we work with every day should get that same care. Not only does that help differentiate us and highlight our strengths, but being better understood and getting more buy-in also translates to better customer outcomes down the line.

From reading an email that really should be a meeting,

Dave

Dear Dave,

Last week a designer asked me: what makes a good design vision?

This comes up often. “Vision” can feel lofty and intangible, even though developing vision is a standard expectation in senior product roles, hand-in-hand with driving strategy. Still, approaching vision work is daunting: where to begin? What to deliver? To who, by when, who cares?

Templates for this particular task come and go. Most visions take a few tries before reaching a canonical ‘final form’; even then, they fall out of date and get rebuilt anew.

Because a vision is a chapter in the story of a product, not the whole book.

The scale varies —1 a vision might zoom in on one problem, or look across the whole company — but its still a chapter we haven’t gotten to yet; it advocates for a direction to build towards. Once we start doing so, we’re already flipping the pages, wondering what comes next.

Subscribe now

Stay somewhere long enough and you start to see this happening at the organizational level.

At Wealthsimple, I joined at a time when the vision was democratizing wealth through managed investing: diversified ETFs that help you ‘get rich slow’. As the market demanded access to more tools, we expanded into trading and crypto. This wasn’t in chapter one, but the story widened: get rich your way, with a balance of investment types.

While the vision grew, it stayed anchored to a north star: making investing accessible to a new generation, without the barriers of traditional banking. Everything else was iteration.2

Within design, we’re often afforded the opportunity to make visions legible — to do the showing that brings the telling to life. And at our best, we pull vision up ourselves from the customer and product knowledge that shapes all the small decisions we make daily, to form something bigger.

So what makes a good vision isn’t the artefacts — though those are worth plenty, and their quality is a bellwether for the quality of your thinking. Its whether the vision positively shapes how the product is perceived by the real people who use it. The plot moves forward, and the hero — the user — moves with it.

Internally, a good vision goes viral3. People ask for the link. It gets shared in rooms you’re not in. It answers pressing questions about where we’re heading next, and inspires new ones about whats possible after that.

So if a vision is a chapter, it takes some pressure off. You’re not writing the whole book. You’re building on a foundation, with more to come after your part. I’ve worked on many visions, and seen them fail, flourish, and eventually get remixed and rewritten.

The first step is to figure out the shape of the chapter: the piece of the story we need to change now, and why. What new forces are at play in our hero’s world, driving us to need to do something differently?

Define the plot points that matter, with whatever tools are best for the job, within some reasonable constraints on time, and certainly not alone. The form it needs to take to make sense to others — ⚠️ intentional hand-waving ahead ⚠️ — will become clear along the way.

Finally, I will leave you with my personal favourite vision ever articulated4:

This is part 1 of 2; next post I’ll share my perspective on the qualities of an effective vision and some examples of tactics I’ve seen work well in practice.

From scream-singing Unwritten by Natasha Beddingfield, because the rest really is still unwritten(nnnnnn🎶),

Danielle.

In our Dear Danielle & Dave & Friends series, we bring you interviews and letters from leaders in tech, focused on the topic they’d most want to chat about with other leaders.

Meet Jessica Pavia. Jessica leads both UX Research and UX Operations at BMO, where she supports a research team of 25 and an operations team embedded across a broader experience practice of over 110 people inside one of the more regulated, higher-stakes environments out there. Before BMO, she built her career at IBM and helped establish a design research discipline at Loblaw Digital, taught applied research methods at Seneca and Sheridan, and has spent most of her career, by her own account, in the business of patterns, which she traces back to being a kid obsessed with Where’s Waldo.

Jessica came to us with a mandate that’s been following her around for most of her career: “do more with less.” She’s got a lot to say about what that phrase actually means, what it doesn’t, and how she’s learned to translate it into something a team can act on without burning out. Below is an edited summary of our chat.

We discuss:

• Why “do more with less” isn’t a euphemism for working harder, and what it actually asks of a team

• The question she asks before approving any plan: what would you do with half the time?

• Where she’s found the highest-leverage place to cut, and the one thing she’s refused to

• What efficiency looks like in a highly regulated industry

• Why AI only earns a place in her team’s workflow once it’s been tested hard enough to break

You’ve been handed “do more with less” more than once in your career. What does that phrase actually mean to you at this point?

It means be intentional. Every process, every meeting, every investment has to earn its place. I think about this a lot through the lens of my grandmother, who’s Italian. She used to say “meno è più”, which literally means “less is more”. And it took me a long time to understand what she meant by that in a work context, because the blunt interpretation of “do more with less” might be perceived as simply working harder.

So a few years ago, when that mandate came down to my team, I introduced a simple quarterly check-in. Once a quarter, I’d ask researchers about the work they were doing: the types of studies, the volume, how fast things were moving, how many insights were actually driving action downstream. It wasn’t rocket science.

But what emerged wasn’t just the data. It was the story: where teams were thriving, where there was friction, where we had real benchmarks instead of vibes. That’s the difference between doing more with less and just doing more.

How do you actually turn a vague mandate like that into something your team can execute?

I’ve been trained to never measure change without a baseline, so that’s always the first question: where are we starting? A lot of leadership, I think, comes down to storytelling: figuring out what story you want to tell about where your team is creating value, and then finding the data points that support it. If you’re a leader, that might be the story of how your team’s working and where you’re seeing improvement. If you’re an individual contributor, it might be the story of how you refined a process or looked at a problem differently to save time or money.

For example, we focus heavily on removing friction through tooling, but every tool has to earn its place in the stack. We spend real time piloting before we adopt anything, which takes longer than some faster-moving industries might tolerate. What I won’t compromise on is anything that touches risk or customer trust. Those aren’t trade-offs to me. I think of them as foundations.

Banking has a reputation for moving slowly. How has working inside that constraint actually shaped how you think about efficiency?

Honestly, before I joined banking, I heard “banks move slower” a lot, and I was hesitant about it. But I’ve come to see it differently. When you’re helping people manage their money, their security, their future, that’s a real responsibility. (Yes there are) more stakeholders, more approvals, more regulatory considerations. That’s just the nature of the environment, and it’s how you choose to see it. I think about those constraints as a creative challenge. Some of the best work I’ve done, and the best work I’ve seen from my teams, has come out of working inside them.

I say to my team a lot: we move as fast as we can, but with rigour — that doesn’t get compromised.

And practically, there’s a question I ask constantly when someone brings me a research plan or a new workflow: what would you do if you only had half the time? Not because I want people to work faster for its own sake, but because the constraint reveals what actually matters. When everything feels important, it’s hard to know where to focus. I also push my team to bring multiple plans, not just one: show the different costs, the different options, and if we only had one bet, what it would be?

Is AI genuinely buying back capacity for higher-value work on your team, or is it just one more thing to manage?

I’m in the camp that it’s genuinely buying back capacity, with a heavy dose of caution attached. I’ve seen researchers, designers, and operators use it to simplify the repetitive work that doesn’t create much value on its own, which creates more room for the things humans are uniquely good at: critical thinking, judgment, connection. But I’m curious to a fault, so my excitement always comes with caution. I believe in piloting before scaling, and honestly, trying to break a tool before I trust it.

I don’t think of AI as valuable because it’s evolving. I think it’s valuable when it earns its place, the same standard I’d apply to any tool. Where does it actually earn its place in the workflow? Is it enhancing the work or breaking it apart, and how are we testing that?

The goal was never just about doing more. It’s about creating room for the meaningful work, and figuring out how AI can help with that.

Lightning round

Best leadership advice you’ve ever received?

Early in my career, a leader I worked with forwarded me along an invite to a meeting with an executive team. I wasn’t presenting, wasn’t really expected to say anything. But before we went in, she asked me one question: what are you bringing in with you? It reframed accountability and leadership for me completely. The goal was never just to earn a seat at the table. It’s to contribute something meaningful once you’re in it.

Who’s a work bestie who’s helped you along the way?

Christina Cornacchia. We were research leaders together earlier in my career, growing and supporting teams side by side. She has this rare combination of pragmatism and empathy; I could bring her almost anything and she’d cut through the complexity without ever losing sight of the people involved. I joke that she’s on my board of directors for decisions. The higher you go in leadership, the fewer people there are who truly understand the weight of what you’re carrying, and Christina’s one of the people who reminds me I don’t have to figure it out alone.

Huge thank you to Jessica for joining us and for the reminder that “less is more” is a discipline, not a shortcut.

Dear Danielle,

In tech we talk about ownership a lot. You know this as well as I do. We have a dedicated item in our career ladder called “radical ownership,” where folks are assessed on whether they can own initiatives from start to finish, make sound decisions, and ultimately be accountable for the work they lead. It’s often the clearest indicator of how someone’s showing up against the expectations of their role.

However, as we inject more and more AI into our workflows, how far does “radical ownership” extend to your agent’s work too? I’m starting to see individuals and teams lean on AI for their work, then step back from taking full ownership of what the agent actually did. When I talked to them, the argument is always some flavour of “well, I can’t control when an agent drifts,” or “the agent isn’t following my already very detailed instructions.”

I get why people reach for that argument. It’s a lot easier to point the finger at an abstract entity that sometimes seems to have thoughts of its own. (And no, I’m not here to get into AI anthropomorphism or whether we’re approaching AGI or the singularity. That’s a whole other can of worms.)

But my take is that owning an agent’s output doesn’t require predicting its every move. It requires the same thing good management has always required: enough upfront diligence to catch the likely failure modes, and enough review before anything ships to catch the ones you didn’t predict. Guardrails narrow how often drift happens and how much damage it can do when it does. They don’t make an agent’s behaviour fully knowable in advance, and I don’t think anyone should claim otherwise. So if the owner can’t get all the way ahead of an agent’s actions through planning alone, and they won’t always be able to, then the responsibility shifts to putting in guardrails and doing real review of the work before it’s handed off or made available to general access.

Share Dear Danielle and Dave

Many people equate using AI with hiring a bunch of interns, and I think the same metaphor holds here too in the context of ownership and accountability. When interns make mistakes, you don’t throw up your hands and say “well, I guess I can’t control what the intern did.” No. You go talk to their manager, because it’s the manager’s job to own the intern’s output. Because when it comes to interns, more often than not, it’s someone senior who puts their name on it and says “this work is ready to represent us.”

Now I’m mostly talking about internal use cases here, where we build agents to power our own workflows, processes and infrastructure. But I think the argument holds for external use cases too, where the stakes are arguably much higher. And this conversation about accountability and ownership is going to land on UX more and more. When our own teams ship agents into our products and those agents drift, who owns that mistake? I think it’s on us: the team who researched, designed and shipped the thing.

Now, I want to be careful not to conflate accountability with zero tolerance for mistakes. Agent drift happens. Learning to spot it, correct it, and build better instincts around it is part of the job now, the same way learning to review a junior’s first pass was always part of the job. As leaders, we need to create room for that learning to happen, not just demand flawless output from day one. But holding space for the learning curve and holding people accountable aren’t in tension. You can be new to this and still be expected to fully own what you ship, including your agent’s part in it.

Here’s the bottom line I think people need to remember: the agent doesn’t get fired. It doesn’t lose customers. It doesn't sit in the room when our work gets critiqued. Agents don’t lose trust with our stakeholders. We do. They have no stake in the outcome. We do.

Ultimately this is about owning the work, and making sure the outcome puts you and your team in the best light, regardless of who, or what, actually produced it. We as humans simply can’t abdicate that.

From blaming autocorrect for a typo I definitely made myself,

Dave

Dear Dave,

Have I ever introduced you to my dear friend, imposter syndrome?

Even if I haven’t, I assure you, they’ve been in the room in many of our interactions, and in fact are there most of the time. I greet imposter syndrome whenever my thoughts creep towards those perpetual doubts of how did I get here and what do I know and when will they all find out and so on and so forth.

This is a relationship many if not most of us engage with in our work lives, especially leaders, and one that there are many ways to manage — but personally I find acknowledging the feelings as just that (not facts!) helps me keep it at bay.

AI is of course adding a whole new layer to imposter syndrome.

On a recent episode of Work Life, Ify Walker described the idea of the “work twisties” - times where you feel a disconnect between what you know and how to actually do it.

I found this notion really resonant in a moment where a lot of us are feeling some amount of disorientation in response to how AI is coming into our workflows. The ways of doing design and research work that define our craft are changing so immensely that it’s creating a real sense of displacement and disconnect from how to do things we know in our bones how to do.

The way that I’ve always handled my imposter syndrome is by naming it. It doesn’t mean I don’t hear the voice everyday, but I have built an accepting relationship with it, and I do my best to focus on the real data before me, namely how I show up, get the work done everyday, and the positive outcomes that drives consistently.

In the interview, Ify describes a similar practice for approaching her work twisties: making a list of fact vs. story. What’s true, and what’s the narrative on top that’s twisting the facts and making things hard to approach?

That won't work for everyone. Having these insecurities is fairly universal; facing them is highly personal work. And certainly naming the twisties won’t make them go away; mine are still very much in the room as I write this.

But it helps me tell the difference between "I don't know how to do this yet" and "I was never any good at this," which feels like an important distinction right now, when so much of what we know how to do is changing shape.

Imposter syndrome and I go way back. The work twisties are new to me, but I have a feeling we’ll be getting to know each other well.

From never having been able to do a cartwheel but trying anyway,

Danielle.

Dear Danielle,

I got some amazing news last week that absolutely made my day: a mentee of mine finally landed a job after months of searching and interviewing!! (LFG!!) It was truly blood, sweat and tears.

They landed an entry level position at a large Canadian company. It’s not their dream job per se, but it sounded like a great opportunity for someone who’s been trying to break into the industry. As we have received many questions on this, getting the foot in the door is often the hardest part for junior designers and researchers.

At the same time, I can’t help but wonder (and worry) how well my mentee is going to be supported by their new team, new manager and the larger org. Especially as UX continues to face the onslaught of AI mandates and the pressure to demonstrate the impact of such tools as an industry.

But zooming out, the larger picture I worry about more is how tempted, or even forced, the new UXer cohorts are going to be to take shortcuts.

I’ve written about this before: AI is giving researchers at all levels something we’ve been asking for for years. By offloading many tasks like tagging, synthesis and analysis, either partially or completely to AI, we now have more time to think. More time to be strategic. More time to actually influence the things we’ve always said we wanted to influence. Many of us would agree it’s truly been a gift.

But gaining something usually means giving something up too, whether we notice it happening or not. The work many of us have been able to offload to AI, we can offload because we already built the judgement and deep intuition to assess whether the output is any good. That judgement was honed through the slow, unglamorous work of sitting with transcripts, tagging themes, writing and rewriting the insights until 5pm on a Friday.

What I worry about now is that a lot of that unglamorous work, the work that quietly built our judgement, has disappeared from the career path entirely under the pressure of speed. And our juniors may be paying for it without knowing what they’re missing.

I’m reminded of my first years as a junior research analyst. I remember the specific feeling of being handed a stack of raw transcripts with no shortcut through them, and how much of a slog it was: reading through every sentence, highlighting key phrases, grouping them into themes. At the time I didn’t know I was building anything. It just felt like the job. It was the job! Today’s junior researcher is far more likely to be handed an AI-generated synthesis and asked to sanity-check it. Faster, yes. But they’re starting one step removed from the thing that actually taught me how to trust my own read on a transcript. They’re evaluating a conclusion instead of arriving at one.

What’s essentially happening is the apprenticeship model that quietly trained a generation of senior UXers is collapsing, and I don’t think many of us in more senior positions are being honest about what that means, or what we owe.

So what do we do as leaders? I don’t think the answer is to stop using AI. But I do think it means something changes for those of us who have already built the thing AI is now doing. If the messy work no longer happens naturally, we as leaders have to build and facilitate an environment to make it happen deliberately. Give the junior designers a bit more time to wireframe instead of jumping straight into AI prototyping. Pull a junior researcher into an actual synthesis session led by a senior UXR. Let them sit (or perhaps even force them to sit) with the ambiguity before the machine resolves it. Give them work AI could do, but don’t always let it.

I keep thinking about what it took to build the judgment I now get to use all day, and I’m not sure I would have built it any other way. My mentee starts their new job in a couple of weeks, genuinely thrilled, and so am I for them. I just can’t shake the question of whether the version of this job they’re walking into still has room to build what I built. And if it doesn’t, what our responsibility is to make that room ourselves.

From teaching my 8 y/o how to do proper push-ups so she can start building the reps,

Dave

In our Dear Danielle & Dave & Friends series, we bring you interviews and letters from leaders in tech, focused on the topic they’d most want to chat about with other leaders.

Meet Konstantino (Tino) Kapetaneas. Tino is Director of Product Design & Research at Flipp, where he’s led and grown the function for nearly eight years, building the UX research practice from scratch, scaling a 27-person team, and helping evolve the company’s product from a single app to a multi-product ecosystem. Before Flipp, he cut his teeth on the agency side in digital health, doing formative work with patient advocacy groups that, by his own account, set the direction for everything that followed. Dave and Tino are also old colleagues; and if you’re wondering whether they’re real-life besties, Tino’s official position is that he can neither confirm nor deny this. Tino has previously written for us and we were very excited to have him on the pod!

Tino came to us with something that’s been eating at him: AI is making teams skip the alignment work, and we’re starting to pay for it. Below is an edited summary.

We discuss:

• Why AI-enabled speed is surfacing alignment problems that were always there

• What happens when four stakeholders ship four competing prototypes before anyone’s written a brief

• The case for participatory design process — and why designers’ instinct to protect their territory is working against them

• Why functional culture, as we’ve built it, might be part of the problem

• What the design brief is doing now that the PRD used to do

You came in with a pretty strong take. What’s prompting it?

A few things. The first is kind of funny. We just did a company offsite with a Dragon’s Den–style pitching competition: use AI to build a new retailer brand from scratch, in 90 minutes. My team — people who’d never worked together before — came out with a deck, a valuation, a pitch to investors, and a theoretically functional prototype. We won.

Here’s the insane part. I won the pitching competition not really knowing what my business was all about or how I was going to run it. I don’t know the first thing about how to run the business I pitched. And I think that kind of underscores what we’re seeing with a lot of the outputs coming through AI-enabled workflows right now.

The second example is less simulated. I was part of a project recently where, at the very early stages, four different stakeholders had each built their own prototype. Nobody asked them to. None were made by designers. There was no product brief. That was how the project started.

What I found really interesting about that early stage was how difficult it was to decide what to do next. What were we evaluating these outputs against? What problems were we trying to solve? How would we know if we were going to be successful? And ultimately, the only way out of that stage — where you have four or more competing ideas, all high-fidelity, all very convincing — was to defer to the loudest or highest-paid voice in the room.

That’s a problem we’ve all struggled with throughout our careers. But with AI, it’s becoming way more common.

Is this AI breaking the process, or exposing what was already broken?

Both, I think. On one hand, I’m concerned about the dysfunction being cultivated as a consequence of this technology. At the same time, it does start to poke holes in the old guard — how we used to operate. And some of those holes were always there.

Take something small: have you ever had a PM request a Figma licence and quietly bristled at it? I say this facetiously, but I think designers can be sort of gatekeepy. Is that conducive to creating the best work possible? Probably not. And now that AI is giving product managers and engineers capabilities they didn’t have before, they’re looking over their shoulder at designers thinking: do I still need these people? The best way to counter that is to stop protecting the territory and start participating in a collective process.

So how do you coach your team through this?

The first thing I’d say is that what teams are experiencing right now, a lot of the time, is a vacuum of leadership. I don’t mean that to be extreme. I just mean that when everyone’s looking over their shoulder wondering if they can trust the person next to them, that’s often a consequence of there not being clear guidance about what to do in an ambiguous transformation moment. And you can point up to the executive layer and blame them — a lot of people do, and I struggle with it myself sometimes — or you can choose to find a path in the chaos and work with your peers to make progress along it.

More crafts-oriented people — designers and researchers especially — can be uncomfortable stepping into that leadership role. So a lot of what I coach my team on is: how do you label and manage uncertainty, and how do you step into that role even when your title doesn’t call for it? Go build relationships with the directors in other functions. That might seem like overreach, but sometimes you need to go up the influence chain before you can move anything laterally.

The other thing: write the brief. We’re seeing a world right now with less and less upfront documentation — no PRDs, no requirements, just outputs. So some of my team is picking up that slack. They’re writing UX briefs, articulating the problem, scoping what’s possible. Not because it’s a designer’s job, but because someone has to create something that people can align to. Even if it’s incomplete. Even if it’s imperfect. Just something to anchor to.

What’s the bigger structural shift you’re pointing at?

This is the uncomfortable part. I think horizontal functional leadership — the investment we’ve made in building functional teams, functional culture, functional identity — is going to have a hard time over the next five to ten years.

I pride myself on the product design and research culture I’ve helped cultivate at Flipp. And that’s a selfish viewpoint. Because what it also does is reinforce silos, even when we’re trying not to. And I think the next leg of our evolution is going to force us to come to terms with that.

In practice, what that looks like at the individual level: stop designing in a silo. Invite your PM and your engineers into your design critiques. Not just other designers. Yes, you’ll have untrained voices in the room — that’s uncomfortable. But that’s also how you build a joint culture around making products. The best teams I’ve ever been on worked that way: T-shaped people, a lot of trust, a lot of improvisation. You were playing jazz. And misalignment doesn’t just create dysfunctional teams — it ships to the products themselves.

Lightning round

Best leadership advice you’ve ever received?

Not from anyone who told me directly — I’m going to be lame and quote Steve Jobs. There’s a video from the early nineties where he talks about how the best managers come from craft experience. They need to know how to make things. They need to be great executors first, because the people working with them want to learn — and you can only teach what you know how to do.

That’s how I’ve built my people leadership layer. Great craftspeople first. The behaviours follow from that.

Who’s a work bestie who’s helped you along the way?

I have to give Dave a quick credit — he’s been incredibly supportive of my personal fitness journey, and I’ve built habits from time spent with him in the gym that I’ll carry the rest of my life. Outside of that: a product director peer at Flipp who’s just gone on maternity leave. She’s been a huge advocate for good product operations, standardised documentation, better roadmap practices. I don’t think I’d be nearly as involved in cross-company operations without the doors she helped me walk through. Genuinely grateful for that partnership.

Plugs

Tino just pre-launched his first home-built SaaS product: Acorn Pad, a privacy-focused digital note-taking app he built himself using AI. There is a floating teal squirrel. We enthusiastically recommend checking it out.

Huge thank you to Tino for joining us, and for articulating something many of us have been feeling but not quite naming.

Tino is based in Toronto and is indeed Dave’s gym buddy. You can find him on LinkedIn.

Dear Dave,

Recently I reconnected with a former colleague (hi Jeff!), and we got to talking about ambition.

I was reminded through our conversation about the early days of building my design skillset. I worked at a company where designers were expected to own everything from discovery through execution alongside developers, without support from specialized roles like researchers, content designers or ops. This was a great place to be when I was learning because it helped me grow in lots of different directions, and figure out what I wanted to do - and what I didn’t.

One such example was struggling over making an icon of an awning sufficiently ‘whimsical’, feedback that kept me up at night unsure how I could achieve that. I managed to get the awning right - and learned that an icon designer, I was not.

That was painful. But it was also instructive.

Knowing what I didn’t want to do helped me understand the kind of designer I wanted to be. And when I was given the chance to lean into the research and strategy work I loved, it was deeply affirming to be celebrated and encouraged for those skills.

Subscribe now

We tend to think of ambition as wanting something grand. But ambition can just be wanting something different. Ambition can be wanting to find a role that’s just right for you, that enables you to thrive and do your best work. Not to always get it right, and certainly not to always know what you are doing - but to love the work you do.

When I meet with people on my team for the first time, I like to ask them, what gives you energy? (Or using more vivid language borrowed from another former colleague - hi Polly! - ‘what fuels your fire?’) And what takes it away?

We often think of career growth in terms of promotions and salary. These things are very real, and very important. But the happiest people I know in their work are the people who made decisions to work places that embrace who they are, and where the work feels good day-to-day, because it’s aligned to how they work best.

I know this moment in the industry feels disempowering for a lot of us in UX, and with good reason. And: operating from that feeling of disempowerment creates poor conditions for doing your best work.

I still think about that awning. Not because I ever got good at making icons whimsical (or at all), but because of what the many, many hours I spent on it taught me about who I am as a designer, and who I’m not. When all was said and done and my icon made it into production, I knew something more about who I was and who I wanted to be.

I think that’s what ambition actually looks like much of the time. Not a big plan. Just paying attention to how you feel in your work, and redirecting your energy where you thrive.

From beneath a whimsical awning,

Danielle.

Share

Dear Danielle,

Bear with me as I talk about sports for a second.

On one of the recent episodes of “Dear Hank and John” (which as you know is the name inspo for our blog!), John shared the latest news on AFC Wimbledon (an English Football League One team where John is a minor investor).

They just wrapped up their season and barely staved off relegation. Now their focus during the offseason is to figure out how to do better next season (for us Raptors fans, this sounds painfully familiar).

AFC Wimbledon is a small market team, so they don’t have all the money in the world to acquire big-name players and improve the caliber of the team overnight. They recognize they have to work hard at developing the talent they already have to get better. John said something on the podcast that really stuck with me: “We can’t buy stars, so we have to make them.”

Deep down, I think what John is getting at is something most leaders know but struggle to practice: we need to have the patience to develop the talent we already have and see that through.

We’re wired for instant results. This is especially true in tech, where we move at breakneck speed so we can get to our next set of milestones and sprint towards the next one even faster. Now supercharged with AI, there’s seemingly “no excuse” to be slow. You wrote about all of this in your very insightful piece on drawing the distinction between speed and momentum.

The interesting irony in all of this is that our obsession with speed doesn’t give people enough room to show us what they’re truly capable of. We hire someone, put them on a team, and start the clock. But how focused their product area is, how collaborative their stakeholders are, how stable the org structure is when they join, how different the culture and ways of working are from wherever they came from — all of these things massively affect how quickly someone finds their footing. It takes a lot of luck for all of that to line up perfectly out of the gate.

Share

And that’s what makes stars — not talent alone, but leaders with the awareness to recognize that someone is struggling because of their environment, not their abilities. Yes, there are expectations for them to adapt, especially the more senior they are, but sometimes they just need a bit more patience and grace to succeed.

We don’t always hire instant stars on our teams. But in the cases where we gave someone more runway — moved them to a different product area, worked with them to find a more focused assignment, paired them with a stakeholder who had the bandwidth to collaborate — I’ve watched those same people become some of the strongest contributors on the team.

I don’t have a formula for how much patience is enough. Three months probably isn’t. A year with no signs of progress probably is too long. The answer, as with most things in leadership, lives in the uncomfortable middle.

What I do believe is that we can do better as an industry. The tech industry loves the narrative of the overnight success, the 10x hire, the person who walks in and immediately transforms the team. Those people exist, but they’re the exception, not the rule. And building a team strategy around exceptions is how you end up constantly hiring, constantly churning, and never actually building the institutional knowledge and trust that makes a team greater than the sum of its parts.

So we can all be a little more patient, a little more curious about what’s going on beneath the surface, and a lot more intentional about creating the conditions for people to succeed before we decide they can’t.

That’s the AFC Wimbledon lesson. You can’t always buy the star player. But more often than not the star player is already on your roster. You just need to invest the time to make them.

From explaining the offside rule to my kids for the hundredth time,

Dave

This week’s letter is brought to you by our brilliant colleague . Kate is Director, Culture & Organizational Initiatives at 1Password; in other words, she makes our work great to do everyday. Before moving into employee experience, she has a background in sales and customer success, and is a card-carrying Theatre Kid.

Dear Danielle and Dave,

I’ve been belting out show tunes since I could speak. I got an acting degree, wildly expensive headshots, an agent, and then made a genuine attempt to “make it.”

What followed was a humbling education in what making it actually required. (There was also a year as a Disney birthday party princess. Separate letter.) (Editor’s note: WE NEED THIS LETTER!)

Subscribe now

By 23, I’d made peace with the pivot, landed my first corporate job as a Business Development Representative, and discovered something unexpected: everything translated. It turned out that reading a room, holding attention when the energy shifts, and showing up composed when you’re not were not only stage skills, but enormously useful in meetings, presentations, and cross-functional conversations.

That translated skill set became the foundation of a decade of career growth.

It also, somewhere along the way, became the whole story I told about myself.

I leaned into it, and it worked. I built things. I read rooms very well. I got promoted — a few times. I got good at being good at work; and more than that, I understood why I was good at it. I began to know my competitive edge; what I didn’t notice yet was that I was also starting to become it.

There’s a difference between being good at something and that thing being the only role you can play. Knowing I could read a room and show up prepared stopped being a skill I had and started being who I was.

It showed up in small ways I didn’t clock until I started looking back. I almost never said “I’m not sure” in a meeting. I rarely let people see me working something out in real time. If I didn’t have a fully-formed answer, I’d hold the question until I did.

Being polished became non-negotiable, not because anyone asked for it, but because I’d stopped being able to separate the skill from the person doing it.

I’m eleven years into my corporate career, and I’m reflecting on what kinds of skills are actually required for the leadership level I’m now at. Realizing that skills are, in fact, just skills has been a reminder that growing as a leader involves pausing to ask what each skill is in service of. The most interesting leadership work, I’m slowly learning, starts when you let people see more than the finished version.

My identity is bigger than any one thing I’ve refined over the past decade, and so is the work.

Somewhere between the birthday parties and the corporate offsites I’ve learned a lot, but many parts of me are still in rehearsal. As we know in the theatre world, that’s where all the real work happens.

From a retired birthday party princess,

Kate

Share

Subscribe to Kate’s substack for more of her writing. 💙

Dear Dave,

A few weeks ago I wrote about speed vs momentum and the perceived perils of process in tech. We do not trust the process. We often loathe it, in fact. The process slows us down and must be disrupted! (Cue pitchforks.)

I also wrote a while back about solving problems in our AI solutions-focused era, noting that:

“The design process has always been adaptable done right — grabbing the pieces we need, leaving behind the ones we don’t, moving at the speed demanded by the problem at hand.”

As you can likely glean, I am something of a process nerd. I love seeing how people adapt and remix processes to solve problems in new ways and pull humans together to do hard things well. There’s delight in the “product-y” way of looking at the world — always looking for opportunities to shift left, try things differently, and see what learning comes out, not just in what we ship, but how we ship it.

I’ve always been conscious of the Feelings process can inspire in others — whether negative (“boo meetings!”), unproductive (“more meetings!”), or dismissive (“don’t talk to me about meetings!”).

But process is how things happen. It reflects the deeply human nature of product work: the thinking, the doing, the dot-connecting we do together as a team to make something other humans find genuinely useful.

And lately I’ve noticed a fascinating development: suddenly, everyone seems to care about it.

Subscribe now

Specifically, there’s a new emphasis on process improvement through AI — in particular, a fixation on personal software, tools you build for yourself at work whose only purpose is making you happier and more efficient. We are being more prescriptive about process than we’ve been since the days of waterfall and scrum, and the prescription is simple: use AI.

Dave recently wrote about AI learning and development, and I’d add: it’s a marvel how much space we’re being afforded to learn these tools on the job, often without any specific metric besides usage (yet).

It’s a curious phenomenon, and one many find rightly frustrating. Adopt AI tools — why? For what? We might respond: tell me what problem you think this can solve, and let’s see whether it actually makes sense.

But tucked inside even a blunt mandate is an invitation: to look at how we work, interrogate the defaults, and ask whether what we’ve been doing is the best way to do it. That’s what I’m embracing — the focus not only on building, but on how we build.

Process, at its best, is just that question, made repeatable.

From shuddering at a distant memory of the job title “Scrum Master,”
Danielle

Share