Application Envisioning idea
Examples from three knowledge work domains:
(Illustrated above) A scientist logs into her analysis application to view data in one of her lab’s clinical studies, knowing that her login identity will allow her to use all of the tool’s many options. She has organized this same study’s permissions so that technicians in her lab can only use the analysis tool to upload their completed experiments and
manually check the quality of their data.
Knowledge workers enacting different roles within an organization may perform different activities (C6) or contribute to the same activity via separate goals and practices (A7, A8). In the context of these established divisions in responsibilities, organizations may have specific requirements for segmenting an interactive application’s scope to meaningfully suit categorized identities in their workforces (A1, A2). Permissions
features in computing tools can shape each user’s ability to see and make use of
certain data and interaction options.
An architect sets up the permissions of a new project in her building modeling
application to have different views and options for other architects working on the project; external consultants, such as civil engineers; and even the project’s client, who will only be able to view building plans and renderings generated at certain project milestones.
A financial trader knows that, within the trading application that he uses every day, there are data views that are only available to his bosses.
Product teams can envision permissions concepts that map to key segmentation needs and desired levels of flexibility. Teams can also sketch structural approaches for tailoring application views to the needs of different user segments, displaying available functionality (A9) and content (B5, B7) in specialized interface layouts and relevant representational forms (F).
When product teams do not adequately consider the potential role of application permissions and views tailored to workers’ identities, opportunities to clarify interactions for different audience segments can be lost. Resulting applications may not contain valuable barriers to access that can be essential for supporting specific cultures of work (C8). Some individuals may find that these products present content and functionality intended for “too many different people” at the same time, making these tools excessively effortful to learn and use effectively (D2, D3, K2, K6) without crossing role based boundaries and committing errors (D4, D4, G3).
Conversely, when permissions and tailored views are applied without sufficiently considering potential impacts on collaboration between roles (C7, G4), workers may find
it more difficult to establish common ground for communication (F1, J2).
See also: A, B8, C, G7, J, M
Application Envisioning questions:
More specific questions for product teams to consider:
What divisions of labor do targeted organizations currently prescribe for the work practices that your team is striving to mediate? What rules currently dictate access to certain workplace artifacts?
How are workers’ identities currently managed within targeted organizations?
How important, relatively, is the security of these identities?
How flexible or prescriptive are different individuals’ roles in observed practice? Do they actually correspond to organizational chart abstractions, or are targeted workers bigger generalists than they often realize or admit?
What larger design and technology trends could influence your team’s ideation on the topic of identity management approaches?
How might your team model existing power relationships and levels of responsibility within targeted organizations in relation to your sketched application concepts?
Which functional areas and interaction objects stand out as “belonging” to some categories of specialized workers but not to others?
At what point does it make sense for your team to start thinking of specialized, role based permission sets as fundamentally different views your application, rather than the same interactive frame with some features turned on or off?
How might separate, permissions based views drive desirable simplicity and decreased learning effort?
Where might the splintering of a computing tool into different views introduce undesirable limitations on individual action, opportunities for mode errors,
and other breakdowns?
What impact could identity based segmentations have on the larger conceptual
and interaction models of your sketched products?
What implications could divergent application views have for collaboration and communication within your computing tool? How will workers maintain common ground?
How might your team’s approaches for permissions and identity based views relate to your functionality concepts supporting cooperation, collaboration,
and workspace awareness?
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