UI/UX & Digital Design

Experiences designed around your users.

Journeys first, pixels later

UI and UX here means the path a person takes to finish a job, drawn and argued before anyone falls in love with a colour. A journey is not a slogan. It is: they arrive from WhatsApp or Maps, they understand the offer, they complete a form or a tap, they know what happens next. If that path is wrong, a beautiful screen makes the wrongness faster. We will not start with a moodboard and call it research.

We work with SMEs in India whose users are on a phone, in a hurry, and unimpressed by decoration. Staff tools and public sites both need design. They do not need the same design. A dispatcher does not need a hero video. A first-time buyer does not need a dense table of last year’s jobs. Write who the person is and what “done” means on a Tuesday. Then we draw. Then we make pixels.

Wireframes are the meeting, not a delay

A wireframe is a low-decoration picture of the screens and the order they appear. It is where you discover that the “simple form” has seventeen fields, that the manager approval has no state for leave, and that the thank-you page never says who will call. Those discoveries are cheap on a grey box. They are expensive in a finished theme. If a vendor skips wireframes because they have a kit, you are buying their kit, not your process.

We use wireframes to settle arguments. Two people, looking at the same boxes, saying what happens when the GSTIN is wrong or the quantity is zero. If they cannot agree, we stop. Software should not pretend to settle a policy you have not written. The wireframe is how the policy becomes visible. It is also how we keep an MVP honest: one job on the first path, the rest on an out-list, not hidden inside a pretty extra screen.

Prototypes come after the path is stable — a click-through that a real user can fail. “They liked the colours” is not a result. “Three people in the bay completed the list without us in the room” is a result. We will ask for the second sentence. If you only want the first, you want decoration. Say that. Decoration is a smaller job and we will not dress it up as UX.

Design systems that survive a second screen

A design system is the boring agreement: type sizes, spacing, buttons, form errors, tables, empty states. It is not a poster. It is how the third screen does not invent a new way to say “save”. For a five-page marketing site the system can be thin — type, colour, a button, a form, a footer that does not fight the thumb. For a portal it has to cover roles, filters, destructive actions, and a history the user will trust.

We hand over components and tokens, not a folder of disconnected artboards. If web development or a later React screen will implement them, the names should match what an engineer can use. If you will never have a second screen, do not pay for a full system. Pay for the pages you will ship and a short note so a future page does not drift. Drift is how a firm ends up with five shades of the same blue and a form that looks like another company.

Brand already exists for most SMEs: a logo that almost works, a colour from a visiting card, a typeface that does not load on a phone. We will work with that. A full identity project is a different service. This page is the experience of using the thing, not a rebrand you did not ask for.

Forms people can finish on a phone

Most of the product is a form, whether anyone calls it that. Enquiry, login, dispatch quantity, leave dates, GSTIN, UPI reference. If the form fails, the journey fails. On a Kerala phone that means large fields, labels that stay visible, errors next to the field, and a keyboard that matches the input — number for a phone, not a full text keyboard for a PIN. It means not asking for a company fax. It means not blocking paste on an OTP.

It also means a length a person will finish. Four fields for an enquiry. The rest can wait for a human. If you need seventeen fields because accounts said so, split the job: the customer sends the minimum, staff complete the rest in a tool they can see on a desk. Forcing a stranger to type a ledger code is how you get empty forms and a WhatsApp anyway.

Long Indian names, two-line addresses, and state-plus-PIN patterns need room. English-only placeholders fail when the user thinks in Malayalam and types in English. We do not have to ship a full Malayalam UI on day one, but we do have to avoid cute microcopy that only makes sense in a San Francisco template. “Zip” is a tell. “PIN” is the word. “Last name” as a required field is how you insult a user who does not split their name that way. Offer a full name field unless a downstream system truly cannot live without the split — and then say which system, in the brief.

• One job per screen on a phone; do not nest a table inside a modal inside a tab.
• Errors in language a person can act on — “Enter the 15-character GSTIN”, not “Invalid”.
• A back path that does not destroy what they typed.
• A submit button that stays usable with one thumb, not behind a chat bubble.
• An empty state that says what to do, not a cartoon and a joke.

Moodboards are not the product

A moodboard is a conversation about taste. It can help a public site feel like the same firm as the signboard. It cannot tell you whether a dealer can find yesterday’s rate. We will use references when they clarify — “this density, not this one” — and we will stop when the board becomes the deliverable. If your last designer shipped forty shots of furniture and no wireframe, that is why the developer invented the form.

