(Illustrated above) A financial trader notices and appreciates the different ways that his trading application prevents him from making errors during the course of his typically hectic day. For example, the tool presents small, informative flags as he enters problematic data so that he can make corrections in real time. And, when he tries to complete an action that does not match established business rules, the tool overlays clear, cautionary messages with suggestions for action.

An architect has learned that her building modeling application provides constraints on her actions that prevent her from making errors in a categorical variety of ways, whether she is “sculpting” the shapes of a building design or entering data about the properties of a particular onscreen object.

A scientist wants clear, highly visible messages in her analysis application that prevent her from making predictable and common data entry mistakes while she creates new studies. However, for any tasks that involve exploring her lab’s clinical data, she only wants messaging of possible errors, without any hard limitations on her actions.

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?

Where might the introduction of your team’s computing tool create new possibilities for human error in targeted work practices?

How might you divide up the pool of potential error scenarios that you have identified into meaningful classes? How could different approaches and perspectives on this categorization provide insights?

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

What existing conventions, from a broad selection of interaction patterns in contemporary computing, are most relevant to the error classes and categories that your team has identified?

What domain specific error scenarios might present opportunities for your team to envision useful and specialized error prevention or handling conventions?

How could different levels of error severity be clearly and consistently communicated throughout your application concepts?

What special standards might your team envision to prevent critical errors in highly directive ways? On the other side of the spectrum, what classes of errors do not require such strict prevention and should leave users in the locus of control?

How might these internally consistent standards become a complementary element of your product’s larger aesthetic direction and brand? What tone and appearance could be most appropriate for these textual and visual languages?

How might your sketched error management standards relate to, or even establish, the pattern language of a broader family of products in your firm?

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?