I’ve decided to start documenting my exploration of the health-tech space through courses, projects, and other things I learn and build. I’ve always had a love for health, and much to my aunties’ chagrin, I did not become the doctor they wanted me to be - the one they wanted to call up as they aged and pained away. Instead, I chose tech, and lately I’ve been wondering where my place really is in the field.

I don’t really love conventional software engineering anymore, or at least I’ve lost some of the desire for it, especially in the age of AI. But I do think there is still so much to be done and uncovered in tech, particularly when we use it to solve real, day-to-day problems. So I went and woke up that 17-year-old who once loved chemistry and biology so much and told her to start reading again, to start learning again.

So here we are, in entry one of a series I’m calling Scrubs - named after one of my favourite sitcoms.

Lesson One: Co-designing Digital Health

The first stop is Part 1 of the Co-design for Digital Health course by King’s Health Partners.

Digital health is an umbrella term for everything from mobile apps and patient portals to software that analyses medical scans, wearable devices, implants, virtual reality, robotics, AI systems, and even standalone software used in hospitals. If technology touches healthcare in a meaningful way, it probably falls somewhere under digital health.

Co-design is exactly what it sounds like: designing with people. The people who will actually use a service or be affected by it become the experts in their own experiences.

The course also spent time talking about what isn’t co-design. It’s not deciding on the problem before you’ve spoken to anyone. It’s not bringing users in for one workshop and calling it participation. And it definitely isn’t asking for feedback after you’ve already made up your mind.

It’s a pretty obvious idea, but I find that even though we did foundational courses in design thinking at uni, more often than not I’ve seen us build products in our own isolated startup bubbles. And I say “us” because I think I’m one of the biggest culprits.

I’ve done a couple of health-tech-projects-turned-startups now, and I can tell you for sure that while we do ethnographic research, surveys, and all of that, we don’t really go in-depth when it comes to involving all the stakeholders. More often than not, we end up focusing on the people who would spend money on the product.

And I get it. Speed is a really important part of the lean startup philosophy. But I think it can become a dangerous thing in health tech. I think it’s part of why we run into problems like low adoption or realise we aren’t actually solving the problems that needed solving in the first place. That’s what I like, at least conceptually, about this whole co-design idea.

When people help shape a solution, you’re more likely to build something they actually need and want to use. You’re also less likely to spend months building features nobody asked for. In healthcare, where people’s lives and wellbeing are involved, that feels worth slowing down for.

One thing that stuck with me was how broad the idea of a stakeholder really is. It isn’t just doctors and developers. Patients, carers, researchers, community organisations, local authorities, and plenty of others all experience healthcare differently. If you’re only listening to one group, you’re only seeing one piece of the puzzle.

But the course wasn’t overly optimistic either. It talked about what the authors call the “tragedies of co-design”: situations where involving people is done poorly, becomes tokenistic, or even causes harm because expectations aren’t managed or participation isn’t genuinely valued.

And even when everyone has the best intentions, co-design isn’t easy. It takes time. You need the right team. You have to think carefully about whether the people in the room actually represent the wider population. And in digital health, there’s the challenge of digital exclusion. The people who could benefit most from a technology may well be the very people least able to access it.

This lesson was a reminder that technology is only useful if it works for the people it’s supposed to serve. Building something clever or cool-looking is one thing. Building something people can actually use, trust, and benefit from is another.

I hope I can be brave enough to do it. For now, my parting words are, “I can’t do it all on my own, I’m no Superman.”