Website UX Checklist: 36 Checks for Websites in Nepal

A website UX checklist tests whether visitors can understand, use and trust your site on the phones they actually own. For Nepal, check a clear first screen, layouts that work at 360 px on mobile data, WCAG 2.2 AA basics, short forms, correct Nepali text and NPR prices, clear eSewa and Khalti steps, and visible contact details.

I am Ujjwal Rupakheti, a web developer and SEO specialist in Itahari. Every site I build goes through this list before launch, and I use the same list when I review someone else’s site in a UI/UX audit. It has 36 checks in eight groups, each with a clear pass rule.

The accessibility rules come from WCAG 2.2 on w3.org and the speed limits from Google’s web.dev. The Nepal-specific checks come from building products for Nepali users, and each one is tied to a real decision in a project you can open.

Why Does Website UX Matter More in Nepal?

Most web visits in Nepal happen on phones. StatCounter put mobile at 69.3% of web traffic in Nepal in October 2026, against 30.17% for desktop, and Android ran on 78.37% of those phones. A site designed on a large monitor and checked only on Wi-Fi is designed for the minority of your visitors.

The same StatCounter data shows how narrow those screens are. In October 2026 the two most common mobile screen sizes in Nepal were 414 by 896 pixels (12.67%) and 360 by 800 pixels (12.38%). So I design at 360 pixels first, then check that nothing breaks at 320, the width WCAG uses for its reflow test.

Connections vary too. A visitor might open your site on fast fibre in Kathmandu in the morning and on weak mobile data on a bus to Dharan in the afternoon. Good UX here means pages that still work when the network does not.

How Should You Use This UX Checklist?

Open your site on a real mid-range Android phone over mobile data, then go through the eight groups in order and mark each check pass or fail. Fix failures that block a sale or enquiry first, then accessibility failures, then everything else.

1. Pick your key journeys. For most sites: find a service, see the price, and send an enquiry or pay.
2. Use the right setup. A real phone first, then Chrome DevTools at 360 px with the “Slow 4G” network preset.
3. Score every check. Pass, fail or not applicable, with a screenshot of each failure.
4. Fix by impact. Anything that stops a payment or enquiry comes first.

1. Does the First Screen Explain What You Offer?

Within the first screen on a phone, a visitor should know what you offer, who it is for, where you work and what to do next. If they must scroll or guess, many will go back to the search results. Headings and short paragraphs then carry the rest of the page.

Check 5 matters twice: text in images cannot be read by screen readers, translated by the browser or quoted by search engines and AI answers.

2. Can Visitors Find Their Way Around?

Good navigation uses the words customers use, keeps the main menu short and puts help in the same place on every page. A visitor who lands deep in the site from Google should still know where they are and how to reach your prices or contact details in one or two taps.

On GuruSanga, a guru booking platform I built from a Figma design, the listing filters are plain links that work without JavaScript, so a filtered page loads and shares like any other page.

3. Is the Site Built Mobile-First for Nepali Phones and Networks?

A mobile-first site is designed for a small phone screen and an unreliable connection first, then enlarged for desktop. It never scrolls sideways at 320 pixels, keeps sticky bars out of the way and passes Google’s Core Web Vitals on mobile: LCP within 2.5 seconds, INP of 200 milliseconds or less and CLS of 0.1 or less.

Google judges these at the 75th percentile of real visits, so most of your visitors must get the good result, not just the ones on fast phones. My technical SEO checklist lists the usual causes and fixes for each.

Weak connections need more than speed. On Sajilai, handover videos upload in 4 MB pieces, so a dropped signal does not lose a 300 MB file. GuruSanga’s phone layouts were designed in Figma alongside the desktop ones, at 390 pixels, because most of its clients will arrive on a mid-range Android phone over mobile data.

Case study: GuruSangaA guru booking platform built from a Figma design, with phone layouts at 390 px and the full price shown before Confirm Booking.

4. Does the Site Meet the WCAG 2.2 AA Basics?

WCAG 2.2, published by the W3C in October 2023, is the current accessibility standard, and Level AA is the level most policies ask for. Six checks catch most of the problems I find: tap target size, text contrast, contrast of buttons and fields, visible focus, text alternatives and the page language.

The most common failure I see is light grey text on white. It looks calm in a design file and becomes unreadable on a phone held outdoors in the afternoon sun. The second is outline: none on buttons with nothing in its place, which leaves keyboard users lost.

Motion needs care too. WCAG lists turning off interaction animation as a AAA criterion, so it is not required at AA, but I treat it as standard. On Nimtto, my wedding invitation product, every 3D design has a still fallback and honours the phone’s reduced-motion setting.

5. Are Your Forms Short and Forgiving?

A good form asks only for what you need now, labels every field, opens the right keyboard on a phone, explains errors next to the field and keeps what the visitor typed. For most business sites in Nepal, a name, a phone number and a message are enough to start a conversation.

<label for="phone">Mobile number</label>
<input id="phone" name="phone" type="tel" autocomplete="tel"
       placeholder="98XXXXXXXX">

Small details remove a lot of friction. In Eknas, my loyalty SaaS for Nepali shops, reward codes are six characters with no look-alike letters, so nobody confuses an O with a 0 at a busy counter. Staff find a member by mobile number or by scanning the rotating QR code in the customer’s wallet.

6. Do Nepali Text, Dates and Prices Display Correctly?

Nepali text should be real Unicode in a proper Devanagari font, never letter-spaced, with enough line height for vowel signs above and below the line. Prices should use NPR with lakh grouping, such as NPR 1,50,000, and dates should show Bikram Sambat beside AD wherever your customers think in BS.

Mixed-script pages need a font stack that does the work for you. Put your Latin font first and a Devanagari font second; the browser uses the second one for any character the first lacks. Then format numbers with the browser’s own tools rather than by hand:

/* CSS: Latin font first, Devanagari font for Nepali characters */
body { font-family: "Urbanist", "Mukta", sans-serif; }
:lang(ne) { letter-spacing: 0; line-height: 1.7; }

// JavaScript: lakh grouping in English or Nepali digits
new Intl.NumberFormat('en-IN').format(150000)  // "1,50,000"
new Intl.NumberFormat('ne-NP').format(150000)  // "१,५०,०००"

Dates are where Nepali products earn trust. Nimtto shows each ceremony’s Bikram Sambat date beside the AD date, because elders read one calendar and relatives abroad read the other. A family can even override the BS date to match their priest’s patro. Sajilai’s PDF receipts write the amount out in lakh and crore.

7. Does Your eSewa and Khalti Checkout Explain Each Step?

A good checkout in Nepal shows the full total before payment, tells the buyer they will leave for eSewa or Khalti and come back, keeps the cart if they cancel, and only says “Paid” after your server has confirmed the payment. The return page must handle success, pending and cancelled payments clearly.

Both wallets send the buyer to their own page and back to yours. Khalti returns the buyer with a status of Completed, Pending or User canceled, and its documentation says to use its lookup API for the final check and to treat only Completed as success. eSewa sends a success or failure response back to your site and offers a status check API to confirm a payment. My eSewa and Khalti integration guide covers the code.

Two of my products show these rules in practice. A Sajilai vehicle page shows the total and the deposit before the renter signs in, and its Fonepay and NepalQR codes carry the amount already inside. GuruSanga shows the full price before Confirm Booking and gives every booking a short reference, such as GS-1001, that is easy to read out on a call.

Case study: SajilaiA car and bike rental marketplace with the total shown up front, QR payments with the amount inside and receipts in lakh and crore.

8. Do Visitors Trust the Site Enough to Contact You?

Careful buyers in Nepal look for proof before they call: a price or price range, a phone and WhatsApp number, a real address with a map, real photos and genuine reviews. If they cannot find these quickly, they leave to ask somewhere else. Make each one easy to find and easy to tap.

Never invent reviews or ratings. Sajilai only lets renters who completed a trip write a review, so its ratings come from real rentals, and a business that asks for the verified badge has its PAN or VAT registration checked first.

How Do You Run a Quick UX Test with Five Users?

Give five people who match your customers three to five real tasks on their own phones, ask them to think aloud, and watch without helping. Note where they hesitate, misread or give up, fix the biggest problems, then test again. Jakob Nielsen’s research found that a first study with five users finds about 85% of usability problems.

1. Write tasks as goals. “Find out what a two-day car rental costs and ask about it”, not “Click Prices”.
2. Pick five real users. People who match your buyers, on their own phones and their own mobile data.
3. Ask them to think aloud. Record the screen with their permission, and do not explain anything.
4. Note every stumble. Each pause, wrong tap, question or give-up, with the screen it happened on.
5. Count and fix. Problems that three or more people hit go first; make the changes.
6. Test again. Five new people, to check the fixes and find what was hidden behind them.

Nielsen recommends spending a testing budget on three studies of five users rather than one big study. If your site serves two very different groups, such as buyers and sellers, test three or four people from each group instead.

UX Checklist, UI/UX Audit or Usability Test: Which Do You Need?

Use this checklist yourself before launch, a UI/UX audit when you want an expert to find and rank problems, and a usability test when you need to see how real customers behave. They answer different questions, and many sites benefit from all three at different times.

If you would rather have it done for you, my usability audit in Nepal runs these checks on your key journeys and ranks every issue by severity and effort. For a new site, UI/UX design is included when I build it as your web developer in Nepal, for clients in Itahari, Kathmandu and abroad. Every starting price is on my services page, and if a new design is part of the plan, read how to handle a website redesign without losing SEO.

About the author

Ujjwal Rupakheti

I am a full-stack web developer and SEO specialist based in Itahari, Koshi Province, Nepal. I have worked in web development and SEO since 2022 and have published more than 200 SEO-optimised articles across five-plus domains. Since June 2026 I have been a full-stack web developer at Ektukra Digital Agency, after a year there on SEO content strategy and QA testing.

Author profileAbout meCase studiesLinkedIn