Application Envisioning idea
C6.

Some cooperative processes in knowledge work can be supported by computing functionalities that facilitate entire sequences of standardized effort. Product teams can envision functionality concepts that could valuably distribute segments of larger work processes among multiple users; however, restrictive workflows may not always be an appropriate
design response.

Examples from three knowledge work domains:
(Illustrated above) A financial trader wants to execute a trade that is so large that it requires signoff from his manager. The trading application displays a large notification on the manager’s screen, and the two coworkers shout back and forth across the trading floor about the merits of the potential deal. Eventually, the manager indicates his approval in his own view of the trading application, which then executes the
pending transaction.
A scientist sets up a work request in her lab’s information management application so that a certain technician will rerun some clinical samples. When the technician receives this work request, he can quickly translate the experimental protocol into his own laboratory processes, run the samples, and then upload the new data for the scientist to review.
An architect defines a standardized workflow in her building modeling application that will usefully drive how her team collaboratively uploads, evaluates, and categorizes early ideas for a new building project.
Established practices in knowledge work professions may bear little resemblance, either literally or in spirit, to highly standardized, “scientifically managed” assembly lines. It can be important to recognize, however, that even within otherwise variable activities (A7, A8) there may exist some consistent, sequential segments of established and
repeated work process (A4). Requirements for these workflow standardizations can arise from individual workers, their organizations, or larger communities of practice.
Product teams’ concepts for mediating workflow processes can have substantial impacts on their sketched ideas for cross functional application frameworks (C1, C2). Computer mediated workflows can outline the number and type of steps to be completed, levels of instructiveness (K2, K7), how handoffs will occur (C5, G7, J3), and many other important factors. Knowledge workers may value how these process oriented functionalities reduce undesired effort through automation (E3, E4) and distribution of efforts to colleagues (J). Appropriate workflow tools may also improve the predictability and quality of cooperative outputs (C9, G3, L1).
When product teams do not actively consider the potential role of standardized workflows in their application concepts, opportunities to translate existing workflows, or to create new value in workers’ experiences of larger processes, can be lost.
Conversely, highly skilled knowledge workers may not always value novel standardization that is rooted in distant notions of efficiency, such as those sometimes outlined
in the name of “business process redesign” (D1, G5).
See also: A, B3, B5, C, D, E, F1, K1, K3, M

Application Envisioning questions:
What portions of the knowledge work that your team is targeting truly follow standardized and routine processes —
but still require human judgment and action? How might your application concepts meaningfully structure and usefully reduce burdens in these procedural flows for all involved?
More specific questions for product teams to consider:
Which tasks or larger activities that your team is striving to mediate are currently part of standardized workflow processes?
What other artifacts and technologies are involved in these processes?
What value do current workflows provide in targeted organizations?
What are the individual measures of success for different segments of existing workflows? For entire workflows?
What work processes do both knowledge workers and their organizations want to standardize further? Where might organizational goals for workflow crystallization show a clear mismatch with workers’ goals and preferred ways of practicing?
How could your application concepts maintain or expand upon the value of existing workflow processes? How might they provide valuable new workflow options?
When might it be more appropriate to support structured work with integrated communication channels and clear object ownership rules, rather than regimented and inflexible workflow tools?
How much visibility might workers want into their colleagues’ activities and workflow contributions? What value could this visibility provide?
How might separate workflow views for different contributors drive desirable simplicity and decreased learning effort?
How might your team’s sketched workflow functionalities support interpersonal interaction and communication at key junctures?
What role could flexibility and customization play in your workflow concepts?
At what point might desirable variabilities challenge the usefulness and viability
of standardized workflow functionality?
What impact could extensive workflow offerings have on the larger conceptual
and interaction models of your sketched products?
How might your team’s approaches for standardized workflows relate to your functionality concepts supporting permissions, identity tailored views, 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?
< PREVIOUS PAGE | NEXT PAGE >

Back to top | View Table of Contents
|