Ever wonder about how good people are at understanding and using technology? It’s worse than you probably think. So says a study recently published by the Nielsen Norman Group (Evidence-Based User Experience Research, Training, and Consulting). I suggest that anyone having to do with the making and localization of software take a look at this compelling and well written abstract: https://www.nngroup.com/articles/computer-skill-levels/
The short version: Across 33 rich countries, only 5% of the population has high computer-related abilities, and only a third of people can complete medium-complexity tasks.
The study breaks down user abilities into 3 distinct levels of task performing proficiencies, plus an additional sub-level of “can’t use computers”. The data was collected from 2011–2015 in 33 countries and was published in 2016 by the Organisation for Economic Co-operation and Development, a club of industrialized countries. In total, 215,942 people were tested, with at least 5,000 participants in most countries. Don’t worry, If you’re reading this, you’re probably in level 3.
If you add language or cultural formatting issues into the equation, it’s a safe bet that skills would skew in an even more negative direction. Poor user experience, for which localization is a considerable factor, makes for bad business. It raises sales and support costs, decreases user loyalty, and can reduce or even nullify competitive advantages.
My personal evidence from running a company that provides enterprise software is that even with technology savvy clients, plenty of people working in positions demanding computer proficiency don’t necessarily have the skills you’d think they should. Inevitably, misunderstandings happen. It’s very easy to overestimate user knowledge skills.
In working with many software companies over the years, we’ve seen that developers don’t necessarily understand internationalization and localization issues – even if they get the basics. For example, You can instruct developers to always externalize strings, only for them to externalize sentence fragments that they later concatenate programmatically. As word order, word gender and pluralization rules change, concatenation methods that worked in English will instead produce garbled and nonsensical sentences.
As another example, Calendar classes might not be provided with locale information. Or a font that won’t work in Chinese may be embedded. There are tons of issues like this, many that are difficult to find in testing. The whole process becomes more complicated and impactful when you have multiple teams that may be distributed over geography driven on fast moving deliverables.
Our customers agree, it’s important to continuously check software as it’s being written for internationalization (i18n) issues. Likewise, integrating ongoing localization (L10n) automation into developer workflow is imperative. Otherwise you fall behind, bugs get lost in testing, or worse – problems fall into a black hole backlog. You get a better product and user experience, in less time and less hassle if you make i18n & L10n an automatically measured, managed and visible part of each sprint and release.
Follow-up Reading on Continuous Internationalization and Localization
To read more about what continuous internationalization and localization systems can mean for your software development, download our free Continuous Globalization white paper: https://lingoport.com/continuous-globalization-whitepaper/.
To learn more about the Lingoport Suite, including Globalyzer, Resource Manager and Dashboard, please visit https://lingoport.com/products. Check the wiki links on that page too: wiki.lingoport.com
