Application Envisioning idea
C1.

Knowledge workers develop particular understandings of which work practices an interactive application is designed to support, how it essentially “works,” and how it might fit into their own activities. Product teams can communicate their computing tool’s intended conceptual models through application design and other channels.

Examples from three knowledge work domains:
(Illustrated above) An architect finds that her studio’s new building modeling application requires a substantially different mindset. Instead of drawing individual elevations, plans, and details for a project, her team will collaboratively create a single, shared 3D model of their building design. The new tool itself communicates this overriding distinction in numerous ways, including how various functions are named.
A scientist quickly develops a working understanding of how her analysis application calculates and presents certain values. Overall, the way the tool displays her lab’s clinical data reminds her of a powerful, zooming microscope.
A financial trader receives periodic updates from the vendor that created his firm’s trading application. In one of these updates, he learns that he will need to develop a clear understanding of how, when, and why some new functionalities will usefully automate certain trade parameters.
While mechanical tools can implicitly communicate how they work based on their construction, digital tools must be designed to communicate their purpose, offerings, and behaviors. Knowledge workers incorporate new technologies into their practices based on unfolding understandings of how available tools operate (A, K2, K6). Even though individual users develop their own conceptual models of a tool over time, product teams can attempt to shape these understandings by developing target models and striving to communicate them in their application designs.
To create compelling functional gestalts, product teams can envision conceptual models for their products that are framed by and build upon analogies and idioms known by their targeted audiences (C3, L2). Innovative models that simply and coherently present predictable relationships can also be quite successful (F3). Complex applications can contain multiple levels of nesting conceptual models, ranging from the overarching product framework, to individual functional areas (C6, B1), to functional variations driven by differing permissions and identity tailored views (A2, C5).
When product teams do not actively consider how proposed conceptual models could shape workers’ experiences, opportunities to drive useful understandings of how an
application essentially works can be lost. In the absence of clearly communicated conceptual models, people may experience computing tools as arbitrary collections of controls and pathways (K3), developing their own murky assemblies of functional interpretation. Even though these tools can be learnable after committed effort or training (D2, D3, M2, K7), potentially valuable functionality may remain undiscovered, misunderstood, or misused, requiring additional defensive measures to prevent errors (C9, G3).
See also: B4, C, E5, G1, L3, M1

Application Envisioning questions:
What overall models could encapsulate the “what and how” of your interactive application’s proposed roles in targeted knowledge work? How might those overall “functional stories” be communicated to users? Similarly, how could your team promote clear “sub-stories” for each of your central functionality ideas?
More specific questions for product teams to consider:
What organizing, big picture mental models do targeted individuals currently have for the work practices that your team is striving to mediate?
How do the mindsets and constraints inherent in different tasks or larger activities drive workers to adopt different frameworks for thinking and acting?
How might your team use your insights into these mental models as a basis for
envisioning innovative and compelling conceptual models for your computing tool?
What essential, high level operational approaches in your sketched application ideas could reference and extend upon workers’ existing ways of thinking about their efforts?
How might individual functionalities make similar connections to workers’ current understandings?
What new and different conceptual foundations might workers need to understand in order to successfully make use of your computing tool in their own practices? How could these new conceptual models be framed by their existing mental
models?
How might people in different roles, using application displays that are tailored to their own identities, develop different conceptual models for your sketched computing tools? How could this impact their common ground for communication?
What might it sound like when a hypothetical user describes one of your proposed conceptual models? What takeaways should they have about your tool’s purpose, offerings, and behaviors?
How might your teams’ proposed conceptual models be communicated through application design and functional scaffolding? Through other channels, such as informative marketing and introductory instruction?
How could your approaches to communicating target conceptual models tie into your larger ideas about design strategy and brand?
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
|