Back
UI/UX Design
OIDC
A 150-hectare island community needed an operating system before it could have an interface.
What I did: Led UI/UX across four surfaces, subscriber mobile and web, staff dashboard, and vendor portal, for a Lagos island development, from client discovery through design system handoff.
Scope: Contractor engagement embedded with Cousant Technologies' product and engineering team of seven or more. Sole product designer on the build.
Outcome: The platform shipped, launched in 2021, and was handed to OIDC as the estate's internal subscriber and operations system.
CONTEXT
Orange Island is a 150-hectare reclaimed island development in the Lagos Lagoon, built as a Public-Private Partnership between Orange Island Development Company and the Lagos State Government. The ambition was a master-planned residential and mixed-use community just off Lekki Phase 1, part of a broader push to make Lagos a more organized, service-efficient city.
That kind of ambition runs into a quieter problem on the ground. A development of that scale has subscribers who need to select plots, pay for them over time, move in, and keep interacting with the estate for years after, alongside a staff and vendor base that has to keep the whole place running. Before this engagement, that entire lifecycle lived across paperwork, spreadsheets, and phone calls. OIDC already had a subscriber base that had never touched a digital portal.
For OIDC, the platform had to work for four very different people at once, and it had to work immediately, since subscribers were already buying land while the system was being built.
PROBLEM
The brief read like a list of apps: a subscriber web and mobile app, an internal OIDC dashboard, a vendor portal. The real problem sat underneath that list. OIDC didn't yet have a defined operating model for any of it. Roles and permissions across Marketing, Accounting, Operations, and Management hadn't been mapped. Subscriber payment plans were calculated by hand, per plot, with no consistent structure for down payments, legal fees, administrative charges, or installment schedules. Vendor work had no lifecycle, no way to move a job from request to proposal to invoice to sign-off.
If the platform felt like four apps stitched together, staff would keep reaching for spreadsheets and subscribers would keep calling the office instead of trusting the portal. The design problem was never really the number of screens. It was whether someone buying their first plot of land, often sight unseen, could trust the process enough to pay for it through a phone.
ROLE
I was brought on as a contractor embedded with the product and engineering team at Cousant Technologies, the studio building the platform for OIDC, on a team of seven or more spanning backend, web, mobile, and database engineering. I was the sole product designer on the engagement and owned UI/UX end to end across all four surfaces. That included running discovery directly with the client, a structured Q&A that defined department permissions, the subscriber data model, search taxonomy, and notification content, before a single screen was drawn. I worked the engagement from July 2020 to April 2021.
APPROACH
The first real decision was to stop treating the subscriber experience as a dashboard with a map buried inside it, and start treating the map as the product. New and existing subscribers didn't need a menu of options. They needed to select, price, and purchase a plot through direct interaction with the masterplan itself, color-coded by availability, on both web and mobile. That decision became the spine the rest of the subscriber journey hung off.
That reframing solved the biggest trust risk directly. Buying land through a phone only works if the first thing a subscriber sees is the actual land, not an abstract product screen standing between them and the decision.
From there, the work moved to the two processes OIDC's staff felt the most pain on. The offer and payment flow, where I designed a live builder that took price, legal charges, administrative fee percentage, down payment percentage, and installment count, and computed the full breakdown automatically rather than leaving that math to whoever was writing the letter that week. And the subscriber plot page, where I consolidated documents, payment history, upcoming payments, work orders, and requests into one view per plot, so an existing subscriber migrated off paper records had nothing new to learn on day one.
The vendor and staff side needed a permission model and a workflow, not just a list. Every department could see a subscriber's full record, but what they could edit differed by role, built directly from OIDC's own department structure rather than a generic admin template. For vendors, the job card became a lifecycle: request for proposal, submission, approval, invoice, progress tracked by percentage, and a certificate of completion OIDC staff could approve or reject with comment, closing the loop between facility work and the estate's records.
Underneath all of it, the four surfaces needed to read as one platform, not four separately branded tools a user would have to relearn switching between them. That decision is why the estate's staff, subscribers, and vendors could all move through the same visual language even though they were solving completely different problems.
OUTCOME
The platform shipped. It moved through a phased launch in early 2021 and was handed over to OIDC at the close of the engagement, going live for internal use by the estate's residents and staff rather than as a public consumer product. Subscribers ran plot selection, offers, payments, and estate requests primarily through the mobile app and its browser counterpart, while the web and dashboard builds carried the administrative load for OIDC's staff and vendors. The handover was definite, the system launched and was in the client's hands by the end of the engagement, though visibility into the build ends there, as is typical of a contractor engagement that closes at delivery.
This is the project that proves I can take an unmodeled operational business, not just a design brief, and turn it into a working system across web, mobile, staff tooling, and a third-party vendor surface, at municipal scale. It is the clearest evidence I have that I can be handed complexity, not just screens, and come back with both.
