Peace Solomon
Work Expertise About Highlights Contact
LinkedIn thepeacesolomon@gmail.com
Open to new roles, available for relocation

I design the systemscomplex businessesactually run on.

Product designer working end to end across beauty SaaS, food delivery, healthcare, commerce, fintech and legal AI. I take products from an ambiguous brief through research, strategy and systems, to interfaces teams can ship and scale. Looking for roles where I can make a global impact.

5+ yearsDesigning products
6+ industriesRegulated and high trust
0 to 1Plus scale up phases
Law trainedCalled to the Nigerian Bar

What I bring to a team

The disciplines I cover

Product strategy

  • Discovery and problem framing
  • Competitive and market analysis
  • Product definition and scoping
  • 0 to 1 concepting
  • Roadmap and prioritisation input
  • Stakeholder alignment

User experience

  • Qualitative and desk research
  • Personas and journey mapping
  • Information architecture
  • User flows and wireframes
  • Usability testing and iteration
  • UX writing and content design

Interface and systems

  • Design systems and tokens
  • Component libraries and states
  • Multi surface consistency
  • Interactive prototypes
  • Motion and micro interaction
  • Engineering handoff and specs

Automation and regulatory

  • Workflow automation with n8n, Make and Zapier
  • Internal ops tooling design
  • AI agent and assistant UX
  • Contract and clause analysis
  • Compliance aware product flows
  • Consent, privacy and policy UX

Tools I work with

Software and AI stack

Microsoft OfficeGoogle WorkspaceAdobe Creative SuiteFigmaMiroNotionAirtablen8nMakeZapierChatGPTCodexClaudeClaude CodeLovableFramer

About

The short version

The interface is the easy part. The real work is the thinking underneath it: how a system holds up with messy data, rushed users, and decisions nobody wants to make twice.

CurrentlyProduct Designer, Velio
PreviouslyProduct Designer, WithSplice
TrainedLaw, called to the Nigerian Bar
Working withDistributed teams, EMEA and NA hours
StatusOpen to relocation

I have spent five-plus years designing for early stage startups where the brief is usually one sentence and the constraints are real. Small teams, tight runway, and users whose day does not pause because your product is confusing. That taught me to design for the system rather than the demo: who has to act next, what happens when they do not, and what the product owes them when something goes wrong.

I work across the whole arc. I sit in the commercial conversation, run the research, frame the problem, build the flows, define the tokens and components, write the interface copy, and stay through handoff and iteration. On multi sided products like DeliverEat and OSSHNG that range is the point, because the hard work is deciding once what an order or a patient record is, then making four very different audiences agree with that definition.

Two things sit outside the usual designer profile and make me more useful early. I am trained in law and called to the Bar, so I can read the contract, spot the regulatory risk in a flow before legal does, and design consent and compliance moments that are honest rather than defensive. And I build automation, mostly in n8n, which means I can take the repetitive operational work around a product and turn it into a workflow instead of another dashboard nobody opens.

I am looking for a team where design has a seat in the strategy conversation and the work reaches people at scale. Open to relocation.

Experience

Full CV ↓
Product DesignerVelio2026 till present
Product DesignerWithSplice2023 to 2025
Product Designer, contractMonimoore Technology2024
UX Designer, contractCarbinAfrica2024
UX DesignerFuturePro2023 to 2024
UI Designer, contractCrevtus Studio2023

What people say

Founders and clients

She displayed incredible levels of ownership, commitment and dexterity. She perfectly understood our objective and created a brand new feature for the project. That was mind blowing and impressive.

Kehinde Durodola-TundeFounder, Monimoore Technology

One of the most intelligent and strategic people I know. Her leadership, administrative and project management skills are very commendable. She would perform every task with excellence, and get your team to do the same.

Titilope AdedokunFounder, Sisterly HQ

A unique blend of creativity and technical skill. Her way of making her design not only aesthetically pleasing but also functional and user friendly is astonishing. She would be a valuable asset to any design team.

Mary-Esther AneleFounder, Inclusively Remote

Super-driven and highly committed. I worked as head of Marketing under Peace at AIESEC in Lagos, and watched her take on a challenging new role with no prior experience and excel at it, building out our media and design portfolio seamlessly.

Jeffrey ObaCreative Director, Marketer and Filmmaker

Peace is the prototype for commitment, dedication and discipline, with a natural bias for action. I was directly involved in her selection as a law student who ended up leading our marketing team, and having tested her against analytical skill, business acumen and emotional intelligence, she was an excellent candidate in every way.

