You will have heard of enterprise software systems, most probably you’ll have used one or the other system yourself. They usually have a bad reputation ? difficult to handle, cumbersome, sometimes of little relevance for the task at hand. Basically, most of these issues are usability-related. A typical after-work conversation may go:
– We’ve just implemented XYZ. And I hate it.
– Oh! That’s tough ? same here (or at a friend’s company, or ?)
Sometimes it feels like this conversation is part of the software implementation package ? as though people only fulfilled the expectations posed upon them by the situation. And while the ERP companies themselves are doing quite nicely business-wise, their products’ reputation still suffers.
But wait ? aren’t the vendors doing anything about it? Have there not been initiatives within SAP, IBM, Oracle, ? to improve the usability? Definitely. All of these companies have invested heavily in usability (and continue to do so).
Usability Engineering as Part of the Software Development Process
Usability engineers in the software development process have an interesting and challenging position. They need to understand the (rather complex and constantly changing) business requirements, translate them into application front-ends taking into account the possibilities and limitations of the technology, and negotiate with development on front-end-related priorities. Oftentimes, they engage in usability testing and / or reviews as well, feeding back user input into the application design team. And user research (via Contextual Inquiry or comparable field studies) becomes a more and more important area as well.
Application front-end design is a process of identifying the best compromise for a multitude of infinitesimal design problems: finding the best possible solution in a force field of different requirements and positions on the basis of a given technological background. When the usability engineer does her job well, the technologies’ possibilities are leveraged to their max, creating a solution that supports the users optimally in doing their job and thus contributing to their companies’ success. Usually, a solution has reached a certain (satisfactory) level of maturity before it is released; it has been tested extensively, and user research has been conducted to get solid support for design decisions. But then, why is it that users dislike using the software after this amount of user-centered work?
Enterprise Software is special in that it is never used in an off-the-shelf way. Through a long and thorough process, the software is “customized”, i.e. adapted to the processes and structures within the target company. This process deeply changes the software that came in the original software package. In fact, the instances of a software package used in two different companies can be very different, nearly incomparable.
Usability Engineering during Implementation and Customizing
Basically, the software in engineered a second time at the customer’s site. If things go well, there is a user experience specialist on the customization team, conducting field work, aggregating and prioritizing requirements and negotiating with project management on how to implement certain features. More often than not, this is not the case, and the requirements from the business are translated into code (and UIs) by technology consultants. As a user experience pro, it’s difficult to get a stand on an implementation project because they tend to be under much higher pressure than the development projects. You will have had to convince your project lead first and the customer second to take you on the team. You’ll have to prove that your works adds value and improves the final solution, and often the UX work will only be part of your role (i.e., you’ll be working on visual design adaptation, change management etc. in addition to the user experience aspects). As far as the level of commitment to and awareness of user-centeredness is concerned, the consulting business is quite a bit below the level typical development units have achieved in the last couple of years. To my experience, it’s the exception rather than the rule that a dedicated UX pro is part of the implementation team.
This is understandable. Implementation projects are always under time and money pressure. “Typical” UX work with ethnographic studies and several iteration cycles doesn’t seem to fit into these constraints. What is needed is an understanding on the consultancy’s and the customers’ side that user experience design in implementation projects needs to be taken care of ? that the changes to the software affect the user experience and usability. The implementation team needs tools to support discount usability engineering and ways to ensure decent usability even if the project has been staffed without a UX pro. (The B?ro f?r Arbeits- und Organisationspychologie (BAO), Berlin have conducted some research projects on ergonomic customizing of SAP software.)
A Solution: UI Patterns
We’ve got a dilemma here: The software company invests in usability engineering for a “raw” product but cannot foresee all possible changes. The implementation partner can only move within the time and money constraints set by the customer and within the boundaries set by the limitations and possibilities of the software. And the customer cannot spend any more money on the project and expect it to deliver good quality.
The UI patterns approach might be a solution to his dilemma.
The software company needs to change their software to be UI patterns-based. The patterns would have to encapsulate UI best practice, no matter how they are parametrized (i.e., set to look and act as a certain “flavor” of the pattern). To achieve this, close collaboration between the implementation partner and the software company must take place. Both parties must ensure a knowledge transfer about what requirements there are in the real world and what answers can be created in the patterns. In the end, the UI patterns need to be frozen ? the implementation partner should not be able to change the internal workings of the patterns, but only parametrize them, responding to the customer’s requirements. Of course, there needs to be a feedback loop from the implementation partner back into development to ensure no crucial flavor of a pattern has been overseen.
If the software company have done their job well, i.e. if most possible requirements have been taken care of and a decent usability within and across the patterns has been ensured, switching to a UI patterns-based approach will solve the problem ? and it will speed up implementation (and, after this first investment, development!) projects tremendously.