(Illustrated above) A financial trader receives a series of automated suggestions in his trading application, based on data that he entered earlier in the day. While reviewing these automated suggestions, he can see the reasons why the application has recommended each potential trade and then make his decisions based on a wider variety of criteria that simply cannot be automated.

A scientist watches as her analysis application pulls from a number of online databases to construct a visualization. The tool color codes content based on its source, highlighting anywhere conflicting information is available from different databases so that she can make decisions about which content to use.

An architect reviews a log of actions taken by the so called “materials manager” in her building modeling application. She wants to see if she agrees with the “decisions” it made while updating a certain attribute across the entirety of a large building model.

What automations are currently part of the work practices that your team is striving to mediate? What baseline expectations do targeted workers have for visibility into automation processes?

What larger design and technology trends could influence your team’s ideas about how visibility into automation might provide value to targeted individuals and organizations?

How might a lack of automation visibility create deskilling barriers to adoption and long term success for your product?

What information about automated operations could be important in the context of different visibility scenarios?

Which of your team’s sketched automation ideas might safely remain a “black box”? At what point could pervasive visibility begin to detract from the offloading value of these functionalities?

What role might certain visibilities play during users’ initial testing of your computing tool during their adoption processes?

What value might visibility into smaller automations provide? How might this information link out to appropriate settings and instructional content?

How, specifically, could visibility into larger automated processes provide value in targeted workers’ practices? Could it primarily be used for real time monitoring or might it become more of a tool for retrospective investigation?

What specialized representations might your team envision to clearly encapsulate and communicate information about automated processes? How might the outputs of automated processes bear meaningful and traceable “signatures” of their creation?

How might early experiences of transparency help knowledge workers build appropriate conceptual models of automation functionalities?

How could refined automation transparency help workers to recover from any critical incidents and standard error cases? How might your visibility concepts tie into your sketched design responses for error handling and functional histories?

What customization options could allow targeted individuals and organizations to tailor automation visibility to meet their local needs?

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?