पाठशाला Pathshala · उत्पाद Utpād, The product · Lesson 17 · Build

Design when you cannot afford a designer

A product can look finished without a designer if it is built from a few systems, respects the constraints it cannot avoid and treats its words as design. Then hire the designer when one of five signals appears.

Pathshala, The Founder Library · 11 October 2026 · 7 min read

Hands sprinkle coloured powder to fill a rangoli pattern on the floor. — Photograph: Nishant Aneja · Pexels

Most seed-stage products in India are designed by whoever built them. That is not the problem. The problem is that each screen is designed separately, on the day it was built, so the product has eleven greys, four button styles and an error message that says “Something went wrong”. Customers read that as a company that will lose their money. Systems fix it, not talent.

This lesson sets out the five systems that make a product look decided, the constraints it must meet whatever it looks like, why copy carries more of the design than any colour, a monthly review a founder can run alone, and the signals that say it is time to hire. The figure sets two of the systems in a minute.

Tactics, not talent

Adam Wathan and Steve Schoger’s Refactoring UI, written by a developer who struggled with design and the designer he worked with, makes the claim this lesson rests on: design with tactics, not talent. Its chapters include establishing a spacing and sizing system and establishing a type scale, which is a polite way of saying that most of what looks like taste is a small number of decisions made once and applied everywhere.

The UK Government Digital Service’s design principles, written for teams building services used by millions, point the same way from the other end. Start with user needs. Do less, and concentrate on the irreducible core. Be consistent, not uniform. A small team that applies those three will produce a plainer product than a well-funded rival and often a clearer one.

Five systems that do the work

Type. One typeface, the platform’s own or a well-made open family with the Indic scripts you need, and a scale of five or six sizes, each the previous one multiplied by a single ratio. Nothing on any screen uses a size outside the scale. Spacing. A short list of allowed values, such as 4, 8, 12, 16, 24, 32 and 48 pixels, and nothing else for margins, padding and gaps. Most of what reads as polish is consistent space. Colour. One accent for the one action you want taken on each screen, a ramp of four or five greys, and three state colours for success, warning and error. Every other colour is a decision you will have to defend later.

A kolam drawn on the floor of a courtyard in front of an ornate doorway. — A kolam is a grid of dots and one rule for joining them. Type spacing and colour work the same way. Photograph: Mainak Dasgupta · Pexels

Components. Use an established component library and adapt its tokens to your type, spacing and colour, rather than building buttons, inputs and dialogs by hand. A library has already solved focus states, disabled states and keyboard access, which home-made components almost never do. Layout. One column on a phone, a fixed maximum width on a desktop, and the most important action in the same place on every screen. Write the five down on one page and put it in the repository where every engineer will see it.

What an afternoon of this does to a real product. A Kochi team building inventory software for pharmacies counts what is in its app and finds nine font sizes, fourteen greys, three shades of its blue and buttons in four heights. It picks a 16-pixel base with a 1.25 ratio, which gives six sizes; seven spacing values; one blue for primary actions, five greys and red, amber and green for states. An engineer spends two days replacing every value outside the lists with the nearest one inside. No screen is redesigned, and the pharmacists who see it in the next round of sessions describe the product as “new”.

A ratio of 1.2 or 1.25 suits dense product screens; 1.333 suits marketing pages with fewer, larger headings. The ink slider makes the more important point. Take body text below about 54 per cent ink on white and it fails the contrast floor, which is where many products end up when grey text is chosen because it looks elegant on a calibrated monitor.

Constraints you do not get to choose

The Web Content Accessibility Guidelines, WCAG 2.2, set two numbers worth building into the system on day one. Success criterion 1.4.3 requires a contrast ratio of at least 4.5 to 1 for normal text and 3 to 1 for large text, defined as at least 18 point or 14 point bold. Success criterion 2.5.8 requires pointer targets of at least 24 by 24 CSS pixels. These are minimums for accessibility, and they are also what makes a product usable on a ₹8,000 phone with a dim screen, used outdoors, by someone with a thumb rather than a mouse. Treat 24 pixels as the floor and make primary actions much larger.

India adds constraints of its own. Devanagari, Tamil and Bengali text needs more line height than Latin text at the same size, because of the marks above and below the letters; test every screen in each language you support, with real words, not placeholder text. Long words in some languages break layouts built for short English labels. Show money in the Indian system, ₹1,25,000 rather than ₹125,000, and dates the way your users write them. The [low-end Android lesson](/library/building-for-low-end-android-patchy-networks) covers the performance side of the same constraint.

Copy is most of the design

On most product screens there is more text than anything else, and the words decide whether the user knows what to do. Jakob Nielsen’s ten usability heuristics, first published in 1994 and still reviewed by his firm, read as a copy checklist as much as a design one. Visibility of system status: say what is happening, sending, sent, failed. Match between the system and the real world: use the customer’s words, khata and udhaar if that is what your distributors say, not the accounting term you learned in a course. Help users recognise, diagnose and recover from errors: every error says what went wrong in plain words and what to do next.

Three rules cover most of it. Buttons say what will happen, “Send invoice” rather than “Submit”. Empty screens teach: a new user’s empty list shows what it will look like when full and the one action that fills it, which is half of the [activation lesson](/library/activation-first-session-that-decides). Errors are written by a person for a person: not “Error 402” but “The payment did not go through. Your bank declined it. Try another UPI app or card.”

Most of what looks like taste is a handful of decisions made once and applied everywhere.

A review you can run without a designer

Once a month take a screenshot of every screen in the product’s core flow, from sign-up to the moment the product does its job, and lay them side by side. Inconsistency becomes visible at once: the button that moved, the grey that is slightly different, the heading one size too large. Then walk the flow against Nielsen’s ten heuristics, one at a time, writing down each place a screen breaks one. Thirty minutes, alone or with the engineer who built the flow, produces a list of small fixes that can ship on the next release train.

Pair it with what the [weekly five sessions](/library/talking-to-users-while-you-build) show. A heuristic review finds what an expert would object to; watching a user finds what actually stops them. The two lists overlap less than founders expect, and the second one wins any argument.

When the first designer pays off

Five signals say the systems are no longer enough. Trust is the product. In payments, lending, insurance and health, how the product looks is part of whether a customer believes it is safe, and a designer’s work shows up directly in conversion. A step will not move. A funnel step that stays stuck after the copy, the system and the weekly sessions have all been applied needs someone who can redesign the interaction, not polish it. The system has forked. Three engineers have each extended it in a different direction and nobody owns it. A second surface is coming, a second app, a merchant side, a web dashboard, and it has to feel like the same company. The buyer judges the look. Enterprise and brand-led consumer sales are won partly on how the product appears in a demo.

When the signal appears, hire a product designer who can run research and design interactions, not only a visual designer. A defined first project, the design system and the one core flow, done on contract over a few weeks, tests the fit before a full-time offer and leaves the company with an asset either way.

The monthly polish pass

First Monday of the month, one hour. Screenshot the core flow and lay it out. Check every screen against the five systems and list each value outside them. Run the contrast check on every text colour in use and the size check on every tap target. Walk the flow against the ten heuristics. Rewrite the three worst pieces of copy, starting with error messages. Put the fixes on this week’s release train. Then ask the one question that decides the next hire: has any of the five signals appeared since last month?

The contrast figures follow the WCAG 2.2 definitions; the scale ratios are conventional choices, not standards, and the Kochi example is illustrative.