Abdulmalik Oladimeji EduFormer AIESEC in Lagos Director

Peace is very skilled, a fast learner and result driven. Her contributions to the team were always well thought through, with a key attention to detail that adds to her amiable work ethic. A rare talent.

Modesta OkekeCo-founder, Ricive

Let's build something great.

Working on a product, looking for an ambitious senior designer, or have an interesting problem worth solving? Let's talk.

© 2026 Peace Solomon. Designed and built by me.

← All work

01 / Splice · B2B SaaS · 2023 to 2026

The backbone of beauty businesses

Designing an all in one booking, payments and business management platform built to scale in Africa.

RoleProduct Designer, end to end
TimelineAug 2023 to May 2025
PlatformWeb app, mobile, booking site
UsersBusiness owners and floor staff
I ownedStrategy, UX, UI, design system
Splice platform overview showing the home dashboard and invoice summary

01 / Context

A bold idea that needed to become a product

When I joined Splice, the founder had a clear thesis: unify Africa's fragmented service businesses under a single, mobile first platform for bookings, payments and client management. My role was to turn that vision into something tangible.

I led the design from early concept to high fidelity execution, translating complex operational workflows into intuitive dashboards, seamless order and payment flows, and automated client communication. Every screen, interaction and workflow was built around the real conditions these businesses work in, so the product was not just functional but effortless to use in a fast paced environment.

The solution serves two very different people. Business owners need visibility into revenue, orders and performance. Staff members need to create an order, update a status and record a payment without friction, often standing up, mid service, with a client in the chair.

02 / Decisions

01

The calendar is the home screen, permanently

Every new capability had to earn its way onto, or explicitly off, a single day at a glance surface. New modules got their own depth, but the entry point never moved.

02

Record money the way it actually arrives

Cash, transfer, card, POS, split payment, voucher, store credit and not paid are all first class states. A binary paid or unpaid model quietly forces the real numbers back into a notebook.

03

Staff are an operational object, not a contact list

A staff profile carries availability, leave balance, services covered, performance and payroll. Rostering is a scheduling problem, so the data model had to hold it.

04

Automate the follow up, not the relationship

Rebook reminders are configured per service with per service delays, an owner written message and a channel choice, so the automation still sounds like the business.

03 / The product

Operational depth, kept calm on the surface

Splice add appointment flow and payment method selection

Add appointment and take payment. Eight payment methods, deposits, add ons, promo codes and discounts, with a progress ring so a long form never feels open ended.

Splice calendar with edit appointment side panel

Calendar and edit appointment. Unassigned appointments surface as a persistent queue, and every service line carries its own time, staff member and price.

Splice staff detail screen

Staff detail: availability, leave, services covered, performance and employment in one record.

Splice add new staff multi step form

Adding staff is a five step form with completion feedback, defaulting to business hours.

Splice rebook reminder configuration

Rebook reminders: per service delays, apply to all, then message and channel.

Splice customer facing booking site checkout

The customer booking site, white labelled to the business and powered by Splice.

04 / Outcome

1 to nFrom a booking tool to bookings, payments, staff, clients, inventory, loyalty and reporting
2 yearsOn one product, long enough to watch my own decisions age and fix the ones that did not hold
Invited backReturned in 2026 to lead the next phase of the platform

Splice is now an all in one solution for service businesses across Africa to manage operations efficiently, engage clients proactively and track performance in one place. The outcome I am proudest of is not a screen. It is being asked back, which is the one result a founder cannot fake.

← All work

02 / OSSHNG · Health tech · 2026

Making a patient record legible to everyone who needs it

A shared medical records platform where patients own their history and providers get exactly the clinical structure they need, for a limited window of access.

RoleProduct Designer, end to end
Year2026
PlatformWeb, two portals
UsersPatients and healthcare providers
I ownedDomain research, IA, UX, UI
OSSHNG patient dashboard with vitals, medical records and appointments

The patient dashboard. Vitals first, then records, then appointments, with share and download as primary actions.

01 / The problem

Health records are not a document, they are a structure

Most record products treat a patient history as a folder of uploads. That is fine until a clinician needs to answer a real question in a real consultation: what is this person on right now, what did the last blood work say, what has already been ruled out, and what was the plan on discharge.

Answering that is not a layout problem. It is a taxonomy problem, and getting it wrong makes a product that looks organised and is clinically useless.

02 / Research

Learning how a record is actually built

This was the most research heavy project I have designed, because I could not shortcut the domain. I worked through how clinical documentation is genuinely structured, and mapped it before I drew anything.

