“Tell me more about that” is a standard phrase used by usability professionals to elicit information from users when gathering requirements before designing a solution. The question’s probing, open-ended nature is the very essence of an iterative, user-centered exploration that makes for building a great user experience (UX).
For enterprise applications (used for enterprise resource planning or customer relationship management functions), understanding how workers accomplish tasks distinguishes UX from usability’s traditional emphasis on user interface (UI) layout, look and feel. At Oracle, we say that applications UX is about how you work, not about how you click. Using a range of disciplines, a UX team delivers thoughtfully designed solutions that reflect anything of importance used to complete a task. This broad consideration we can usefully refer to as context of use: the core of successful user requirements gathering.
Context of use varies by enterprise location, country, region, culture and so on, nuanced by worldwide trends. Business must reflect this. Intuit’s founder Scott Cook, explaining Intuit’s failure to expand globally, highlighted not taking local UX requirements into account in a video on Inc.com: “We didn’t build our products based on a deep study of the countries. We built them based on what we had in the US. I kicked myself. We should have known better.”
The challenge for makers of enterprise applications is to uncover how local users work, and then bring a compelling UX to life in a single globalized software application. That means working from code meeting internationalization standards; translating the application; providing localization capabilities — in the enterprise sense of reporting, compliance functionality and so on; facilitating customers to implement applications to reflect their business processes; enabling the customization and extension the applications; and helping individual workers to personalize their UX.
Context of use demands that no assumptions be made about how people work. Instead, UX teams perform research on real workers performing real tasks, experiencing real interruptions and relying on real assistance, all in real work environments, be they at home, in the office or on the go. Generalized best practice usability guidance read on the web must be validated for enterprise applications suitability by testing with user groups in a reliable setting.
UX context of use versus conventional localization wisdom
Take the widespread localization guidance about the dangers of portraying body parts in icons. That was reasonable as a general principle in the past, but years of business globalization, the influence of the internet and worldwide social media use has changed notions of what is acceptable in the stuffy old world of work.
So, the “thumbs up” icon (Figure 1) often seen in social media is now widely accepted as meaning approval in an enterprise context too, where many tasks performed are inherently social. Using that human-based gesture in the context of the streets of Bangladesh, Iran or Thailand is a different matter.
Some icons may remain associated with actions even when the iconic inspiration has long since faded. What remains universally recognized is the metaphor behind that icon. Scandinavian applications customers may be bemused at a 3.5-inch disk icon used for the save command and refer to it as the washing machine, but they know what that icon means and how to use it.
Exploring the concept of context of use may begin with the National Institute of Standards and Technology (NIST) Common Industry Specification for Usability — Requirements (CISU-R) document. The NIST CISU-R was created to help website developers, usability professionals and IT implementers to define usability requirements for their projects. CISU-R defines context of use as “The users, tasks, equipment (hardware, software, and materials), and the physical and social environments in which a product is used.”
Context of use provides information on intended use of the product or service. CISU-R does not specify product globalization requirements or methods, although it does refer to nationality and culture. The CISU-R underlying compliance for user requirements gathering provides for seven context of use areas. Adding local UX examples illustrates how context of use varies by location.
Stakeholders, for example, are end users and all parties who have a legitimate interest in the product throughout its life cycle. For a financial accounting application, the stakeholders might include the external auditors, taxation authorities and other functional departments in the company, as well as the accountants.
Naturally, the list of stakeholders varies even for the same application in the same enterprise, if located in different parts of the world. Labor unions, employee forums and work councils (such as the German Betriebsrats) may need to be involved in the design and deployment of new technology. How people are organized in work determines what features may be used, and when. Requirements stakeholders for globalized applications might include internal localization departments or external translation vendors too. The error of omitting a key stakeholder is costly. For instance, applications requiring hotel maintenance teams to scan bar codes in rooms need the housekeeping department stakeholder involved in case they clean such codes away.
The main user groups critical to the business or those who use the application most often are the intended user groups. This aspect to context of uses most usefully covers the globalization aspects for applications. What languages do workers use, but also what is the language of the business? Are users working in an international company with regional offices or country-based subsidiaries? A multinational operation may use many local languages, with English or French as its core business of language. The UI too must be localized to reflect locale formats and business information. Consider what information in what format is to be exchanged between parts of globalized operations and other external parties.
Be wary of the claim that “everyone speaks English.” Workers understand domain-based applications terminology more easily in their native languages, even if they can converse in English. Public sector procurement would require translations or certain terminology be used, for example, by the Office québécois de la langue française. Starbucks in Québec is known as Café Starbucks Coffee. KFC is PFK (Poulet Frit Kentucky). The Australian state of Victoria recommends creating a language profile for workforces to facilitate compliance with health and safety requirements.
Look at the main goals for each user group. Again, this may vary locally as people do not all work or behave the same way, even within the same corporation, and business processes and rules may impact goals. Accounts payable clerks may have a goal of avoiding data entry errors, but expenses policies and how expenses are processed vary by country and business process. In some countries, hard copies of receipts must be submitted, and in other places scanned files are permissible. In others, itemized receipts must include named individuals at business meals and so on.
It’s also important to study the intended computing or other technical environment. This might cover everything from the national broadband provision or wireless connectivity to availability of particular devices, applications or services in a country to identifying the locale-based paper printing sizes (US letter versus A4 in the United Kingdom, for example).
Mobile solutions based on expensive devices, native apps and heavy data consumption may not be appropriate in some countries or regions. The BBC World Service uses applications for Nokia feature phones, not smart phones, to provide localized news content for listeners in emerging markets. In some countries, users may prefer to send SMS text messages instead of making expensive phone calls or sending images because of cost. Technical requirements may include availability of language technology-related features such as translated versions and tool support. Is there natural language processing support for your voice or avatar-based application?
The worldwide phenomenon of Bring Your Own Device (BYOD) represents a classic context of use exploration. Consumerization of information technology, largely driven by mobilization, sets new expectations about what devices and apps are used to perform business tasks and when, driving a very high quality of enterprise UX overall. Workers might personally enable corporate-owned mobile devices with their own apps used in a private capacity (LinkedIn, Twitter, Facebook and so on) as well as work-provisioned apps to complete business tasks, for example. BYOD is subject to requirements that vary by enterprise but also by country or region, reflecting cultural, social, and political factors. Workers may value leisure time differently by culture and need to “switch off” in different ways.
Intended physical and social environments covers physical location (remote or office-based work, for example); ergonomic factors such as lighting and temperature; organizational aspects concerning how workers are managed or supervised; health and safety issues; financial or security risks; and so on.
An insightful video from Human Factors International (HFI) about cross-cultural design illustrates how medical device design may be influenced by attitude of the local caregivers, their literacy levels, water quality and even climate. “The only solution is to design for the local customer’s ecosystem and the local customer’s feelings!” says HFI’s Apala Lahiri Chavan, explaining how the design for a banking solution in India’s hierarchical, caste-based society led to user rejection when applied to less stratified African markets. Local health and safety regulations in some jobs may require use of gloves so think about those pinch features on mobile devices. Very secure enterprises or public sector or government agencies may prohibit the carrying or use of personal devices or applications or any integration with cloud or third-party applications. Remember, using mobile phones while driving is against the law in many places, so designing for headset and audio notifications, and other multimodal usage is required for mobile workers.
Scenarios of use illustrate how users carry out their tasks in a specified context. These scenarios describe how users meet their goals. They tell the story about a day in the life of workers’ activities, their motivations and how they use the product to complete work tasks. A mobile application for insurance company risk assessors based on availability of property owners to interview, and optimized for entering structured data and minimizing manually typed in text suits UK workers. But do all risk assessors work the same way internationally, or by type of property? Could voice entry, cameras or scanning in of details be a UX solution in other places?
Where required, prerequisite documentation or training materials specifies what user assistance materials are provided and for whom. Considerations here include localized materials and the internationalization enabling of delivery technology. Learning experiences may also vary. The evidence from the enterprise space suggests that expertise level is the key learning differentiator for users rather than nationality (or other dimensions), though some localities might react differently, so research is required. Coca-Cola Bottling used Angry Birds to move their workforce to an iPad-based working environment, but could this onboarding strategy transfer to every country? Solutions need to reflect what is appropriate for the culture and users. Law may even enforce training requirements. The US Occupational Safety and Health Act (1970) requires training to be provided in a language that workers understand.
Language professionals and other non-UX experts may also gather user requirements or contribute to such efforts. The task doesn’t require special resources, expertise or techniques, and once representative workers and their work environments have been located, the process can begin. Gathering requirements and exposing their context of use means engaging with users where and how they work (Figure 2), and observing and recording their activities as they go about completing tasks, while asking users to explain or to tell more about their thoughts and actions.
Observation of even the humblest item’s use is a major UX opportunity. A Post-it note attached to a PC screen might mean a recall failure for a feature, a need for organized information or a collaboration requirement (the note being used to pass information to a colleague). Perhaps it is just a hot date. It depends on the context of use.
Researching mobile workers in different parts of the world might reveal variances in UX requirements such as headset use (a legal or consumer preference); number and types of devices carried; preference settings (vibration versus audio notifications); methods of communication (using SMS distribution lists instead of e-mail); use of device features such as cameras or bar codes as determined by laws, technical environment or cultural convention; whether electronic wallet solutions are used for payments; and so on.
Real local users
Rely on local knowledge to find real representative workers to start the user requirements process. In enterprises, such workers might be selected through works councils, labor unions, departmental managers or human resources. Suitable subjects might be approached through international user groups and user communities, conferences and other events. Subsidiaries’ sales, marketing and support organizations will also know where to find companies and users to gather representative requirements. In some cases, specialist in-country agencies may be employed to source representative worker and role scenarios.
Crowdsourcing for information in the enterprise space is not without problems as expertise and representative tasks are critical to reliable and valid UX research, but subjects with the right characteristics may be found from the community when acknowledged as reputable by other members.
Screening for potential users and companies helps focus the context of use. Having access to professional UX user profiles and personas helps, but relying on the source material of real users doing real tasks in a real environment is as good a start as you need.
Language professional insight into local markets, trends, and access to resources and information is a rich resource to mine. Translators and interpreters are sometimes required too when nonlocal researchers conduct usability studies with local users in the wild. By participating in UX requirements gathering and later stages of the user-centered design process, language professionals have an ideal opportunity to proactively identify translation issues, and to start the terminology development, especially important in the enterprise space where specialized domains abound. Knowing context of use is a powerful insight for language professionals, enabling the delivery of a quality local product reflecting the domain and what users really require.
As a best enterprise applications practice, it’s important to design flexibly, with internationalization, localization, customization and personalization in mind, enabling multimodal and fallback solutions where necessary. Always provide for scalability, migration of solutions and continuance of business in the enterprise, whether workers are in the office, on the street or at home. Consider these local stories:
In Germany, Volkswagen agreed with the company’s works council to not send e-mails to employees’ BlackBerries outside of work hours. Henkel agreed to a Christmas and New Year period amnesty for work-related e-mail.
Irish mobile users found that SMS texts in Gaeilge cost more than in English due to the síneadh fada diacritic. Users were charged for the equivalent of three English text messages if they included a single síneadh fada in a text of 160 characters. It is cheaper to send a digital image.
In Africa, dual SIM mobile phones enabling users to use different SIM cards from one device deals with variances in network coverage and roaming costs. Broadly, the approach is ideal for reducing the number of devices carried as well as providing separate numbers for regional use or user roles.
Apps for Islamic users and locales need features to support customs and rituals such as those relating to Ramadan. For example, Oracle E-Business Suite supports the Hijri calendar. The BlackBerry Call to Pray app features support prayer times, Qibla direction, Athkar and Hijri calendar, with real-time prayer timings and sharing through BB Messenger, SMS, e-mail and Facebook.
A security ban by the Indian government on bulk SMS and MMS use at times of unrest led to a surge in uptake of mobile messaging apps such as WhatsApp and Nimbuzz. Telemarketers switched usage habits accordingly.
Knowing local user requirements is an investment that yields high return on investment not only for language and UX professionals and ultimately users, but entire businesses. What you find in one market may yield major innovations and insights for others. Kenya’s M-PESA (Figure 3) simplified mobile money transfer solution has inspired mobile banking innovation to reflect context of use in more developed markets.
Language is part of UX. But cultural convention, local business and personal practices and technical and other environmental factors also need to be taken into account. Gathering user requirements and exploring context of use is not rocket science. Existing tools, resources and knowledge make it all very doable even for small companies or individuals. If you are a language professional, then offer your services to UX designers and IT implementers for gathering requirements. If you are a designer or UX professional, then reach out to that language person. The “Tell me more about that” type of information gathering removes the risk of the dreaded “But, all I wanted was . . .” UX feedback from the post-application implementation of the product life cycle. A true skill is bringing language and UX expertise together to focus on the design problem, referring back to the context of use to remain focused on the issue. Only when the problem is removed for the user can design said to be truly done. Ultimately that accomplishment must be proven by usability testing with real people, performing real work tasks in real settings.