Most product design happens on a machine that costs more than the phone the user is holding, on office broadband, with a data allowance nobody thinks about.
A large share of the people using an Indian consumer app are on an entry-level Android handset. Around eight thousand rupees buys an HD+ screen, a modest chipset, a few gigabytes of memory and slow onboard storage. It works. It just fails differently from the device the design was approved on.
These are not edge cases. For a lot of products this is the median user, and designing for them is mostly a matter of knowing which constraints are real.
Know what the device actually is
Four constraints, and they are separate problems.
The screen is small and unusually tall — commonly around 360 points wide in the browser or in Android’s density-independent units. Vertical space is cheap; horizontal space is not.
The processor and memory are limited, so anything that animates, blurs or composites many layers drops frames. A design that feels smooth on a laptop can feel broken here, and people read stutter as the app being unreliable rather than the phone being slow.
Storage is slow, which shows up as launch time and janky first scrolls. And the network is intermittent and metered: prepaid daily limits are normal, and someone near the end of their allowance is making a real choice about opening your app.
Tap targets: the numbers, and what they cost in layout
The platform guidance is unambiguous and worth quoting properly. Google’s Material Design guidance sets a minimum touch target of 48 by 48 density-independent pixels. Apple’s Human Interface Guidelines put the equivalent at 44 by 44 points. WCAG 2.2 added a target size minimum of 24 by 24 CSS pixels at level AA, with the larger 44 pixel figure at AAA.
Take 48dp seriously and the layout consequences arrive at once. On a 360dp-wide screen, four targets plus their gaps and the page margins is a comfortable row. Five is tight. Six will be mistapped.
The GPS trip and mileage app we designed opens on a six-tile grid where every tile leads with a number: hours logged this week, reports filed, miles tracked, receipts stored. Six tiles, but two or three per row, so each is a large, unmissable target rather than a small icon in a strip. That is the trade on a cheap phone — scroll is free, precision is expensive.
Tall and narrow is a layout change, not a scale change
A tall aspect ratio means the bottom of the screen is where the thumb lives and the top is a stretch. In the student app, booking, messages and sessions share one bottom bar, and the primary controls sit within reach.
The same logic favours horizontal strips over wide blocks. The student learning app schedule leads with a horizontal date strip with today marked, then the next session as a card with time, subject and location. A date strip works on a narrow screen because it scrolls sideways by design; a month grid crammed into 360 points does not.
On the GPS app the add-trip control is a floating button that stays put while the list scrolls, because that is the one thing a driver does mid-shift. What does not survive the narrow screen: multi-column tables, side-by-side comparisons, and anything expecting a hover.
Image weight is the whole performance budget
On an entry-level phone with metered data, images are almost the entire cost of your product. Everything else is rounding.
The student app presents subjects as a short illustrated list. Illustration rather than photography has a weight consequence: a flat illustration compresses to a fraction of a photograph and looks identical on a low-density screen.
The one image that has to load properly is the tutor’s photo, because it is doing a job — a student comparing tutors is partly comparing faces. Everything else can be an icon, a colour or type.
The discipline: list the images on your busiest screen and, for each, name the decision it helps someone make. Images that do not survive that question are the cheapest kilobytes you will ever save.
Design the screen that arrives in pieces
On a slow connection an interface does not appear, it assembles: type first, then colour, then images, sometimes much later. The first stage should already be useful.
In the student app, each subject keeps its own colour and icon everywhere in the product, so screens identify themselves before the heading is read. On a fast phone that is a nicety. On a slow one it means a half-rendered screen still tells you where you are.
The GPS home screen does the same with numbers. Text renders before images, so a tile leading with a figure is readable in the first paint, and the driver has the state of their week before the icons arrive.
The opposite pattern is a screen whose meaning lives in imagery — a hero photograph with the value proposition inside it, or icon-only navigation. Those are blank for the people with the worst connections.
Offline is a normal state, not an error
A metered, intermittent connection means the app gets opened without a network regularly, and not by accident. Someone checks the schedule on a train.
Decide which questions must be answerable from cache. In the student app, the home screen counts down to the next session, and the schedule leads with a next-session card carrying time, subject and location. That should never require a request: it changed hours ago at the earliest, and it is the most common reason to open the app.
Write the rule down for your own product — the two or three facts that must be readable offline, stored locally, shown with a quiet note about when they were last updated. A stale answer with a timestamp beats a spinner, and both beat an error screen.
What to cut
Parallax and scroll-linked motion, which are frame-rate problems by construction. Background blur, expensive to composite. Stacked shadows and large translucent surfaces. Autoplaying video near a first screen. Splash animations, on a device already slow to launch. Carousels of full-width photographs. Infinite scroll that loads images forever on a metered connection.
Web fonts deserve their own line. Two weights, subset to the characters you need, with a system fallback the layout tolerates. Four weights of a display face is a second or two of blank text, and blank text is the same as no app.
Skeleton screens deserve a second look too. One that ships more markup and animation than the content it stands in for has made the wait longer to make it feel shorter.
One check to run on your own product
Get hold of the cheapest phone your users actually own. Browser throttling models the network and not the device: it will not show you dropped frames, slow cold starts, or how the screen looks in sunlight at a bus stop.
Sign out, clear the cache, turn off wi-fi, and complete your product’s single most important task on mobile data in the evening, when the local network is busiest.
Time it, and count three things: taps you missed, screens blank for more than a moment, and points where you could not tell whether the app was working. Each is a specific fix — target size, image weight, or missing feedback — and none of them would have shown up on your laptop.
Constraints like these shape how we approach EdTech product design and SaaS product and dashboard design for Indian audiences, and a live product can go through our free 15-point UX audit, which covers mobile layout, tap targets and performance basics.
Questions we get asked about designing for entry-level phones
Should we build a lighter version of the app for cheap phones?
Usually not. A second version splits your team’s attention and the lighter one stops getting updated. Design the one product against the constraint instead: it makes the app better on expensive phones as well, which no separate lite build ever does.
What screen width should we design at?
Design the small layout first at around 360 points wide and let it grow. Starting wide and compressing produces screens where the content technically fits and nothing is comfortable, because the decisions about what to cut were never made.
How do we handle images we cannot avoid?
Serve them at the size they are displayed and no larger, use a modern format with a fallback, and load anything below the first screen only when it is scrolled to. Most image weight on a slow phone is a picture sent at three times the resolution it will be shown at.
Is dark mode better for cheap phones?
Only on OLED screens, and most entry-level phones use LCD, where dark mode saves nothing. Choose it for comfort and contrast if you want, but do not count it as a performance decision at this price point.
How do we test with users who have these phones?
On their devices, not yours, in the place they normally use the product. Bringing someone into an office with good wi-fi removes the two constraints you are trying to study.