(Illustrated above) A financial trader no longer has to cut and paste information between his trading application and a secondary tool. His firm’s IT staff has coded an automation that has removed these frequent, tedious tasks from his day, opening up more time for him to focus on trading and analyzing market trends.

An architect asked her IT department to develop a small addition for their studio’s building modeling application. This new option allows her to view building model data in the context of project budgeting data.

A scientist makes vendor selection decisions based in part on her desire to have her entire clinical lab’s operations integrated into a unified clinical data repository. She looks at potential products as collections of functionality that could be integrated into that central system.

Which computing tools do targeted individuals primarily use, given the larger constellation of technologies that are available to them?

What role do each of these tools play within your team’s targeted tasks and larger activities?

How do knowledge workers currently coordinate their various onscreen applications to accomplish their goals in different scenarios?

Which interoperations between computing tools are frequent and standard enough — and outside the core of enjoyable, valued, thinking work — to represent opportunities for integration and automated interoperation?

What integrations and custom extensions are already present in targeted workers’ environments? Who accomplished these highly technical feats? What successes and problems did they have along the way?

Where might your team’s sketched strategic directions suggest “open” and networked approaches to other technologies in targeted workers’ environments? At what point might your product and brand become “too invisible” due to integration or “too mutated” by local modifications?

What market trends and technological realities might your team consider when ideating around the technical openness of your application concepts?

What attitudes and expectations do targeted individuals and organizations have about how open their chosen tools should be to systemic connection and custom improvements?

How features might allow your application become a platform for innovative local solutions? What specific points of technical openness could provide value?

How might your team effectively document and publish technical interfaces and code? What additional support and services might you provide?

What vulnerabilities and security problems might be created by opening up your product to outside integration and extension? How could your envisioned design responses mitigate some or all of these risks?

How might your team eventually learn from the changes that your users will presumably make based on technical openings in your computing tool? How could you promote community sharing of these local innovations?

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?