From Design Thinking to Product Decisions: How Designers Influence the Way Teams Work

Dian Wessels at UXDX Community: From Design Thinking to Product Decisions and AI Evaluation. Video: https://youtu.be/ovvf9Nz0IWA

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

How much does design influence decisions?

[00:00:08] Thanks, Rory, and hi everyone. It's great to be back at another UXDX community event. It's a beautiful spring day in Rotterdam, and it's so awesome that you're joining us today. I want to start my talk with a simple question. Just think about that for a moment. How much does design influence decision-making in your team? How about in your company?

[00:00:39] I've been working in product teams for a while now, and something started to bother me. We talk a lot about design thinking, different frameworks, design processes, double diamond, etc. But in practice, a lot of important decisions still happen outside of design thinking. In other words, without making sure the right problems are solved together. Product roadmaps get locked. Some ideas get validated after building and releasing them. Or the right people are involved when it's too late. And in my experience, it's not that people don't want to be involved. It's that they don't always get access to the thinking, or an invitation to the table.

[00:01:29] So what I've been exploring is quite simple. What happens when we make our thinking more visible, so that more people can participate in shaping product decisions and decisions in the company? What if design thinking wasn't a phase, but a shared way of working? And not just in product teams, but in the whole organization. Because ultimately, designers don't just shape interfaces. They shape how decisions get made. We have a unique role, not just to design solutions, but to influence how decisions get made in the first place.

[00:02:13] And this is exactly what I've been exploring at myTomorrows: not how to do design thinking better as designers, but how to make it more visible and usable for everyone. Before I continue, allow me to introduce myself. I'm Dian Wessels, director of design at myTomorrows, and we are a health tech scale-up based in Amsterdam. We help patients with serious diseases find and access emerging treatments.

[00:02:45] What I'm sharing today comes from trying to make design thinking more visible across our teams and in the company, and to show you what impact it can have to get everyone involved. I will share three stories with you, and each one focuses on different ways we have made design more visible and inclusive at myTomorrows. And I'll end off with some shared practices built around design thinking principles.

Story one: a design sprint for patient referrals

[00:03:16] Let's start with the story about a very important product decision. At the beginning of 2024, we had a strong clinical trial search platform for physicians. They were able to find clinical trials in any country for any disease, filtered by phase, recruitment status, age, etc. But there was an obvious gap. Physicians couldn't refer patients on our platform. They had to rely on manual outreach to research teams, and often the information was outdated or missing. This was a huge opportunity for us, so we wanted to do it right.

[00:03:57] So we called in design thinking's favorite workhorse, the design sprint. As with most scale-ups, time is precious, or pretty much nonexistent, so we used a condensed format: four half days and a full day of prototyping for the designers. But these days maybe even a half day is enough with AI tools. And we made sure to make it very cross-functional. We had design, product, our medical community team, and then many expert interviews, including several physicians.

[00:04:32] Even on that first day, we made a key discovery that became clear during the interviews, and it was something we did not anticipate. This insight changed everything for us. We stopped thinking of referrals as a submit-and-forget kind of flow. It became clear to us that various documents and details are shared back and forth before a decision can be reached. So we designed a two-way interaction between the referring physician and the clinical research team.

[00:05:12] This conversational approach led to the core experience we have today, what you see here in this demo. Physicians can now send secure messages to research teams, and they can decide whether they just want to reach out and ask some questions or refer a patient directly. With their patient's consent, they can add contact details and upload medical documents, all with the goal of helping research teams reach a decision about a patient's eligibility faster. Since we launched this feature, we have had hundreds of patient referrals on our platform, and we get strong usability and usefulness scores from physicians.

[00:06:01] Better decisions happen when more people are involved in understanding the problem. Not just designers talking to users, but teams understanding and then designing solutions together. So, in the spirit of the design sprint, here is a how-might-we question for you. How might we increase our team's opportunities for sharing insights that can affect crucial product decisions? Design sprints are one way, but they're a huge time investment. Take this question to your team and brainstorm some ideas. We'll also look at some other tactics and practices towards the end.

