UI/UX Design

03

Design is not decoration

On a product that moves money, the interface is not a skin painted over logic — it is where the product's promises become tangible. A calm balance screen, a clearly stated fee and a confirmed state are trust controls, not cosmetics, and we design them with the same structure we bring to the backend: deliberate, tested, failure cases included.

• Design is not decoration — it is the difference between a screen a stranger understands in one glance and a screen that needs a training session.
• The interface is the product — users never see the ledger, the locks or the callbacks; they see a button, a number and a feeling of whether the product is safe.
• Every screen makes a promise — on a money app that promise is 'your money did exactly what you asked', so the UI states outcomes, not just actions.
• Trust is a design consequence — an unexplained fee, a dead-end error or a frozen spinner teaches users not to trust the product, no matter how correct the backend is.
• Deliberate beats tasteful — personal taste is fragile; decisions tied to evidence, behaviour and product goals survive contact with real users.
• Failure is designed, not stumbled into — timeouts, 'we could not reach M-Pesa' and retry prompts get the same design care as the happy path.

This is why we start before pixels: with the user, the flow and the outcome — and only then decide how it should look.

04

Research before any screen is drawn

We interview and observe before we draw. The most useful thing you can learn about a user is not which colour they prefer but what they actually do when the app does something unexpected — and that fact only surfaces by watching, not by guessing.

• Interview first — we talk to real and prospective users about how they do the task today, where it hurts and what they fear going wrong.
• Observe, do not ask users to design — users cannot specify interfaces; they can tell you what they tried, tapped and abandoned, which is far more useful.
• Watch the environment — a user on a bus, in a queue or in a shop behaves differently from a user at a desk; we design for the bus, the queue and the shop.
• Mine the data you already have — support tickets, session recordings and funnel exits are free research; a repeated complaint is a design finding.
• Test assumptions cheaply — a 'would you trust this?' sketch costs an hour and prevents a month of building the wrong mental model.
• Keep the receipts — research is recorded, quoted and referenced so design decisions can be traced to evidence instead of vibes.

On our own platform, research is how the exact-shortfall top-up prompt was born — a user told us they topped up 'enough' and still failed; we stopped guessing and started telling them the precise amount.

05

User flows that settle what the product must do

A screen is a moment; a flow is the journey between moments. Before we design any screen we map the journeys the product must carry — happy path, retry path, dead end and recovery — because a flow diagram exposes decisions that a screen sketch hides.

• Map the happy journey first — from opening the app to the confirmed outcome, every step and every decision point written down.
• Then map what breaks — network drop at the PIN pad, insufficient balance, double tap, expired session; each is a branch the design must carry.
• Number the steps — a flow of fourteen steps to pay rent is a problem being hidden; we compress before we design.
• Name the state at every step — what the user sees, what the system knows and what happens if they kill the app mid-flow.
• Assign every decision one owner — each branch must know who asks, who decides and who tells the user, so no screen dead-ends.
• Keep the flow testable — a flow that cannot be run end-to-end against real logic will be redesigned in production; we design it testable from day one.

Flows come first because they cost nothing to change on paper and everything to change once screens, copy and code have been built around them.

06

Wireframes that cost nothing and catch everything

Wireframes are where the product's skeleton gets settled: layout, hierarchy, the order of fields, what appears first and what is hidden where. They are cheap to draw, cheap to throw away and expensive to skip.

• Structure before beauty — wireframes settle hierarchy, flow and labels before colour and polish enter the picture.
• Every state gets a frame — the empty state, the loading state, the error state and the success state are drawn, not assumed.
• Content is real before design — labels, fees and confirm text are drafted during wireframing, because accurate copy changes layout.
• Winnow the churn — it is dramatically cheaper to argue about a skeleton than about a finished screen; arguments happen at the right layer.
• Numbers and banks align early — the fee row, the total row and the balance row are pinned in the wireframe so arithmetic and layout agree before code.
• Reviewers review structure — stakeholders who would be dazzled by a polished screen actually evaluate the flow when shown a wireframe.

A wireframe that survives stakeholder review is a flow that has been stress-tested before a single professional pixel was spent.

07

The mobile-first Kenyan reality

Kenya is an Android-first market on dramatic device variety, prepaid data and networks that flap between generations. Every design decision we make is tested against that reality — a screen that only works on a flagship in a lab is a screen we consider broken.

• Entry-level phones first — low RAM, old OS versions and small screens are the baseline, not an afterthought; expensive hardware is the bonus tier.
• Data costs money — every megabyte has a price to the user, so screens are lightweight, lazy-loaded and never download what the user has not asked for.
• Networks flap — 4G becomes 3G becomes 'no network' mid-flow; designs survive the drop instead of pretending it cannot happen.
• Small bundles mean short sessions — users act in quick bursts; flows compress so a task can be completed in one focused sitting.
• Dark mode saves pixels and battery — and is demanded anyway — OLED-friendly dark themes reduce battery drain on the phones most people hold.
• Plain language beats long sentences — clarity matters more than word count; a long English sentence on a small screen is a readability risk, not a virtue.

