Published: Apr 05, 2012
It's a sad truth that intranet and internal systems often receive the short end of the user experience stick. Much like the proverbial shoemaker's children who never get decent shoes, a resource-limited user experience team often focuses on the customer-facing systems, leaving the internal designs to evolve organically, often without care or thought.
Over time, this creates costs for the organization. The systems become clumsy and difficult to use, which slows down or prevents the employee from doing critical functions. For those who work in customer service, this makes it difficult to resolve customer issues, which lowers customer satisfaction. An inefficient organization can't jump on new opportunities thus opening up entry points for competition to step in and take business away.
The good news, it's easy to find improvements to make. This helps us show the value of great user experience. We can reduce costs, increase customer satisfaction, and improve revenues, often through simple enhancements to employees? existing work experiences. Here are four tricks we've uncovered for teams to see quick wins in their intranet and internal system user experiences:
One of the hallmarks of a poor user experience is frustration. When something doesn't work well, it's frustrating to the users. By observing that frustration, we can often see something that is an easy win.
Identifying the frustration isn't hard, if you do the right things. We've found spending a day shadowing employees as they do their job can reveal many frustrating bits. We create an employee journey time line, which plots the activities over the day, showing a frown face every time the employee runs into something frustrating, either with the systems themselves or with the way they need to accomplish their work objectives.
Repeating this with a handful of employees often reveals patterns of frustration that many folks are experiencing. For example, in a recent study of call center staff, we found they were flustered by seemingly random session timeouts, which resulted in them having to sign in to their account at unexpected and inconvenient moments. (To make matters worse, the sign in process didn't remember where they were at the time of the timeout, so they frequently had to find their way back to the screen they were on.) Fixing the timed sessions for the call representatives removed a major source of frustration for many users.
The world changed for people when shipping vendors made their package tracking data accessible to their customers. Suddenly, a part of the process was transparent, which made it easy to plan and detect problems.
The same is true within organizations when we surface the internal data about 'how the sausage is made'. By showing employees where things are in the process, they too can set priorities, make plans, and detect problems earlier.
Fortunately, we now have a lot more data to work with. It's easy to see where things are in their process and show what's been completed and what's left to be done. Making this available on mobile platforms makes it even better.
When a dental hygienist gets notifications about changes in upcoming patient appointments, she can adapt her schedule appropriately. An airline customer services rep who has a status box on their screen showing recent flight cancellations can start looking for alternative routes for those stranded customers before they even show up at her desk.
What new data could be helpful to an employee right now? Surface that critical data and you'll seen an instant UX win.
Tool time is the enemy of productivity. It increases costs and reduces service quality.
Tool time is the time a user spends doing something that computers are really good at. Recently, we watched a call center representative hand writing data from one screen, so they could re-enter it into a second screen. This multi-step process was only necessary because there was no support for the applications to see each other's data.
Tool time issues usually arise because the developers focus on application functions in isolation and aren't looking at the workflows between them, expecting users to tell them where the inefficiencies are. Unfortunately, employees are often too focused on their work issues to step back and report where things could be improved. The result is an organic entropy to their work process that slowly gets worse over time.
Watching employees through their day will likely point out many tool-time issues. In many cases, they can be easily fixed with some quick data transfer features, letting one application see the data of another.
In one study, we collected all the functions of a law firm's intranet and put each one on an index card. We then asked a sample of the firm's employees to do three things with the cards: First, sort them into piles that made sense. (This is a traditional open card sort.) Then we had them write “Frequent” on any function they used more than once a week. Finally, we had them write “Important” on any function they used that was absolutely critical to the success of their job.
We were surprised by the results. For people with the same job title, like paralegals in a large law firm, there was little consistency amongst the frequent and important functions. Instead, that consistency came when people worked in the same areas, like intellectual property law or tax law.
Of course, once we saw this, we knew why immediately: job titles don't matter as much as what you really do at work. The architecture of the information and layout of the menus needed to match what people actually did for their work.
(This is why we refer to user experience as the “science of the obvious.” Once you get one of these insights, it's perfectly obvious as to why it's true.)
When we asked the employees to explain why they grouped the cards in the sorting exercise, they had really great, logical explanations for the functions they used. However, for those functions that weren't important or frequent in their own work, their rationale became muddy and filled with guess work.
We realized that the model we wanted for the menus was similar to the way a fisheye lens worked. If you've ever played with a camera that had an extreme wide-angle lens, you'll notice that objects appearing in the center are big and up close, with lots of detail, while those objects that are on the edges seem much smaller and farther away. The navigation system needed to reflect a similar fisheye perspective.
One common approach to a fisheye perspective is to use role-based functionality. This assumes you have the roles identified right (which probably means you have to look beyond job titles) and that they never change. We've found this to be too structured for most organizations where people's duties can change from one day to the next, depending on the current assignments and priorities.
Another is to group common functionality into menus that duplicate functionality listed elsewhere, but are purposely constructed for the work at hand. In many cases, making it clear when to use each menu can be very effective.
The biggest problem with the user experience of today's intranet is that we're not paying attention to it. We've found, once we shift our attention on what's happening in the world of our fellow employees, it's easy to see opportunities for improvement.
It's often very easy to come up with several solutions that will make the problem better. Once we know that a problem exists and understand its context and constraints, any good designer can generate a half-dozen acceptable solutions. Then it's just a matter of finding one that'll be easy to make happen without creating more issues.
The wonderful side benefit of all this is it is usually easy to point to real business gains from focusing on the intranet. The fixes usually hit all the executive hot buttons by reducing costs, increasing customer satisfaction, and producing more revenue opportunities. That's an easy sell for a great user experience.
What techniques are you using to reduce the costs of iteration for your team? We want to hear your experiences. Leave your thoughts on our UIE Brain Sparks blog.
Read related articles: