Contents 8 sections · 6 min
We design every site at 390 pixels wide before anyone sees it on a laptop. Not because desktops do not matter, but because the visitor who decides whether your business gets the call is holding a phone, on a bus, on prepaid data, with the sun on the screen. This is what that visitor’s phone is like, and what we do about it.
The phone in their hand
In our experience the typical visitor to a Bhutanese business site is on a mid-range Android, a Samsung A-series, a Redmi, a Vivo or an Oppo, that is one to three years old. iPhones are common enough in Thimphu to matter and rare enough elsewhere that they cannot be the baseline. The phone has a screen around 390 logical pixels wide, a processor that is fine until a page throws a lot of JavaScript at it, and storage that is nearly full.
The connection is 4G from TashiCell or B-Mobile, prepaid, bought in data packs. That last part matters more than the speed. A visitor on a data pack notices when a page eats 8 MB, because they paid for it. Office Wi-Fi in Thimphu hides all of this from the people who commission websites, which is why so many sites in Bhutan are built for the wrong device.
Start at 390 and stay there until it works
The first design of every page is a 390px column. Every decision, what comes first, what the headline says, where the phone number is, gets made at that width. Only when the page works on the phone do we widen it.
This is the opposite of how most sites get made: designed on a 27-inch monitor, then squeezed. Squeezing produces the familiar failures. A hero image that fills the screen and says nothing. A menu with 12 items behind a hamburger. Three columns that stack into a page that scrolls for a minute. A phone number in the footer, three screens down.
At 390px there is room for one idea per screen. That constraint is the best thing about designing for phones. It forces the business to say what it does in the first sentence.
Tap targets and thumbs
A thumb is about 44 pixels wide on the screen. Every button, link and form field needs at least that much room, and needs space between it and the next one. Links inside a paragraph are fine; three small icon buttons in a row are not, because the visitor hits the wrong one and does not know why.
We keep the things people actually tap, call, WhatsApp, directions, opening hours, at the bottom of the screen where the thumb rests, not at the top where it has to stretch. Forms use native inputs at 16px, so the phone does not zoom in when a field is tapped, and labels sit above fields, always visible, never floating away.
The visitor is not reading your site. They are looking for the one thing they came for, with one thumb, in the sun.
Image weight is the whole budget
On nearly every business site we audit, images are more than three quarters of the bytes. A page with six 3 MB photographs straight from a camera is an 18 MB page, which on a prepaid data pack is not a page, it is a decision to leave.
What we do instead:
| Practice | Effect |
|---|---|
| Resize to the size it is shown | A 390px-wide photo does not need 4,000px |
| Serve WebP or AVIF | Roughly half the bytes of a JPEG at the same quality |
Provide several sizes with srcset | The phone downloads the small one, the laptop the large one |
| Lazy-load below the fold | The first screen arrives before the gallery |
| Reserve the space | No jumping while images load |
| One good photo, not five average ones | Fewer bytes and a clearer page |
A first page under a megabyte, images included, is our usual target. It is achievable for almost any business and it is the single biggest thing that makes a site feel fast in Bhutan.
Text that does not depend on scripts
A surprising number of sites show a blank screen until a large bundle of JavaScript has downloaded and run. On office Wi-Fi with a fast laptop this takes a moment. On a mid-range Android over 4G it takes long enough that the visitor assumes the site is broken.
We build pages as plain HTML first. The text, the phone number and the WhatsApp link are in the page before any script runs. Scripts add things, a menu that slides, a form that validates, but nothing the visitor needs is behind them. If the connection drops halfway through, what has loaded still works.
This also decides what platform we recommend. WordPress with a light theme, or a static site, both produce plain HTML. A site built entirely in a JavaScript framework can be made fast, but it takes real care, and most of the ones we inherit did not get it. See how much does a website cost in Bhutan in 2026 for how platform choice shows up in the price.
Patterns for a flaky connection
Bhutan’s mobile coverage is good in towns and uneven between them. A site cannot fix that, but it can be forgiving.
- Keep what loaded. A page that renders its text first stays readable when the images never arrive.
- Do not lose the form. If sending fails, keep what the visitor typed on screen with a plain message, so they can try again or copy it into WhatsApp.
- Cache the shell. For sites people return to, a small service worker can keep the pages they have seen, so the second visit works on the bus.
- Small pages, many of them. Ten pages of 300 KB beat one page of 3 MB, because each one is a smaller bet on the connection holding.
- Say what is happening. A button that goes quiet after a tap looks broken. A written “Sending…” costs nothing.
None of this is an offline app. It is a website that behaves well when the signal drops for ten seconds, which happens between Thimphu and Paro every day.
The one-tap rules
The purpose of most Bhutanese business sites is to produce a phone call or a WhatsApp message. So the phone number is a tel: link that dials on tap, the WhatsApp button opens a chat with the number pre-filled, the address opens in Maps, and all three are reachable without scrolling on the first screen and again at the bottom of every page. If the site does nothing else, it does that.
How we check
Before launch we open the site on a real mid-range Android, over mobile data, with Wi-Fi switched off, and we time the first screen. We check every tap target with a thumb, not a mouse. We fill in the form on the phone. We load the heaviest page on a TashiCell connection in a car park. If any of that is slow or clumsy, it is not done.
This is part of our UI/UX design and WordPress development work, not an extra. If you want to see how your current site does, open it on your own phone with Wi-Fi off, and count the seconds until you can read the first sentence. That number is what your customers see.
Q&ABefore you ask
Questions people ask
Q1 Should I design for iPhone or Android?
Both, but test on Android first. In our experience most visitors to business sites in Bhutan are on Android phones in the mid-range, with iPhones a meaningful minority in Thimphu. A site that works on a three-year-old Android over 4G works everywhere.
Q2 What is the right page weight for a site in Bhutan?
As light as the content allows. We aim for a first page under a megabyte including images, and the images are nearly all of it. Every extra megabyte is prepaid data the visitor paid TashiCell or B-Mobile for, and a few extra seconds before they see anything.
Q3 Do I need an app instead of a website?
Usually not. An app has to be found, downloaded and updated, and it uses storage on phones that are often full. A fast website works from a link in WhatsApp with nothing to install. Build the app when you have a reason the website cannot serve, not before.
Q4 Why 390 pixels?
It is the logical width of the most common phone screens in use, from mid-range Androids to recent iPhones. Design at that width and the layout holds on nearly everything; design on a desktop and shrink it, and something always breaks on the phone.