(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.

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 stakeholders.

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.

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?