Tangible value of UX in internal reporting solutions

13 May 2016

Karun Soni

Karun Soni

Consultant

Design Thinking (DT) and User Experience (UX) can add value to all design processes. In this post I’m going to focus on an Internal Reporting Solution with a huge user base and look at what DT and UX can bring to both the processes involved and the end solution.

To get an idea of more specific figures about how UX can be valuable, have a play with this UX Calculator from SAP.

The interface

Karun-Tangible-value-of-UX-2.jpg

I’ll start with User Interface. Working in the SAP world, experiences of the end users can be restricted by the look and feel of the tools they are working with. However, this is more about understanding how to design these interfaces in the most efficient manner.

Imagine reducing ten navigational clicks down to three in a report by effective design thinking around the front end, or heightening performance through slicker development centred around the user’s needs as opposed to every single possible earthly requirement(!).

These kinds of considerations come from a fundamental understanding of what the users need to do their job. When you look at the number of reports, number of users, time and productivity, these seemingly insignificant small changes amount to significant ones when measured cumulatively across organisations, as the UX calculator above indicates.

Requirements

When it comes to requirements, the ability to appeal to the stakeholders, end users and anyone else in the huge hierarchies on a client’s site is a big challenge on its own. However, being able to consider all of these components and then focus on what you want to achieve, along with what brings value, is important.

An approach that is airtight, based on bringing the end user value and giving them what they need is far preferable than business processes with too many required approvals, bottle necks, forms nobody reads and unnecessary politics which negatively affect various work streams.

As UX designers, if we truly understand the key requirements, reports can be more focused, less wasteful in both development and time, and we can gain quicker business value. Iterating, reflecting and understanding what users do – how they run reports, why they run reports and how often they are run (if ever) – is a good way to continue this process.

Change requests

The point above translates well to change requests (CRs). UX and agile methodology, for example, can keep users in the loop during the design and build. This way there are less CRs afterwards which saves time, reduces frustration and means less money and/or resources are wasted.

If a user needs one thing and gets another, many issues are to be expected such as time wasted on helpdesks, IT tickets and big CRs. A consistent, considered goal created around users is important to avoid these common pitfalls. Sometimes requirements change during the build too so keeping users in the loop is important.

Less waste

As described above, users can throw requests at the project team all the way through the initial stages, development and build. However, it is important to know what they actually need, not just what is on their wish list. This translates to high user adoption and less waste. There needs to be a focus on what a user actually requires to do their role more efficiently and no more. A UX designer should work with the business to understand what is fundamentally required to add value. There is less waste in memory, money and time, as well as better performance and higher productivity.

Training

Poor design in a reporting project may lead to lots of training for users. However, engaging users during the design and build process means that the tool/interface will not be entirely alien to them. In addition to this, designing for the user (e.g. using descriptions as opposed to IDs, where appropriate) is important. The project team should know who the end user is and create a solution for them.

If we look at the salaries of trainers looking to teach a number of end users a particularly difficult reporting tool, combined with the number of people who are trained and factor in the business days lost, again we are looking at huge costs, not to mention effort.

In addition to this, most of these end users have smart phones with brilliant UX; instant answers to questions and an enjoyable experience. It is more and more apparent that people have less tolerance for clunky, slow and non-intuitive screens! It is hard to calculate the tangible value in this, but surely productivity will rise as a result of these reports leaving the Stone Age.

Users in control

So now the users are more in control; there is incredible value in this. When looking company-wide, sometimes the person giving the tasks to developers is not an end user and cannot relate to or understand their everyday tasks. By gathering requirements from the correct end users answers are collected quicker, user adoption is higher and the build is more focused and less wasteful.

Put yourself in the shoes of a user looking into one aspect of a report. If you can find the relevant data quickly in a report, this means quicker analysis, answers and value. This is far better than having to investigate or get a team of business analysts to pull out the answers for you. Really great UX might mean that drilldowns and interactive features enable improved analysis. While you may argue this is all about the tool used, I would say that this is irrelevant unless we truly understand what the user is going to do with it. Once we know this, we can angle functionality strategically towards user needs to bring value.

The value of User Experience is clearly defined in better interfaces, efficient requirements, better user adoption/control and less training, CRs and waste. The means of getting there is through Design Thinking. As I have said in a previous post, User Experience is exactly what it says on the tin: the experience of an end user! So surely we need to get down to grass roots, listen, understand and then design and build something meaningful?

Bluefin and SAP S/4HANA - welcome to the one horse race