Solo Product Design Lead: Led research through high-fidelity prototyping, defining the app structure, core flows, UI direction, and early component patterns.
Team: Partnered with an NYU medical team embedded at Tamale Teaching Hospital, local care providers, and AMPATH Ghana leadership.
Goal: Translate locally adapted clinical pathways from posters and PDFs into a mobile product that could expand access to real-time clinical guidance across northern Ghana.
Current state: Designs supported grant proposals and later helped guide a functional version now being used by clinicians across multiple hospitals.
In northern Ghana, “resource-limited” was not a general constraint. It shaped every clinical decision this product needed to support.
Clinicians at smaller hospitals and rural clinics often make treatment decisions without access to reliable diagnostics, consistent medication supplies, or senior support nearby. International guidelines often assume access to equipment, drugs, and tests that simply aren’t available. In that context, a guideline that says “order an MRI” or “administer Drug X” may be technically correct, but practically unusable.
At Tamale Teaching Hospital — the largest training hub in the region — AMPATH Ghana and local clinicians had already developed a better model: locally adapted clinical pathways designed around the resources actually available. Distributed as posters and PDFs, the pathways were already helping clinicians make more consistent decisions. The model worked. The problem was reach.
Posters were fixed to hospital walls. PDFs were hard to use on phones. Updates were slow and costly. Fewer than 6% of care providers were accessing the website’s PDF library, which meant the clinicians at smaller clinics, who needed guidance most, often had the no access to it.
A competitive audit confirmed the gap: existing clinical pathway tools were either too expensive, too narrow, too broad, or still relied on static PDF-style content. None solved the actual problem: locally adapted, multi-specialty guidance designed for real-time use in resource-limited settings.
The pathways were working, but the access model was not.
The primary user was a clinician managing high patient loads with variable resources, unreliable internet, and limited specialist support nearby.
I focused on three provider types: House Officers, Medical Officers, and Specialists. Their experience levels varied, but the shared need was consistent: fast access to trusted, locally relevant guidance during patient care.
The problem was not whether the pathways were valuable. Survey data from 37 clinicians showed the existing program was already improving consistency, outcomes, and medical education. The issue was access: posters were fixed in place, PDFs were difficult to use on mobile, and fewer than 6% of providers were regularly accessing the digital library.
That translated into three product requirements:
Clinicians needed guidance during active patient care, not after the fact
Make pathways usable at the point of care
Available medications, diagnostics, and equipment varied by facility
Support locally validated guidance, not generic international protocols
Pathways included checklists, branching decisions, and reference tables
Create one flexible display system for multiple pathway structures
The product had to work where typical clinical tools assume too much.
The product requirements became three design principles. Each one was specific to this environment.
The biggest design decisions were product decisions, not screen-level choices. Each one came from the same constraint: the app needed to be reliable, fast, and scalable in environments where internet access, resources, and clinical workflows varied widely.
Reliable access was the core product requirement. In this context, offline access could not be treated as a fallback state or secondary mode.
I designed the product around an offline-first model: first access required connectivity, but once opened, pathways remained available later without a connection. Updates synced quietly when internet access returned.
What I left out: Heavy media, real-time-only features, personalization that required live data, and search across uncached content.
Why it mattered: Every feature had to pass the same test: does this still work when there’s no signal?
The pathways were not all the same shape. Some were linear checklists, some were branching decision trees, and others were dosing tables or references.
Designing a custom mobile layout for each pathway would not scale. Forcing every pathway into one rigid template would distort the clinical logic. I designed a flexible, mobile-first display system built around shared components and a consistent interaction model, so different pathway types could feel like one product without requiring custom design work for every guideline.
What I left out: Free-form authoring, rich media inside pathways, and multi-column layouts that would not hold up on small screens.
Why it mattered: Without a flexible system, every new guideline became a design project. With it, the product could scale from a small set of launch pathways to a much larger clinical library.
The hardest problem was not whether clinicians would understand the app. It was whether the product could reach clinicians beyond Tamale Teaching Hospital.
Clinical knowledge often travels through trust networks: one provider sharing a useful resource with another. I designed sharing as a core pathway action, not a settings utility. A clinician could share a pathway through WhatsApp with a pre-filled message, preserving the human context around the recommendation.
Two product decisions supported that model: the app was web-based, so a shared link could open immediately with no app-store download, and account creation was progressive. Clinicians could view a pathway first, then create an account when they wanted to save, bookmark, or share.
What I left out: Social features, algorithmic recommendations, and upfront account creation.
Why it mattered: For this product, distribution was part of the user experience. A pathway shared by a trusted colleague carried more credibility than a generic link or institutional announcement.
The final design turned a PDF library into a usable point-of-care tool.
.gif)
The validated design covered the core clinician experience: finding a pathway, using it during care, returning to frequently used guidance, and sharing it with a colleague.
The prototype flow showed how a clinician could move from search to actionable guidance without navigating a PDF library.
.png)
The design helped move Pathways from proposal asset to working product.
The original design work produced a build-ready product direction and a set of grant proposal assets. The grant is still pending, but the design has already helped guide a functional version of the app, built in collaboration with a physician using Claude and Excel-based content tracking.
That scrappy live version is now giving us early evidence that the original product hypothesis was worth testing: locally adapted clinical guidance can reach farther when it is mobile, shareable, and easier to use at the point of care.
Registered users now span roughly 40 distinct hospitals, including teaching hospitals, district hospitals, and smaller rural facilities across northern Ghana. Tamale Teaching Hospital remains the largest single site, but the app is already reaching beyond the original flagship hospital.
The most-opened pathways include high-acuity topics like Cardiac Arrest, Sepsis and Septic Shock, Tachycardia with a Pulse, DKA/HHS, and Hypertensive Emergency. This does not prove clinical impact yet, but it shows early use around the kinds of time-sensitive guidance the product was designed to support.
Growth has come in bursts, often tied to training, direct sharing, or word-of-mouth. That matches the product’s distribution strategy: clinical guidance spreads through trusted provider relationships, not passive discovery.
