Overview
The Problem
Design was seen as the blocker to delivering on new features.
When I joined to replace a two-person team, I inherited a reputation that Design was too slow. As the sole designer, I built infrastructure to help move and scale faster. Output improved with not only speed but greater consistency. Yet the perception remained the same.
Hypothesis
Faster design should have resolved the friction if speed were really the constraint.
I had a hunch speed wasn't the real ask. In order to find out what was behind the tension I sensed, I came up with an experiment to test if improving speed once more would alter the perception of Design in the team culture.
Experiment
AI-coded prototypes showed potential for speeding up the most time-intensive parts of the process.
I made coding accessible in a way it hadn't been before. Combined with our component library, it meant I could iterate on complex interactions much faster than traditional design tools allowed. This was the moment to test what that capability could unlock for the process itself.
Complex interactions
Code offers a way to create more complex prototypes much faster than can be done in Figma.
Faster ideation
Being able to create a prototype much faster allows for rounds of ideas to be worked through more quickly.
Scalable prototyping
Coded prototypes can be made to be cumulative, with each one becoming the foundation for the next.
Speed up development
Coded prototypes using the product's tech stack have potential to speed up handoff.
01
No-code tools were the most accessible entry point, and, as it turns out, the most limited
No-code tools promised speed but hit their ceiling fast. Local environment coding tools such as Cursor offered more flexibility at the cost of a steeper learning curve. Scalability meant choosing the harder path.
Levels of AI coding tools
02
AI assistance made the learning curve manageable.
With no coding background, I leaned on AI assistance to work through the basics and build up my foundations.
Cursor AI-assisted Coding
03
Starting from zero, I rebuilt both products in code and built the testing infrastructure around them
No access to the sandbox environment opened another opportunity to build scalable prototypes. I built the mock version of our claimant platform and our claims professional portal, starting with the applicable flows from live projects.
Claim Professional's portal prototype
Component library built in Storybook
Results
New process excelled, and proved "speed" wasn't the real ask.
Days, not weeks.
Complex interactions that would have taken an additional week in Figma were resolved in days, with clearer outcomes and faster creative clarity.
Faster, realer feedback.
Handing off working prototypes for internal testing meant stakeholders reacted to something real, and feedback came back faster.
Leadership wanted in.
The Head of AI and Head of Product didn't just approve the process. They brought their own ideas to it and requested access themselves.
What surprised me was the immediate request from Heads of departments for access while the feedback stayed the same.
Design is still too slow.
It confirmed the real constraint wasn't Design's speed. It was the desire to build their own ideas out.
Analysis
Crosstie's internal tension reflected a shift already reshaping how product teams were changing across the industry
Crosstie's internal friction wasn't unique. It was a microcosm of a larger shift reshaping product teams everywhere. With AI lowering barriers to research, strategy, design and even code, the competencies once exclusive to Product, Design, and Engineering have become more permeable. Yet this blurring doesn't mean roles collapse into one; rather, it's about who wants to own which competencies, and what your organization actually needs.
Product Trio roles diverging with AI lowering barriers
For Crosstie specifically, a build-to-learn model made sense:
- 1. Established design system and a library of components to pull from that would cover at least 90% of their design needs.
- 2. If current trajectory maintained, they could achieve their $10-12M ARR goals within 1 to 2 years with the given roadmap and very light Designer input.
- 3. The team had proven they could whip up technical prototypes at a speed which made build-to-learn less risky.
- 4. Heads of departments already showed a desire to bring their own ideas to life. If the Design function stayed as it was currently set up, it would continue to create friction.
But the real insight was recognizing that as building becomes easier, the needs shift from efficiency to focus. Without design thinking to guide which experiments matter most, teams risk scattering their energy across too many directions.
The companies that'll win are those that keep design thinking as their north star, even as design's output becomes more democratized.
Findings
A recommendation that seemed to argue against design was the one that proved its value most clearly
I recommended the team adopt a build-to-learn model, shifting toward fractional design support. It was adopted immediately. The design role transformed from gatekeeper to guide, present for strategic moments that truly needed design thinking, while the team moved fast on their own.
It felt counterintuitive to recommend Design step back, but that constraint was exactly what unlocked the team's potential. The team could move fast, and Design stayed where it added real value.
More work
Helping claims professionals find what matters in complex files
An AI document tool helping claim professionals navigate massive claim files, turning a day of reading into minutes of verification.
Guiding respiratory patients towards the best technique
Redesigning NuvoAir's spirometry app to guide patients through the latest ATS standards, securing FDA 510(k) clearance in January 2024.
From single measurement tool to full clinical trial platform
Redesigning the two-sided clinical trial platform to reduce participant dropout and give coordinators early visibility into at-risk participants.