Application Envisioning idea
Examples from three knowledge work domains:
(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.
Within the complex mental operations and symbolic abstraction of computer mediated work practices, we can safely assume that people will make errors (G3). The best envisioning response to a recognized possibility for user error is often to design away the conditions under which it might arise.
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.
In cases where there are conflicting requirements and high flexibility needs, product teams may find it difficult to prevent errors strictly by envisioning behavioral constraints in their functionality concepts. Teams can meaningfully categorize these stubborn
error cases, based on their severities and interaction consistencies (A4). They can then envision patterns for error prevention and handling to apply throughout their sketched application concepts (C3, E3, F10).
Teams can choose many of these patterns from among the error conventions that are commonly used in contemporary interface design (D7, L2). Some products may contain unusual, domain specific error classes (A) that could benefit from ideation of novel, tailored patterns or display formats (F).
When product teams do not actively consider potential conventions for preventing and handling errors, resulting inconsistencies (K13) may frustratingly hinder a worker’s ability to effectively accomplish important goals (L). People may have more difficultly learning such applications (D4, K5, K6, K7) and recovering from mistakes made while using them. Additionally, their perceptions of product quality and utility may decline (K12) as they create and enact defensive work arounds (D2, D3), such as active versioning of valued content (H1).
See also: B6, C, E6, H2, H3, J4, J5, K5, M
Application Envisioning questions:
More specific questions for product teams to consider:
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?
< PREVIOUS PAGE | NEXT PAGE >
Back to top | View Table of Contents