Application Envisioning idea
Examples from three knowledge work domains:
(Illustrated above) A scientist is reviewing a visualization of a large clinical results set in her analysis application. She notices a visual distinction that seems to be indicating missing data for one subject, prompting her to view the particular subject’s data table in order to make a determination of what, if anything, has gone wrong.
Content stored in interactive applications may present knowledge workers with a variety of surprises and problems. Large data sets can develop holes and distortions over time that workers must recognize and understand in order to act effectively. Colleagues may unexpectedly and drastically modify the characteristics of one or more interaction objects (B6, C7, G4, H4). Individual objects or entire repositories of data can be merged with like content, often with surprising results. Automations can programmatically
generate garbled outputs after “choking” on small input abnormalities (E3, E4, E5).
A financial trader views a historical pricing graph of a particular security in his trading application. Several intervals of the graph are flagged to show where the pricing information is unreliable due to too much variability between the three different pricing feeds that his firm uses.
An architect opens a project in her building modeling application only to find that part of the 3D model has been programmatically colored red to show conflicting changes from different members of her team. A contextual message states that the segment is critically uncertain and requires resolution before any further modifications can be made.
Product teams can attempt to identify these types of scenarios in their concepts for work mediation (A). After identifying cases that are both probable and potentially damaging, teams can then envision functionality concepts that could provide workers with appropriate visibility into potential issues (F10) and clear pathways to subsequent action (C4).
When product teams do not actively consider approaches for promoting graceful handling of uncertain or missing content in their application concepts, resulting tools may promote certain types of errors (C9, G3) and lead to less beneficial work outcomes (L1). When users recognize the existence of key content problems but are not provided with tailored functional support, they may have difficulty determining how to proceed
(D2, D3, K7).
Conversely, uncertain or missing content is a characteristic part of some knowledge work endeavors. In these cases, the diversity of scenarios (A6, A7, A8) may be too high for teams to envision systematic responses, and users may find any such responses to be distracting and unnecessarily limiting (A9, D4, C8).
See also: B1, B5, D6, G6, H, I, K12
Application Envisioning questions:
More specific questions for product teams to consider:
What types of anomalous information do targeted individuals currently encounter in the work practices that your team is striving to mediate?
How serious are these situations? What errors and collaborative problems can result?
How frequent are different cases of uncertain or missing information? Are they rare exceptions or a common part of what it means to accomplish the work that your team is targeting?
How do knowledge workers currently handle uncertain and missing content in their computing tools? What attitudes do they have about these anomalies in their information environments?
Where in your team’s envisioned application concepts might anomalous data negatively impact work practices? How likely and damaging are these cases?
What larger design and technology trends could valuably inform your ideation around relevant solutions for uncertain and missing content?
What automated checks might your product conduct in order to determine the presence or absence of anomalous data?
What symbology and visual cues could communicate the existence of uncertain or missing content in your application’s displays? What information representations and messaging could help targeted workers to effectively recognize, understand, evaluate and work through these issues?
What interaction options could be presented in conjunction with flagged data in order to allow workers to take appropriate, or even mandated, next steps?
How might your team’s sketched responses for anomalous data situations relate to larger error prevention and handling conventions in your application concepts?
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