100 APPLICATION ENVISIONING IDEAS | C. ESTABLISHING AN APPLICATION FRAMEWORK
WORKING THROUGH SCREENS
C2. Application Interaction Model Knowledge work applications can benefit from a consistent and overriding interaction model that defines a computing tool’s “shell” of navigation and overall approach to interactivity. Product teams can envision interaction models that are complementary to targeted work practices, appropriate for their sketched design strategies, and framed by workers’ experiences with other tools.
46
What directions can your team generate for the deliberate “shells” of your application concepts, including their approach to containing, enabling, and shaping your sketched functionality ideas? What types of interaction models could effectively support targeted knowledge work in a way that embodies your strategic focus?
Each edge of my analysis applica�on has a clearly defined purpose, and it’s clear where I should turn to do different things...
More specific questions for product teams to consider while envisioning applications for knowledge work:
Examples from three knowledge work domains: A scientist sees that each edge of her analysis application is a panel that can have different impacts on the central visualization area of the tool. One edge controls what data is being displayed, while another controls how selected data is visualized (see illustration).
What interaction models are commonly found in the computing tools that targeted individuals currently use?
Clinical Scientist
Which models are normally associated with the specific tasks and larger activities that your team is striving to mediate?
A financial trader’s new trading application presents four columns, each with a different purpose. The left column has tables that drive what is shown in the next two columns, while the right column shows market data and other trader’s action.
What larger design and technology trends could inform your ideation process on this important topic? Which conventional interaction models could be well suited to the quantity and type of functionality concepts that your team is considering? What benefits could reusing these patterns have for your product’s success? What modifications might they require?
An architect discovers that her new building modeling application is organized by a series of different views of a project, with each view providing its own set of related functionality. Since the tool seems to have countless functions, she finds this organization method to be very clear and effective.
What advanced analogies to other types of products might your team draw upon when thinking about possible interaction models for your computing tool?
Interaction models, in the parlance of this book, are the highest level expressions of an application’s structure. The population of interaction models used in many knowledge work domains does not contain much useful “biodiversity,” and, in general, there is considerable potential for product teams to explore meaningful innovation in this area. Contemporary conventions (L2, C3) are extensively recycled, often with the expectation that these standards will drive efficiencies in product development and adoption. For many technologists, the selection of an interaction model seems to be simplistically divided between either a general, “menus on the top” workspace model, where tasks are largely open and unsequenced (B4, L1), or a “wizard” like model, where single track processes can be highly constrained (A4, C6). Within these broad categories there is considerable room for tailored solutions, and product teams can improve upon conventional approaches by specifically optimizing them around their sketched concepts for mediating work (A, C5). Concerns about interaction efficiency (D2, D3), multitasking (G5), learnability (D7, K2, K5, K6), findability (C4), and other factors, can drive teams to envision new approaches or consider leveraging specialized interaction models from other domains. Iconoclastic interaction models (L5) can be direct expressions of a product’s conceptual models (C1) or novel hybrids of different design patterns. When product teams do not actively consider divergent approaches for their applications’ interaction models, opportunities to appropriately tailor the encompassing structures of computing tools to targeted work practices can be lost. Beyond lost opportunities for targeted innovation, resulting application frameworks may not adequately support the flow of workers’ practices or sufficiently communicate a tool’s purpose, offerings, and behaviors. See also: B9, C, L, F, G2, J2, K1, K4, L4
What types of interaction models could match the embedded conceptual models in your sketched application directions? Which of your sketched functionality concepts could play a primary role in your interaction model choices? Which should probably not? How might your team tailor typical interaction model features to better support and encompass certain functionality ideas? What novel, or even iconoclastic interaction model concepts might you envision? How could these concepts embody valuable approaches for sense making, organization, and interactive flow in targeted work practices? BOTTOM TICKER: Presents collaborator status and �me sensi�ve messaging around the central database being visualized
TOP PANEL: Contains all of the controls that determine how data is visualized in the screen’s central area
What could it be like to navigate through tasks and larger activities in the interaction models that your team is considering? Which models could be more likely to provide workers with a sense of compelling engagement and accomplishment? How could requirements for multitasking, procedural efficiency, or instructional clarity influence your interaction model decisions? What impacts could different interaction model selections have on brand and branding approaches?
LEFT PANEL: Contains flexible tables that can be transformed to show several different types of rela�onships in clinical data
RIGHT PANEL: Presents saved snapshots of users’ ac�ons, allowing them to retrace and alter their naviga�on pathways
How might your interactive application scale in functionality over time? What impacts could these scaling scenarios have on your team’s interaction model choices? 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?