In 2013, I designed the UI and UX for the largest web project I’ve ever been a part of. The design governs around 1800 pages of content (in the primary language); it’s also global, multi-region and multi-language. I was also responsible for designing the UI/UX for a Magento e-commerce instance of similar scope.
I worked independently on the design and made a lot of UX decisions beyond my pay grade at the time with minimal feedback or checking-and-balancing taking place. In short, there was no one else. It was at once extremely stressful and awesome on account of the freedom.
Now, to discuss some of the challenges I faced:
1. Designing for the space hog
If there isn’t a way around building text into your interface (navigation, for instance) build in enough space, or adjust the font in a way that will allow for the space-hoggiest languages.
2. Icons vs. Type
Example: Instead of aligning the word ‘Search’ next to/above your search box, consider one of two approaches:
- Remove the word altogether and use an icon.
- Pre-populate the field with the term – making sure that your search box is large enough to contain the longest translation of the word
Removing the descriptor altogether or including it inside of the field will save space and save you the trouble of gathering translations of the word Search in 12 languages.
3. Be aware of your language-based biases when choosing icons / typography
When using icons in place of words, conduct some user testing to make sure you are selecting symbols that are truly universal. When choosing font families, make sure they offer all of the characters you will need for the languages you need to support. This might mean only using system fonts in your style sheet or paying for a service such as TypeKit.
Examples: Is a shopping cart an applicable icon in developing countries? Which icon should you use to represent help?
As a rule, I try to use visual representation in place of text to avoid need to localize the interface, but there are several instances where an icon isn’t enough on it’s own to indicate clearly to the user. Be aware of these situations.
4. Change location mechanism should display current location
Looking back, this one seems obvious, but initially it was not. If your site requires that the user change their global location, the menu should probably display the current location as opposed to the menu identifier (Change Location/Choose Region).
In my example case, we used IP-based geolocation on the home page and we quickly found it to be less than 100% accurate (no surprise). In the first version the user was blind as to whether they had been placed in the correction region of the web site. I made a tweak in the first round or design improvements – see below:
5. Training: Involve bilingual stakeholders in the early stages of development
Training was a tough aspect of our web site roll out. The development company offered on-demand training, but on top of being very costly, the trainer’s knowledge only spanned a base installation of the content management system.
As our project was a highly-customized version of Typo3 the training wasn’t adequate. We only utilized this service to train our relatively small design group, the remainder of our learning was done through trial-and-error.
Beyond our small design team, however, we had a global marketing team of about 100 people who needed to be trained.
I have no previous experience in user training. Not to mention, I have several other responsibilities. Training small groups (the only method I found effective) remotely, in a language that was secondary to many of they key stakeholders was an exercise in patience for all parties. Having involved stakeholders who represented the major languages spoken by our employees in the development process would have been helpful in more effectively training the staff.
Key point: After some weeks of training small groups and straining my voice, I created a video tutorial library. This minimized the time cost for myself and was more efficient in transferring the basic knowledge. Furthermore, it helped to identify the team members who were truly invested in learning, as they came to me for more information after completing the video courses.
6. Date format is different around the globe
Just a simple note. Europeans date format is: DD/MM/YY – North Americans use MM/DD/YY. When you have administrators on both sides of the global – make sure everyone is aware of the chosen format. Date pickers (below) are helpful in avoiding confusion.
7. Training materials for your customers (multi-language)
In rolling out the global e-commerce instance, our team decided it was important to create short training videos in the major supported languages.
Our chosen method was to create them on-the-fly in English. Being the most well-versed on the system, I created the initial videos.
I used SnagIt to record my voice and on screen movements through the e-commerce shop. I simultaneously recorded myself on an iPad using Dragon Dictation (an app which automatically transcribes voice into text) to use as the basis for the “script” that my global counterparts used to re-record in their native languages using Audacity.
Finally, my co-workers sent me .mp3 and .wav files of their recorded translations of my original script and I synced them using Final Cut Pro X.
8. Post-launch support
Make sure that you have a solid agreement with your development company prior to beginning the project. Geographical limitations can lead to frustration when it comes to timely support.
Also, having an idea of the type of access you have to developers for improvements and in case of emergency is of extreme importance – especially if your web site is responsible for a large portion of your company’s sales.
9. Choosing a hosting location/strategy to minimize latency
My company hosts our website at our corporate headquarters in Cincinnati, Ohio. In the US, our website performs quite well despite making several requests on the server.
However, our European customers are still dealing with slow page load times based on latency (which is the amount of time it takes for the host server to receive and process a request for a page object).
There are several techniques you should employe in considering page load speed, including: front-end optimizations like bundling scripts together and using a Content Delivery Network (CDN).
Lastly, strongly consider the value of every element you add to a page. The fewer server requests any given page makes, the more quickly it will load for your users.