Over the last year, I’ve seen some interesting commentary, particularly in the DevOps community, around the concept of workflow tickets.
I was reminded of this yesterday by Rob England (aka @theitskeptic), on reading his recent Kill the Ticket article. This article, in turn, links to a passionately argued Damon Edwards blog, Tickets Make Life Unnecessarily Miserable. Perhaps, argues Edwards…
“…ticket queues (are) a significant source of operational strife hiding in plain sight?”
I don’t disagree with this suggestion, but I don’t see tickets themselves as the fundamental cause of the problems described in Edwards’s article. My own view, reinforced by my work with really great UX people over the last few years, is that those problems are a result of two significant failings: the way system interfaces are built around those tickets, and the way work is organised around them.
I’m a big fan of Peter Johnson’s deconstructive way of approaching a conversation like this, so this seems a good time to get to the heart of what a ticket is, and why they are in such common use.
The ancestor of the “ticket” used in electronic systems of record and activity is the simple paper form. Before the widespread adoption of computerised business systems, paper forms were a very common communication medium around which workflow processes were built. Often written on typewriters and embellished with ruler and ink, they’d be photocopied, completed by hand, and passed on to the physical in-tray of the next actor in a documented process. At some point, the data might be input into a spreadsheet or database, but prior to that, the paper was a vehicle through which the data… and people’s response to that data… shaped and adapted, often very slowly.
The emergence of business IT systems, and the appearance of a personal computer on each knowledge worker’s desk, changed things, though arguably not much. The data fields on those paper forms became the database tables underpinning business software applications. The database tables were represented back to users as on-screen forms… typically a collection of fields, structured in a none-too-dissimilar way to the paper forms which they were replacing.
Initially rendered in the green glow of terminal screens and tabbed-around with the keyboard, the paper form metaphor became arguably even stronger in the Windows era, with skeumorphic form designs, and mouse-pointer interactions with widgets like tabs and check-boxes, many translated almost verbatim from the physical stationery being replaced.
Digitisation of those forms provided some big improvements over paper, of course. Transmission became instant, replacing the slow passage of the internal office memorandum envelope through cumbersome internal mail systems. Data consistency could be promoted through the use of selection menus and field data entry rules. Buttons and other controls allowed more intricate interaction with the interface. But the design was still effectively nothing more than a dumping of some or all of the columns of a database record onto the screen, rendered in the style of a paper from. User experience wasn’t a primary consideration: it was about data first and foremost.
Unfortunately, that user experience tended to be pretty awful. Here is is just part of the sequence of web forms which I used to use to book a car from our San Jose office, in California, to San Francisco airport:
These forms, about five in total, forced me to make one painstaking field-entry at a time, even imploring “Wait, don’t leave!” if the process was abandoned (I’m serious).
To a business systems creator like myself, it’s pretty clear what is happening here: a ticket is being created to record and track the job of taking me to the airport. Some of these fields are obviously important to the service provider (they obviously need to know where to pick me up, and when), while some are of dubious value, but they’re all exposed. As the customer, I’m being asked to key in many of the columns of the database row which will hold the ticket. The ticket disappears into a work queue, and I hope for the best.
Then, one day, this came along:
Uber may have some reputational issues, but it is still a strong example of good user experience. There’s still a ticket, but it is not made painfully obvious that it is there. As a user, all I need to do is hit a button — even the destination field is optional. I don’t need to submit the ticket far in advance, either: the queue is replaced by a more immediate experience, backed up with sufficient feedback to give me reasonable confidence that the process is working (even if an Uber “minute” often seems more like three real life minutes!).
There is no reason we should not tackle the same issues in our business systems. At BMC, for a number of years now, we’ve aggressively challenged the form metaphor. Users of our Digital Workplace product can request services in many straightforward ways, none of which looks like a paper form transposed to the screen. Instead, they click single buttons, or enter a simple search string which guides them to a lean interface requiring only the minimum data input to create a request.
We’ve done the same for the service agents who support them. The phrase “Sorry, I’ve just got to take down some details” is remarkably common in service engagements. You hear it more than you realise. It’s a painful example of the form representation of the service ticket actually being a driver for sub-optimal behaviour. After observing its use time after time in service desk observation sessions, we responded by reducing the incident logging interface to a single input field. Removing the complexity from these interactions, in favour of a “formless” interface, abstracts away the database row and significantly improves people’s day. The interface fits the user’s task. The system does the data entry.
Uber, at first glance, also eliminates queues (though one might argue that if no driver is available, you’re most definitely in a queue, and a chaotic luck-of-the-draw queue at that). These are another key target of Edwards’s frustration (though by his own admission, his article somewhat interchangeably talks of ticket and queues). He’s right about the issues that come with them. Queues, he points out…
“…add delay, increase risks, add variability, add overhead, lower quality, and decrease motivation”.
Customer service management industries (including IT service management) have long implemented tiered support structures and work-handover practices built around the transfer of tickets from one assignment bucket to another. The queue, again, is a metaphor for a physical entity: the recipient’s on-desk in-tray. Just as a paper form gets passed to a single team or individual, so does the electronic workflow ticket.
As a result, the technical fix you need might have trickle down through several levels of support before it gets to the technical specialists who need to work on it. When it gets there, it might bounce around from specialist to specialist before any real progress is made. I’ve explored this challenge at length in the context of an alternative — Swarming (there’s a shorter take here at bmc.com), and my years-old blog about the “ticket tennis” problem feels as relevant today as it did back then.
I worry, though, that if it’s the ticket that is the target of our ire, then we are not actually focusing on the problem. We need to recognise the importance of what the ticket itself represents: a discrete unit of work, and its current state within its expected lifespan. Tickets are not the problem. The user experience and behaviour that has built up around them is the problem. And tickets don’t themselves cause queues to happen: If tickets are getting stuck in queues, this is not a fundamental property of a “ticket”: it is the result of the way we organise people and processes around them.
We’ll always find queues. After all, we can’t do everything at once, and service work comes in at irregular intervals with varying priorities. It has taken the DevOps movement, with its underpinnings in lean manufacturer, to recognise that those queues themselves can be a fundamental problem. In Lean terms, they are unfinished goods sitting idle rather than receiving the attention they need.
But trying to remove tickets and queues begs the question of what they’ll be replaced with. I’d argue that there is still a need to represent atomic units of work. Doing so has great value. A ticket creates a definitive record of work. It enables prioritisation, communicates the current state of the task to anyone who needs to know, and even enables higher value behaviours such as exploration of supporting resources like knowledge articles. Even once the work is complete, and a live ticket goes dead, the body of recorded tickets provides great value, in the form of data analytics (a practice that is particularly advanced in the retail sector, where your purchases, however smoothly enabled through modern payment systems, each generate a detailed ticket of data). Perhaps there is scope for more sophistication in the structure of the records themselves: a shift from a predefined database row into something more fluid, but this doesn’t feel like the priority. Tickets and queues will still happen.
The key to improvement is to abstract away the tickets: to shift work upwards from the atomic data record, towards a representation aligned to the actual work that people or automated systems do. For example, where a cluster of tickets represents a single situation, requiring a single response, we should present that overarching need rather than a granular and uncorrelated list. Collaboration methods such as swarming can replace repeated individual reassignments. High quality user experience design in our business workflow systems ensures that they present work in a leaner, more human way. Where queues build, dynamic reallocation of resources aimed directly at preventing their unhealthy growth, transforms them from a simple work stack to a tool for process improvement.
The problem, in short, isn’t tickets. Tickets are simple and pretty fundamental. The big problem is the behaviours that have built up around them.
(interdepartmental envelope image adapted from https://www.flickr.com/photos/adrianblack/2366979251/ under Creative Commons license)