We literally test on these realities — our own KodiiPay screens are exercised on budget Android devices and throttled connections, so the design that ships is the design that survives.

08

Thumb reach and the one-handed screen

Most Kenyans hold a phone in one hand and thumb the screen; the top of a tall screen is a dead zone. We design the primary action where the thumb already is, and we put the risky actions out of reach of accident.

• Primary action in the thumb arc — the pay, confirm and continue buttons live in the lower third where the thumb actually rests.
• Big targets for tired hands — touch targets are generous — 44 pixels and wider — because users in a hurry tap sloppily.
• Destructive actions get friction — a confirmed money move is never sitting next to a casual control; it is separated, labelled and re-confirmed.
• One screen, one decision — each screen asks the user to make one decision; everything else is information supporting that decision.
• Reach stays predictable — navigation lives where the user has already been taught to reach, so muscle memory carries them.
• Scroll is a last resort — long screens push the action off-screen; we cut content before we ask for a thumb marathon.

A screen you can use one-handed in a matatu is a screen the whole market can use; that is the practical definition of accessible.

09

The PIN keypad and money-adjacent craft

Money touches are where craft matters most. The PIN keypad, the confirm dialog and the 'result received' screen are the moments a user's trust is made or lost, and we treat them as a craft of their own rather than one more screen in the style guide.

• The keypad is a ritual — digits are large, spaced, tactile and familiar; the user never has to search for their thumb's home position.
• Numbers never feel like decoration — balance, fee and total are typographically distinct, legible at arm's reach and never squeezed into a corner.
• The confirm moment is quiet and deliberate — the amount is restated large, in words the user recognises, before anything moves.
• Feedback is instant and honest — every input becomes a visible check, then a clear result; no tap goes unanswered.
• Ambiguity is forbidden — 'pending' is paired with what it means ('waiting for M-Pesa, your card network or the bank to confirm'), so a state is an explanation, not a mystery.
• The wrong tap is survivable — cancel, back and retry are always available, and a mistaken initiation is reversible with a visible outcome.

These are the screens KodiiPay users see every day, and we have rewritten them enough times to know the difference between a screen that moves money and a screen that earns trust.

10

Exact-shortfall top-up: designing for the user who is already short

An 'insufficient balance' error is a design moment, not just a validation message. Telling a user they need KES 142 when they have KES 100 creates a loop of failed attempts; telling them they are short by exactly KES 42 — and offering a one-tap top-up for that precise amount — turns a failure into a completed payment.

• Say the exact amount — 'You need KES 142. You have KES 100. Add KES 42 or more' is a complete sentence; vague errors send users in circles.
• Offer the fix in the same screen — the top-up action is one tap away, pre-filled with the precise shortfall, so the user does not have to search for it.
• Count the fee in the math — the shortfall includes the transaction fee, because a user who budgets the amount but not the fee is set up to fail.
• Never silently deposit — the app asks before an STK push fires; a surprise deduction is a breach of trust even with the best intentions.
• Keep the flow on track — after a successful top-up the original payment resumes, so the user never restarts a journey they already walked.
• End in the result — the user lands on the outcome ('paid' or 'failed') with a receipt reference, never back at the start in confusion.

This pattern exists in our own production app because we measured how many failed payments came from vague shortfall messaging — then we fixed the message, not just the users.

11

Component craft and interaction design

Consistent software is built from a library of components whose behaviour is defined once and inherited everywhere: buttons, inputs, dialogs, chips, toggles, lists and the states each can be in. Craft is in the detail of those states.

• Every component knows its states — default, pressed, disabled, loading, error and success are designed, not improvised per screen.
• Toggles say what they do — a switch is labelled with the action it takes, so no control depends on a user guessing a glyph.
• Inputs validate kindly — a wrong phone number is corrected with guidance on the spot, not rejected with a red wall at the end.
• Loading is honest — a spinner comes with what it means and how long the user might wait; a frozen button is a promise broken.
• Chips and filters get badges — counts, states and selections are visible, so the interface tells the user what is currently true.
• Rows are tappable and predictable — lists feel like lists, chevrons mean navigation and nothing looks tappable that is not.

Component craft is what makes a product feel engineered: the same control behaves the same way in every screen, and the user learns the product once.

12

Micro-interactions that guide, confirm and reassure

The small moments — a button that deepens as it is pressed, a check that confirms a code, a card that slides to reveal a result — are not flourishes. They are how the interface tells the user 'that worked', 'keep going' and 'now you can relax'.

