I have to admit it: In the last 10 years of my professional career as an developer and architect, I did not care a lot about user experience. I really like a nice UI and love to experience a good designed screen flow, but my mantra has been: functionality first. Perhaps this is just somehow typical for people like me who raised up with lots of clumsy command line interfaces and prefer to build great data structures and algorithms to designing fancy and shiny UIs.
But today my view to this has totally changed and I want to share the lesson that turned me around with you here.
The magical Seven-Step
The change started about four months ago when we thought about how to make life better for the users of our inhouse application. Just like everytime, we thought about new functionalty and enormous gains in performance. Typical developer stuff so to speak. Then one of my colleagues had a meeting with managers and users to learn about their biggest pain points and what they would love to change. Surprisingly, the top pain point was something they called “the magical Seven-Step”.
They explained to us, that for every interaction with a customer on telephone or in a shop, they need to get an overview about this person and booked products and this process took seven “classic” transactions to step over. So just for knowing where the customer lives, which products are in use, which complaints are still open or how the user is paying its bills, seven transactions had to called one by one. You can see some examples of them in the screenshots below.
Ugly, aren’t they? And to give you an impression on how often this seven steps are excuted: These transactions are call over 3.7 Mio times per month. Highly trained service desk personal is able to complete the magical seven-step in less then 30s. Now imagine: You call a hotline and want to talk about the correctness of the lastest bill and after getting through to a human being, you have to wait for another 30s before the real customer interaction could start. I think you would not be amused at all.
But on the other side, the service desk person has to click through these transactions under high pressure and keep in mind what was presented. This is some kind of brain jogging you really do not want to do the whole day. To make it even a bit worse, the search for the right contract or customer data is executed in an external third-party tool, so you even have to switch between two separated applications with totally differenty UIs.
At first I could not believe the story, so I tried it out for myself. And yes, this was a really PITA way to do daily work. So we needed to think about ways to do it better.
We start sessions with users to discover their possibly hidden needs and after a few iterations we had enough information gathered together to build a first solution, that should really impress users and managers alike. Therefore classical Dynpros did not make it as the underlying technology. New UIs should look a little bit sexy today, also at work. Coincidentally we had just upgraded to a new ABAP stack (7.40 SP7) so we had a new UI weapon at hand: SAP UI5.
Without much of knowledge or experience in UI5, a very small team of three developers and architects started to build a first prototype that should make life easier for the users. After two weeks, we had something ready to show and so we did. Success was overwhelming. The management of LoB, that did not had the confidence in the IT guys to come up with a great solution, wanted to have this in production ASAP and so we could build what is now called “OneClick”:
In the new world, the external search tool is simply integrated into the UI (see the long text entry field on top), so there is no need to switch applications anymore. When the correct customer is found and selected with one click, all of the needed information is loaded asynchronously in just a few seconds. All products and contracts, past and present, are shown as well as every contact or document of the customer. Detail information is presented in popups if the users needs it and does not clutter the screen with unimportant data. And if more information is needed or actions are required, the user can jump to the web UI version of the well-known classic dynpros.
So far, the renewal of the unattractive Seven-Step is a huge success. Besides delivering direct value to the users, it also gave our development team a good chance to get their hands a little dirty with a new technology. And it closed the gap of trust between IT and LoB at least a bit. A win-win-win-situation!
Personally, this little story told me how much a great user experience can matter and what potential lies there hidden in our old-school dynpros. And if UX is important to our users, it should also be important to us. This is my new mantra. 😉
In this example, we not just did a redesin of the user interface or copied a screen to a new technology. Because we talked to the users that had to work daily with the sh*t we produced a long time ago, we learned a lot about their work and how this could be enhanced. In the end, we build a whole new UX based on UI5 and improved their work life a lot.
Looking back, I am sure that this was the right way to go. Talking to users, watching them work with the old UX and working with them together to build a new one felt just right. For the next time I would not change a bit, but follow a few simple rules:
- Dare and win! Search for a real pain point where today’s way of doing things is causing a real headache. This gives you enough management attention to work on it because the effect of improvement is big enough.
- Always talk to real end users of the application you are working. Even better: Work with them together for some days to get a feeling for being a service desk employee, for example. Never trust management in what would be best for the users. Management can not know it because their working days are totally different.
- Start with a small, but somehow working prototype and show it to users to get their feedback early! It is no problem if the first versions use a lot of mockups that need to be replaced later on anyway. But perhaps you discover functionality that is not needed and could be removed to concentrate on the most important things.
- Do not build a feature that only one person requests. Most of the time it will turn out to a not-so-needed thing, but the time to build it is wasted.
- Think about UX, not just UI!
Hope you enjoyed the small story about UX and feel free to comment or ask questions about it.