Why Desishub · Pillar 03 of 03
Every pixel is a decision
Your staff will spend more hours in this software than in any room in your building
Business software is not used once. A cashier opens it four hundred times a day, a bursar lives in it through fee season. This page sets out how we design for that: research first, a clickable prototype you approve before any code, testing with the people who will actually use it.
Facts on this page last verified 6 November 2026
- Written scope before you pay
- A working demo every Friday
- You own the code
Why we prototype before we build
The most expensive moment in a software project is the one where a client sees a finished screen and says that is not how the work is done. By then the database shape, the API and the tests are all built on the misunderstanding.
So we move that moment forward. The clickable prototype exists so you can be disappointed early, cheaply, and in detail. The projects that go well are the ones where a client marks up the prototype heavily — every note at that stage is an hour of rework that never happens.
Designing for the counter, not the showroom
A dashboard that demonstrates well can still be unusable at a counter with five people waiting. The constraints that actually decide a design are mundane: can this be done with one hand while holding a product, is the confirm button reachable with a thumb, is the most common action the easiest one, does the screen still work when the name is forty characters long and the connection has dropped.
Those questions are why we test with staff rather than stakeholders, and why we check the design on the hardware it will run on.
Accessibility, as a habit rather than an audit
We hold interfaces to WCAG AA contrast as a floor, in both light and dark themes, and we check the ratios rather than eyeball them. Controls get a visible focus state so the keyboard works. Form fields have labels tied to them, so a screen reader announces something useful. Content renders from the server, so it is readable before scripts finish.
Most NGO and government tenders in Uganda now ask about this. Building it in from the start is considerably cheaper than retrofitting it when a procurement form demands it.
Design you own
The design system, the Figma file and the assets are yours at the end, the same way the source code and the database are. If you bring an existing brand we extend it rather than replace it; if you have none, we design one and hand it over.
Related: the security and performance pillars, and web design and development if you want the pricing for a specific build.
Why teams pick us
How we design
- 01
Research before screens
We watch how the work is done today — the paper, the spreadsheet, the workaround everyone uses. The existing process tells you more about the right design than any brief.
- 02
Flows, then a design system
User flows settle what happens before anything is styled. Then a design system of tokens and components, so screen forty looks like screen one and the build goes faster.
- 03
A clickable prototype you approve
Real screens and real navigation in Figma, before a line of production code. You click through it and reject what is wrong while changing it is still free.
- 04
Tested with the people who use it
A cashier, a bursar, a loan officer. We watch somebody try to finish a real task, which is the fastest way to find out a screen cannot survive a queue.
- 05
WCAG AA contrast, checked
Minimum AA contrast in both light and dark themes, visible focus states, touch targets you can actually hit, and real form labels. Verified rather than assumed.
- 06
Built on real devices
Tested on low-end Android hardware at the smallest width we support, not on a resized desktop window.
FAQ
Frequently asked questions.
01Do we see the design before you start building?
Yes, and you approve it. Every project goes through a clickable Figma prototype first: real screens, real navigation, the actual flows your staff and customers will use. You click through it and tell us what is wrong while changing it still costs nothing. We do not write production code against a guess.
02What does your design process actually involve?
Research into how the work is done today, then the user flows, then a design system of components and tokens, then the clickable prototype, then usability testing with people who will use it, then build, then testing on real devices. Each stage produces something you can look at and reject.
03Who do you test with?
The people who will use the system, not their managers. A cashier, a bursar, a loan officer, a nurse. The fastest way to find a broken design is to watch somebody try to finish a real task on it, which is also the fastest way to find out that a screen the client loved cannot be used at a counter with a queue.
04Do you follow accessibility standards?
We hold our interfaces to WCAG AA contrast as a minimum, in both light and dark themes, and we check it rather than assume it. Interactive controls get a visible focus state and a touch target large enough to hit. Forms have real labels. This is also a requirement in most NGO and government tenders, so it is worth having before you need it.
05Will it work on an old phone?
We test on real low-end Android hardware, not just a resized desktop browser. Layouts are built mobile-first, touch targets are sized for thumbs, and we check that a screen is still usable at the smallest width we support rather than merely not broken.
06We have an existing brand. Do you work within it?
Yes. If you have a brand, we build the design system from it — your colours, type and tone, extended into the components your product needs. If you do not, we can design one, and you own it.
Ready to grow your business in Uganda?
Desishub Technologies is the partner you need for world-class web design and custom software development.