Story two: the product design dream day

[00:06:47] Now let's move on to a story about the design team. At some point last year, I noticed my team was stuck in execution mode. We were doing good work, we were supporting the product teams, but it was reactive. Product requirement documents leading to wireframes, feedback, prototypes, all in this continuous loop and cycle, but it's still just reacting to what we get. So I wondered, what would we design if we started from a clean slate? Just the designers in a room with an empty canvas.

[00:07:29] And so the product design dream day was born. We used no documents, no constraints. We just asked, what do users really need? We explored the problem space, going as wide as we could. We themed to zone in on the biggest problems, and then we voted for the most important jobs to be done across user groups. Then we created several concepts across the full journey. We voted again, and then we picked the best ideas to wireframe.

[00:08:02] And here is what we did next. We invited key stakeholders in the company into our process. I had meetings with our head of product, CTO, COO, CEO and many others to take them through our vision. There are so many Cs and Os in our company, and I'm guessing in yours as well. I took them through the Figma wireframes, and afterwards people could review and comment on them. In this way we could refine our thinking and align it with what was feasible and viable for the company, not just what we thought was desirable for our users.

[00:08:46] At some point during this process, I told the CEO that maybe we could make an inspirational video for our annual company event, called My Tomorrowland. And he loved the idea. Oops, now we have to deliver on it. So we created a high-fidelity prototype in Figma, and this was before we started using Cursor and all these wonderful tools. It was all still manual. We created a full storyboard for a video showing our reimagined patient, navigator and research team user journey. And we managed to create a full video with stock footage, some of our own footage, music, you name it, and we finished it just in time for My Tomorrowland.

[00:09:36] Our CEO used it to end his speech at the company event, where our Mighties, as we call them, flew in from all over the world. It was a very proud moment for me and my team. People saw the future as we envisioned it, not as static slides, but as something tangible. And afterwards, it changed how people talked and felt about what our platform could be.

[00:10:04] Unfortunately I can't show the video here, but what I can show you is a glimpse of what the product team is currently building. This design solution came directly out of our design vision prototype and made its way onto the company roadmap. So people got excited by what they saw, they bought into it, and now it's becoming a reality.

[00:10:33] Design thinking made visible can influence what we decide to build. Not by pushing, but by inviting others into the process and helping them see and contribute to your vision. So here is another how-might-we question for you. How might we make our thinking more visible to the rest of the company? My advice is, don't wait for permission. Take the initiative. Dream. Imagine, shape and share. And then see what happens.

Story three: Mighty Minds and company culture

[00:11:16] And finally, a story about company culture, which is to say, how we do things. I've always loved Pixar's movies: the creativity, the craftsmanship, the humor. It's just magical. But this level of animation excellence doesn't happen in isolation, of course. Hundreds of people are involved in the process, and to ensure quality, they have this concept called the Braintrust. The Pixar Braintrust is a regular peer review meeting where trusted directors and story experts provide honest, constructive feedback on films that are in development. It drives quality by offering, not mandating, solutions to creative problems. The director still has the final say, but it helps them towards their shared goal of excellence over mediocrity.

[00:12:21] Inspired by this spirit of collaboration and design thinking, I put forward the idea of Mighty Minds. At my company, we add "mighty" to everything, because the "my" of myTomorrows sounds like "mighty". And as I said before, we even call each other Mighties. I pitched it as a cross-functional workshop where people could offer ideas they wouldn't normally bring up in regular meetings. We would foster a culture of curiosity, psychological safety and shared ownership of our future. And it could potentially help leadership uncover important themes that help us with long-term planning and innovation.

[00:13:10] Leadership liked the idea, and a few weeks later we had our first workshop. People from different departments joined in. I opened it up to the whole company, and I was happy to see that people from operations, marketing, the people team, engineering, basically every department, were represented in some way. Using a design thinking approach, we identified current problems or opportunities in the company. We double-diamonded throughout the morning. Yes, I just made that a verb. We diverged, we converged, we themed, we voted, we picked a problem, we brainstormed ideas using Crazy Eights, we picked the best ones, we riffed on them, etc., etc.

