UI/UX design / Madurai, India
User Experience Design Services
Now that software is quick to build, the expensive mistake is building the wrong thing beautifully. We design products the way we design our own — starting with the people who have to use them, and testing before anyone commits a sprint to it.
Why UX matters more now, not less
When building gets cheap, judgement becomes the scarce part
AI tooling has collapsed the cost of writing code. Our own team ships in a fraction of the time it used to take. That's genuinely good, and it has an uncomfortable side effect: it's now much easier to build the wrong product quickly.
The constraint has moved. It isn't development capacity any more — it's knowing which screens should exist, what belongs on each one, and what a user is actually trying to finish when they open your app on a Tuesday afternoon.
That's the work UX design does. It was worth doing when software was slow to build. It's worth considerably more now that a bad decision gets implemented in a week.
The business case
Where design shows up in the numbers
Design arguments get won with outcomes, not adjectives. These are the four places a client usually notices the difference first.
Less rework
Changing a prototype takes an afternoon. Changing a built feature takes a sprint, plus the migration, plus retraining the people who already learned the old way.
More people finish signing up
Most drop-off happens in the first five minutes, in onboarding flows and forms that were designed by whoever built them last. That's usually the cheapest thing to fix.
Fewer tickets that are really design bugs
"How do I export this?" is not a support question. Every recurring ticket points at a screen where the next step wasn't obvious.
Staff stop working around the software
When your team keeps a parallel spreadsheet, the system lost. Good internal UX is measured in minutes saved per person per day, and it adds up fast.
What we do
Our UI/UX design services
Engage us for a single piece of this or for the whole arc from research to a built design system.
Discovery and research
Stakeholder interviews, user interviews, and time watching people do the job the software is meant to support.
Information architecture
What screens exist, how they're grouped, and what the navigation is called. Most usability problems are really structure problems.
Interaction and flow design
Task flows, states, empty screens, error handling and the edge cases that get discovered late if nobody designs them early.
UI design
Visual design in Figma, built on a type scale, spacing system and colour palette rather than page-by-page decisions.
Prototyping
Clickable prototypes — and increasingly working coded ones — so you can use the thing before committing to it.
Usability testing
Real users given real tasks, moderated remotely or in person, with a written list of what broke and what to change.
Design systems
Components documented and built in code, so the twentieth screen looks like the first without a designer reviewing every pull request.
UX audits
A heuristic and analytics review of an existing product, with findings ranked by impact against effort.
How AI changed our design practice
We prototype in code now, because it costs about the same
A high-fidelity mockup used to be the cheap option and a working prototype the expensive one. With our engineers using Claude Code daily, that ratio has flipped for a lot of work. So instead of reviewing a picture of an interface, you use one.
You test the real thing
Clicking through a coded prototype on your own phone surfaces problems a static frame never will — how it feels on a slow connection, what happens with real data lengths, where your thumb can't reach.
More directions get explored
When an alternative layout costs a day rather than a week, you see two or three genuine options instead of one safe one with the risky ideas quietly dropped.
Nothing is lost at handoff
The classic gap between what design intended and what engineering shipped mostly closes when the prototype is already components in the real stack.
Designing products that have AI inside them
If your product includes a chat interface, suggestions or automated decisions, it needs design patterns most teams haven't built before: showing where an answer came from, handling a confidently wrong response, making it obvious what the system did on the user's behalf, and giving people a way to undo it. We design these because we build them.
What AI is still bad at
Deciding what to build. Sitting with a warehouse supervisor for two hours to understand why nobody uses the app. Knowing that a form is technically fine and still humiliating to fill in. Judgement, taste and talking to people remain entirely human, and they're most of the job.
Process
How a design engagement runs
Iterative, and adapted to the problem. A small audit takes a fortnight; a full product design runs six to twelve weeks alongside development.
Kick off and discovery
We agree goals, users, constraints, decision-makers and how we'll communicate. Then we talk to the people who will use the product and, where one exists, look at what the current system's analytics and support tickets are already telling you.
You get a written summary of what we found, including the parts you may not want to hear.
Structure and prototype
We map the user journeys, settle the information architecture, then build a prototype in Figma or directly in code depending on what needs testing. You review something you can click through, not a static image with arrows drawn on it.
Two or three rounds of revision here is normal and expected — it's the cheapest place in the whole project to change your mind.
Test, refine and hand over
Real users attempt real tasks while we watch. We report what broke, fix the design, and hand over components documented well enough that your developers — or ours — can build from them without guessing.
After launch we look at how people actually use it, because the first design is a hypothesis and usage is the result.
Where we've designed
Complicated software for people who didn't ask to use it
Most of our design work is for products where the user is at work, under time pressure, and has no interest in your interface. That's a harder problem than a consumer app and it's the one we know best.
Education
GegoK12, used by 20+ schools — one system serving administrators, teachers, parents and students, each needing something different from it.
Construction
BOQ Manager, where estimators work in dense numeric tables and every extra click is repeated hundreds of times a day.
Banking and microfinance
Lending and collections platforms with branch hierarchies, approval chains and field staff working offline.
Compliance
ChemTracker, where the interface has to make an audit trail feel like a by-product of normal work rather than extra admin.
Procurement
eTender, with strict role separation and time-bound rules that have to be legible to buyers, evaluators and vendors alike.
Healthcare
DentalPro.cloud and tryiDoc, designed for clinics where the person at the screen has a patient waiting.
What you receive
Deliverables, in plain terms
The team
Design sits inside engineering here, not next to it
GegoSoft is led by a founder with a UI/UX background, which is unusual for a software company and shows in how projects run. Design isn't a phase that hands files over a wall — the people making layout decisions sit with the 18 engineers who have to build and support the result.
That has one practical consequence worth knowing about: we will tell you when a design idea is going to be expensive to maintain, and we'll say so during design rather than three sprints later. Some agencies won't, because it isn't their problem after handoff. It's always ours.
Questions we get asked
Hiring a UX designer, answered plainly
What's the difference between UI and UX design?
UX design decides what the product does and how it's structured — which screens exist, what order things happen in, what each one is for. UI design decides how it looks and feels: type, colour, spacing, components, motion. You need both, and doing UI first is how you end up with a beautiful product nobody can use.
Can I hire a UX designer without also hiring you to build it?
Yes. Plenty of clients take our design work to their own engineering team or another vendor. You get the source files, the design system and the specs, with no licence or dependency on us afterwards.
How long does a UX design project take?
A UX audit of an existing product takes about two weeks. Designing a focused MVP is typically four to six weeks. A full product with several user roles runs six to twelve weeks, usually overlapping with development rather than blocking it.
What does it cost?
Design is quoted by scope — number of unique screens, how many user roles, and whether research and usability testing are included. An audit is the cheapest way to start and tells you whether a full redesign is even warranted.
Do you do usability testing with real users?
Yes, and we'd push for it. Moderated sessions with five to eight people in your actual user group will find most serious problems. Where recruiting real users is difficult, we run structured heuristic reviews and use analytics from the existing product instead.
Which design tools do you use?
Figma for design, prototyping and handoff, with FigJam for workshops and journey mapping. For interactive prototypes we increasingly build in React or the project's own stack, because a coded prototype tests better than a linked set of frames.
Can you redesign our existing app without disrupting current users?
Yes. We usually recommend a staged rollout rather than a single launch: fix the highest- impact flows first, keep familiar navigation labels where they work, and give existing users a way back if something changes underneath them.
Do you design mobile apps as well as web?
Yes — iOS and Android, following each platform's conventions rather than forcing one design onto both. Our three mobile engineers build in Flutter and Kotlin, so what gets designed is checked against what's actually buildable.
Not sure whether you need research or just better screens?
That's a reasonable place to start from. Show us the product or describe the idea, and we'll tell you which of the two would actually help — including if the answer is neither.