• Press feedback — every tap responds visibly, because a silent tap on a money flow feels like nothing happened, and users tap again.
• State confirmation — success states are distinct and immediate, so 'I did it' is felt, not assumed.
• Motion with purpose — transitions guide attention to what changed; they are fast, subtle and never the point of the screen.
• Progress is visible — multi-step flows show where the user is and how many steps remain, so a flow is a journey, not a tunnel.
• Reassurance at the risky moment — the confirm dialog is calmer, slower and clearer than the surrounding flow, not jumpier.
• Respect reduced motion — every animation has a static counterpart for users who need motion off.

We use micro-interactions to reduce doubt in exactly the places doubt costs money — the moment before an STK push fires and the moment after the result lands.

13

Usability testing on real users, before the build spends money

Every screen we ship has met a real user before it ships. Usability testing on the actual audience — not the founding team, not the developer's mother — is the cheapest insurance in software, and we do it on prototypes before writing production code.

• Test the prototype, not the app — interactive wireframes and clickable designs expose misunderstanding weeks before the build.
• Watch the hands, not the words — what users tap, hesitate on and abandon tells more than what they say in a survey.
• Use real tasks — 'pay this rent bill' beats 'rate this screen'; tasks force the user to actually navigate, not admire.
• Five users find most things — a small round of real users beats a large panel of colleagues; each round finds different truths.
• One observer, one notepad — the facilitator asks 'what are you trying to do?' and records behaviour, not opinions.
• Fix, then test again — usability testing is a loop; the second round proves the fixes, not the design's virtue.

On money flows we test the costly paths hardest — double-submission, low balance, killing the app mid-payment — because the design must hold when the user is stressed, tired and in a hurry.

14

Accessibility is part of the aesthetic, not an add-on

A screen that fails contrast, ignores screen readers or assumes two working thumbs excludes real users and fails real audits. We treat accessibility as a design constraint from the first frame, not a checklist shouted at the team a week before launch.

• Contrast is signed off in design — text, states and alerts must pass contrast on the actual colours used, checked before the build, not after.
• Screen readers are a first-class audience — labels, landmarks and focus order are designed in, not patched in.
• Focus is visible — keyboard and screen-reader users can see exactly where they are at all times.
• Tap targets are generous — the 44-pixel-and-wider target rule protects everyone, not just motor-impaired users.
• Plain language is inclusive — a clear sentence beats a clever one; the clearest copy is also the most trustworthy on a money screen.
• Reduced motion and large type are honoured — users who need stillness or size get it without asking twice.

Accessibility is not a special case of good design; it is the full definition of it. We design for the widest audience because the widest audience is the real audience.

15

Dark and light theming without the chaos

Dark mode is not a filter you flip; it is a second palette with its own contrast decisions, elevation rules and stress on colour. We build both themes from tokens so they stay coherent and testable, never as afterthoughts painted late onto each screen.

• Tokens, not per-screen colours — both themes come from the same token set, so no screen can invent a colour of its own.
• Dark is designed, not inverted — dark surfaces, raised cards and contrast are decided deliberately; inverting light colours byte-for-byte usually fails.
• Contrast is re-verified per theme — a colour that passes in light may fail in dark; both palettes are checked against the same rules.
• System default respected — the app follows the device theme, with an in-app override and a remembered choice.
• Charts and codes survive both — data colours, QR blacks and status chips are chosen to remain legible in light and dark.
• Theming never becomes chaos — because tokens drive both themes, adding dark mode never means revisiting every screen's styles.

On an app used in glaring Nairobi sun and dim evening rooms alike, a theme that adapts is kindness; a theme that breaks is a bug.

16

Typography, colour and spacing as a language

Visual consistency is not a coincidence; it is a language of type, colour and spacing with agreed grammar. When the scale, palette and rhythm are defined once, every screen inherits the same voice, and the product stops feeling stitched together.

• One type scale — sizes, weights and line heights are tokens, so hierarchy is never re-decided per screen.
• One palette with jobs — colour is assigned roles — primary, success, danger, warning, neutral — so colour means something consistently.
• A rhythm of spacing — the 4-point grid gives every gap, margin and padding a reason and a name.
• Numbers are typography's hardest job — balances, amounts and fees are set in a tabular, legible style, aligned and never squeezed.
• Consistency reads as trust — a product using one voice looks maintained; a product stitched from different moods looks abandoned.
• The language is versioned — when the scale or palette changes, it changes in the tokens and ripples through every screen, not screen by screen.

A user should not be able to tell where one designer ended and another began; on our builds they cannot, because there is only one language.

17

Empty, loading and error states as first-class screens