[00:14:00] What amazed me was how engaged people were, and the level of creativity that we could see in the workshop. People used all manner of stickies, stickers, stick figures, anything to express their ideas. I find that people generally love getting the opportunity to get creative and playful in a safe space. And the more diverse the group, the better: the more fresh perspectives and ideas come to the table.

[00:14:32] But when I did the same workshop for a second cohort a month later, the mood had shifted. The themes that surfaced related to trust and morale, with ideas like electing a trusted person or showing a weekly happiness chart. I shared these insights with the leadership team, because it was clear that a lot of people felt uncertain and burdened at work. And then leadership acted. In a company-wide all-hands, several measures were introduced to relieve the pressure and to create more transparency. During that meeting, Mighty Minds was cited as evidence that helped leadership make these decisions. In the weeks thereafter, the mood shifted in the company. People felt more positive, seen and appreciated, as became clear in a survey that we did.

[00:15:37] The more people you include in design thinking as a shared practice, the more your company will benefit. You can help shift company culture by surfacing the most important problems to solve, and by solving them together in a safe space where everyone's creativity matters. So here is your final how-might-we question. How might we make design thinking a shared practice in our company? Again, I encourage you to be proactive. Come up with an idea, a workshop, a brainstorming session, anything, and see what impact it can have. Remember, you miss 100% of the shots you don't take. I know it's cheesy, but it's true.

Shared practices across the design thinking phases

[00:16:29] Now, to wrap things up, here are some principles and practices for you to try with your team. Maybe you already do some of these, maybe you do all of them. For each of them I'm using a design thinking principle or phase as proposed by IDEO, and I'd like to share some common practices that we have at myTomorrows.

[00:16:55] Empathize. Our UX researcher hosts regular watch parties after significant research has been completed. This includes video clips with core insights, and we usually encourage all engineers and product people in the feature teams to participate. We also share patient stories during our company-wide monthly meetings, and this helps everyone in the company get closer to real people sharing stories about how access to treatments has changed their lives.

[00:17:30] Define. We have bi-weekly UI squad meetings where the product designers and the front-end engineers meet to define current problems to solve. We recently completed a thorough platform audit where we documented and themed all UI and UX issues, big and small. I like to remind the team that we need to eat our own dog food, and an audit is an opportunity to do just that.

[00:18:00] Ideate. While we don't have a specific ideation practice that stands apart from the design thinking process, I want to mention that I believe teams miss out when ideation excludes engineers. So my advice is to include them as early as possible to contribute their thinking. More often than not, engineers impress me with their systems thinking, their user-centeredness, and how they approach problems in a different way. And often we go with their solutions instead of something that the designers come up with.

[00:18:42] Prototype. We live in the best age to prototype quickly and efficiently. Our team is constantly experimenting with new canvas-to-code and, recently, code-to-canvas workflows. And with Claude Design [?], which launched just last week, it's a very exciting time to be a product designer. So you have no excuse not to prototype and test as often as possible.

[00:19:09] That brings me to the last one, which is test. We like to have open research sessions. When we have moderated research sessions, we open them up to small groups of relevant stakeholders so they can observe silently. We usually have a big FigJam canvas in the background where watchers can comment on what they see in real time. Then afterwards we can analyze and theme those comments and use that to inform our product decisions.

[00:19:46] To summarize, I want to remind you that design thinking is a human-centered problem-solving toolkit with unlimited potential. Its ripple effect is powerful. As you include more people in the practice, its influence gets bigger, and its impact can be felt not just in your team and company, but by all the people that come in contact with you and the products you make. That's it, folks. I hope you found the session valuable. You can scan the QR code to connect with me on LinkedIn, or visit my website for future talks. Back to the studio for some Q&A. Thanks for watching.

Q&A

[00:20:33] Rory: Excellent, thank you very much, Dian. I love the real examples. It's almost like I can get an insight into the company culture at myTomorrows, so thanks for taking us through it.

