Application Envisioning idea
Examples from three knowledge work domains:
(Illustrated above) A scientist, while using her analysis application, tries to recognize key moments and jumping off points during her interactions with a set of clinical data, saving different versions of the analysis file at these important junctures.
Active versioning of valued information can be an important part of computer mediated knowledge work. Historically, workers have needed to version content in order to provide safety from computer glitches and to defend their progress from their own or colleagues’ poorly conceived changes (H2, H3). Workers may also version content to preserve organizational memory within an activity (I7, E1, E2), to create new interaction objects from an existing object (B10), or to temporarily maintain “views” while
exploring possible scenarios (G5).
An architect uses her building modeling application to create several different versions of a small building segment where she is currently thinking through detailed design. She has a few ideas of how the design could effectively play out, so she saves each idea as a named version in order to discuss them later with project
A financial trader uses his trading application to save each round of communications on the topic of closing a large, multi-component deal. By saving each version of the negotiation, he can double check that his counterparty does not make any hidden changes to trade parameters.
To version an existing interaction object, people often seek expected and conventional “Save as” and “Copy” commands to create named duplicates (B1, B4). Product teams can envision additional interaction pathways to tailor active versioning to targeted work practices (C4) and relevant error prevention scenarios (C9, G3).
When versioning “genealogies” are both informative in work practice and inherently complex, teams can envision functionality concepts that could allow workers to meaningfully organize (B2) and view version lineages (B4).
When product teams do not consider the potential role of active versioning in their application concepts, opportunities to support outcome exploration, cognitive tracing (H), and information security (K13) may be lost. Even though products can often leverage versioning functionality from their surrounding technology environments, knowledge workers may value integrated versioning interactivity within their tools. When they perceive available versioning methods as confusing (C1) or as excessively effortful
workarounds (D2, D3), their opinions of a product’s utility may suffer.
See also: A, B2, B5, B6, E1, F1, I1, J5
Application Envisioning questions:
More specific questions for product teams to consider:
When do targeted individuals currently create different versions of information artifacts in their work practices? What value do these versions provide?
How do knowledge workers and their organizations keep track of multiple versions of an object? What language do they use to categorize and describe them? Do they track “genealogies” across versions?
Based on your understanding of current practices, which of the interaction objects in your team’s application concepts will targeted workers likely want to actively version?
How might the introduction of your computing tool create valuable opportunities for workers to use versioning to intentionally differentiate threads of effort or preserve milestones of progress over time?
What larger technology and market trends could influence your team’s ideas about active versioning of stored content? What related aspects of targeted IT infrastructures might your team use as grounding for envisioning these functionalities?
What events might trigger workers to consider versioning information in your sketched application concepts?
Which of the interaction objects that your team has envisioned should not support multiple versions? Why?
How might your sketched functionality concepts contextually provide versioning options in related interactive pathways and error scenarios?
What goals and practices might drive workers to investigate versioning lineages
of specific onscreen content?
What representations of lineage information might clarify valuable versioning relationships?
What functionality concepts might your team envision to allow users to navigate
or “restore” previous versions?
Could automated versioning, in the form of stored history about changes in interaction objects, complement or provide more value to targeted workers than active, “manual” versioning?
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