Perspective · not a claim that fundamentals are dead
UX process in the AI age.
AI has changed the cost and speed of making things. When a rough but working prototype takes hours instead of weeks, UX has to become more continuous, more evidence-led, and more experimental — closer to the material of the product itself.
This is a point of view on process, not a claim that research, strategy, or craft matter less. It's about how those fundamentals get applied when the cost of making has collapsed.
The old sequence moved through separate rooms: research first, then strategy, then design, then engineering — each handing a polished artifact to the next. That worked when making something tangible was slow and expensive, so teams saved the real cost for the end of the process.
That sequence is too slow for a lot of questions now. A rough but working prototype can exist in hours, which means a team can test an assumption about the problem and the solution at the same time, instead of waiting for a clean handoff to find out either was wrong.
Speed alone doesn't create value, though. Without clear goals, reliable context, and honest evaluation, a faster loop just produces more noise, faster. The Stingray process is a way to keep that loop deliberate.
The framework
The Stingray process
Three connected stages — Train, Develop, Iterate — replace a one-way funnel with a loop. What a team learns in Iterate feeds directly back into the next round of Train. Named for the Board of Innovation's AI-powered "Stingray" model (see sources), adapted here as a personal working framework, not a claim of original authorship.
Forward motion with a return path — not three isolated boxes.
Stage 01
Train
Set direction and build context before anything gets made.
Define outcomes, constraints, and success measures
Pull in known research, market signals, and org knowledge
Use AI to synthesize and challenge those inputs
More on Train
AI is genuinely useful here for synthesizing and pressure-testing inputs faster than a person alone — but the team stays accountable for the context, the data quality, and how the problem gets framed. A well-trained model on a badly framed problem still ships the wrong thing, just faster.
↓ feeds into
Stage 02
Develop
Explore problem and solution hypotheses in parallel, not in sequence.
Generate multiple problem framings, not just one
Use AI to widen the option set and speed up tangible prototypes
Build directly in the delivery medium when it reduces handoff loss
More on Develop
The point isn't to generate more options for their own sake — it's to avoid committing to a single polished artifact before the team knows which problem is worth solving. Some paths will visibly fail fast; that's the loop working, not a wasted effort.
↓ feeds into
Stage 03
Iterate
Test the strongest concepts against real evidence, then feed what you learn back into Train.
Validate with real users and stakeholders, not just internally
Weigh desirability, feasibility, viability, accessibility, and risk
Route what's learned back into the next Train cycle
More on Iterate
Synthetic or AI-assisted evaluation is useful for generating hypotheses quickly, but it doesn't replace research with representative people — especially for decisions with real consequences for real users. The loop closes with evidence, not a confidence score.
What stays human
AI expands the exploration. People still own the direction.
Across all three stages, AI is doing real work: synthesizing inputs, generating options, speeding up prototypes, surfacing patterns. What it isn't doing is deciding what matters, recognizing harm, interpreting context, or building the trust that makes a product worth using.
StrategistDeciding which problems are worth the team's time.
Systems thinkerSeeing how a change in one part of the product moves everything else.
FacilitatorGetting the right people and evidence into the room before a decision gets made.
Quality stewardCatching what's unsafe, inaccessible, or quietly biased before it ships.
In practice
A familiar starting point
A product leader arrives with a familiar challenge: customer needs are changing, the team has more ideas than capacity, and the pressure to move faster is rising. In the past, the work might have moved through separate rooms — research first, then strategy, design, and engineering — each handing a polished artifact to the next.
In the AI age, that sequence is too slow for many questions. A rough but working prototype can be created in hours, making it possible to test an assumption while the team is still defining the opportunity. But speed alone does not create value. Without clear goals, reliable context, and thoughtful evaluation, teams can simply generate more noise.
The Stingray process provides a more deliberate rhythm. The team trains on the right context and constraints, develops a wide range of problem and solution hypotheses in parallel, and iterates through real-world evidence. AI expands the range and speed of exploration; people remain responsible for framing the work, interpreting what they learn, and deciding what should exist.
The result is not less UX. It is UX practiced closer to the material of the product: faster to make tangible, more continuous in its learning, and more accountable to the people it serves.
See this thinking in the work.
The Stingray process shapes how these projects got built — quick working prototypes, tested and refined against real use, not just polished mockups.
"Stingray" is the Board of Innovation's term for this model, not an Adomski invention — the framing above is my own take on applying it to UX work, adapted from their article. The two pieces on the double diamond below shaped the broader argument that a strictly sequential process struggles to keep up with AI-assisted, working-prototype speed; their specific arguments and conclusions are the authors' own, not reproduced here.
