MedTech Developer Portal
A global MedTech company had built its developer portal on Backstage and let it sprawl. Four wikis, inconsistent components, a homepage full of mission statements — the support queue had become the de facto navigation system. I was embedded for eight months as both designer and frontend engineer to rebuild it into something engineers would actually open first.
My Role
// What I personally ownedDesigner and frontend engineer, both. I ran the user research, produced the designs, and wrote the code — no handoff in the middle.
The Problem
// Why this needed to existThe portal had been built on Backstage and extended piecemeal by a rotating cast of engineers, most of whom had moved on. What was left read like a museum of good intentions: overlapping wikis, a landing page that opened with a paragraph about the company's mission, and inconsistent section labels that changed depending on which sub-team had built them last.
A few patterns surfaced quickly in interviews:
- Navigation names varied from section to section, so muscle memory didn't transfer
- The homepage buried every useful tool beneath mission/vision content
- Service catalog metadata was half-filled and impossible to audit at a glance
- Onboarding happened entirely via external docs; the portal itself taught you nothing
- Components came from at least three different sources with no shared tokens
Ongoing engagement
Dual role — research, design, and code
Platform
Key Design Decisions
// What I tried, what I changed, whyLanding page hierarchy
Homepage was overloaded with mission/vision content that blocked access to core tools. Dense layout with flat navigation. Developers couldn't find what they needed without asking someone.
Clear landing page with task-oriented cards ('How can we help you?'), structured sidebar navigation, and self-service flows that reduced documentation reliance.
Why: A homepage should answer "what do I need to do right now?" The mission statement wasn't helping anyone do that — it was just taking up the top of the page.
Navigation restructure
Sections labelled differently across the platform. No consistent icon usage. Developers had built muscle memory for workarounds — Slacking specific people rather than searching the portal.
Consistent navigation with clear task-based categories. Added icons per section with subtle colour tints to make scanning faster.
Why: When section names shift between pages, people stop trusting the nav and ask a colleague instead. That behaviour came up in almost every interview.
Theming consolidation
Components pulled from multiple sources with no shared tokens. Remnants of previous design system attempts created visual inconsistency.
Applied consistent theming using MUI tokens aligned to the client's internal design system. All components standardised.
Why: If buttons look different on every page, the tool reads as broken even if it isn't. Consolidating tokens gave the whole thing the same visual personality again.
Outcomes & Validation
// What I can point to- Support request volume dropped noticeably once the landing page stopped hiding the tools
- Service catalog metadata got filled in because teams could finally see where the gaps were
- New engineers started onboarding from the portal instead of from a Slack thread
- The visual language finally matched the rest of the internal design standard
Screenshots and client name are withheld under NDA. Visuals available upon request during interview process.