Page 92



H2. Extensive and Reconstructive Undo Undo functionality can offload effort from knowledge workers to their computing tools by storing step-by-step trails of their onscreen actions, effectively freeing them from concerns of damaging previous efforts. Product teams can envision functionality concepts that could allow workers to sequentially reconstruct earlier states in their interactive applications.

I’ve got to be extra careful entering the details for this huge, very high value deal...

Examples from three knowledge work domains: A financial trader, realizing that he has made a mistake, uses undo to navigate backward in his trading application, removing some changes that he had made to the parameters of a large deal. If he had already executed the trade, undo would not have worked, and he would have had to pick up the phone to try to make corrections to the committed data (see illustration). A scientist has applied a change to too many clinical samples in her lab’s information management application. She is relieved that a single undo action removes this change across all of the affected samples. An architect working on a residential project in her building modeling application realizes that her current design approach is creating too much obstruction between two spaces. She instinctively turns to the application’s undo command to sequentially remove a series of actions, watching them “peel back” to where she had been a few minutes ago.

In contrast, the nature of some onscreen actions should have a certain level finality. Depending on the specifics of targeted work practices (A), product teams can identify operations and larger tasks that should not be the subject of rapid, lightweight undo. When varying undo rules exist within an application concept, teams can envision clear and consistent models of how undo will operate on different functionalities (C1, H3), referencing existing conventions when applicable (C3). When product teams do not actively consider the potential role of undo in their application concepts, opportunities to directly support dynamic and exploratory user experiences can be lost. Without undo functionalities, workers may have severe difficulties recovering from errors (C9, D2, D3, G3), potentially leading to lower quality work outcomes (L1). In an attempt to overcome these limitations, they may enact extensive workarounds, such as repeatedly saving and managing different versions of their valued data (H1, I). See also: C2, C10, D4, D5, G5, F9

How might undo functionality play a role in the knowledge work practices that your team is striving to mediate? Does the nature of targeted work allow for such uncommitted action? How might undo options “save” targeted workers from erroneous outcomes and allow them to valuably explore a breadth of scenarios? More specific questions for product teams to consider while envisioning applications for knowledge work:

Financial Trader

How do targeted individuals currently consider different options within different “episodes” of their work? How can these current explorations prevent mistakes and improve work outcomes? What expectations do targeted workers and their organizations have about undo functionality in their computing tools?

Now I’m just double checking whether I’ve put in the right things before I press the final bu�on here...

What benefits might undo provide in the specific tasks or larger activities that your application concepts are intended to mediate? What larger design and technology trends could influence your team’s ideas about what undo options could look like? What existing undo rules and conventions might you usefully apply? How might your product’s preordained technologies influence your team’s envisioning of undo experiences?

While a typewriter’s correction tape leaves artifacts of its use, the digital contents of interactive applications can withstand repeated modifications without any loss of quality. Undo functionality exploits this mutability to provide valuable options. By capturing sequential evidence of workers’ previous actions, undo can become a key pathway for knowledge workers seeking to reconstruct their earlier thought processes and emergent actions (A6, E, H). Workers using trusted, stable products (K12, K13) can become comfortable with the idea of taking actions without committing to any particular outcomes that might occur. They are able to try, then try again.


How, specifically, might undo apply within your sketched functionality concepts? What unusual cases may present definition and design challenges? Damn. I’m glad I double checked. I was thinking about this all wrong... I have to undo a lot this info, because I put this deal in the wrong category up front...

Which stored user actions might be skipped in undo sequences? How might scenarios around cooperative or collaborative efforts impact your ideas about undo rules in shared workspaces? Should users’ actions become more or less permanent in these scenarios? What might the experience of “rolling back” actions be like after elapsed intervals of time? What novel interactive and representational approaches might your team envision to allow workers to more effectively use their stored action histories? How might the stored pathways of undo functionality relate to any other longer term, historical information about interaction objects in your application concepts?

Okay, now I am back at the point where I made the wrong choice, and I can make this right...

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?

Working through Screens (Tabloid Size)  

Working through Screens: 100 Ideas for Envisioning Powerful, Engaging, and Productive User Experiences in Knowledge Work This heavily illus...