Marie Stopes Uganda

I am currently engaged as a Locum Website Developer with Marie Stopes Uganda. The engagement is active, so this page describes the work as it stands rather than presenting it as a finished case study.

The remit spans WordPress development using the Gutenberg block editor, structuring and restructuring content, keeping the experience consistent across devices, and attending to the technical health of the site: performance, accessibility and search visibility.

A health organisation's website is rarely browsed casually. People arrive looking for a specific service, a location, or a way to make contact, often on a modest mobile connection and often in a hurry. Everything else on the page is secondary to that.

That puts a particular kind of pressure on the build: content has to be findable in very few steps, pages have to stay light, and the interface has to remain legible and operable for people using assistive technology or older devices.

I work inside WordPress with the native block editor rather than layering an additional page builder on top. Gutenberg keeps the markup closer to standard HTML, reduces what the browser has to download, and leaves the site maintainable by the team after any single developer moves on.

Before building a page I map what it actually has to do: which question it answers, what the next step is for the reader, and where it sits relative to everything else. Structure first, styling second.

Design decisions follow the organisation's existing identity rather than replacing it. My work concentrates on hierarchy and rhythm: what the eye reaches first, how much a reader has to hold in their head at once, and how comfortably a page reads at arm's length on a phone.

Type sizing, line length and spacing are set to stay readable across breakpoints, and interactive elements are given targets that work for thumbs as well as cursors.

Build work is done with WordPress and the block editor, with custom blocks and patterns introduced where a repeated layout would otherwise be rebuilt by hand each time. Templates are kept modular so a change to a shared element propagates rather than needing to be repeated.

Changes are checked across the breakpoint range before going out, and anything touching a live page is verified after deployment rather than assumed.

Technical health is treated as part of the build rather than a later clean-up. That means attention to image weight and formats, avoiding scripts that do not earn their place, keeping heading structure semantic, and making sure pages carry the metadata search engines need to index them correctly.

Accessibility checks cover keyboard operability, focus visibility, colour contrast and alternative text.

The contract is ongoing. Rather than publish outcome figures that have not been measured and verified, this section will be updated with confirmed results once the work reaches a stage where they can be reported accurately.

Working inside an established organisation's site is mostly an exercise in restraint. The useful instinct is not to redesign everything visible, but to find the specific frictions that stop someone completing the task they came to do, and remove those.