The record resolved into five distinct types, each with a different shape, a different author and a different lifespan:

  • Current medications. Dosage, frequency, route, duration and instructions, with a prescriber and a start date. Medications end, they are not deleted, so the model needed an end state and an addendum rather than an edit.
  • Investigation results. The deepest structure by far, and the reason this project needed real study.
  • Clinical notes. Narrative, timestamped, authored, and append only once signed.
  • Past medical and surgical history. Long lived context that a new provider reads first.
  • Vital signs. Time series values with expected ranges, not free text.

Investigation results are where most products flatten everything into "lab reports". They are not one thing. Hematology (blood cell counts) behaves differently from biochemistry (chemical analysis of blood and fluids), which behaves differently again from microbiology (culture and infection), histology (tissue examination) and radiology (imaging). Each carries its own test names, result values, units and normal ranges, and a clinician reads a result against its range, not on its own.

So the entry model became: pick the record type, pick the test categories in scope, then add tests within each category as rows carrying test name, result, units and normal range. Discharge summaries and treatment plans sit on top of that as composed documents rather than a sixth loose category, because they are conclusions drawn from the record rather than new raw data.

OSSHNG edit medical record with record types and test categories

Record entry: choose the type, then the test categories, then add tests with result, units and normal range.

OSSHNG provider view of a patient record with access expiry banner

The provider view. Allergies, conditions and vitals stay pinned in the rail while the record is worked through.

03 / Decisions

01

Access is a countdown, not a permission

A provider sees "Access expires in 4h 23m" with a complete now action. Consent that expires by default is safer than consent someone has to remember to revoke, and the timer changes provider behaviour in the session.

02

Allergies and conditions never scroll away

The one thing that must never be missed sits in a persistent rail beside every record view, not inside a tab someone might not open.

03

Records are appended, never overwritten

Medications end and notes take addenda. An edit that erases history is a clinical and legal risk, so the interface only offers the safe verbs.

04

Two audiences, one record, two hierarchies

Patients lead with vitals and plain language summaries. Providers lead with active medications, results and notes. Same underlying data, sequenced for the question each one is asking.

04 / Outcome

The result is a records platform where a patient can share a complete, structured history in one action, and a provider can read it the way they were trained to read it. The design work that mattered was almost all upstream of the interface: deciding what a record is made of, and refusing to let five different kinds of clinical information collapse into one list.

What I learned. In regulated domains, research is not a phase you compress when the timeline tightens. The taxonomy is the product, and no amount of interface craft rescues a model that a clinician cannot work inside.

← All work

03 / Tulip Bodycare · Ecommerce · 2026

In beauty commerce, trust is the product

Designing a trust first skincare platform that combines expert advice with a seamless shopping experience.

RoleProduct Designer, end to end
Year2026
PlatformMobile first web
SectorBeauty and skincare retail
I ownedUX, UI, content strategy
Tulip Bodycare homepage with AI face scan entry point

01 / The challenge

Three problems standing between a shopper and a purchase

Nigerian skincare shoppers struggle with the same three things: fake products, confusing ingredient choices, and low confidence buying online. Tulip Bodycare wanted an ecommerce experience that felt as trustworthy as an in store consultation, while supporting a growing catalog of global skincare brands.

02 / What I designed

A trust first skincare commerce platform that combines retail, education and personalised guidance in one experience.

  • AI powered skin analysis with product recommendations, entered from a face scan that sits in the primary navigation rather than buried in a quiz
  • Ingredient and concern based search, so a shopper can start from "pigmentation" rather than a brand name
  • Curated routines for hydration, acne, pigmentation and sensitivity
  • Authenticity and sourcing transparency pages, addressing the counterfeit worry directly instead of hoping it does not come up
  • Consultation booking with skincare specialists
  • Mobile first shopping flows across discovery, wishlist, cart and checkout
  • A nationwide store locator with live open and closed status and pickup selection, connecting online browsing to six physical stores
Tulip product detail page with personalised match score

The match score is the trust mechanic on the product page. It states the reason, not just a number, and sits above the size and cart choice.

Tulip store locator with six locations and pickup selection

Store locator with live open status, directions and pickup selection, so the online catalog and the shelf are one system.

03 / Outcome

The final product positioned Tulip as more than an online beauty store. It became a digital skincare advisor. The experience made product discovery easier, reduced decision fatigue, and reinforced the brand's clinical credibility through clear education and transparency.

What I learned. In beauty ecommerce, trust is the product. Clear guidance, evidence led recommendations and transparent sourcing are stronger conversion drivers than discounts or aggressive merchandising.

← All work

