Inbox & Notifications

Video, 12:56

Text equivalent: Hi, I'm David Bingham. I'm a designer here at Workday. I'm going to walk you through a presentation that I put together around the inbox and notifications concept. This talk will be just a little over 10 minutes. There are going to be a lot more words on screen than I'm going to read, so feel free to pause and read some of the details. This presentation outlines experiential problems with Workday's inbox and notification system. It depicts a future system that addresses these problems, as told by a to-do traveling through a workflow. The story ends by outlining project areas that contribute to the realization of this experience. In the past year, we've had a number of customer conversations that have contributed to and inspired this outline in some way, shape, or form. The first big problem that we're addressing here is around inbox and notifications being confusingly similar, without a very clear and consistent relationship. The second big problem is that Workday's notifications follow a different model than contemporary notification systems; it's also not very tied out with a lot of external notification systems. Third, customers want to address inbox content with better information in the context of their role, be it an employee, or a manager, or some profession. Fourth, management of notifications and channel preferences is neither intuitive nor scalable. To guide some of the design direction, we've put together a few design principles. The first one is around being action-oriented, where the inbox becomes the user's queue of to-dos. The second is around workflow representation, where individual inbox items represent the entirety of a single workflow. In user awareness, notifications are the messaging extension of an inbox item. And lastly, respecting context: inbox items surfaced in Workday products and through notification channels respect the context and capabilities of that particular medium. So all of this was put together into a diagram that will tell a story addressing these problems and leveraging our various design principles. We'll follow the path of our to-do friend through definition by a Workday app team, creation by an initiator, and inputs from assignees. To understand what those roles mean, I built a legend that defines the key people and components used to describe the concept. There are green people, who are part of my fictional Dot Co company. The primary groups here are assignees, which is any individual assigned to a to-do; an initiator, that is any person that generates a to-do; and a channel admin, who provisions channels available to assignees, and may also inject company-wide branding and imagery for use in those channels. Blue people are Workday employees. There's only really one here, and that's the application development team. It builds applications used by initiators to generate to-dos. There are some objects and abstractions of key software components and parameter definitions within the Workday to-do workflow. There are applications. There are to-dos, which I am defining as an actual assignment, created by an initiator for an assignee. And as a point of clarification, there are tasks, there's a formal notion of to-dos, there are items coming off of business processes, there are surveys that go through notifications. I'm including all of those together as the total list of things and generically calling them just a to-do: any unit of work for an assignee. We'll also touch on notification designs, task schemas, audience definition, and user preferences. A notification is a to-do related message delivered via a channel to an assignee. And we have a number of channels here that we'll touch on. Some of them exist now. Some of them might be included in the future. So let's start. The Workday app dev team defines to-dos and the default notification design. They build their application and associate the type of decision that needs to be made with that to-do, the default message that might get sent out with a notification, and the way that message links back into the Workday system, to the right place to execute whatever the to-do is requesting. They publish their application to the Workday cloud. The channel admin provisions tenant channels and inputs company-wide communication assets. So they decide what channels will be used. They might add some additional company-wide branding, some other imagery that's licensed for use, for sending out more detailed and nicer notifications. An initiator creates a to-do from the application. They preview the notification design and edit it to suit before launching the to-do. The to-do goes out and checks the first assignee's preferences, and a notification is sent to the preferred channel using the associated notification design. The assignee receives a notification, in this case on their mobile device, as their preference, and they provide the requested input. In this case, the approval is now appended to the to-do, and the to-do moves on to the next assignee. It checks their notification preferences, and a notification is sent to that assignee's preferred channel, again using the associated notification design. The assignee gets a cursory understanding of the need and clicks the included link. So from their email, when they view that link, they're routed to the best available location to complete that to-do. Within the Workday cloud, as they're moving into the Workday environment, they traditionally come to the inbox or view that task page, and that's the generalized, current fallback for all things. In the future, as we move towards specialized or more ideal hubs and application spaces, this routing may be able to evolve to point people to those better tools that Workday has provided for them. Ultimately, the assignee provides the requested input, and it moves on to the next assignee. And I think you get the picture. In this last one, though, as the assignee views the notification, they are taken to the place where they're requested to provide their input, and they can view all the relevant information for the to-do type, formatted to whatever device they have. So as they view this in detail, they can see the steps taken prior to their receiving this to-do, and what comes after they complete it, on its way to completion. This continues until the to-do completes, collecting information and inputs from the assignees. But now let's review what is needed to make this journey possible. I've put together seven identified areas contributing to the realization of this experience, and I'll walk through each of these. Inbox Search is a funded program that is helping to improve discoverability of items within the inbox. It's focused primarily on the current inbox itself, but as we figure out ways to surface these items, that may trickle out from the inbox into other areas that I'll discuss. Second is around inbox tagging and taxonomy. This is: as a to-do flows through Workday, how might we tag it for users to group, type, and discover? The left half of this is a technical endeavor, to make sure that we've got the right metadata and information associated to those to-dos, and then additional data collected as it moves through the process. The right half of this is much more around human decision-making types, and understanding what information is needed in order for people to make the most informed decision. The third item here is around audience creation. This is really to ensure that the right inclusion and exclusion logic is defined in order for to-dos in any sense, could be learning, could be recruiting, could be finance, to be sent to the right people. Fourth is around notification designer. The problem here is expanding from the v1 focus on email: how might we allow initiators to create channel-agnostic notifications? This is really spreading out from email into the variety of channels that need some sort of design and formatting as appropriate to those channels. As we get closer to the core message, I believe the initiator needs to focus on that message, and then borrow some of the enrichments and channel specifics that were defined earlier on, and then assign those and preview those in the various channels that are available on their tenant. The fifth one is around notification communication control, or user preferences. The problem here is keeping users engaged but not overwhelmed: how might we structure a scalable notification control module? If we try to do this by each to-do, by each channel, within each application, it's going to become very, very overwhelming, but we do need a way to allow channel admins to require certain channels and set good defaults. As more sources and more to-dos come online and more channels become available, it's going to become very overwhelming, and we need a model that allows people to stay in control, learns from their interaction patterns, and aligns notifications to their schedule. Some sample models might be how we think of this in terms of point in workflow, or how we associate critical to-dos to the immediacy of some channels, where push notifications tend to come quite immediately, while email tends to be a little bit more passive. We might think of this around due dates for to-dos. But in either case, we need to find a balance in order to get attention where it is both most critical and most urgent. The sixth is around content, where we need to make sure that the right information is there for each of these types of task schemas to support good decision-making. And lastly is the design system question: as the inbox moves into more spaces across Workday, how might we keep engagement with to-dos scalable and consistent? Now, these seven areas are very interrelated to the success of each other. Audience definition is used in notification design. The schemas can action from the notification in some cases. The schemas will inform content and layout. That content and layout will be broken up into various components in our design system. And preferences relate to the various schemas and channels. So, some next steps to consider. We'd like to go and validate the inbox and notifications model with key stakeholders. We want to find top task workflows and pressure-test this model, to see where it falls apart, where it succeeds, or things we just haven't thought about. We need to refine these supporting project areas and detail design briefs for them. And then lastly, as this becomes a priority or formal initiative, define resourcing needs, assignments, and metrics for success. That's all. Thank you. Please reach out if you have any questions.

1. 1Inbox Search $$
2. 2Item Metadata & Tagging $$
3. 3Audience Creation ✔
4. 4Notification Design ✔
5. 5Notification Preferences
6. 6Content Strategy
7. 7Design System Integration

$$ Funding Secured
✔ Strategy Alignment