100 APPLICATION ENVISIONING IDEAS | J. FACILITATING COMMUNICATION
WORKING THROUGH SCREENS
J3. Explicit Work Handoffs As part of contributing to larger activities, knowledge workers often need to formally or informally handoff their efforts to certain colleagues and stakeholders. Product teams can envision communication functionalities that could allow workers to clearly and directly deliver certain tasks or interaction objects. Examples from three knowledge work domains: A financial trader sends part of a list of offers to another trader in his group so they can divide up a larger pool of decision making and transactional effort, which needs to be resolved as soon as possible. His trading application notifies him when his colleague has accepted the request, allowing him to focus his efforts on the offers that are left on his plate (see illustration). A scientist defines a number of clinical samples in her lab’s information management application. She then assigns the task of running experiments on the samples to a particular lab technician, who will receive the task description in his prioritized queue, along with links to the sample files in question. An architect finishes another version of a large, structural arch in her building modeling application, based on feedback from a civil engineer. She then uses a feature in the modeling tool to hand the component back to the same engineer for further review and modifications.
Where and when do handoffs occur in the knowledge work practices that your team is striving to mediate? What functionality concepts might your team envision to usefully support certain “special deliveries” of application content, closely tying them to sketched features for permissions and collaboration?
I am ge�ng too many trading messages at the moment... I’ve got to delegate some of them in order to make sure that the work gets done fast enough...
More specific questions for product teams to consider while envisioning applications for knowledge work: What role do handoffs currently play in targeted tasks and larger activities? What, specifically, do targeted individuals hand off? What communication accompanies different types of handed off items?
How do specific types of handoffs fit within larger trajectories of work? Are they elements of defined work processes or improvised distributions of effort based on situational needs? What breakdowns and errors can currently occur at handoff points? Could these problems represent potential opportunities for your product?
So I’m selec�ng some parts of my list...
How might existing approaches for managing work handoffs be influenced by your team’s application concepts?
The ones that I don’t need to handle personally...
In which work practices might your computing tool provide value by integrally supporting defined handoffs?
The complex problems tackled in knowledge work organizations may require the input of several or many different individuals, roles, and skill sets. Increasing specialization can mean that workers provide their inputs sequentially, with related artifacts and responsibility being passed back and forth. Appropriate design approaches for supporting handoffs can vary based on whether they are highly structured or largely improvised. In highly structured cases (C5, C6), mediated handoffs can occur at defined points in targeted workflows (A9, C4). In improvised, emergent work scenarios (A6), options for handoffs can be provided more contextually, opening up opportunities for dynamic, shared decision making (G5, J) and the flexible offloading of effort (D2, E, A7, A8). To promote confidence (D3, G7, K13) and awareness (C7, G4) in handoff actions, teams can envision how their functionality concepts could provide workers with visibility into whether handed off items have been received, reviewed, and acted on by intended parties. When product teams do not actively consider how explicit work handoffs could factor into their application concepts, resulting products may hinder the flow of work process with unclear transitions and undesirably vague rules surrounding individuals’ responsibilities for valued work items (C9, G3). Conversely, extra functionality for explicit work handoffs may not be necessary. For example, highly concrete work processes can exist as shared organizational norms outside of computing tools, reducing related technological needs. See also: A, B, D5, H2, H3
Outside of any structured delivery points, how might your team’s sketched functionalities support workers’ more open and emergent handoff choices?
And now I’m sending those to the en�re desk to see if anyone has the �me to help me out...
What could the experience of handing off content be like? What feedback cues could allow senders to meaningfully know that their handoffs have been received, reviewed, or even acted on? Select List Recipients
I will holler in a minute if no one picks this up...
How might your team’s approaches for supporting explicit work handoffs relate to your other functionality concepts for supporting cooperation, collaboration, and workspace awareness? For tailoring views of application content to particular identities? How might handoff options be different when recipients are not users of your computing tool? How could “external” work remain clearly tied to your product? 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?
And, almost right away, I’m ge�ng a message that Jon has just taken the list, so I don’t have to think about it now... Delega�on Successful
Published on Jan 13, 2010
Working through Screens: 100 Ideas for Envisioning Powerful, Engaging, and Productive User Experiences in Knowledge Work This heavily illus...