In brief: AI made producing designs almost free, but it couldn’t speed up knowing whether the data was real. On our life sciences program, the hardest bottlenecks came from data and the human structures around it: knowledge held by a few experts, experts stretched across several programs, and answers that didn’t travel between parallel workstreams. We responded with templates bounded by what the data could support, earlier and better-targeted expert involvement, a planned agent to remember every data validation, and a new integrated planning model built with the whole team.
This is the final article in our series on AI-accelerated design inside a large life sciences program. Earlier parts covered how we sped up, the design system that made it possible, and the AI agents that build alongside us. This one looks at the bottlenecks all that speed exposed, and what we did about them.
When producing screens becomes almost free, your bottlenecks don’t disappear. You simply reach them sooner. On our program with a global life sciences leader, the hardest walls we hit sat outside the design process. They came from data, and from the very human structures that governed it.
Why data sets the real timeline in AI-accelerated design
AI speeds up the parts of the work that live in words, logic, and screens. It cannot speed up knowing whether the data is real. Mapping the data, confirming that it exists, and working out which connections still need to be built all happen at human speed. In life sciences and healthcare organizations, that work is harder still.
Much of the data is highly sensitive and protected, so knowledge of it is limited to a few people, and sometimes to one. When the answers to “does this data exist?” and “how does it connect?” live in a single person’s head, that person sets the timeline, whatever the tooling can do.
These data mapping constraints were always there. In a slower process, they stay hidden for weeks, waiting to derail the work later, when they are far more expensive to fix. Our accelerated way of working reached them sooner, and we count that as one of its most valuable features. Moving fast turned a future surprise into a present problem we could see and act on.
Three lessons about data, experts, and shared knowledge
Our bottlenecks had little to do with making things. What needed attention was how knowledge of the data moved across calendars, across our design canvas, and between designers working on parallel tracks. Three lessons stood out.
Lesson 1: Guardrails would have made us faster than a blank canvas
Our early drafts let us explore openly with the business, and that openness let us design things the data could never support. We would follow a promising direction, invest real design work in it, and then backtrack once we learned the data underneath couldn’t deliver it. Guardrails wouldn’t have slowed the exploration. They would have kept it inside what was possible, so no effort went into building toward something that was never real.
Our solution was to start from a canvas with as many guardrails as possible. We built templates and patterns bounded by what the data could support. Design exploration stayed fast because it stayed inside what was real, which streamlined the path from discovery to development.
Lesson 2: Inviting experts early is different from having their attention
We did invite data experts into our early discovery. The problem was that they were often double- and triple-booked, so even when they joined, we didn’t always have their full focus.
The data SMEs we needed were frequently committed to two, three, or more programs at once. Even when they attended a discovery session, questions that needed their undivided attention were often answered in fragments, spread across weeks of emails and Microsoft Teams chats. Their availability set the pace more than the design work did.
Our fix was to treat expert attention as a scarce resource and design around it. We brought experts in early to help define design guardrails before the blueprinting workshops and validations that depend on them, so their limited time went where it made the most difference.
Lesson 3: Answers that don’t travel get asked twice
We were learning a new domain as we went and uncovering solutions in real time, while separate blueprinting workshops for different capabilities ran in parallel. Data experts weren’t always available, and they were often hearing requirements for the first time in those same sessions, so we had to wait for their approvals before signing off work for development. Validations arrived at different times, in scattered conversations, across tracks that weren’t always aware of each other. One track would settle a question, and another would unknowingly ask it again, or wait for an answer that had already been given. Some data questions were asked and answered more than once, and on at least one occasion, a workstream waited for an answer that already existed.
To fix this, we identified the need for another agent. Like the Orchestrator, it wouldn’t design or build anything. Its job would be to remember. Working alongside us, it would hold what had been discussed and what had been settled, capture every data validation the moment it was confirmed, and surface it as soon as anyone on any track was about to retrace a path we had already ruled out. We didn’t have it ready for this engagement, but it is one of the clearest improvements we are carrying into the next one. It also sums up the lesson of this article: getting an answer mattered less than making sure the answer traveled with us.
Our most important fix was a team conversation
Our wider team, spanning business, design, development, data, and testing, came together in focused working sessions to name what went right, what went wrong, and, most importantly, how to fix it going forward.
Those sessions produced a new integrated planning model aimed at the real problems of visibility, dependencies, and coordination. Its core ideas are:
- Recurring, focused planning sessions with a cross-functional group, so every discipline sits at the same table instead of being consulted after the fact
- Regular cross-team dependency check-ins, to catch the connections between teams before they turn into surprises
- Entry criteria, exit criteria, required inputs, and expected outputs defined by every team, so hand-offs are explicit instead of assumed
- Planning backward from release targets, which moves the hard conversations upstream, where they are still cheap to have
The goal went beyond planning work. It was to expose constraints and prompt earlier conversations about commitments, capacity, and dependencies, so missed assumptions surface before teams reach their delivery dates. One of the sharpest challenges raised in the room was whether business priorities alone give teams enough to plan against, and how well this new way of working absorbs the lessons of earlier releases.
Every lesson pointed back to knowing what is true
Each of these lessons comes back to the same need, and the speed of making has little to do with it. What matters is keeping the truth present and remembered: getting the right knowledge into the room, bounding the work by what is real, and making sure a hard-won answer never has to be won twice.
We built a design system that machines could reason about, and a team of agents to do the making. Together, they made us fast. The fast part, though, was never the hard part. AI let us design at the speed of a sprint, and the biggest takeaway is that walking into the right data beats sprinting into the wrong data.
Speed is now cheap. Judgment isn’t.
Where has your bottleneck moved?
This is how it played out for us, and we’d like to hear how it is playing out for you. If you’re designing or building with AI, where has your bottleneck moved? Is it still in the making, or has it shifted upstream to the data, the experts, and the truth underneath the design?
If it would help, I’m happy to share more of the mechanics. I can post the checklist our Analyze agent runs when it turns a plain request into a structured spec, including the questions it asks about areas, data, actions, states, and accessibility. Say the word below, and I’ll drop it in the comments.
Frequently asked questions
In our program, the biggest bottlenecks came from data rather than design. AI speeds up producing screens, but mapping data, confirming it exists, and working out missing connections still happen at human speed.
Much of the data in life sciences and healthcare is sensitive and protected, so knowledge of it often sits with a few people, sometimes just one. When the answers to whether data exists and how it connects live in one person’s head, that person sets the timeline.
Guardrails keep exploration inside what the data can support. We built templates and patterns bounded by the available data, so designers never invested effort in directions the data couldn’t deliver.
Treat their attention as a scarce resource and plan around it. We brought data SMEs in early to help define design guardrails before the blueprinting workshops and validations that depend on them, so their limited time had the most impact.
Capture every data validation the moment it is confirmed and make it visible to every track. We identified the need for an AI agent built to remember settled answers and surface them before anyone retraces a path that has already been ruled out.
It is a planning approach built around visibility, dependencies, and coordination. Ours includes recurring cross-functional planning sessions, regular dependency check-ins, entry and exit criteria for every team, and planning backward from release targets.
No. Those constraints existed all along. Reaching them sooner turned a costly future surprise into a present problem the team could see and address.
