(Illustrated above) An architect uses her building modeling application to change the attributes of a material used throughout a developing design. To confirm that she wants to make the extensive change, the application presents her with a total count of building elements that would be modified. After she has applied the change across the model, a number of areas have error symbols attached to them, indicating where building codes may now be violated.

A scientist lowers a threshold in her analysis application to the lowest value that the underlying analysis algorithm will allow. This interactive constraint implicitly prevents her from making an error by removing the opportunity to drop the threshold so far as to make the analysis invalid.

A financial trader adds one too many zeros to a number of shares in his trading application. The tool rapidly informs him that there is insufficient quantity in the organization’s holdings to complete the transaction.

What error scenarios are targeted individuals currently concerned with in the operations, tasks, and larger activities that your team is striving to mediate? Why?

How do they currently prevent and handle these errors? Could these situations present opportunities for your product?

What key error cases could arise as part of specific interactions within your team’s functionality concepts? What important new cases might the abstraction of interactive computing introduce?

How might you categorize the severity of each error case that you have identified? Which could lead to loss of information, unrecognized and problematic outcomes, compromised security, or collaborative conflict?

What larger design and technology trends could influence your ideas about preventing and handling classes of errors within your computing tool’s various interaction offerings?

Especially for potentially serious cases, how might your team redesign your sketched functionality concepts in order to effectively remove the possibility for errors?

What cross checks could allow workers to actively prevent errors on their own behalf?

How might the larger error prevention and handing conventions you have envisioned for your application concepts apply to specific error cases?

Could any individual error cases benefit from or require novel error management solutions that fall outside of your internally consistent, top down patterns? How might these solutions reference the aesthetics and tone of your larger standards?

Where could recovery from errors be supported solely through undo functionality, rather than more attention demanding methods?

Where might constraining or frequent interactions with error prevention and handling features frustratingly conflict with common or local needs in work practices?

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?