UI/UX Design in Kenya

UX (user experience) is how a product works, the structure, the flows, whether people can complete their task. UI (user interface) is how it looks and responds, layout, typography, colour, states, motion. A Haryes UI/UX engagement can include any of:

• UX research: interviews, analytics review, and usability testing with real Kenyan users on the devices they actually use, covered on our usability testing page
• UX audit: a heuristic and data-informed review of an existing product, with issues ranked by business impact, covered on our UX audit page
• Information architecture and flows: site maps, user journeys, and wireframes
• Interface design: high-fidelity screens for every state, not just the happy path
• Design systems: documented tokens, components, and usage rules so a growing team stays consistent, covered on our design systems page
• Developer hand-off: organised Figma files, specs, and a walkthrough with your build team

1. Understand the problem

   We start with the business goal and the user’s goal, and where they conflict today. For an existing product this means analytics, session data, and a five-participant usability test. For a new product it means interviews and competitor teardowns.

2. Structure before surface

   We agree the information architecture and the key flows as low-fidelity wireframes and test them before any visual design. Fixing structure in a wireframe costs hours; fixing it after build costs weeks.

3. Interface design and system

   We design every screen and every state (empty, loading, error, success) and capture the reusable parts in a design system with written usage rules.

4. Hand-off and support

   We deliver organised files, a specification, and a walkthrough with your developers, and stay available for design questions for four weeks into the build.

Book a UX Review →See Design Engagement Rates

Design and build are separate services, but they are not separate problems. When Haryes handles both, structure decisions are made once and the performance budget is set from the wireframe stage, see web design and development.

When your own team or another vendor builds, the hand-off is what determines whether the finished product matches the design. We deliver an organised Figma file, a written specification covering spacing, states, and behaviour, the design system, and a live walkthrough with your developers, then stay reachable for design questions for four weeks into the build. For products with logins and workflows, we recommend pairing the design work with custom web application development so one team owns the outcome.

A design system is a documented library of tokens, components, and patterns with rules for using them. It costs time to build, and it repays that quickly for any team shipping regularly.

• Faster design and build: new screens are assembled from existing, tested components instead of designed from scratch
• Consistency: the interface stays coherent as different people work on it and the team grows
• Fewer decisions: spacing, colour, and type are settled once, not re-argued every project
• Cleaner hand-off: developers build against a known system rather than interpreting one-off screens

We build these in Figma with written usage rules and developer notes, and keep them small enough to actually be maintained.

A focused UX audit or a small design system sits at the lower end, from KES 60,000; full product design with research and a complete system sits higher. Design-only engagements cost less than a full website build because they exclude engineering.

A clickable prototype is the cheapest place to be wrong. Before a line of production code exists, the main journeys can be assembled from the designs and put in front of the people who will use them: a customer making an enquiry, a member checking a statement, a staff member completing a daily task.

Watching three or four people attempt that on a prototype reliably surfaces problems that no amount of internal review catches, because the team already knows where everything is. Changing a screen at that stage costs an afternoon. Changing it after the build costs a week and an awkward conversation about scope.

Most Kenyan projects cannot fund a formal research programme, and they do not need one. What they need is to stop designing on assumptions. There is almost always evidence already in the business: the questions the front desk answers twenty times a day, the messages that arrive on WhatsApp, the reasons people abandon a form, the search terms bringing people to the site, the complaints in reviews.

We start there, then add the cheapest primary research that will change a decision: half a dozen short conversations with real customers, a session watching someone from the target audience attempt the main task on the current site, or a review of what competitors ask people to do. Five people will surface most usability problems, and a morning of that is worth more than a month of opinions in a meeting room.

The output is a short, written list of what we now know and what we are still guessing, so the design decisions that follow can be argued against evidence rather than taste.

The screens where users give something up, an enquiry form, a booking, a registration, a checkout, are where most conversions are lost and where the least design attention is usually spent. Every additional field costs completions, so each one has to justify itself against the work it saves your team later.

We design the whole state machine, not just the tidy version: what a field looks like while being typed into, what a helpful error says and where it appears, what happens when the connection drops halfway, what the user sees while the submission is in flight, and what confirmation looks like. Errors are written as instructions, not accusations, and they appear next to the field that caused them.

Small details decide this: input types that bring up the numeric keypad for a phone number, sensible autofill, and a submit button that disables itself after one tap so nobody sends the same enquiry three times.

A large share of the improvement in a redesign comes from what the page says and in what order, not from how it looks. Headings that state what the page offers rather than a brand phrase. Buttons labelled with the action they perform, not “submit”. Prices, timelines and next steps present rather than implied. Reassurance placed exactly where hesitation happens, next to the form, not in a footer.

We write that copy as part of the design rather than dropping lorem ipsum into a layout and hoping words arrive later. Designing around real content also exposes the awkward truths early: the service that cannot be explained in a sentence, the testimonial nobody has, the price the business is not ready to publish.

Interfaces designed on a fast laptop and reviewed on a fast laptop fail on the hardware most visitors carry. The realistic target is a mid-range Android on mobile data, sometimes with an intermittent connection and often with the person paying per megabyte.

That shapes design decisions, not just engineering ones: fewer and lighter images, layouts that do not depend on hover, text sizes that stay readable without pinching, primary actions inside comfortable thumb reach, and interfaces that degrade gracefully when something fails to load. We review designs on a real device before sign-off rather than in a browser window resized to look like one.

Tell us what you are building or improving, who will build it, and where it stands today. You get back a scoped design proposal within three working days.

Request a Design Proposal →Discuss Your Product on WhatsApp