Building a More Durable Healthcare Design Jobs Board
Healthcare design is one of the most antiquated, highly complex, and high-impact domains out there, and the problem space couldn't be more important right now. I've been following the landscape for years, which is how I came across Design with Care, a newsletter and job resource focused specifically on healthcare design roles. It was a genuinely valuable effort, and like so many community-focused projects, it eventually went quiet. I started thinking about the gap it left and whether there was a way to fill it with something structurally different. So I built a new website Design Jobs that specifically focused on healthcare and is open source from day one.
Designing for Longevity
The core question was simple: What would this look like if it were built to outlast any single contributor?
I approached this like any usual design task: identify the problem, understand technical constraints and user flows. To me the issue is not making a website, but it's how to nail down the contribution flywheel. There are people wanting to help, but not everyone is highly technical and I looked to AI as a way to create bridges for participation. One guiding principle was I wanted this effort to be open source.
I used Lisa, my OpenClaw agent, heavily during this process. We started off with a long conversation about the project via Slack. I provided the context of healthcare design, the existing resources, and the recurring problem with community-driven initiatives. Eventually the founders step away and there's no clear path forward. We went back and forth on the structural side: I set requirements around wanting this project to survive any individual contributor and be easy for anyone in the community to pick up. Then we worked through the granular flows of how the project should eventually look and feel:
- How does a job listing get submitted?
- How is it reviewed and published?
- How can someone improve the system itself?
- Can we automatically validate hosted links to ensure quality?
- Can we set up automatic scraping so we always have at least some jobs listed?
An Infrastructure-First Approach
In the planning phase, we focused on a few core questions: What's the purpose of the project? How do we anticipate community members contributing? And what guardrails should exist around those contributions?
We decided that anyone should be able to contribute by submitting a job or feedback, and we chose GitHub Issues as the backbone for all of it. Every contribution becomes visible, versioned, and part of a shared system rather than sitting in someone's inbox.
From there, we built out an automation layer. An AI agent runs a daily cron job to review incoming issues, triage fixes based on community feedback, and format valid job submissions for the board.
DAILY CONTRIBUTION FLOW
User → Site → Submit → GitHub Issue
│
▼
┌─────────┐
│AI Agent │
└────┬────┘
│
┌─────────┼─────────┐
▼ ▼ ▼
┌─────┐ ┌─────┐ ┌─────┐
│Valid│ │ Log │ │Deny │
└──┬──┘ └─────┘ └─────┘
│
▼
┌───────────┐
│ Job Board │
└───────────┘But since the reality is that not everyone is going to submit jobs manually, we also set up a three-times-a-week automated pipeline with three stages: the first stage scrapes job listings from across different surfaces and sites, the second validates that no URLs were hallucinated and all data points to the right places, and the third rechecks every new link and all existing active links on the site. Each stage runs thirty minutes after the last, so the full pipeline completes within an hour.
3x WEEKLY PIPELINE
t+0 t+30 t+60
│ │ │
▼ ▼ ▼
┌──────┐ ┌──────┐ ┌──────┐
│SCRAPE│→│VALID.│→│VERIFY│
└──────┘ └──────┘ └──────┘
│ │ │
sites no 404s check
& jobs no fakes links
│
▼
┌──────────┐
│jobs.json │
└────┬─────┘
│
▼
┌──────────┐
│ Website │
└──────────┘The website pulls from that structured source of truth. Routine tasks are automated not to remove humans, but to reduce friction and prevent backlog fatigue.
Interestingly, the design was the last thing I touched. Lisa had created the scaffolding for all the UI I wanted, and from there I opened Claude Code to make granular changes, adding subtle animations, cleaning up the flow, fine-tuning details by hand. Even for the forms, rather than pointing people directly to GitHub to create an issue, we built a wrapper: a clean form on the website itself that creates a GitHub Issue on submission, lowering the friction of participation.
The result is that contributions are fully transparent. And if I step away as a contributor, the project is open source. Anyone can fork it, continue maintaining it, or take it in a new direction.
Why This Matters for Designers
When I reflect on this process, I think it represents one of the most interesting ways designers can apply their skills right now. We've spent our careers hyper-focused on user flows and UI, but we also understand architecture and product requirements. When you take something that exists and try to figure out how to give it longevity, you're drawing on all of those skills to make important architectural decisions. That's why I believe designers are the best-suited for this moment in AI.
Plus we have an eye for detail that is really missing in a lot of AI generated work. By using prompts like "I want to modify colors, give me a leva controller", we can quickly modify work to make it feel exactly how we want without touching Figma.
What I'm Hoping For
I'm hoping more designers set up their own AI agents and start creating things from scratch in their spare time. Not as financial or speculative ventures, but as one human trying to help another. If designers can combine open source governance, lightweight automation, clear contribution loops, and AI-assisted maintenance, then small, focused ecosystems don't have to fade when individual energy dips.
Healthcare design deserves a durable home for job visibility. This is one attempt at building it in a way that can survive beyond any single person, including me.