Application Envisioning idea
K9.

Knowledge workers may want to accomplish their activities by using a series of functionalities that sequentially span more than one computing application. To allow for the movement of large volumes of data in relevant formats, product teams can envision functionality concepts that could facilitate cross boundary interoperations with distinct import and export options.

Examples from three knowledge work domains:
(Illustrated above) A scientist exports a set of clinical data from her new analysis application so that she can import it into her old analysis tool, which includes some different visualizations. Depending on what she discovers in the older tool, she will likely import a subset of the clinical data back into her new, primary tool for further examination.
A financial trader, who wants to better understand the potential long term value of a large trade offer, exports the offer’s data into a format that he can then easily uploaded into his preferred market information tool.
An architect needs to post some plans on an extranet website for her clients to view. Since these clients do not have the specialized software applications that her studio uses, she instructs her building modeling application to export the selected plans
as web pages.
When dealing with complex information, large volumes of data, and entire arcs of activity, knowledge workers frequently want or need to apply several different computing tools to their efforts. Individual products are often only one component of an overall system of tools that workers have appropriated to accomplish their activities.
Based on analyses of common product and activity interrelations in targeted work practices (A5), product teams can provide workers with opportunities to sequentially bridge applications through the export of their product’s content and the import of related content from other tools. Desirable approaches and formats for these functionality concepts can be highly contingent on teams’ predictions about how their product will be used in conjunction with other technologies. Support for more open standards may promote directed interoperation with a variety of computing tools, including those that may not yet exist during application envisioning or at the time of a product’s eventual release (M4).
When product teams do not actively consider how knowledge workers may want to directly interoperate their applications with other onscreen tools, resulting products may be experienced as inaccessible “islands” of functionality. These applications may pose critical barriers to long term productivity and satisfaction (D2, D3, G3), creating a need for redundant data entry (E3, E4) that can take the place of higher order, and potentially higher value, pursuits (D4).
Conversely, for reasons involving top down business or brand strategy, teams may intentionally decide to keep their application concepts closed to this sort of interoperation, regardless of the value it could deliver to workers and their organizations. However, over time — and under the influence of Internet driven thinking — this line of “protective” reasoning appears to be becoming less prevalent in many workplace computing domains.
See also: A, B, C8, E, G1, I5, K, M

Application Envisioning questions:
Which of the work practices that your team is striving to mediate could bridge multiple computing tools in knowledge workers’ technology environments? What separate, named functionality concepts might your team envision to allow targeted workers to valuably move selected collections of application content across otherwise isolating product boundaries?
More specific questions for product teams to consider:
Which computing tools do targeted individuals primarily use, given the larger constellation of technologies that are available to them?
What role do each of these tools play within your team’s targeted tasks and larger activities?
How do knowledge workers currently coordinate their various onscreen applications to accomplish their goals in different scenarios?
Which interoperations frequently result from actively and sequentially moving data between computing tools?
What breakdowns and errors can occur in these interoperations? Could these problems represent potential opportunities for your product?
Where might your team’s sketched strategic directions suggest “open” and networked approaches to other technologies in targeted workers’ environments? Where might they suggest “closed” approaches?
What market trends and technological realities might your team consider while envisioning possibilities for the directed movement of data between certain computing tools?
What attitudes and expectations do targeted individuals and organizations have regarding exporting and importing as a means of bridging their own assemblies of various tools and systems?
Which collections of interaction objects in your application concepts might targeted users want to export? What data might they like to import?
What data formats could support directed, manual exchanges of content between computing tools? What open standards could allow workers to move data into forthcoming and future applications — some of which your team may not yet know about or be able to predict during your own product development process?
What flexibilities could allow workers to have desirable levels of control over the content that is moved into and out of your application concepts?
What vulnerabilities and security problems might be created by allowing the import of “outside” data? What functionality responses could mitigate these risks?
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
|