(Illustrated above) A scientist knows that some options in her analysis application are unavailable during intensive automated processes, such as importing large clinical data sets or running extensive analyses. Since the actions that are currently available during different states are always obvious, it is easy for her to figure out what work she can accomplish while the product is processing complex requests.

An architect indirectly learns all of the states of her building modeling application during the course a single project. She now knows that the tool behaves in special ways when it is, for example, opening a building model, creating a detailed rendering, displaying problematic areas of a design, or as occasionally happens, experiencing technical difficulties.

A financial trader expects his trading application to run at top speed whenever he turns to use it. If an issue does arise within the product’s operations, he wants the tool to be “smart” enough to detect the problem as soon as possible and then tell his team what to do about it.

What technical limitations might your team’s computing tool face when it is run on the available infrastructures of targeted organizations?

How might integration into other systems, or use of networked resources, affect goals of near real time responsiveness?

What interaction cases, looking across the breadth of your sketched functionality concepts, might benefit from an application state that could appropriately direct users’ actions?

Which interactions or automated processes in your sketched functionality concepts are likely to require processing time that workers will probably experience as a period of waiting?

What critical errors could become default application states by blocking action until they are resolved?

What set of high level states could comprehensively cover key scenarios in your team’s application concepts?

How much detail is too much detail when considering your list of application states? When might several states that are namable and very different from your team’s own perspective be better presented to your product’s users as a single state category?

How might simplicity in application states promote more accurate conceptual models of your computing tool?

What interactive pathways, due to technical requirements or defined constraints in work processes, could need to be disabled during certain states?

How might application state information be communicated both in your product’s overall framework and as part of certain functionality concepts?

Where might these state categories become too confining for variable work practices? How might constraining states be eliminated through redesign of your sketched interaction models?

Which state categories could be more appropriately envisioned at the level of interaction objects rather than presiding at the application level?

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?