When talking about users, we usually refer to our existing or potential clients. But it is important to remember that users are not only the customers but also your employees, those who face in-house systems. Their user experience is at least as significant as this of your paying clients, but they are the easiest to overlook.
Nowadays, nearly-fictional technologies such as VR, augmented reality and IoT are already here, and in our day-to-day, we continuously experience systems that adapt themselves to the user. However, this does not counter the fact that many people are forced to use mediocre systems at work and struggle to perform even the most basic task. These systems look like no one has planned or tested for ease of usability, or at least verified that it does not trouble the user. Even if we overlook the visual factor (which is not to be underestimated), these systems simply do not cooperate with the person who is using them, while he or she find themselves struggling with an incompatible interface. Does that sound familiar?
Why is the discussion about modernizing systems so important? Although it is safe to say that today, most people hold a state-of-the-art smartphone and use complex digital products, we still see many service providers working with programs that look and function like an interface taken out of a retro movie – not a thing we would expect to see as we approach 2018.
I am sure you know what I mean – those systems used by cashiers, doctors, inventory managers, postal clerks and accountants, some of which still operate in a DOS window. I am sure that some of you encounter such systems on various occasions or during your work. Such systems leave you wondering why no one has taken the stand and created an easy-to-use system, which pays more attention to the user and the objectives they need to achieve while using them. Why are we still working with tools that make us more productive and less frustrated or exhausted? The technology is available, so why are there so many companies lagging behind?
While working with various types of clients, I also get to work with companies on improving their systems, and the road there is paved with information worthy of understanding. Putting aside the will to improve or increase efficiency, this information has financial meaning as well. I assume that understanding real-life systems may help company owners and managers understand the importance and even begin solving these hardships. This knowledge is also practical for UX designers everywhere. It will be easier for your employees when their primary work interface helps them reach better results, and the benefit is all yours.
The Current State of Things
While the awareness of the importance of UX has increased in the last couple of years, it is not yet apparent when dealing with complex internal systems. Those are becoming even more unstructured as time goes by (patch on top of a patch, on top of a… you guessed it, patch). In a nutshell, this time I will not be talking about cool apps and cutting-edge capsule systems, but on modernising these old systems. This topic finds itself in the day-to-day agenda, and you should be informed too.
I approach systems as a UXer as well as a typical user, and too often I find things that should have been planned, designed or behaving differently. For example, misplaced functions, countless steps to document a process, systems having too many buttons and barely providing any feedback to the user … and more.
This results in encumbrance and a slowdown of both the system and the user. To top it all, this lack of usability tends to lead users to make various mistakes.
Unfortunately, the ‘solution’ that most companies go for is the setting up of internal tutoring to teach employees how to use the system “properly” and adapt themselves to the quirks rather than the other way round.
In fact, from several interviews with such users (who are service providers in companies) I realised that even after taking the time to learn the system, it was not enough. In counter-intuitive processes, “learning on the go” accumulates too many errors and ramifications that the organisation cannot always afford.
Why Does it Happen?!
There are several reasons to that, which I will not elaborate on because if you have reached this point, it does not really matter. In reality, you have a mega-system on your hands which will remain a problem forever. This is a statement I almost take personally: “let’s just settle with the fact that things would never be better”. This notion does not fit with reason, as the reality teaches us that there is always a way.
When I began accompanying processes of this sort, one of the things I was often stating in meetings is that it is unreasonable to see such a gap between the internal systems, and the service/product end-customers are exposed to. Not mentioning competition, which is a whole different conversation, you should take into account that the tools you use reflect on your business, in your employees’ and customers’ minds.
So Why is Everyone Not Doing This?
The million dollar question! Why is everyone not taking their old systems, rewrite, implement them and enjoy new possibilities to grow, to be updated and to be more efficient? In such processes, scalability is gained, along with new options to monitor and overview – all of which directly influence the success and the profit of the company, “so why aren’t we doing this already?”.
First and foremost, even though we are fully aware of the importance of the user’s experience when using digital products, many people still cannot properly define the term “user”, or the identity of the user they should be addressing. Remember the first lines of this article?
Next, sometimes the decision makers within the company are aware that there are problems but still cannot estimate how to deal with them (timeframes, costs, implementation, etc.). As a result, they tend to push the task of addressing them to ‘later’ (which we all know that means ‘never!’) despite the need constantly hovering on their head (and no one likes that!). Sometimes it happens under the false assumption that the system is impossible to fix, that it is too special and customised and that the data is too massive to be converted. You should know that there is always an option. There are companies and professionals who specialise in solving such issues – yes, even for your overly-complex system.
Take a deep breath. I will try to explain how to approach this process, and how to do it smartly.
How Can We Make this Upgrade?
Good news! You might need to work on just one of the levels I will explain next. The not-so-good-news: you may have to work on both, but it is normal (and sometimes even better).
1. The Technical Infrastructure
If you are already upgrading, I would firmly recommend to take a closer look at the infrastructure and possibly to rewrite it using modern platforms. It is tough to introduce progress to a system that relies on outdated languages. Make sure your tech fits your requirements. That way, changes are being made available, like updating the interface and making it more intuitive, being able to run your system from a browser window anywhere (and not from your internal network alone, for example), being able to use devices such as smartphones/tablets, and so on.
2. The Experience and Usage
Even if hypothetically I was not a UX designer myself, as a consumer, I value good product engineering. It might be more natural for me to state, but understanding the importance of excellent user experience in digital/virtual products proves its value. This is true at all stages – from planning your upscale and modularity, up to taking into consideration behavioural researches.
What happens if your company expands tenfold in the following year? What happens if, by next month, you will have to face a new, unplanned requirement? Take everything into account as early as the planning stage, and plan for future quick additions, as well as for being able to trim and omit entire sections. Also, some systems provide value to various types of users: employees, clients, system admins and more. Each type of user should be adequately addressed in the characterisation and in the new version.
Apply change to either one of them, and you will see a noticeable improvement. From a crammed-up system – you can make work more comfortable for your employees and usher in new capabilities: starting an action at the office and completing it from the cellphone, creating a customised experience for various types of users, more management possibilities, the ability to scale and adapt fast, etc. That way, you guarantee a much more reliable system, in more than one aspect.
How to Approach This: Who Does What?
So, you have decided to go ahead and upgrade the software you work with? Awesome! This is the first step! Also, I will allow myself to assume that you have allocated the budget and the personnel needed. What is next?
1. How does the system feel?
I recommend starting with learning the existing system and how it is being used de-facto, checking and verifying data, interviewing different users (not just the most seasoned ones), and plan the wireframe in accordance to the gathered information and requirements. This is the responsibility of the user experience designer. UXers will be able to point you to the right directions regarding the technological tools you may need to use, the interfaces your system will operate in (screen types, mobile accessibility), even time and cost estimations.
2. How does the system function?
During stage 1, or immediately after, developers should be brought onboard. It is crucial for them to be able to use the existing system assets (database, stats and more) and to implement the requirements using the tools that are to be picked for this project. Of course, I would recommend an experienced developer, and in this case not necessarily from within the company, who is familiar with such projects. This is mainly because modernisations often require a fresh look that is not always present in employees (who have their set routines and “inside the box” thinking).
3. How does the system look?
Contrary to the (still) common belief, a UXer and a UI designer are different professions, with various tools and mindset, and they find common grounds only when working on a product. It is advisable to hire a designer who specialises in the company’s particular field of expertise or a designer that is experienced with related systems – because a web designer will not necessarily have the skills to design systems. I would not suggest overlooking these things.
4. Familiarity with the system
Allocate a person who is familiar with the system through and through to be the product manager. This person would overlook the process and possibly be in charge of the integration of the final product. That way, there would be a go-to person for any queries that may arise and guide the product’s various aspects, basing it on experience and knowledge that are distributed among everyone who works on the project.
You can add and improve on top of what I have mentioned, but from this point on, you are ready to begin the change.
The Process: What Stays, What Goes, and How to Implement?
If you ever wondered how do we know what is crucial and what is not needed in a system, the answer is data. If there is no data – stop reading right now and send a mail to the person who would implement data collection code or a statistics infrastructure of your users (remember who they are?). In older systems, it is possible to assume that there is an abundance of collected stats too.
If the data is there … that’s excellent news! Analyse it and decide what stays and what gets the boot, what is being used and what is causing confusion. Again, if you do not have this data, hurry up and start collecting it so that decisions could be based on facts.
Another, less “techy” but more immediate option, is to speak with users. In essence, to interview the system’s users, to ask questions, and if possible, to watch them work. It is not always ideal, but it beats not knowing! UXers are familiar with the tools required to conduct such researches and interviews correctly, so it is a good idea to invest some effort into that.
Of course, combining both approaches is the gold standard!
Following that, to make progress, I would build a structure of data hierarchy. Meaning: an initial inventory, which allows the planning and improvement of the system. That way, you will be able to logically see where everything goes, how to create useful continuity between various screens, and plan the end product.
After a process/function is concluded, you can move on and develop the next component, up until the point the entire system is rebuilt. Working that way guarantees careful and meticulous execution, because replacing an existing corporate system must be as flawless as possible, for everyone’s peace of mind.
Terms such as alpha, beta and gradual launch become relevant. This concept of testing is advisable, although not always possible. Generally speaking, it is an efficient practice that allows you to detect and deal with unexpected outcomes. If the product’s and company’s culture allow that, try to isolate particular users, offer them to use a new version, and take note of their feedback. More than once in my work, breakthroughs were reached after observing live experiences of individual users.
And, of course, before users make their first click, be sure to implement tracking and monitoring capabilities. Simple Googling will reveal plenty of platform-specific tools for such needs. Use any tool that offers insights of usage patterns, flows, bugs and their causes be they in the form of heat maps, mouse clicks, retention times, screen transitions and more. These tools exist. Do not be afraid to utilise them – the data they provide is invaluable.
Real-Life Examples
There are obviously plenty of examples, and I am not necessarily referring to old government sites that ask Chrome users to “install and use Internet Explorer 7”, even though such cases are always amusing to see.
These are some of the examples I have had the chance of meeting myself, and perhaps any of you readers might be able to “see yourselves” in the text and become more confident about your systems.
If you are weary by now, maybe this is the part I would skip.
Case Study #1
- The company: A financial services company that utilises a terminal-based system.
- The problem: An outdated framework, which forces the users to memorise a page-worth of keyboard shortcuts, have a physical folder nearby and observe the documentation every time they cannot remember how to accomplish the most esoteric tasks. Being a financial system, which is not easy to use – using it required the users to retain a high level of concentration, as an error is disastrous and could lead to loss of client money. Aside from the textual interface (one might say that there was no interface whatsoever), working with the system was a task on its own merit.
- The solution: Solving such a case required a complete overhaul. The database was duplicated and upgraded. The front end was rebuilt, then a company-wide shutdown was issued, at non-working hours. When dealing with finances, data falsification was an actual threat, so it was of utmost importance to make sure that the new system is launched a moment after the old one was shut down. There was almost no need to tutor employees, because the new interface was using the same old “terms” as the previous one did, but in a simplified manner.
Case Study #2
- The company: A service provider for the medical industry.
- The problem: the system was put together over the span of several years, by many different programmers, in a “patch on top of a patch” manner as I have mentioned before. Every new developer was not aware of the complete capabilities of the system, worked the way he had seen fit, and built a new tool – when there was always such a capability already hidden somewhere. This practice created confusion and work overload, both of which were passed on to the users, causing errors.
- The solution: It was clear from the start that initial focus should be placed on the hierarchy and the planning. Schematics of the entire inventory were drawn, and decisions were made based on them, regarding what to leave and what to omit. Besides the planning, the design and the visual cleanup. Internal code documentation was emphasised, for future developers, while defining an agreed code of conduct for documenting work.
Case Study #3
- The company: A startup from the BI industry, that quickly had maxed out the technological capabilities it had to rely on.
- The problem: The underlying tech was not supportive of the quantities of data objects the company had to collect while preventing analysis and filtration. Several upgrade attempts were made but they were halted due to indecisiveness and the constant need to use the latest tools. Every time a new framework was launched, the work began anew in an infinite loop, without addressing the required features of the system.
- The solution: The first step was a managerial one. A deadline was set for making decisions regarding technology! Even if the next best thing was to be launched the following day, it was not used. Up until the deadline, there was time to deal with planning, characterisation and design, and after considering the available tools at the deadline day, the programming began. The dev team was instructed to work in a scalable manner, as close to the standard as possible, so that if an upgrade was to be made in the future, it would be much easier.
Case Study #4
- The company: A big telecommunication company, that hit an impasse with their CMS.
- The problem: This company had a single, unified platform, that attempted to address the need of every employee – without realising that there is no single employee who really needs this much info. A field operative did not need the financial history of the client, and service operator did not need deep technical data. Working that way made it obligatory to conduct internal tutoring, frequent company-wide seminars and team courses, with emphasis on error prevention and dealing with data mixups.
- The solution: As a part of a wider reform, the CMS was rewritten too. The database remained comprehensive as it was, but every employee level was granted access to relevant data only. For example: editing the client’s details was left in the hands of the service personnel, rather than every employee. Soon, the number of errors had drastically dwindled, the investment in tutoring was reduced. The new, employee-specific interface was praised across the board. This had also allowed data to be displayed on mobile interfaces. The cost was not negligible, but the improvement has increased the productivity, nearly eliminated errors and increased overall morale and satisfaction. Cool, isn’t it?
The Day After
We have wrapped everything up, the new system is built and the switch is waiting to be flipped. How to ensure that the transition is being made as smoothly and as correctly as possible?
First, as I have mentioned, do it in stages, to allow quick fixes on the fly.
Second, implementation. As it often requires a change of habits, it is advisable to make time for a short seminar for the existing users. Many companies already keep training personnel on the payroll: they could prove useful at this point. If you do have such employees, involve them in the process near the end of the system’s modernisation, so they can experience the changes firsthand and think on how to pass the knowledge on. They should be able to take the responsibility from that point. New employees, by the way, are expected to develop correct work habits from the start.
If you have no employee training personnel, the task is often passed on the product manager (with great power comes great responsibility!). I have witnessed such processes being launched, and from my experience, the most efficient way to accomplish that is to set a meeting for the minimal necessary amount of people – the modernization team and the other department/team leaders. If it is possible to demonstrate the outcome to the entire company – it is unbelievably amazing! As it is not often possible, you can expect the middle-managers to pass the knowledge to the workforce. I would suggest that the developers, the designers and the UXers would attend this presentation as well, to answer questions and hear feedbacks.
From this moment, observe users while they are making their first interactions. Track mishaps, as well as uses outside the flow. Do not be afraid to take this into account and publish a fix or a new version – the goal is to have the entire organisation enjoy the product.
And of course, congratulations! You have taken an old system and made it into a tool that is comfortable and even fun to work with. Besides the fact that the employees and (inherently) the clients will experience an upgrade, you have made a better impression, increased productivity and taken a giant leap forward. Fortune favours the bold!
Disclaimer: I have originally published a similar version of this article in Israeli on GeekTime and I have adapted it in English for UsabilityGeek.
Want to learn more?
If you’re interested in the managerial and strategic aspects of UX, then consider to take the online course on UX Management and Strategy. If, on the other hand, you want to brush up on the basics of UX and Usability, then consider to take the online course on User Experience (or another design topic). Good luck on your learning journey!
(Lead image: Depositphotos – affiliate link)