A product with no data, a product waiting for a network, and a product that just failed are not edge cases — they are the majority of some users' experience. We design these states with the same attention as the happy path because they are where users decide whether to stay.

• The empty state teaches — no transactions yet is an opportunity to show the user what the feature does and how to start.
• Loading states are honest — a clear progress cue with context beats a blank screen; users tolerate waiting they understand.
• Error states recover — every dead end offers a way forward: retry, check network, contact support, return to balance.
• Nothing is ever a blank wall — a broken screen with no text and no action is the fastest way to lose a user forever.
• Language stays calm — failures are stated plainly without jargon, blame or panic; 'we could not reach M-Pesa right now' is as calmly worded as a card decline or a held bank transfer, and every rail's failure is a sentence a user can act on.
• The way out is always visible — from any dead end, the user can get back safely to their balance, their home or their saved draft.

The users who see only our empty, loading and error screens are our most fragile users; we design for them deliberately rather than hoping they never exist.

18

Prototyping and iteration before the build spends money

A clickable prototype is the fastest way to make an idea tangible, testable and killable before production costs accumulate. We prototype at the right fidelity — rough for flow, refined for feel — and we let the prototype do the arguing.

• Fidelity follows the question — flow questions get rough sketches; feel questions get refined clicks; neither jumps ahead of the decision.
• Low-cost feedback loops — a prototype shared on a phone gets a stakeholder to actually tap it, which beats a slideshow of screens.
• Kill ideas cheaply — a prototype that fails with five users costs days; the same idea in full build would have cost months.
• The prototype becomes the spec — the approved prototype and its copy become the reference production builds to, so nothing is lost in handoff.
• Iterate in hours, not sprints — a prototype is edited in hours, so improvements happen fast, before they harden into code.
• Prototype the risk, not the whole app — concept testing focuses on the unproven moments, not the thousand screens that follow a pattern.

Every KodiiPay flow that carries money was walked as a prototype before it was walked as code — the shortfall prompt, the confirmation card, the failed-payment recovery.

19

Design and engineering working from the same language

The handoff is where products die: a beautiful screen cannot be built as designed, a component does not exist in the library, a state was never designed because design and engineering never compared notes. We keep the two disciplines inside one loop.

• The designer knows what the stack can do — screens are designed against real component and platform constraints, not against fantasies.
• The engineer sees the design early — reviewing the prototype before defining endpoints means the data model and the interface agree.
• States are co-owned — the design defines every state; engineering confirms every state exists in the build; neither can claim innocence later.
• Measurements and labels are agreed — the fee string, the balance format and the error copy are agreed in both places before the sprint.
• Design tokens cross the boundary — the same tokens drive the prototype and the codebase, so what was designed is what ships.
• QA checks against the design — visual QA compares the build to the prototype, not to memory, so drift is caught and fixed.

Design is not a department that throws drawings over a fence; it is a discipline inside the build that starts before code and ends after launch.

20

Honest limits of UI/UX design

We are direct about what user experience can and cannot fix. Great UX cannot make a broken business model work, cannot compensate for a slow backend, and cannot keep a feature alive that nobody actually needs. Design's job is to make the true strengths feel effortless — not to decorate over weaknesses.

• UX cannot fix a wrong product — a beautiful interface on a product nobody needs is a beautiful waste; the flow work starts before the screens.
• UX cannot rescue a slow backend — the best empty-state copy cannot hide a ten-second spinner; performance is a design requirement, not a rival.
• Design cannot outrun bad copy — every label, fee and error message is part of the design; words are design material, not a later task.
• A design system cannot fix every page — screens built before the tokens exist still need migrating; the system pays off over the rebuild.
• User research cannot read the future — research reduces risk; it does not guarantee the market; iteration after launch remains the real test.
• Taste is not a standard — we give you opinions backed by evidence, and we respect that some calls belong to the business owner, not the designer.

We will tell you when the problem is not the interface — and fix the thing underneath instead, because a studio that only knows how to design is a studio that will let you polish a dead product.

The toolchain

The UI/UX toolchain

This is the design machinery we run on every engagement — from the first user interview to the shipped, tested screen. Every layer exists because a money product in the Kenyan market demanded it.

Lifecycle

The UI/UX lifecycle — from user to shipped screen

Every interface we build travels the same arc: learn before you draw, draw before you build, test before you ship, measure after you launch.

Closing

More than development

UI/UX design is where engineering meets humanity — turning complicated systems into software a stranger trusts in ten seconds. Our interface work includes:

Design is not decoration, and it is not magic. It is the disciplined work of making a complicated system feel effortless — and the hardest work is in the moments users never mention because they just worked.

We design software nobody has to explain — because on a money product, the first ten seconds decide whether the user ever gets to experience the engineering at all.