Application Envisioning idea
K1.

Product teams can envision support in their application concepts for individuals from different cultural backgrounds. Targeted knowledge worker populations can have different wants and needs for the linguistic, symbolic, layout, and procedural aspects of their computing tools.

Examples from three knowledge work domains:
(Illustrated above) An architect from Seattle is using a different computer during a visit to the Beijing office of her firm. She is pleased to learn that she can change the language from Mandarin to English in her own view of their shared building modeling application. This does not change the text of the informal notes that her Chinese colleagues have entered into design files, but it does allow her to navigate the application’s interface labels in her native language.
A financial trader from New York, visiting the London office of his firm, finds that UK traders have set up their shared trading application to display their preferred spelling, time, and date standards. They have also added a number of UK specific fields in their standard trading forms that are not needed in the US domestic market.
A scientist in San Francisco sends a clinical study file from her analysis application to a German colleague. She takes for granted that when her colleague opens it, the study file will be viewable in the localized, German language version of the software.
Many types of contemporary knowledge work are practiced in a number of global locations (A1), potentially driving a variety of application localization requirements. Even within a single customer organization, there can exist a diverse array of localization wants and needs.
Many product teams take for granted a certain linguistic and representational perspective when creating their computing tools. And, from within the influences of globalization, targeted workers may be familiar and somewhat comfortable with the experience of interpreting interfaces in a non native language (D2).
When a team does not wish to push their cultural frame onto their potential users, or cannot afford the impact of such a decision on their product’s brand, they can envision localization approaches and functionality concepts based on targeted understandings of their intended audiences. While the languages available for display in an interface are often the most important localization factor (B1, C8), localization of symbolic content (F, K5), screen layout (C2, C4), and support for local variations in knowledge work practice (A7, A8) can also be crucial.
When product teams do not actively consider potential localization requirements for their application concepts, opportunities to be competitive in a broader range of markets (M4) may be lost. Knowledge workers in markets outside of a resulting product’s originating region may face longer learning processes (D7, K2, K6) and a higher rate of errors (C9, G3). Additionally, teams may find it difficult to retrofit localization needs in
a post hoc way due to their extensive, often structural, nature in interface design.
Conversely, intensive localization may negatively impact representational coordination and common ground between a product’s audiences (F1, J2).
See also: A, C, G6, I, J6, K, L4, M

Application Envisioning questions:
In what localization intensive markets might your team be striving to provide a viable and desirable computing tool for knowledge work? In what localization intensive markets might your team be striving to provide a viable and desirable computing tool for knowledge work? What aspects of your application concepts could benefit from early envisioning around targeted local wants, needs, and opportunities?
More specific questions for product teams to consider:
What global markets might your team be targeting with your application, based
on your emerging ideas about product strategy?
What impacts might the inclusion of various markets have on the sketched design strategies and brand positionings of your application concepts?
What separate linguistic audiences are likely to use your computing tool within and across these global regions?
What information does your team have about the specific localization needs within the breadth of your targeted audience segments? What do you not know?
How might this information impact your sketched directions for the linguistic, symbolic, layout, and procedural aspects of your application concepts?
What larger design and technology trends could influence your team’s ideas about localization of your computing tool?
How might you prioritize localization needs in relation to other product design constraints? Which of these needs are strictly necessary? Which are desirable, “nice to haves”?
How could specific localization requirements influence the approach of your envisioned functionality concepts? Your sketches for high level application structures?
What unique opportunities could be present within your targeted locales? What design concepts might your team generate in order to explore these opportunities?
How might localization of shared views interfere with representational common ground in cooperative and collaborative work practices?
Do you have enough information to usefully answer these and other envisioning questions? What additional research, problem space models, and design concepting could valuably inform your team’s application envisioning efforts?
< PREVIOUS PAGE | NEXT PAGE >

Back to top | View Table of Contents
|