The UIE Podcast with Jared Spool

The Next Generation of Podcasts from UIE. Stay tuned for new stories and take-aways you can use in your day to day design work.

Episode #1 Time Traveling with Enterprise Applications - UX Immersion Podcast

December 17, 2015  ·  13 minutes

Listen Now

Download the MP3

Enterprise applications are massive, often unwieldy pieces of software. You get a sense they were never truly improved or updated, they just had a continuous string of features tacked on until it got to the point where they are almost impossible to use. And they’re old.

This focus on features let design fall to the wayside, making it less important than the application’s perceived capabilities. Now, you’re forced to stare at a screen straight out of 1995. You’ve become a time traveler, whether you were aware of it or not.

We’ve come across other time travelers in our journey. You aren’t alone. One such person is Hagan Rivers, who has worked tirelessly to bring these enterprise applications into modern time, if not the future.

In this podcast, listen to Jared Spool weave a tale of time travel with special guests Hagan Rivers and Dana Chisnell.

Full Transcript

Jared Spool: This is the UX Immersion Podcast. I’m Jared Spool.
If we want to immerse ourselves in serious design challenges, there’s probably no better starting place than time travel.
Dana Chisnell: Yes. I’m a time traveler.
Jared: Now some of you may recognize that voice. She co-authored the Handbook of Usability Testing, co-founded the Center for Civic Design, and created the Field Guides for Better Ballot Design.
Dana: Hi. I’m Dana Chisnell.
Jared: And since Time Traveler looks a little weird on a resumé, she is currently...
Dana: Digital Services Expert, Executive Office of the President.
Jared: And since that looks intimidating on a business card...
Dana: On my business card, it says Generalist Problem Solver, U.S. Digital Service.
Jared: So Dana is a Time Traveler, sent by the government, and she is in fact, here to help.
Dana: So it's not a top secret project but it is government work. What makes it feel like time travel is that when I got a hold of what the design looked like, what the software looked like for the users all you had to do was look at the screens to feel like you had been transported back to the 1990s. Completely reminiscent of early Windows systems, really felt like I had been here before already. And I was going to get to do this again.
Jared: I know what you're thinking: it's 2015 and despite promises by Robert Zemeckis, Time Travel really isn't a thing yet. But it turns out that Dana's experience isn't all that uncommon.
Hagan Rivers: Whenever I sit down with Enterprise apps, it's back to the '90s. They're old. The apps are old. The code is old. The databases...Some of these databases have been around 25 years. [laughs] It's the same database that they set up the first time they built it.
Jared: That's our go to person for tackling time travel issues like Dana's.
Hagan: My name is Hagan Rivers. I am a User Interface Designer for mostly enterprise applications.
Jared: Hagan is the person that we at UIE turn to when it comes to taking old enterprise apps and bringing them into the future. She says that a lot of the problem of why these applications get stuck in the past is that they are narrowly focused.
Hagan: I find for most of them it's such a struggle to even get the features in. Thinking about design is something they just don't make time for, or have time for. They seem to be stuck in this, "Get the features in," mode. Honestly, when you look at the folks purchasing this software, they're often looking at, "Does it have this feature or that feature?"
Jared: This focus on features is something that I talk about a lot. When you keep adding feature after feature after feature, you actually reduce the usability of your product. It's called "feature creep". And the problem in this instance is that the people buying the software aren't the ones who are actually going to be using it on a daily basis.
Hagan: They're not paying attention to design. It's not a space yet where design is a big selling factor.
Jared: Now because of this disconnect between the purchasers and end users, the purchasers are only focused on what the product allows them to do. And the more things it allows them to do, the better because they can accomplish more tasks. But the thing that's lost in the shuffle is, if you can do these tasks that's great, but you also need to be able to do them well. And that's where the design factors in.
The companies that buy the software actually believe they can train their users, who are their employees, on how to use this complex software. They focus on the features and not the actual task at hand. So since features are the focus of the people buying the software, the people making the software in turn just keep adding more and more features into the product.
Now this type of problem isn't exclusive to the private sector, it's actually part of the reason why the US Digital Service exists. Dana ran into this when she first started working at the US Digital Service and had a look at some of the designs they were using.
Dana: They were horrible. They didn’t reflect what users did one bit. It was like the programmers just barfed the database onto the screen.
Hagan: Yeah. Dana's very... visual. I like her. [laughs]
Yeah, the Enterprise applications, first of all, are very database oriented, because you're essentially manipulating data in a database. That's what they want you to do, is enter, update and maintain a bunch of databases.
For them, the design works if you can update the database, if you can adjust the fields, or make the connections, or remove the records, whatever you need to do. They don't care if it was easy or hard to do those things, because the only thing that matters is that you can.
It is true. There's this classic case of like, "Build a database, and then whatever's in the database you just throw that up on the screen with the switches and levers that manage it". But no real sense of, "How does the user do a task? How do they accomplish something?"
"How many steps does it take to add a patient, and to hook them up to the information, or to create a purchase order and send it to the next person who has to deal with it?" It sometimes is a lot of steps to get that work done.
Jared: So it may sound daunting, as Hagan was just explaining, but this is what she does. And if she wasn't successful in making these types of products and services better, she wouldn't have a job.
So the question then becomes, is this something that is a complete tear down from the beginning or are you redesigning the plane while it's in flight?
Hagan: The answer is it's a little of both. I'm a big believer in continuous improvement of software. I think, at any given time, you should have a good list of your user's current pain points. What's aggravating them in the software? Every time you do a release, you ought to knock a couple of those off that list.
I worked with a client. We did some field studies. We watched the users using the software. I made that list of pain points. We added the three of them. They were doing a rollout of new features. They have all these great new features and they were telling the customers about them. They were very excited about them. They had been getting asked for them so that was good. But I added these three troublesome spots that their users were running into.
One of them, it was seven clicks to do this one thing that people did a lot.
Honestly, I don't even remember the exact thing, but I remember it was a lot of clicks.
We fixed it. We fixed it so it was one click.
It got done. You went to a screen. You did everything you need to do and it was done. I have to tell you.
When we finally showed the new version to the users, they were more excited about that one little fix than they were about the six other new features that they had also wanted. But that fix was something that had been driving them bonkers. It was a pain point for them every single time they sat down to use the software.
Jared: So it seems that addressing users' problems as they have them versus adding new features that they might not even use will make the product and the experience of using it better than just bloating it with more and more and more and more features that can actually get in the way of the task at hand.
Hagan: I do believe you've got to know what the problems are. You should never let a release go out that you don't throw in your own, "Here's what we need to fix." At the same time, there are opportunities to make big changes. Typically, a software company might be going to a new framework. They're going to a new toolkit. They've acquired another company. There are these times in engineering and development that are good times for big movement.
In those times, that's a good time to sit down and really look at the design from a top to bottom standpoint. If you're porting the code to a completely new framework, that's a great time to say, "Have we got the right design? What do we need to change?" and to go through that process. But that doesn't happen very often. You have to also chip away at it.
Jared: And here comes the importance of research. If you want to find out what things in the product are annoying your users, you actually need to watch those users use the product.
Hagan: I say, "Take me along on a sales call," which these days I don't even physically leave the office, I just sit in on a sales call and listen to the questions people ask. I listen in on support calls, and I go out and I do field studies with the users.
Again, sometimes you don't even have to leave your desk. I just do a screen share with a user and I watch them for an hour, and occasionally I ask them questions, and I ask them to talk aloud. It's very traditional, old-school stuff.
I'm a consultant, so I'm not at the company. It's not that great to have me doing that. It's great, because I can help them with the design, but I always rope in their own people and I start them in this process of, "You have to be touching base with your users regularly, constantly, so that you understand their pain points."
I have yet to meet an engineer who can watch a user struggle with something that's broken and not want to fix it. That's an instinct for them. They love to fix problems.
Jared: When you get the developers, product managers, stakeholders, and other decision makers in the room and you actually watch these users struggle to use the product and you're there and you're living their frustration along with them in real time, it's a really good way of getting everyone on the same page. Because no one wants to ship a crappy product. And as Dana's experience with the U.S. Digital Service shows, knowing who your users are is a universal problem.
Dana: When we started out there was no attention paid to who the users were and what their needs were at all. The developers would get a story that was completely out of context. They didn't even know what task that user might be doing. And the users were treated very generically in addition. Internal users were this enormous category that might actually describe any number of different kinds users. Up to ten or twelve of them.
And so they were having to guess what needed to be done. And we were seeing a lot of "Well what if we did this?" and "What if we did that?" and "will this work for that thing?"
But as soon as we sent them out into the field to actually see how the work got done, meet the users, get a chance to ask questions of them about how they did their work and how they thought about their work, as soon as they came back we noticed an immediate difference in the work product they delivered. They had a much better idea of how to interpret the requirements and to translate the stories they were working on. They understood better, the context that any given story might be coming from. But now they also had met human beings that they were making this thing for and they didn't have to guess anymore.
Jared: Time Travel. The general idea of it sounds great. Fun and exciting. But in real life, in it's real world application, it's exceedingly frustrating.
You can alleviate that frustration by watching your users use your enterprise application. You need to exposure your team to what those users are trying to accomplish. Then you chip away one frustration at a time. Every frustration you chip away brings you one step closer to the present.
The UX Immersion podcast is brought to you by the UX Immersion: Interactions conference, which is going to be April 18-20, 2016 in San Diego, California. That’s where Hagan Rivers is giving a full-day workshop on simplifying complex enterprise applications.
I hand picked Hagan to be a part of this program, to teach this workshop, for the people who have to deal with these problems every day. If you deal with these problems every day, Go to to read a complete description of Hagan’s workshop and what you’ll learn.
The UX Immersion podcast is produced by myself and Sean Carmichael. We'd like to give special thanks to Hagan Rivers and Dana Chisnell for being a part of this episode.
You can find more information about the UX Immersion podcast on iTunes and at the UX Immersion: Interactions web site,
You’ve been listening the UX Immersion Podcast, part of the growing UIE Podcast Network. Thanks for listening and encouraging our behavior.