[00:20:44] Dian: Of course.

[00:20:45] Rory: Just to reiterate, as Dian said, please write in your questions on whichever platform you're watching this on, and we'll put those questions through to Dian. One thing that came up for me as I was listening was: what is the approach in your company for when ideas get funded? In some companies it's quite formal; it goes through a business case process, often driven by sales or marketing or things like that. But it seems like it's a lot more fluid, or informal in my terms. Can you explain a bit more about how that works?

[00:21:22] Dian: I think it's a combination. We certainly have leadership being responsible for where the company is headed, and that includes the product. They need to make sure that whatever we build is viable. We focus more on desirability in product and UX, of course, and then viability with the engineering team. But all of that serves the business and its users. Ideas, though, are born either within the teams or outside of that. What I'm getting at with design thinking made more inclusive is that you can expand the sphere in which those ideas are born, so that eventually it includes everyone in the company.

[00:22:15] It's not mandated just from the top, or from the bottom from the design side, but it can take root anywhere in the company, and then you take it through the rest of the design thinking process. You validate the idea, you create quick prototypes, you take action, you go and test it with real users before you decide to actually build. So, to get back to your question, for us it's a mix. It's certainly not just leadership, and it's not just the product and design teams.

[00:22:51] Rory: Brilliant. And I'm sure that's a situation a lot of people would be quite jealous of.

[00:22:55] Dian: Yeah, I think it's because we're still a small company. We're 130 people or so. I think when it's a very large organization, it gets harder to do that. So I've been very lucky that I've had the opportunity to take the initiative and try things. But I guess the message is that wherever you are, in whatever size company, try something. At the very least you will learn something if the idea doesn't work. But don't wait for opportunities to come to you.

[00:23:32] Rory: That's great advice just in general. My question then, and I guess it's linked, is around how you got or convinced people to give so much time, particularly senior executives. How did you convince them that this would be a valuable use of their time before they invested in it?

[00:23:53] Dian: With the design sprint, we were faced with high uncertainty, and that's usually when it's a good idea to do one. We weren't sure what the best approach would be for this high-stakes problem to solve. And we used the condensed format, like I said, so it uses much less time. We try to keep the team small, like seven people or so, and then we only bring in senior leaders for expert interviews, which would only be about an hour of their time.

[00:24:34] We've also experimented with even shorter design sprints, like mini design sprints conducted over a day or two. I once tried one that was two hours, but that's too short. That didn't work at all. It was a company-wide training on design thinking and design sprints. So it has its limits. But we try to bring leadership in at specific moments in the process, so that they can weigh in. We don't expect them to sit in on a full day of mapping or designing.

[00:25:11] Something else that we did, now that I think of it, that works really well, is to have a public vote on the idea. When you have your gallery day for the design sprint, we let important stakeholders vote, of course, but we open it up to the company, so that, using a different kind of sticker, people can vote for their favorite ideas. That also helps to validate the direction we're going.

[00:25:38] Rory: Excellent. A nice and democratic approach.

[00:25:42] Dian: To a point.

[00:25:44] Rory: We have a question coming in from Irene. First of all, she thanked you for the insightful talk, but her question is around vulnerable users. How do you decide at which point or points to involve them in your process?

[00:26:02] Dian: Accessibility is a very important theme for us at myTomorrows. We deal with patients from all walks of life, with a stronger focus on patients with serious disease, and some of these diseases can be debilitating. In those vulnerable groups, it's sometimes harder to get specific users to contribute to research, and in those cases we rely on people that have worked with those kinds of patients. We have a very diverse team with medical backgrounds in the company. The UX researcher in my team is a registered physician. She used to work in hospitals in South Africa with many vulnerable patients, and her insights are so valuable to us in the team, because they're from real-world experience.

[00:27:03] But wherever we can, we do try to interview real users, whether patient or physician or research team member, and we try to make what we build accessible. Our goal is to have at least AA level for the platform and the website. It's still a work in progress for us, but it's definitely the goal to make it as accessible as possible for all users.