Motion, illustration, and hero video are costs on a mid-range Android. They belong on a marketing page only if they do not hide the offer or delay the first paint. Public performance is a design problem as well as a build problem; the metric language is in Core Web Vitals explained. We will not specify a full-bleed video on a service URL that already ranks and then blame engineering for INP.

Dark themes, glass, and gradients are optional. Contrast is not. If a supervisor cannot read the quantity in sunlight at the gate, the palette failed. We test that with a phone outdoors, not with a screenshot in a deck.

Staff tools versus marketing pages

Marketing pages persuade a stranger. They need a clear offer, proof you can stand behind, and a next step that works on a phone. Staff tools help a known person go faster without making a mess. They need density, filters, and a destructive action that is hard to do by accident. Using the marketing kit on the dispatch screen is how you get a beautiful table nobody can scan. Using the admin kit on the homepage is how you get a wall of links a visitor will bounce from.

If you need both, they can share tokens — colour, type, logo — and still have two layouts. That is normal. It is also why this service often sits beside web development and mobile rather than replacing them. Design without an implementer is a PDF. Implementation without a journey is a theme. We would rather be in the room for both than polish a file that will be rebuilt from scratch.

What a first design slice looks like

A week or two of journeys and wireframes for one job, reviewed with the people who do the job — not only the owner. Then a short UI pass on those screens: type, form, empty and error states, a phone and a narrow desktop. Then a handover the builder can use. That is enough to start an MVP or a five-page site. A twelve-week “experience programme” before anyone writes a line of code is how the process changes under you and the boards go stale.

Time bands: one to two weeks for a focused website look-and-feel on pages you already listed. Two to four weeks for a portal journey plus a thin system. Longer when we must sit in a bay, when two roles fight, or when accessibility and bilingual copy are in the first slice. We will not invent a rupee total for a Figma file. If the design is attached to a build, the build’s estimate still follows the same week-band rules as any custom software slice. Design-only work is a fixed phase with a written out-list — no “also the app” in week three without a new page.

Research here is conversation and observation, not a fifty-person survey you will not run. We will watch one enquiry or one dispatch if you will let us. An hour in the real place beats a persona workshop with names nobody has.

Handover — files a builder can use

You get the journeys, the wireframes, the UI for the agreed screens, and a short system: type, colour, spacing, components, form rules. You get exportable assets at sizes a phone can finish. You get notes on what we did not design. If we used a shared file, you own the file. If a developer will implement in Blazor or React, we will name components in a way that does not require a translator. A pretty PDF with no measurements is not a handover. It is a souvenir.

A week of questions after the builder starts is normal. An unpaid second product — “now do the customer app” — is a new slice. Say it early. We will also say when the design is done enough to code. Pixel-chasing a marketing site while the form still drops the phone number is the wrong order.

What we will not do

We will not treat a Dribbble shot as a specification. We will not hide required fields in a stepper so the demo looks short. We will not specify a chat widget that covers the primary button. We will not invent usability scores or fake quotes from users we never met. We will not deliver forty artboards and no empty state. We will not redesign Tally. We will design the screen that talks to Tally, if that is the job, and we will respect the fields accounts already refuse to drop.

We will not run a week of “ideation” when you already know the job and the constraint is the phone in the yard. We will not use stock photos of European offices to sell an Indian workshop. If you want that look, say so and we will still warn you that your buyers can see the gap.

How to choose this work — and how to brief it

If you are still choosing a partner, the buying motion is on how to choose a software development company. Use it. This page is only what the design slice should contain. A studio that leads with brand and never asks who completes the form is a studio. Fine for a poster. The wrong animal for a portal.

Brief us with the job, the person, the phone they use, and one real example — a filled form, a chat, a sheet. Say what you already tried. Attach the current site or app and the complaint you hear twice a week. Name who can approve the wireframe without a committee. If you also need the build, say whether it is a site, a .NET portal, or a phone app so we do not draw a journey the stack cannot keep.

When that page is honest, we can start. Send it through contact. Bring the person who does the job, even for an hour. Leave the moodboard in the folder until the wireframe has survived them. If they cannot finish the path on a phone in the room, we will not colour it. We will fix the path. That is the work. Everything else is paint.