By Brian Still
This column examines the ways technical communicators contribute to the development of more usable products, especially those used in complex, dynamic environments. Novel usability evaluation methods and design techniques, as well as those rediscovered or repurposed, will be the focus. Please send your comments, questions, and suggestions for future articles to me at brian.still@ttu.edu.
Amish Patel, managing partner of L3ARN, has a real challenge on his hands. L3ARN provides usability, learning, and development solutions for Fortune 500 companies that rely on Enterprise Resource Planning (ERP) software systems, such as SAP, to manage their vast, complex, and always-changing data structures. SAP, in particular, has been a great boon to global companies because it enables multiple users, administrators, business analysts, and, yes, even consumers, to access data through a variety of interfaces—data that can be changed, real time, because time is money, and guaranteeing (in theory) accurate, always-accessible data is absolutely necessary to run a successful business.
The problem, however, and one that Amish and his L3ARN team are taking on, is that SAP usability is difficult and challenging. An SAP might allow, for example, a new employee to be added across the system, but such an action typically takes multiple steps, and those steps take time and also open up the possibility for the kind of error that then is unleashed throughout the system to cause child problems that begat more problems and so on.
SAP, because of how it works structurally, is also very resistant to the typical usability approaches that would have evaluators test and modify a Web or mobile phone screen to make the GUI more usable. Much of the SAP interface is dependent on the application layer, resting between the presentation layer and the database layer, and the application layer isn’t easily customized. Customizations, in fact, are time-consuming and expensive, and often when done they can cause problems. SAPs’ applications are always being upgraded, which is great, but that upgrade often wipes out or conflicts with any customizations done between versions.
SAP has heard enough feedback about this and other usability issues that it is responding now to add in more flexibility to customize interfaces and application settings. But that still, most likely, won’t go far enough, which is where Patel and his company come in. The challenge is big and unique, but I like L3ARN’s approach because it offers lessons and reminders for those of us faced with evaluating and improving the usability of a variety of different products.
L3ARN is focusing on developing software solutions outside the SAP that allow scripts to be run to carry out tasks, such as adding an employee or changing an item’s price on a material list faster, and thus more effectively. It isn’t perfect but is a workaround that displays adaptability and originality. L3ARN is also not just going into companies and telling them what’s wrong with an interface and leaving. Since programmers inside can’t affect changes to correct usability issues without a lot of work (that might get overridden anyway), L3ARN is developing and offering solutions that include user training. Lastly, it is focusing on the use process overall, mapping out how users use applications and where they use them, and it is putting into place mechanisms for gathering data that allow SAP administrators at the companies to monitor transactions and other user data, thereby allowing them to think proactively about what solutions may be implemented, and what impact these solutions may have after implementation. "Realistically, usability is the key for both learning and IT managers so that more training will not be needed in some cases," Patel said. "In the past, we were unable to offer meaningful solutions, but now through our end user learning experiences and technology we think we can offer a more permanent solution for customers with user specific agile solutions."
Usability, after all, just isn’t about interface. That’s right. I wrote that. It isn’t just about navigation and content layout. Obviously, a usable product must have an effective interface. No one would ever say that such things, and testing for them, isn’t important. But they’re not everything. In fact, if we move too quickly just to correct the issues we find with them, we forego what I think is just as necessary, and that is a careful examination of the user experience process.
How did developers think about users when developing the product? How do users use the product? How are users involved in designing the product they will use? Is the process top-down or more user-centric where, even if the core structure can’t be changed, considerations are given for how user needs can be accommodated through other means, such as training and support?
No amount of testing will ever help a system if the process isn’t addressed, because once a new product version replaces the old one the same issues corrected after the fact for the old product will be there for the new one. This is all the more true for those situations where evaluators are given little flexibility to make major recommendations, as is the case for those working in the SAP environment.
A user-centered process goes beyond testing five users by carrying out a series of tasks in a single test. It is more than problem finding. Rather, it assumes problems aren’t finite, so testing just to find them is a zero-sum game—new ones will just crop up, and without an understanding of how things work, how users use the product in the environment, problems will continue.
Really, this is a more ecological approach. An effort is made to understand how everything within the system, users, and product interacts. Eventually, once the system is mapped and the processes of use within it better understood, models are created which allow the usability evaluators to experiment by testing out different approaches, layouts, navigation, etc. The assumption—and this is key—is that a system just can’t be thrown away. Just as we can’t do away with a species, or re-introduce one, in a system because that will have negative effects, we can’t throw out a website or ERP because we don’t like it. Too many times usability has advocated for this because problem-finding was more important than process monitoring and enhancement. If we accept that the system is there to stay, as is the case for the SAP, then we need to find ways to understand how it works and then model solutions for it that involve modifications to the system, not deconstruction. Yes, obvious usability problems that impede use need to be addressed, but not every situation allows for them to be addressed by modifying or doing away with a bad interface. Changing the way use is viewed, how things are made for users, and how users are supported and trained may be highly valuable alternatives for addressing causes as much as effects within the framework of an entire system.
