Application Envisioning idea
C3.

Looking across the sketched functional offerings in a product team’s application concepts, there are often opportunities to categorize and standardize certain repeating patterns. Teams can capture and expand upon internal consistencies at different levels of granularity, promoting eventual learnability, usability, and implementation efficiencies within their computing tools.

Examples from three knowledge work domains:
(Illustrated above) An architect finds that there is an overall feel of consistency in the design of her new building modeling application, even though each area of the product seems carefully optimized to support different actions. Across the entire application, different tools and dialog boxes are presented in a predictable and clearly mapped manner that makes them easy to interpret and use.
A scientist discovers that there are two distinct ways, within the same overall
interface, that her new analysis application allows her to act. Common, standard analysis methods are supported by highly directive, step by step screens, while less predictable analyses are supported by a series of flexible workspaces devoted to particular approaches.
A financial trader knows that his trading application has different “categories” of screens. When he navigates to tools and options that he does not use very often,
he recognizes smaller components that follow the same mold as screens that he uses repeatedly throughout his day.
While envisioning applications, many product teams gravitate toward copying low level, “literal” user interface patterns from other products that they, and presumably their targeted knowledge workers, are familiar with. These vernacular design selections are often made on a one by one basis within particular functionality concepts, without
considering requirements and consistencies across the entirety of a computing tool
(B9, C6).
Product teams can envision more expansive value from interaction patterns by mapping them at multiple levels of convergence, starting at an application’s interaction model (C2) and working downward through several tiers of user interface detail (A4, A5). Teams can then experiment with applying their nesting and interrelated patterns across their sketched functionality concepts, envisioning how knowledge workers might transfer their experiences among interactions (C1, D7).
When product teams do not actively consider the potential role of interaction patterns at different levels within their application concepts, resulting inconsistencies may hinder workers’ abilities to develop useful expectations. Without these expectations, people may find new or infrequently used functionality more difficult to learn (D2, D3, K2, K5, K6). When inconsistencies are noticeable, they can also negatively impact
individuals’ perceptions of an application’s quality (K12).
Conversely, product teams that focus too heavily on establishing and applying interaction patterns can overlook opportunities to envision design concepts that are highly tailored to the work practices that they are striving to mediate (A).
See also: B1, C, F, G2, G3, J6, K1, L

Application Envisioning questions:
Scanning the breadth of your team’s promising functionality concepts, what typical or novel interaction patterns might you identify and meaningfully reuse? How might your team organize these valuable regularities into different tiers of patterns within your application proposals, ranging from large to more granular?
More specific questions for product teams to consider:
What, if any, interaction patterns do targeted individuals expect to see when using computing tools in the work practices that your team is striving to mediate?
What patterns, at different levels of granularity, have become a standard part of how knowledge workers’ understand their computing tools?
What value do workers find in these known and expected patterns? What do they think of the conventions that they currently use?
What larger design and technology trends could influence your ideation about interaction patterns?
What advanced analogies to other types of products might your team draw upon when thinking about appropriate patterns?
What inherent consistencies are present within the scope of work practice you are targeting? Based on these consistencies, which of your envisioned functional areas could have strong similarities?
Within the particulars of your sketched functionalities, what smaller consistencies could become internal standards?
How might the reuse of interaction patterns in your application promote the transfer of workers’ learning in one interactive experience to other interactive experiences?
Where could the particulars of workers’ goals drive meaningful differentiation in interaction design responses, rather than patterned standardization?
When introducing new interaction patterns into workers’ practices, what analogies might your team make to known interactivity scenarios?
How might your ideas about your product’s larger conceptual and interaction models impact your interaction pattern choices?
How might the emerging language of patterns in your sketched application possibilities 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
|