Application Envisioning idea
Examples from three knowledge work domains:
(Illustrated above) A scientist’s use of her analysis application is highly contingent on what trends she discovers in her lab’s clinical results. Within the tool’s data visualization functionalities, her goals can change drastically based on the patterns that appear after each visual transformation that she explores.
Some types of knowledge work are practiced without step by step procedures or even high level road maps. Workers may begin these practices with clear goals in mind, but their intentions can evolve as outcomes unfold through a progression of actions. To successfully accomplish these scenarios, individuals can become highly skilled at recognizing patterns, situationally turning to supplemental resources and tools (G5, K8, K9), making meaning, testing hypotheses (F8, F9, I2, I3), revising their expectations
and understandings, and defining success (L1).
An architect is working in her building modeling application on a floor plan for a hospital’s critical care ward. She tries out a number of different rough layouts that could meet the project’s requirements, evolving her own criteria for a successful solution as she explores different ideas.
A financial trader’s work is primarily composed of frequent, brief, discrete, and habitual actions. However, some parts of his work are often not so routine, such as conversations about problematic trades or large potential deals, both of which can follow irregular processes and require unpredictable amounts of time.
The variations that stem from open and emergent ways of working can be difficult for product teams to appropriately capture in their shared, rationalized models (A7, A8). In some cases, a single model of these work practices can cover a critical mass of important variations. In many other cases, teams may benefit from creating models that represent a “cloud” of potential scenarios — an interrelated network of largely unsequenced patterns of action.
When product teams do not actively consider how open and emergent scenarios might impact their developing ideas about work mediation and application scope, resulting products may lack necessary flexibilities (A9). In the name of standardization (A4), product teams may crystallize processes based on inadequate understandings of complex realities (B8, C8), resulting in applications that can be difficult for workers to adopt and use (D2, D3, G1, K). At their worst, these hindrances to open and emergent work can be evidenced in the overall framework of a computing tool (C1, C2), which can be an excessively difficult issue to correct in implemented products.
See also: A, B4, G6, H, I5, K3, K6, K11, M1, M4
Application Envisioning questions:
More specific questions for product teams to consider:
What tasks or larger activities, within the scope of work that your team is investigating, take shape through the improvisational structure of workers’ practices?
What do targeted workers accomplish in these open and emergent scenarios
What are the initiating goals in each of these cases? How can those goals evolve through different series of actions?
Is the knowledge work domain that your team is targeting trending toward more improvisation or toward further specialization of defined processes and roles?
How do targeted individuals and their organizations view the importance of open and emergent practices? Do they wish they were more standardized? Do they value their openness?
What situations in these improvisational scenarios trigger workers to make
decisions about subsequent approaches and actions?
What are the most important points of flexibility for your team to consider when attempting to support these work practices?
What other patterns and regularities can your team find in these “clouds” of potential scenarios? How might you use these insights to ideate useful and meaningful functionality concepts?
How could support for these practices impact the overall scope and frameworks
of your application concepts?
How far might your team push certain flexibilities for open and emergent practices before the interaction clarity of your sketched computing tools begins to
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