The Initial Vision
Lately, I’ve been working with some amazing companies in the healthcare space. The Grants Program at Arionkoder began as a way to support impactful startups while expanding our knowledge in AI and UX — two disciplines that, at first glance, might seem like opposite ends of a spectrum. Yet they share something crucial: users and the need to simplify experiences.
At the start, we introduced the go-to tool for researchers, designers, and product teams: the Design Sprint. It’s an incredible method for gaining structure, speed, and clarity. And while it’s a great starting point, we realized that sometimes, we need to dive deeper into the unique context of each project.
Our initial hypothesis was simple: every Grant would benefit from fast prototyping and UX/UI improvements. And that’s still true — they do. But let’s look at some real examples to go beyond the surface.
Why the Design Sprint Felt Like the Right Starting Point
When we first kicked off these projects, we craved structure, speed, and clarity. On one hand, we had deep expertise in product development and technology. On the other, we were stepping into industries — especially healthcare — that felt intimidating due to their complexity and real-life impact.
We partnered with iSono Health, Clarified Precision Medicine, and SkinCheck — three incredible companies with a shared mission: to democratize and improve access to cancer detection and treatment.
We wanted to make the most of our time with them and deliver the most relevant outcomes. As Google defines it, a Design Sprint is “a proven methodology for answering critical business questions rapidly through designing, prototyping, and testing ideas with users. Design Sprints save four to six weeks of development time by aligning teams under a shared vision with clearly defined goals, deliverables, and validated solutions.” (Google, 2025).
The Turning Point: What If We Need to Adjust to More Specific Needs?
As the weeks went by, we realized not all projects had the same level of maturity across business, tech, or openness to innovation. This made it difficult to fully leverage the Design Sprint process in every case.
During early conversations, we started asking ourselves: is a prototype or a UI fix all we can offer?
UX Design is a broad field — and it shouldn’t be reduced to usability or screens. Designers need to understand the who, why, what, and how before they begin creating anything.
Some of the early challenges we faced:
- No access to user personas or none defined
- Lack of customer journey maps
- No review of real product usage
So we started implementing what was actually needed:
- Better problem definition
- Interviews with users and domain experts
- Direct user feedback loops
Why One-Size-Fits-All Doesn’t Work
After several discussions and observations, one thing became clear: Discovery was the biggest challenge.
When we pushed Discovery too close to the Sprint (days before), we ran into problems like lack of maturity, missing information, unclear definitions, and team misalignment.
We realized that applying the same linear process to every Grant wasn’t ideal. It could still add value — but we could do more.
The core challenges we faced:
- A premature focus only on software/product solutions
- Skipping the Discovery phase too early
- Over-emphasizing outputs like mockups instead of outcomes
Introducing a Maturity-Based Approach
So, we decided to adapt. We started evaluating each project’s research readiness, business/tech maturity, and used that input to tailor our workflow.
We created a simple model to classify projects based on their stage, and matched our process accordingly:
- Early-stage Grant → Start with interviews, user journeys, and pain point mapping
- Mid-stage Grant → Co-creation and design exploration
- Mature Grant → Prototyping, usability testing, and scaling
This helped us align expectations and deliver value where it mattered most.
Lessons Learned & Recommendations
One of the biggest lessons: design methods are tools, not dogmas. You can (and should) adapt them — because the goal isn’t to follow a book. It’s to make a product that’s meaningful.
Discovery is not optional — it’s the core of what we do in product. Knowing where we stand with users, product-market fit, and data gives us real tools to move forward.
And most importantly: alignment with the team’s context saves time and increases impact.
Final Reflection
After closing most of the Grants, my biggest recommendation?
Don’t just sell a process. Start by listening — to your client, their project, their users.
In Arionkoder we truly believe that listening is one of the most underrated human skills. We started by asking better questions. So can you.
Don’t start with “What method should we use?” That’s valid, but it’s not always the first question.
In UX, we deal with people and problems. That means we must be adaptive, not prescriptive.