Application Envisioning idea
F11.

Information representations may require supporting content in order to be interpreted correctly by knowledge workers. Product teams can envision how different representational forms in their sketched application concepts could be clarified with useful labels and keys, as well as descriptions of current data scope.

Examples from three knowledge work domains:
(Illustrated above) An architect sometimes gets confused while rapidly navigating the virtual space of her building modeling application. She often turns on the application’s scale indictor and a small overview map of the building model, both of which help her to orient herself without devoting much of her conscious attention to wayfinding.
A financial trader learning a new trading application leaves a reference dialog open on one of his monitors so that he can quickly refer to its legend whenever he is unsure of a symbol’s meaning.
A scientist needs the visualizations in her analysis application to always be framed by graphic scales. Without them, she finds it easy to jump to incorrect conclusions while quickly switching through different views of her lab’s clinical data.
Even highly experienced knowledge workers may find that certain representational views are not self explanatory, even after extended use. Workers can benefit from,
or potentially need, certain kinds of supporting content in order to make a given data display meaningful in their own practices (A).
Especially when functionality concepts contain innovative new displays (F3, F4), product teams can envision supporting information that could scaffold initial learning of abstract representations (K2). This type of content may be referred to infrequently after users have learned a tool, though it may still be highly valued when needed during ongoing interactions (C4, E1). To prevent perceptions of clutter in long term use (D4), such supporting content may be optionally viewed, with choices to present or hide it through progressive disclosure (C3) or display customization features (C8, A9).
In cases where workers could be frequently switching back and forth between displays (F9) or using a single representation to look at different data (F8), product teams can consider how important interpretive cues and explanatory information could become meaningfully integrated into representational formats (D7). In these cases, the
“supporting” distinction may be somewhat artificial.
When product teams do not actively consider potential supporting content for the abstract representations in their application concepts, a variety of issues can arise. In the absence of needed information, workers may find that resulting tools are difficult to adopt (K6). They may need to repeatedly turn to assistance outside of their focus within a display (K7, J), potentially creating and enacting work arounds to ascertain the meanings of certain screens (D2, D3). People may also commit interpretative errors without realizing (C9, G3, K5), which can be effectively impossible to prevent through application logic and can effectively decrease the overall quality and quantity of work outcomes (L1).
See also: B3, F, G6, I4, I5, J7, K

Application Envisioning questions:
What explanatory content about abstract codes and data contexts could help targeted knowledge workers to more effectively learn and actively use certain representations? How might supporting cues and information be contextually presented or made interactively available in order to clarify workers’ interpretive acts?
More specific questions for product teams to consider:
What supporting content do targeted individuals currently reference while using information representations in the operations and larger tasks that your team is striving to mediate?
How might existing interpretive cues and explanatory information, or their underlying intents, be incorporated into your team’s functionality concepts?
What advanced analogies to other types of information display might you draw upon when envisioning useful representational codes and contexts for your sketched application directions?
What additional supporting conventions could provide value in the varied representations that your team has envisioned? Could specific data displays valuably include further labels, keys, or scope indication?
How might support for certain representations relate to, or literally connect with, appropriate instructional content in your computing tool’s help functionalities?
How could key instances of representational support be made parallel with your product’s error prevention and handling conventions?
Where could persistent presentation of representational codes and context
provide value in workers’ practices?
When might targeted workers come to view supporting content as clutter after they have learned how to interpret a visual display? How might certain codes and context cues be interactively hidden or displayed in support of these scenarios?
What customizations might your team provide to allow targeted individuals and organizations to tailor representational aids to their own local needs?
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
|