Application Envisioning idea
Examples from three knowledge work domains:
(Illustrated above) An architect archives all projects in her studio’s building modeling application that have been fully constructed and occupied for over two years. Although there is no technical need to move old projects, everyone at her firm finds their systems easier to navigate when they contain only current and recent work.
Completed projects and dated information can fill up space and cognitively clutter a knowledge work environment. Given that interactive applications can house growing volumes of information, workers may come to value the ability to exclude selected older content from their day to day onscreen views.
A financial trader knows that he can view his group’s transactions from the last three months in his trading application. Older, archived information is available on request, though he rarely needs to look back more than a week.
A scientist finds that her lab is filling the capacity of their shared research database faster than expected. To make room for a massive new clinical study, she chooses to archive older studies to a separate database.
Product teams can envision archiving functionality based on informed predictions of how their computing tools will be used over time (A). Available options from associated storage technologies, such as off the shelf file servers or databases, may not provide compelling or effective support for specific archiving needs that can arise after product adoption (K10). Useful and usable archiving functionality can include tailored pathways for placing content into an archive (C4), managing archived content (B9, I1), searching and viewing archived content (I2, I3), and restoring archived content to an active state.
Functionality concepts for archiving can invoke the feeling of separation and distance between active and archived information (G1). Even though this feeling can be somewhat artificial in a technical sense, it may be a useful notion when envisioning instruction (K2, K6, K7) and visual representations (F10, L4) within archiving experiences.
When product teams do not actively consider the potential archiving needs that are inherent in their application concepts, resulting tools may become unwieldy through extended use. Products may present workers with escalating navigation difficulties, decreasing clarity around current workload (D3), and increasing technical performance problems (K13). Users may find the circuitous paths of their own workarounds to be excessively effortful (D2) and prone to serious errors, such as data loss (C9, G3, K5).
See also: B2, E2, H3, I, J7
Application Envisioning questions:
More specific questions for product teams to consider:
How much information is currently generated in the work environments that your team is targeting? How much of that volume comes from your targeted tasks and larger activities?
Do these volumes of information eventually become an obstacle to workers’ successfully accomplishing their practices?
Is the idea of archiving information already present in some way in targeted organizations? How are existing archives currently categorized and accessed?
How frequently do targeted individuals review “old” work?
What goals can trigger retrospective action? Do workers typically reopen past efforts briefly to find some specific information or do reopened items provide value over a more expansive period?
How might current archiving needs be supported within the bounds of your team’s application concepts?
How might your product’s preordained technologies influence your team’s envisioning of archiving options? What larger technological trends could be influential?
How might the adoption of new computing options into targeted work practices create new volumes of information that could benefit from being meaningfully separated into “current” and “archived” pools?
How, specifically might “old” information “get in the way” in your team’s primary functionality concepts?
What interactive pathways might your team envision to effectively support processes of archiving information, managing archived content, searching for and viewing archived content, and restoring archived content an unarchived state?
Which of your sketched interaction objects might serve as the basis of archiving interrelated and dependent collections of stored content?
How might the states of interaction objects be used to drive archiving actions? Might “archived” be valuable as a distinct object state?
How might an archive’s conceptually separate, “distant” nature inform your team’s envisioning of related visual representations and instructional content?
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