100 APPLICATION ENVISIONING IDEAS | K. PROMOTING INTEGRATION INTO WORK PRACTICE
WORKING THROUGH SCREENS
K5. Understanding and Reframing Alternate Interpretations When product teams foresee potential “misinterpretations” of their functionality concepts — and these possibilities cannot be effectively “designed out” — they can envision cues that may help knowledge workers to reframe their own interpretations to be more closely aligned with their products’ intended conceptual models.
Where might targeted knowledge workers’ domain background promote interpretations of your team’s sketched computing tool that are different than those that you intended, potentially leading to errors and inefficiencies in use? What corrective cues and instruction might your functionality concepts include in order to reduce the likelihood of such conflicts?
We are trying out some new chemistry in our lab ‘s process, and I am about to look a the ﬁrst batch of experiments in our analysis so�ware...
Examples from three knowledge work domains: A scientist is used to thinking about certain areas of a scatter plot graph as representing outlier data within a set of clinical results. After she changes the chemistry that her lab uses to process samples, her analysis application provides some additional cues and instruction about how to interpret the new data (see illustration). An architect expects that all communications within her studio’s building modeling application will be saved as part of the building model file. She is surprised to read that one type of communication is not saved, though the application’s stated reason makes sense to her. A financial trader has used the same set of trading shortcut codes for years, but his group has recently decided to switch to a more efficient and all encompassing set. Now, when he accidentally enters an outdated shortcut code, his trading application suggests alternate codes that could match his intent.
More specific questions for product teams to consider while envisioning applications for knowledge work: What domain knowledge, existing skills, learned interaction expectations, and other background will targeted individuals likely bring to their experiences with your team’s product?
Where might peoples’ existing understandings conflict with the conceptual models that your team is attempting to communicate throughout your sketched application concepts? In which cases might it be better to redesign certain functionalities rather than attempting to reframe targeted workers’ alternate interpretations of them?
So I’m choosing a visualiza�on that I normally start with to get a sense for data quality...
Where might the opposite be true? Where could the value of your team’s sketched approaches to mediating work be strong enough that you may want to try to respectfully mitigate and reframe users’ alternate interpretations?
Some technologists talk of knowledge workers’ “legacy” characteristics with dismay, as if trained professionals should simply abandon their cultures of practice for new processes that some believe to be more efficient or contemporary. Taking a more respectful approach, definers and designers can instead think of targeted workers’ “legacy” of existing understandings and abilities as the core of valued skills that they are attempting to augment with their products. Armed with the later perspective, product teams can recognize that valuable technologies often conform to, rather than rework, users’ known practices. Teams can envision functionality concepts that harness knowledge workers’ backgrounds, presenting them with useful new approaches in support of their existing working cultures (K2, K6, K7). Even within this emphasis on intentionally suiting the design context, new technologies inevitably carry some novel ideas. By design, some of a product team’s sketched concepts may necessarily operate in ways that can conflict with workers’ existing understandings. Faced with these situations, teams can identify areas where damaging misinterpretations may occur and then envision ways to reframe these conflicts. These envisioning efforts can be particularly important when teams are seeking to deliver value by evolving or intentionally modifying some fundamental mental models within a knowledge work domain (D7, F2, F11). When product teams do not actively consider potential alternate interpretations of their design concepts — and how potentially problematic interpretations could be reframed — resulting products may leave knowledge workers more susceptible to errors in decision making and action (C9, G3). Users may also find such applications to be difficult to learn, generally inefficient (D2, D3), and built on a flawed understanding of their motivations and needs (C1). See also: A, G1, F, K, H, I4, L4, M
What larger design trends and advanced analogies to other products could influence your ideas about attempting to reframe certain conceptions within your computing tool? What corrective cues, instructional content, and other design communication could reduce the incidence of potential misinterpretations? And apparently the tool sees that we have switched chemistry for collec�ng this data, and it wants to tell me how to interpret the same old visualiza�on a li�le bit diﬀerently...
And then, a�er reading that informa�on and diving into our data, the so�ware is s�ll poin�ng out what is diﬀerent than usual as I inspect this interes�ng data point...
Analyzing New Chemistry
How might your concepts for reframing alternate interpretations tie into other instructional assistance approaches in your application concepts? How might they relate to your approaches for error prevention and handling? 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?
Published on Jan 13, 2010
Working through Screens: 100 Ideas for Envisioning Powerful, Engaging, and Productive User Experiences in Knowledge Work This heavily illus...