Application Envisioning idea
K3.

In order to communicate to potential users that the particulars of their work practices have been thoroughly considered, product teams can envision legible domain cues within their application concepts. When these cues are easily recognizable, knowledge workers may be more inclined to consider how they might use a new technology in their own activities.

Examples from three knowledge work domains:
(Illustrated above) An architect likes that her new building modeling application uses language, conventions, and workflow that are specific to the practice of architecture. Other collaborative design products she has tried using in the past felt more like overly general 3D modeling tools that required her to excessively translate her ideas into arbitrary commands and design shapes.
A scientist finds that the features of her new analysis application are geared specifically to the types of clinical data explorations that she performs in her research. Whereas the general “data mining” tools her lab is migrating away from seemed arbitrary and unnecessarily difficult to learn, her new tool seems very approachable and relevant.
As a financial trader quickly scans the menus and field names of the trial version of a new market information application, he recognizes standard options and functionalities that he is accustomed to using.
People judge how onscreen products could apply to their goals, while also considering any new opportunities that a application may facilitate. Computing tools that are intended for specific knowledge work practices can intentionally invoke their specializations through inherent branding and design. When targeted workers somehow see their own professional practices in a product’s details, they may develop a focused interest in the tool, which can then evolve into committed adoption.
What this recognition may mean is highly contingent on the specifics of a given domain and the scope of work that a tool is intended to mediate. Given that expectations of applicability must be met with corresponding functional value, potential cues can include product genre (C1), interaction conventions (C2, L2), specialized language (B1) or
information representations (F2), iconic design references (L3), and other domain
specific elements (K2).
Product teams deliberately envisioning more generalized applications, to be used in multiple domains or markets, may face the challenge of not being able to leverage
obvious references from any one specialty (A). Even without these literal cues, teams can uncover commonalities in work activities across specialties and then use these
similarities to reveal legible, goal directed cues in their designs (B9, C4).
When product teams do not actively consider how they could make their application concepts a clearly recognizable part of the work that they are striving to mediate, resulting tools may fare poorly in workers’ intuitive, “snap” judgments of utility. Depending on the market context, these judgments can impact both individual and organizational attitudes about acquiring and adopting products and brands (K).
See also: D1, F10, G1, L4, M

Application Envisioning questions:
Beyond expected marketing messaging, how might the form, appearance, and behaviors of your team’s computing tool rapidly communicate relevance for targeted knowledge workers’ own goals and practices? What domain signs and emotive cues might workers feel a compelling affinity for while interacting with your application concepts?
More specific questions for product teams to consider:
What meaningful consistencies in work practices across targeted organizations might your team translate into readily recognizable domain cues?
What clear commonalities in nomenclature and information representation could become visible references within your product?
Do your application concepts fit into — or somehow relate to — existing product genres that targeted individuals will likely know about? How might your team’s design strategies play up these affinities while retaining meaningful brand differentiation?
What domain specific interaction patterns could trigger targeted knowledge workers to view your product as a potential addition to their technology environments?
How might the interactive entry points for primary pathways within your sketched computing tool provide a strong sense of domain relevancy?
How might strong or subtle design references to familiar and iconic artifacts improve potential users’ “gut” judgments of your product’s utility and applicability?
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
|