04 / DeliverEat · Marketplace · 2026

A food delivery ecosystem designed for Nigerian realities

Designing four connected products for one delivery business: customer app, rider app, restaurant OS and operations dashboard.

RoleProduct Designer, end to end
Year2026
SurfacesCustomer, rider, vendor, admin
Scope78 plus screens and sections
I ownedEcosystem design and system
DeliverEat customer, rider and operations console interfaces

01 / The challenge

Most delivery products are designed for a market this is not

Food delivery products assume reliable addressing, card payments and structured logistics. DeliverEat had to work for Nigerian realities: informal addresses described by landmarks, transfers and cash alongside cards, rider earnings visibility as a retention mechanic, and restaurant operations that go well beyond order management.

Building four products separately would have been faster in week one and unmaintainable by week four. I designed them as one system with four faces.

02 / What I designed

  • Customer ordering experience. Browse, order, pay and track to the doorstep, with landmark based delivery notes treated as first class address data.
  • Rider app with earnings and support flows. 48 screens including a full help centre, payout history and daily earnings.
  • Admin operations dashboard. 17 sections covering live orders, riders, vendors, payouts, disputes, zones and reporting.
  • Dine OS, the restaurant platform. POS, orders, inventory, staff, cash, recipe linking, KYC and multi location management.

03 / Key decisions

01

One order state machine, four presentations

Every surface renders the same states with the same names and colours. Only the hierarchy changes: the customer sees time, the rider sees the next action, operations sees exceptions.

02

Earnings transparency is the rider retention feature

Payout per trip, daily total, hours online and rating are visible before a rider accepts, not buried in a wallet tab after the fact.

03

One decision per screen while riding

The rider is the only user who is moving, in traffic, in sunlight. Density there is a safety problem rather than a preference, so navigation stays reliable and targets stay large.

04

Dine OS is information rich on purpose

I deliberately let the restaurant and operations tools break the calm rules the consumer apps follow. A minimal interface that hides important data costs an operator scroll, and scroll costs orders.

04 / Outcome

4Connected products designed on one shared system in a single engagement
78+Screens and sections, fully interactive and navigable end to end
0Broken navigation links across the 48 screen rider prototype

Delivered a fully interactive, production quality prototype ecosystem that demonstrated end to end marketplace thinking across customers, riders, vendors and operations teams. It became a strong showcase of designing complex, multi sided products grounded in local user behaviour and business reality.

← All work

05 / ClauseGuard · Legal AI · 2026

Don't sign anything you don't fully understand

Upload any contract and we'll break it down for you: the risky parts, what's missing, and what to say back. Simple language, no legal background needed.

RoleProduct and website design
Year2026
PlatformWeb app
UsersFounders, freelancers, ops leads
I ownedUX, UI, every word of the interface
ClauseGuard contract upload and analysis interface

01 / The problem

The people signing the worst contracts are the ones who cannot afford to ask

A founder gets twelve pages on a Friday evening. A freelancer gets a client agreement with an indemnity clause that could end her business. Neither has a lawyer on retainer, and both will sign, because the alternative is losing the deal.

An AI can read that contract in seconds. That was never the hard part. The hard part is that in law, a confident wrong answer is worse than no answer. It does not merely fail to help, it manufactures false comfort that someone then acts on. So the design problem was trust calibration, not summarisation.

I am a lawyer as well as the designer on this product, which meant I could draw the line between helpful and reckless myself rather than guessing at it.

02 / Decisions

01

Three verdicts, in plain words

Every finding resolves to risky, missing, or worth pushing back on. Not a severity score out of ten. A non lawyer can act on three categories, and granularity they cannot interpret just returns the judgement call to them while looking precise.

02

No finding without its clause

Every result is anchored to the exact language that produced it, shown in place. This is what lets a user disagree with the tool, and a legal product a user cannot disagree with is a liability.

03

Give them the sentence, not the advice

Not "consider negotiating the limitation of liability". The actual redline language, ready to paste into the reply. The user's real job is answering the email, so design for the next action.

04

Say what it does not know

Low confidence findings are labelled and separated from confident ones, with the not legal advice framing stated where it is read rather than buried in a footer. Honest limits are what make the confident findings believable.

03 / Craft

The interface is a reading experience

Contract review is reading under stress, so the layout borrows from documents rather than dashboards: a single analysis rail beside the source text, a generous measure, and risk marked by a rule and a quiet label instead of a wall of red highlight.

I wrote every word of the interface. In a legal product the copy is the design. "This clause is missing" and "this clause may be missing" are two different products, and only one of them is defensible.