Ahmed.Idris
All projects
Health-sector data company · Saudi ArabiaUNDER NDA

Health Sector API Marketplace

A marketplace where companies buy access to health-sector data services. They find a product, choose a plan, and manage their own keys and team. An earlier version was already live when I took it over. The decision that shaped the redesign was about who an account belongs to.

Role
Lead UI/UX designer
Team
Solo
Timeline
Aug 2023 – early 2024
Status
Design delivered. Build suspended.
FIG 01The landing page, which is where the look of this product sits. The product pages below are plainer by design.Recreated for this portfolio. The company, its products and every figure here are invented.
Outcome
A marketplace where a company pays for access to health-sector data services.A company finds a product, reads what it does and how to call it, picks a plan at a stated price, and manages its own keys and team from the same account. There is a price on the page and a bill at the end of the month. That is why the account has to belong to an organisation and not to the person who happened to sign up.
The brief

The marketplace already existed. I was asked for a surface change, which meant a better catalogue and clearer pricing. The account model was the thing holding it back.

A marketplace that supports individual developers as well as companies has to carry both in every product, every plan, every invoice and every report. Nobody sees that cost until they publish one product with three tiers and find they now have six to keep up to date.

Confidentiality

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 marketplace, its products, its plans and every figure on these screens are fictional. The account-model argument is the real part.

The argument

Who owns an account

I argued for removing the personal account type and making the organisation the only kind of account. That is the model most developer marketplaces use.The argument was about how much there would be to maintain. With two account types, one product with three tiers becomes six products and six plans to configure, bill and report on. Every product added after that doubles in the same way.

The client pushed back for a concrete reason. They had hackathons and a researchers’ programme coming, and the people in those programmes are individuals who will never have a company behind them.That requirement outweighed the simpler model.

Where it landed

We settled on one account per organisation. The personal account stayed, limited to the programmes that need it, so there is one account system with a named exception inside it.

What that bought

Billing, subscriptions and key provisioning work the same way for everyone. The organisation owner hands credentials to their own departments outside the portal, so the marketplace does not have to manage who works for whom.

What it cost

The exception still exists, so every new product has to be checked against both account types. I would make the same call again, and it is a cost the team carries.

FIG 02The account model is visible here. The switcher names an organisation, not a person, and people belong to it with a role each.Recreated for this portfolio. Names are invented.
Pricing

Plans people can read

The original structure had add-ons stacked on top of plans. In a joint workshop both teams agreed to drop them. Each product now has its own plans, one proxy, and tiers that line up across the catalogue.

That decision is what made the pricing tab legible. A plan card states the rate limit, the upfront cost and the per-call cost together. One plan is marked as recommended, and anyone whose volume does not fit a card is sent to the enterprise route. A reader does not have to add anything up to find the price.

FIG 03Costs are shown in the currency the market bills in. Anything above the larger card goes to the enterprise route, so there is no third card.Recreated for this portfolio. The plans and the prices are invented.
Structure

One product, three tabs

Every product page has the same three tabs: what it does, how to call it, and what it costs. Overview carries the marketing case, Documentation carries the reference, and Pricing carries the plans. They are tabs because three different people read them, often in different meetings.

I tightened registration, verification, password reset and team invitations at the same time. The model only works if getting the second person from a company into the account is easy.

Scope

What this was and wasn’t

I did not start this product. A design for it already existed and had sat unbuilt for a long time, and I took it over. I do not know who made it and I never worked with them. There was no written design system and nobody to ask, so I worked the rules out from the screens that already existed and designed everything new to fit them.

Everything on this page is mine: the landing page, the product catalogue, the three-tab product pages, the subscription and billing screens, members, apps, payment methods, the error pages, the email templates, contact and FAQ, and the set of components the pages are built from. Other parts of the product were designed before I arrived and I never touched them, so where a module never came to me its older screen is still the one in use. It was tested once, with a single internal user, and no usage data came back to me afterwards. That is why there are no outcome figures on this page. The account-model decision is the one worth reading here, and it was settled by argument and by what the business needed.

Next projectVehicle Operations Platform