01
Configuration over custom build
Every workflow change used to require an engineering release. I design the model so operations teams define their own processes — slower to design, substantially cheaper to own.
Open to senior product design and product management roles
I build the platforms that large operations run on.
Four years building internal systems across agriculture, agri-finance, mobility and Web3 — carrying the whole product loop, not just the screens: the research, the requirements and PRDs, the design, and the success metrics that say whether it worked. Currently on Afaas at Babban Gona, the platform coordinating 350,000 acres of farmland.
- Current
- Product Designer, Babban Gona
- Experience
- 4 years, research to results
- Works as
- Product designer and product manager
- Based in
- Lagos — working remote
Scale
What the work supports
Figures from the Babban Gona network that Afaas helps run. The platform supports the coordination behind them; it does not produce them on its own.
0,000+
acres of farmland coordinated through the system
0,000+
jobs created across the farming network
0,000+
individuals reached by the programme
0+
years designing and shipping production software
Selected work
Work I am proud of
Three platforms running real operations every day — a farming network, a driver fleet and a membership community. Each case study sets out what was actually broken, the decisions I made, what each one cost, and what changed afterwards.
Process
How a platform gets built
The same five stages run through every project. The time is weighted heavily toward the first two — by the time I'm drawing screens, most of the decisions are already made.
Approach
Three principles I design by
Operational software fails at the model, not the interface. These are the commitments that shape how I spend the time.
02
Design for incomplete data
Field records arrive late and partial. Interfaces that assume clean input are abandoned within weeks, so the incomplete state gets designed before the ideal one.
03
Validate with operators, not stakeholders
Field officers, drivers and non-technical administrators. The strongest decisions in each project came from watching someone struggle with something I assumed was obvious.
Beyond the screens
The product management half
On small internal teams there is no wall between design and product. These are the parts of the product manager's job I already do — documented in the case studies, not claimed.
PRDs
Requirements before pixels
I write and maintain the PRDs for the flows I design — the Commodity Valuation requirements went through formal review, with open questions tracked to closure before build started.
Metrics
Success defined up front
Every project states its measures before the first screen, so the result is arguable from evidence — payment-rule turnaround, audit integrity, onboarding drop-off — rather than from impression.
Research
Evidence sets the backlog
1,981 onboarding responses analysed into a ranked list of what to fix first. When the data and an internal opinion disagree, the data wins the prioritisation argument.
Scope
Trade-offs made in the open
Each case study records what a decision cost, not just what it gained. Constraining the Formula Builder's operators was a scope call against flexibility — made, written down, and defended.
Delivery
Coordinating the build
I run the design QA gate across six Harvest modules, coordinate four designers to a sign-off, and stay with engineering through release — the product does not ship without a pass.
Positioning
Naming and go-to-market groundwork
I led the platform's renaming — shortlisting, then screening each candidate for trademarks, domains, meaning across Nigerian languages and French, and ease of use in the field.
Experience
Where I have done it
Case studies
Selected work
Three platforms in production. Each written the way a product owner reports: the context, what the research found, the decisions and their trade-offs, what shipped, and what it changed — with the cost of every call stated next to it.
Beyond the case studies
Ongoing work
Design system maintenance across the Babban Gona product suite, usability sessions with field teams, and a research workflow that turns raw session notes into tagged, searchable findings.
All work
Explore the thinking
![Afaas product screens]()
AgricultureOperations platform2023 — ongoing
Afaas
Agriculture Finance as a Service
The internal platform Babban Gona runs its farming network on — registration, configurable field workflows, and the performance views regional leads decide from.
350,000+
Acres coordinated
299,000+
Jobs supported
1
Configurable system
Inside Afaas · Operations platform
01 — Context
A network that outgrew its tooling
Babban Gona coordinates smallholder farming across hundreds of thousands of acres in Nigeria. Field officers register farmers, log activity through a season, and report performance upward. As the network grew the supporting systems stopped keeping pace — not because any individual screen was poor, but because the underlying model assumed every region operated identically.
They do not. Planting windows shift, input packages differ, and a process that is correct in one state is wrong in the next.
02 — The problem
Operations could not change their own processes
Four constraints surfaced consistently across interviews with operations leads and field supervisors.
- 01Process changes required engineering. Adding a step to an activity sequence meant a release. Operations waited weeks for changes they understood better than the engineers implementing them.
- 02One process, multiple realities. Regional variation was absorbed by workarounds — parallel spreadsheets, and context buried in free-text fields.
- 03Records arrived incomplete. Connectivity in the field is unreliable. Partial records were the norm, and the interface treated them as validation errors.
- 04Performance data was fragmented. The data existed but was scattered across views, so decisions followed whoever reported most persistently.
03 — Research
Mapping the season as it actually runs
I ran sessions with operations leads and field supervisors across regions, mapping a full season against the process the software assumed. The gap between the two became the brief.
The variation was not an edge case. It was the system.
04 — Design decisions
Three decisions, and what each cost
Decision 01
Model workflows as configuration, not as screens
Rather than designing each process as a fixed flow, I defined a structure where a workflow is a sequence of typed steps, assembled by operations inside the product. A new activity type became a configuration task instead of a build.
Trade-off — configurable systems are harder to keep simple. Generic builders drift toward database administration. Most of the project was spent constraining choices and naming concepts in operations language rather than schema language.
Decision 02
Treat the incomplete record as the default state
Every record view was designed for partial data first — what is known, what is missing, who can supply it, and whether the gap blocks anything downstream. Completeness became a visible property rather than a submit-time failure.
Trade-off — more states to design and maintain, and a denser record view than a clean-data version would need. Field officers stopped abandoning entries midway, which settled it.
Decision 03
Separate the daily task from the oversight view
Supervisors and regional leads shared a single interface and both were poorly served. I split the surface — a task-shaped view for logging work, an aggregate view for reading performance. One data model, two reading orders.
Trade-off — two surfaces to keep consistent, and a navigation model that had to make the split legible without implying two separate products.
05 — What shipped
A configurable operations platform
A configuration layer for defining activities and workflows, a farmer and farm registry built around partial records, regional performance views, and a component library that keeps the suite consistent as new modules land.
Some screens and figures are withheld under NDA. I can walk through the full system in a portfolio review.
06 — Impact
What it changed
350,000
acres coordinated through the platform
299,000
jobs created by the operations it supports
849,000
individuals reached across the network
The outcome I value most is quieter: process updates that previously required a release now happen inside the product, owned by the teams that run the process. The engineering backlog stopped being the constraint on operational change.
07 — Reflection
What I would do differently
I began by designing representations of existing workflows, which was the wrong level of abstraction — it encoded current process into the interface. Moving to a configuration model required a rework that a week of modelling up front would have prevented.
I would also push harder on measurement. The qualitative evidence that the system is faster to work with is strong; the instrumentation proving it is not. On the next platform, success metrics get defined before the first screen.
All work
Explore the thinking
![AlphaPride product screens]()
Web3Mobile product2024
AlphaPride
Membership, payments and community in one product
Passes, token transactions and community ran as three separate flows. They were consolidated into a single product under one navigation model.
4 → 1
Pass types unified
3
Onboarding stages
2
Platforms shipped
Inside AlphaPride · Member experience
01 — Context
Three products sharing one name
AlphaPride combines identity (passes granting access to events and tiers), money (a token wallet and purchases) and community (members, conversations, curated experiences). Each had been designed as an independent flow. Members experienced them as three unrelated applications that happened to share a logo.
02 — The problem
The product asked members to learn the infrastructure
- 01Crypto vocabulary blocked progression. Wallet connection and token purchase used the language of the chain rather than of membership. Members who had never held a token stopped at that step.
- 02Passes had no legible state. A pass could be active, expired, tiered, gifted or corporate-issued, and all rendered near-identically. Members arrived at events with passes that would not admit them.
- 03Onboarding was a single long form. Account creation, verification and security arrived together, before anyone had seen a reason to invest.
- 04Context was lost between features. Purchasing a pass meant leaving community, and returning meant starting over.
03 — Research
Mapping every route through the product
Before any screen was drawn I mapped the complete flow set — every entry point, state and exit across passes, wallet and community. The overlaps made the consolidation argument on their own.
Members were not confused by the product. They were confused by the plumbing.
04 — Design decisions
Three decisions, and what each cost
Decision 01
Name actions by outcome, never by mechanism
Wallet connection became the step that issues your pass. Token purchase became adding to your balance. The chain still performs the work; it is no longer a concept the member must understand to proceed.
Trade-off — crypto-native members lost the precise vocabulary they expected, so exact transaction detail sits one level deeper rather than being removed.
Decision 02
Treat a pass as a state machine, rendered plainly
A single component with genuinely distinct states — what it grants, until when, where it originated, and what to do if it is not usable. Issuance route became a property rather than four separate objects.
Trade-off — a heavier component carrying more edge cases than four simple cards. It repaid the cost the first time a new pass type shipped with no design work.
Decision 03
Stage onboarding against earned trust
Account, then verification, then security — each triggered when the member reaches something that requires it, rather than all three before any value is visible.
Trade-off — deferred verification produces more partially configured accounts, which pushed real complexity into states elsewhere in the product.
05 — What shipped
One product, one navigation
A single bottom navigation spanning passes, wallet and community; staged onboarding; a multi-state pass component; and transaction flows written in membership language. Prototypes were tested with members before build.
06 — Impact
What it changed
1
navigation spanning passes, payments and community
4 → 1
pass types consolidated into one component
3
onboarding stages replacing a single long form
In testing, members with no prior crypto experience completed pass purchase unassisted — the step that had been failing most frequently.
07 — Reflection
What I would do differently
I designed the pass component before understanding how passes would be issued commercially, and corporate issuance arrived late and awkwardly. Every route a pass can enter the system should have been mapped before designing how one looks.
I would also test recovery paths harder. The happy path was validated thoroughly; the failure cases — a declined payment, an expired pass at a door — considerably less so.
All work
Explore the thinking
![Aplus Drivers product screens]()
MobilityDriver app + web2023
Aplus Drivers
Driver dispatch and booking platform
Drivers used four separate tools to accept a job, navigate to it and track earnings. The redesign puts a complete job on a single screen.
4 → 1
Apps per shift
3
Service categories
Live
aplusdrivers.ng
Inside Aplus · Driver experience
01 — Context
A working day split across four tools
Drivers accepted a job in one application, located the address in another, and reconstructed weekly earnings from memory. Meanwhile customers arriving at the website could not determine what Aplus offered, or what it cost, without contacting someone.
02 — The problem
Neither audience could complete their job in one place
- 01Drivers operate one-handed, frequently moving. Any flow requiring more than a glance and a thumb fails in the real context of use.
- 02Earnings were invisible until payout. Not knowing the value of a day was the most frequent complaint across driver interviews.
- 03Services were described across unrelated pages. Personal, corporate and event hire could not be compared, so customers could not self-select.
- 04No published pricing. Every enquiry became a conversation, which slowed the team and lost customers who wanted a figure.
03 — Research
Testing in the context of use
Driver interviews and in-context sessions established the real constraint: the app is used in short bursts between trips, often in poor light and with one hand occupied. That constraint set the information budget for every screen.
For a driver, prominence is a zero-sum budget.
04 — Design decisions
Three decisions, and what each cost
Decision 01
One screen per job, not one screen per feature
The driver home surfaces the next job, the route to it, and the day's earnings — the three things checked between trips. Everything else moved one level down.
Trade-off — features the client wanted visible lost their position on the home screen, which required making the zero-sum argument explicitly.
Decision 02
Make earnings continuous rather than a weekly reveal
Earnings update per completed trip, with day and week always visible. An invisible outcome becomes feedback on the work as it happens.
Trade-off — a running figure makes a slow day visible in real time. Pairing it with trip history keeps the number explainable rather than discouraging.
Decision 03
Lead the customer site with services and pricing
The site was restructured around the three service categories with pricing stated up front, so customers qualify themselves before contacting anyone.
Trade-off — published pricing removes negotiating room and requires upkeep. The team accepted it in exchange for better-qualified enquiries.
05 — What shipped
Two surfaces, one component set
A driver application covering job requests, navigation, trip history and earnings; a customer site structured around service categories with transparent pricing and a direct booking path; and a shared component set across both.
06 — Impact
What it changed
4 → 1
applications required to run a shift
3
service categories, transparently priced
Live
in production at aplusdrivers.ng
In usability sessions drivers located the next job and the day's earnings without prompting, which is the entire bar for a screen used between trips.
07 — Reflection
What I would do differently
I tested the driver application seated, in good light, on reliable connectivity. None of those conditions match a driver's day. Later sessions in a parked vehicle changed my position on tap targets and contrast; that should have been the first test rather than a late one.
I would also treat the customer site and the driver application as one product earlier. They were designed in sequence, and the shared component work happened at the end when it should have led.
About
I design the product, then the system that keeps it coherent.
Most product design assumes the user is also sitting at a screen. The people I design for are in fields, in warehouses, in traffic, or at a door verifying a membership pass — and that context decides almost every choice in the interface.
Four years on systems that coordinate physical operations: the platforms running an agricultural network across 350,000 acres, a driver dispatch application, and a Web3 membership product. Designing the screens is half of it. The other half is the design system, the icon tooling, the QA process and the training media that keep a product coherent as six teams build on it at once.
And because the teams are small, I have always carried the product manager's half too: writing the PRDs, defining success metrics before design starts, turning research into a ranked backlog, and holding the release gate. I am looking to keep doing both — as a product designer, or as a product manager who designs.
FigmaDesign systemsPrototyping
Usability testingJourney mapping
Information architectureResearch synthesisPRD writingSuccess metricsHTML & CSS
In practice
What the work looks like
Less resolved than the case studies suggest. Most of it is session notes, naming arguments and rebuilding the same component twice.
Experience
Four years, two teams
Next
What I am looking for
A senior product design or product management role on a team building operational or infrastructure software, where the hard problem is the model rather than the marketing surface. I write the requirements, I work closely with engineers, and I would rather own one deep problem end to end than five shallow ones.
Contact
Let's talk about the hard part.
I am most useful on operational products where the model is the difficult problem — hire me to design it, to manage it, or both. A sentence describing it is enough to start a conversation. I reply within two working days.
Emailalaorichard2010@gmail.com
X@richarddar76016
Dribbbledribbble.com/Daram_ola
RésuméRichard Daramola — CV (PDF)
Based in Lagos, Nigeria. Working remotely with teams in any timezone that overlaps mornings WAT.