It’s Friday. Mary the mailroom clerk scans an invoice into the system and makes sure it is coded with the vendor and project code. Thank goodness for the new straight-through-processing workflow-enabled application toolbelt (SWEAT) system put in by Big Consulting, Inc. (BCI) as part of a business process automation project. SWEAT routes the batch of data to Bob, the project manager who then approves the invoice on behalf of his project. SWEAT then sends it to Joe in accounting for payment generation.
It’s now Monday morning. Joe opens the approval screen, but realizes he needs to see past invoices and credit memos from BCI to ensure this invoice is payable, so he opens the handy SWEAT credit memos screen. It has two credit memos that may be relevant, but Joe doesn’t know if he can just subtract the credit memo amounts from the invoice. He tried to contact Bob to get the contract details; to do that, he has to look up Bob’s extension, dial Bob, realize Bob is not there and write an email. While doing so, he pops up a calculator to get the exact difference between the credit memos and the invoice so he can be specific about the numbers with Bob. He gets an email back saying that Bob is on vacation this week, and repeats the whole cycle to identify who Bob’s alternate is, write an email and wait for a response.
The first two steps (Mary and Bob) took a total of 90 seconds but the third step has taken nearly twenty minutes and the invoice is still not approved for payment. However, the workflow automation worked flawlessly. What happened?
The answer is that the process doesn’t break down in workflow; it breaks down at the execution level of an individual step. This is in fact not an actual individual step but a complex series of tasks that is not well supported by the system described: information that should be in context with the task (project manager contact info and alternate info, totals of previous invoices and credit memos, reconciliation terms) are not available, forcing the user to perform manual workarounds, access other systems, cross-map information from different systems in his head, and so on. The misconception that business process automation (BPA) happens only between people is at the heart of why many business process automation projects fail to deliver maximum impact.
As a discipline that helps to optimize how individuals perform work in the context of their digital and non-digital environments, User Experience (UX) Design is the discipline that is both least utilized and most needed during business process analysis and re-engineering, and certainly during design of business process automation solutions.
UX Design results in highly visual artifacts: site maps, wireframes (low-fidelity screen designs focused on information availability and task flows), detailed design compositions (high fidelity screen designs focused on visual style: spacing, color and emphasis, typography, photography and graphics).
The UX discipline includes exercises which can identify system design problems early. Prototype walk-throughs and design reviews often prompt users to point out requirements gaps which were missed in use cases.
The case for using UX early in the process is quite compelling. UX Design can:
-Identify gaps in data availability and inform data mastery and data management architecture.
-Ensure that role requirements are accurately captured, not simply requirements for how the roles will collaborate.
-Engage users visually and ensure that the verbose and often tedious use case documentation does not get in the way of users identifying and pointing out requirements gaps.
-Foster collaboration with a major project by “bringing people along” on the journey in a visible, accessible way, ensuring business buy-in across what is often a challenging up-and-down trail of challenges and triumphs.
-Help control scope by creating accessible, visual artifacts which depict scope and around which clear, concrete discussions can be held about the real needs behind each screen element.
-Improve outsourced development by increasing the clarity with which scope is communicated between the client firm and the outsourced development team.
Business processes are made up of individuals performing tasks large and small, simple and complex, and then packaging the result for use by others. These packages are the stuff of Business Process Rengineering and Automation, but what’s inside the packages is the stuff of UX. Greater understanding of this reality and greater engagement of UX will result in smarter projects and, finally, more efficient and effective enterprises.
How is redoing a bathroom like building an application? The tools may be different, but a lot of the principles of working with contractors are the same. When we meet...
Today your usual hosts (Liz Flyntz, Director of UX & Design and Jonathan Blessing, CEO) are joined by Bart Michalek, head of DOOR3’s Business Analysis practice and BA Zev Gottdiener....