(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.

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.

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?