Health Insurance Developer Portal
Where companies get the documents and keys they need to connect their own software to a national health-insurance regulator. The design took a week. The brief was to fit a bilingual portal inside a corporate identity manual that had been written for print and signage.
- Role
- Design lead and mentor
- Team
- A junior designer and me
- Timeline
- Signed off May 2024
- Status
- Delivered
This is a showcase. It ran for a week and had no research phase.
It did have one constraint worth describing. A corporate identity manual written for print and environmental signage had to become a working bilingual developer portal, with a catalogue, registration and application management. The manual had to stay intact, and the portal had to stay a portal rather than a marketing page.
Everything on this page is a recreation. The client is not named; their branding, real identifiers, customer data and internal documents are replaced with fictional equivalents built for this portfolio. Figures appear only where they describe my own process, and anything commercially sensitive is left out.
The council’s name, emblem, photography and service catalogue are removed; the screens here carry invented content at the fidelity the originals had.
What the week produced
This was a branded shell, not a product design. It has the structure a developer portal needs, and I handed it over as components instead of finished screens, so the build team could carry it across the pages that were not drawn.
Putting a brand book into a portal
The manual gave a palette built around two greens, a circular motif, and a logo lockup with strict clear space. None of that was written with a dense interface in mind. The usual mistake is to put the brand colour on every button.
So the identity sits where a portal has room for it. The footer runs full width and carries the gradient and the mark at full size. A soft circular field sits behind the hero. The brand green is kept for state, and interface blue carries the primary actions, which keeps the green meaningful and the buttons readable.
I would not compromise on contrast. The lighter brand green fails against white at body sizes, so it appears only on the gradient panel where it sits under white text, never as text on a light ground.
Right to left, on every screen
Every screen was drawn in both directions from the start. The layout flips, the navigation flips, and the filter rail moves to the other side. The parts a developer copies stay where they are: endpoint names, parameters and identifiers remain left to right in mono.
The other change was density. I restructured the page onto a three-column grid and laid the catalogue out as a grid of cards. Product names run to different lengths in Arabic and in English, and in a list that uneven edge becomes the most prominent thing on the page.
What this was and wasn’t
I did not draw most of this. I gave the project to a junior designer I was mentoring, and near the end I stepped in and reworked the screens myself. The final set is the part I worked on directly: the landing page signed in and signed out, getting started, our services, contact, my applications, and adding an application. The earlier explorations in the file are theirs.
The content in these screens is placeholder, and it was placeholder at delivery too. The API catalogue had not been finalised, so the design sets out how a product is presented without saying what any product says. Testing was a single session with one internal reviewer. Nothing was measured, so there are no outcome numbers here.
