Why a shipped feature isn’t finished until clinicians can find it, what our feature announcements were getting wrong, and the review we’re missing between design and go-to-market.
Adoption was the topic at our Monday design warm-up this week, and I wanted the design org to treat it as partly our number. The standard I gave the room was this: our design isn’t done until we know the clinician can find it, understand it, and trust it. And if the answer is that we created a banner for them, that’s not good enough.
Our design isn’t done until we know the clinician can find it, understand it, and trust it.
A senior designer pushed back. Adoption has a lot of causes, from how we explain a feature’s value to the product decisions behind it, and design isn’t in every one of those conversations. Their point was that design carries the weight for adoption without having a say in most of the decisions that drive it.
I accepted the pushback, partly. It’s not all on us, and it is partly on us, for 2 reasons. Design is one of the few teams that looks across the whole platform on a predictable rhythm, every week in crit. And we can see the experience end to end in a way a launch plan can’t. Where we landed together is that the gap they described is a missing review: a session where product, design, engineering and go-to-market look at the product together, before launch, as one team. Today our go-to-market partners often learn why we built something late in the process, and it turns into a handoff. I’d like it to feel like a partnership.
Then there’s the banner itself. This week I asked one of my design leaders to go back through every feature introduction we’ve launched recently: the banners, the modals, the small boxes that tell clinicians something new is here. Some have illustrations, some have old illustrations, some have icons, and some have nothing at all. The wording changes from one to the next. Put side by side, they read like ads, and I think the reason is that they don’t look like us.
So, here are the moves we’re making.
Scrub the pattern first. Go back through every one of those boxes, make the container, the elements inside it and the wording consistent, and use that as the standard for every feature introduction after it. The goal is an introduction that feels like something we’re doing for the clinician, and not something we’re selling them. My first message about this asked for consistency on “every new feature,” and a design leader read it as a request to change our design system components. That one was on me: I meant the introduction surfaces, and I’ve since said so in the thread.
Look at what a clinician sees when they sign in. Before we add one more announcement, rebuild what a clinician actually sees at login, even with a fake account if that’s what it takes, and count the messages competing for their attention. It’s hard to argue for another banner once you’ve seen the stack of them a clinician scrolls past on a Monday morning.
Explain it in the context of their practice. A banner says what a feature does. The question a clinician is asking is what that does for their business: here’s the problem this solves, and here’s what solving it means for your week. Customer support hears that question on calls every day, so what they hear should seed the story before we write a word of it.
Bring go-to-market into crit for confirmed launches. If we know something is going to launch, our marketing partners should see it in crit while it’s still taking form, and our designers should sit in on marketing’s reviews to catch where the story drifts from the product. Experiments can skip this, since a good share of them won’t ship.
A banner is still allowed, as the last thing we design, after the clinician can already find the feature, understand it and trust it.