(Illustrated above) An architect runs a tolerance checking function in her building modeling application to check whether one section of a design meets a specific building code. Where the automated function discovers a potential violation, it gives her the opportunity to ignore the finding based on her own interpretation of the particular code’s description.

A scientist likes that the latest version of her analysis application allows her to intervene in real time when she sees that automated algorithms are not producing desired outcomes. In the previous version of the same application, she could not interrupt lengthy analyses to make changes.

A financial trader turns off the automatic trading function in his trading application, which normally takes care of low value, uncontroversial transactions. Accomplishing these deals manually, when he has time, gives him a better sense of his group’s standard business.

What automations are currently part of the work practices that your team is striving to mediate? What do targeted individuals think about their level of control over these technologies?

What problems currently occur due to workers feeling that they are being “controlled” or “reined in” by certain standardized artifacts and computing tools? Could these problems present opportunities for your team’s product?

What categorical classes of local needs in targeted organizations might influence workers perceptions of control and augmenting alignment?

What analogies and language might your team use to describe the relationship between user and product that you are striving to create? What implications could this described relationship have on brand?

How might you envision automation functionalities as actionable extensions of workers’ skills, rather than distant and self operating replacements for them?

How could thinking about automation as just “another tool” in workers’ available repertoires allow your team to sketch more appropriate functionality concepts?

How might a lack of control over certain aspects of your product create deskilling barriers to its adoption and long term success?

How might desired levels of control change over time as users increasingly trust your computing tool?

What settings and options might your team envision to give targeted individuals and organizations meaningful influence over automation functionalities in the context of their local ways of working?

What interactive scenarios and behaviors might provide users with a direct and engaging sense of control over your computing tool’s actions?

How much control might be too much control? What constraints could usefully promote reductions in effort, clarified interactive experiences, reduced likelihood of errors, and the confident creation of desired outputs?

What contexts could require automation to be highly standardized, rather than modifiable on a case by case basis at the discretion of individual workers?

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?