Application Envisioning idea
B1.

Knowledge work applications can support specific work
practices with named interaction objects that are equivalents
of familiar workplace artifacts. In addition to incorporating existing domain ideas and entities, product teams may need to
introduce new objects into workers’ vocabularies and practices in order to meaningfully enable certain functionality concepts.

Examples from three knowledge work domains:
(Illustrated above) A scientist sets up a new clinical research study in her lab’s information management application. She creates a study file, a revised lab automation procedure,
and onscreen instantiations for several clinical samples and test tubes that are physically present in her lab.
A financial trader’s work primarily focuses on individual trades, though his trading application subdivides each deal into several different subcomponents that are meaningful for certain tasks.
An architect uses various modeling tools, standard 3D shapes, templated components, and many other onscreen elements to design buildings with her building modeling application.
When knowledge workers act “through the screen” of an interactive application, they are typically acting on specific, named objects that are framed by and made visible through the product’s display. These named, visible “pieces” of an application can be central to its underlying conceptual models (C1) and can activate workers’ deep seated understandings and skills.
Product teams can adapt many interaction objects from existing tools, resources, work products (L1), and other artifacts that have historical trajectories of use within a knowledge work domain (A). In order for these conventional objects to make sense in a computing context, they may require substantial transformation and thoughtful reframing (K5). For example, a single artifact may need to broken into multiple interaction objects in order to support certain actions (B4, G2). To maintain recognizability, adapted objects that undergo considerable redesign can reference conventional visual forms (F2) and useful iconic resemblances (L3).
Existing domain objects may not adequately support some of a product team’s concepts for mediating work. Teams must commonly envision new interaction objects to represent useful system concepts that have no previous corollary in offline work, such as customization settings (C8) or object templates (B10).
When product teams do not actively consider the menageries of interactive objects that form the primary “materials” of their sketched application concepts, opportunities to drive learnability and interaction clarity can be lost (C9, G3). Workers may be forced to make sense of unfamiliar, strangely named structures that are essentially external manifestations of a product team’s own misunderstandings. Central domain artifacts may be overlooked or underemphasized (A9), which may cause workers to see
resulting applications as irrelevant (K3) and excessively effortful to learn (D2, D3).
See also: B, C, F, H, I, J, K1

Application Envisioning questions:
What artifacts do targeted knowledge workers currently focus on in the work practices that your team is striving to mediate, and how might these objects be embodied in your application concepts? What new interaction objects are implied in your sketches of functional possibilities?
More specific questions for product teams to consider:
What inventory of artifacts from targeted individuals’ environments might your team consider as potential elements and references for your computing tool?
Who uses each type of artifact, and how do they use them? How does usage vary across targeted organizations?
What characteristics do workers value in the objects that they currently use?
What emotional connections do they inspire?
Are these artifacts primarily physical, primarily digital, or a combination of the two? How permanent or malleable are they?
How have these artifacts evolved into their current state within particular organizations or larger professions? What can be learned from recent evolutionary steps in these historical trajectories?
What nomenclature do targeted workers from different organizations and market segments currently use in reference to specific artifacts?
Which existing objects might benefit from meaningful subdivision or elaboration within the setting of your team’s application concepts?
How could useful representational characteristics of certain artifacts be preserved or even enhanced?
Which existing artifacts could be difficult to effectively translate into a cohesive
and well resolved onscreen object? How might these challenges impact your team’s sketched functionality concepts?
What conventional interaction objects, found in many computing tools, are implied in your ideas about mediating work?
How might your team invoke workers’ valuable conceptions of known artifacts as part of new interactions and representational forms?
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
|