Okay I lied.
This isn’t really a guide. And it’s certainly not going to be frustration-free.
This is a catalog of issues we’ve experienced at dli5 when designing Urdu apps.
More truthfully, it’s a cry for help.
By documenting these problems and workarounds in one place, my hope is that those starting out in Urdu design don’t have to go down the same dead-ends that we did.
1. Choosing the right tool
When picking a design tool, the general advice is usually to be tool-agnostic.
No such luxuries here.
Take Figma, for example.
It’s lightweight and (mostly) free, meaning there are virtually no barriers for anyone with a web browser to get started in design — an important consideration in Pakistan, where many people cannot afford paid software.
But Figma’s support for right-to-left (RTL) languages — including Urdu — is severely limited.
For starters, if you try to type Urdu text in Figma, you get this:
Do not adjust your screens. That is indeed a picture of…nothing.
Because nothing happens. You can’t see the text.
That’s because you need to install an Urdu font first.
Once you do that, you get this glorious mess:
In case you can’t tell, it’s supposed to say میں اردو لکھ رہا ہوں۔ / mai Urdu likh raha hoon.
Besides the obvious problem of the letters being disconnected, the more observant will have noticed that they’re also reading left-to-right instead of right-to-left.
So then you install a right-to-left plugin and things get a little better:
You can almost make sense of it now.
Turns out it really depends on which font you use, and each comes with its own quirks and frustrations when interacting with Figma.
Adobe XD — another popular and free(ish) tool, doesn’t fare much better.
What to do about it
Update: Figma has added right-to-left support as of March 2022.
Clunky workarounds — including more plugins — exist, but are unreliable; and for any project of some complexity, it’s a slow and laborious process.
For our designs, we had to switch over to Sketch.
Given that Sketch has a paid subscription, and only runs on macOS, this is hardly encouraging news for accessibility in Pakistani design.
2. Choosing a script
Naskh — the Arabic script — is the predominant choice in much of the design world, as it works well across platforms, font sizes, and apps.
Nastaliq — the Persian script — is what most Urdu readers are accustomed to, but does not fare well at the first hint of complexity.
Here’s what they look like:
In Pakistan, the vast majority of newspapers, books, pamphlets, and signboards are written in nastaliq.
For a population accustomed to reading nastaliq, the naskh font is often harder to parse.
So given the prevalence of nastaliq in Pakistan, it would seem to be the obvious choice when designing in Urdu.
But most nastaliq fonts don’t play nice with Figma or Adobe XD.
You can see how the nastaliq fonts tend to end up in a garbled mess, while naskh fares better.
The other issue with nastaliq is that its primary characteristic — round, loopy letters — does not go well with vertical line spacing.
Ascenders and descenders — the parts of the letter that rise above or fall below the line — cause major headaches when they clash together in nastaliq.
Here’s what happens when the vertical line spacing does not accommodate for the ascender-descender interaction:
Naskh takes care of this by using evenly-spaced letters that ‘flatten’ the ascenders and descenders.
Here’s the same tweet in naskh:
The adaptability of naskh in digital products means it is often the default choice when designing in Urdu, despite the prevalence of nastaliq in Pakistan.
This is usually not a big problem for single-word or single-line text.
Here’s Bykea using naskh for their buttons, for example:
But across larger pieces of text, there is usually a significant difference in reading speed and comprehension depending on which script you are used to.
Compare the two scripts below:
If there is to be more complete Urdu-only interaction across the web, it is important for nastaliq to be fully supported. Otherwise you get problems like this:
What to do about it
Increasing the vertical space between lines helps, of coure, but this is often not possible at system-level, and also uses up valuable real estate on smaller screens.
From our experience, the only way is to be hyper-vigilant about testing your design across devices and at various font sizes. Even then, there will always be plenty of cases where it will just not work.
WhatsApp (and other Facebook apps) have done a decent job of this — and I’m not entirely sure how.
Compare this text in the iOS composer…
…with what happens after you send the message:
That comfortable, readable vertical spacing is not an accident.
Another less-than-ideal workaround is to convert your text into images. We’ve found that this is okay for limited use cases such as buttons, where scalability across different screen sizes isn’t much of a problem.
Or you can switch to naskh; which, while serviceable, forces millions of Urdu readers to adapt to the technological constraints, rather than have the technology improve to adapt to their needs.
3. Creating hierarchies
On an English interface, designers are used to establishing a hierarchy of information using formatting options:
Headings in bold, or for emphasis
Some regular text
Italics to indicate secondary information
In Urdu fonts, these formatting options are rare or missing altogether — partly because of technological limitations, and partly because options like italics don’t seem to be part of the script’s tradition in the first place.
What to do about it
Information hierarchies can be established using a range of different font sizes — more so than what you’d use in an English interface.
In our work, we’ve also relied on colour to distinguish different types of information.
As an example, compare the Urdu newspaper Jang with its English counterpart Dawn:
Jang has used a much wider range of font sizes and styles, and contained information in blocks of various colors: white, black, light grey, dark grey, green, and red.
Dawn, by comparison, is pretty uniform and monochrome.
4. Using Roman Urdu
One workaround to many of these issues is to use Roman Urdu: phonetically spelling out the words using Latin letters (i.e. “kya haal hai?” instead of کیا حال ہے؟ ).
The trade-off here is accessibility: depending on who you’re designing for, they may not be able to read the English letters at all.
Then there’s the issue with standardization.
Consider this prompt:
“Are you sure you want to transfer 1500 PKR to this contact?”
I asked several of my friends how they would translate this in Roman Urdu. Here are the results:
Note the variety of different translations. For example, ‘contact’ has been translated as contact, banday, jannay waalay, shakhs, number, and account.
Then there’s the range of spellings used for common words: we have ap and aap; chahtay and chahte; bejhna and bhejna.
When interacting with friends and family, we learn to adapt to everyone’s unique typing styles with Roman Urdu. But when designing a product to be used by millions, which words and spellings would you use?
In my experience, long chunks of text in Roman Urdu, in a spelling variation that is unfamiliar to the reader, can significantly hinder reading and processing speeds.
What to do about it
I’m not sure, to be honest.
If your users are able to read Roman Urdu, I think short messages are okay depending on the use case (such as SMS alerts).
Beyond that, this is a problem worth cataloging for awareness purposes. The bare minimum is to at least test the copywriting with your users to see if it makes sense for them, not just for you.
Interestingly, in our testing we found that most users — even those who couldn’t read English or Urdu, were still able to read Roman numerals, and sometimes even preferred them to Urdu numerals. They were able to recognise things like rupee amounts, dates, times, and phone numbers with no problems.
5. Going back — or forwards?
A mildly amusing design problem when working right-to-left is thinking about where to place the ‘Back’ button.
On a standard English interface, the back button is usually in the top-left corner:
But when you switch your phone language over to Arabic, the back button swaps over to the top right:
But most phones in Pakistan tend to have English as the phone language — even when the user does not understand English.
So when you make an Urdu app that runs on an English phone, do you swap the position of the ‘Back’ button?
If you do, you place the button in the top right, as with Arabic:
But now you have to contend with breaking users’ mental models: the ‘back’ button is in the top left for every other part of their phone, except your app.
And if you don’t swap it, then the interface seems counter-intuitive:
After reading the word ‘peechay’ from right-to-left, you are pressing an arrow that is pointing forwards in context.
What to do about it
In our work, we leave it in the top-left because that’s what’s most common and what worked best for our specific users. It’s also more intuitive on older Android phones that have dedicated back buttons:
Here’s what happens when you don’t consider how changing the directionality also changes the flow of your menus:
Daraz has transposed their Urdu menu onto the original English menu; so while the Urdu text reads right-to-left, the menu still expands left-to-right.
6. Typing in Urdu
Everything I’ve mentioned so far has been about reading Urdu.
But typing in Urdu is a whole different beast.
Many users prefer reading in Urdu but typing in English — simply because it’s easier and faster than fiddling around with an Urdu keyboard.
Some apps are entirely in Urdu, but typing anything in English inevitably breaks something in the interface — and God forbid you try to type English and Urdu together in the same message.
While you may do an excellent job designing an app that Urdu readers can read, they may not be able to interact meaningfully with it if it requires a significant amount of written input.
What to do about it
Efforts are being made to improve the Urdu typing experience, including the Matnsaz Urdu keyboard. But there remains a disconnect between reading and writing.
I personally don’t think there’s going to be wider acceptance of Urdu typing any time soon. But if the underlying problem is simply enabling meaningful user input, there’s a couple of workarounds we’ve used.
One is to use audio input. In our fieldwork, we’ve often observed WhatsApp users with chat threads that consist entirely of voice notes. So we’ve tried including audio components in our designs (Bykea does this too); but audio input is a technical challenge that does not scale well for most tasks.
Another option is to try and capture as many closed-input scenarios as possible. Populating them as a list — with pictures, ideally — means people can tap options instead of having to type or search for them.
The USSD interface is based on a similar philosophy: using the *786# commands on your phone and inputting your options as numbers helps overcome typing challenges.
Good luck on your journey into Urdu design — I sincerely hope that this piece will make it a little less frustrating for you than it was for us.
And if you know of any solutions I’ve missed, please reach out and I’ll be happy to update the article. We’ll probably have lots to talk about anyway.
Here’s a case study on how we’ve used some of these principles to design Muawin, a financial app for low-literacy users.
And here’s a whole bunch of resources I’ve compiled for designing in Urdu (amongst other UX stuff).