I meet Aaron Gustafson at a coffee shop in downtown Chattanooga, Tennessee, not far from where he and his wife, Kelly, live with their young son Oscar.
As we order our coffees, the barista compliments him on his belt buckle and asks him if it’s the Triforce, as in the powerful item central to Nintendo’s Legend of Zelda series, and he says yes.
And then they start talking about the new Nintendo Switch. Gustafson asks her about her experience playing the new system, how the controller feels in her hands, and how it affects her gameplay.
I ask him if it’s hard to stop working, to keep his brain from going into analysis mode when doing things like playing video games.“Sometimes, yeah,” Gustafson tells me.
“I start thinking about the usability of the game, and how much thought went into the way the controller works, or just the overall controls of the character. One of the things that really frustrated me, and it’s a small thing, admittedly, was in the Dragon Age: Inquisition game.
In certain instances where you’re reading something on the screen, pushing the controller up would scroll it down. But in other panes, doing it the other way scrolled it down. It was clear to me that two different teams had obviously worked on implementations on what is effectively the same component, but had actually reversed the controls.
It’s such a small thing, but it made a difference. Every time I’d try to read, I’d get frustrated because I’m like, ‘Why isn’t it scrolling?’ It was because the controls were mapped the other way.”
Gustafson should know. Not only is he a web standards and accessibility advocate at Microsoft, he’s also the founder and technical lead of Easy Designs, a content-focused web development consultancy.
He’s also written books and articles, as well as spoken at conferences and workshops, on adaptive web design, coding, mobile navigation, and other topics. Like the video games he plays, it’s part of Gustafson’s job to think about how software decisions behind the scenes affect the way we work.
As critical as it is for businesses to upgrade software to keep up with ever-changing business technology, it’s just as important to fully think through the level of disruption that comes with the change.
How will these changes affect other departments, and what can be done to minimize that disruption? And how do we effectively communicate the changes that are coming, so that everyone in every department can be ready? “Let’s say you’re somebody in HR who’s using PeopleSoft, and you’ve gotten used to some of the power user quick commands, and stuff like that,” Gustafson says.
“You’ve customized it so you can do your job more quickly. Now, all of a sudden, you’re going to a software that is overall more user-friendly, but has different shortcuts (if it has shortcuts at all, depending on where it is in terms of maturity). It's certainly a whole new workflow to learn, especially if it's something where you can't custom-define workflows.”
Gustafson further explains that if a user is evaluated by their productivity and their ability to accomplish a certain number of tasks in a day, talk of upgrading that software can cause that user to worry about a lot of things.
How long will it take to learn this new system? How much more time will it add to the job learning this new system? Will that user be viewed as unproductive by management while learning how to interact with this new software? And will that lead to getting fired for not being as productive while learning? Change can make a lot people nervous, and even afraid, especially if that change disrupts a very process-driven job.
“A lot of times the decision to switch software is made completely in the absence of any input from the people who are implementing and using the software, which is not a good thing,” says Gustafson.
“I’ve seen this a number of times, where sales teams will talk to clients and promise them things. Then, they have to go back and talk with designers and developers about how to implement the new software.
It turns out that what they were promising just wasn’t possible, at least given the time and budget that the client was talking about. You can avoid all of that stuff if you have a stakeholder from design and development in the room during those conversations.
You can discuss the pros and cons to approaches and discuss realistic expectations, in terms of time and budget. Frankly, in the software world, given time and budget, you can pretty much do whatever you want.
But do you have that time? Do you have the budget? And then, do you have the ability to maintain whatever it is that you built? That’s another aspect a lot of companies don't think about, the overall maintenance of a new software system.”
But sometimes, people don’t know enough about implementing new software to ask the questions they should be asking. Gustafson talks about an example he encountered with a fairly large investment company that wanted a toggle instead of checkboxes on a form.
While it could be implemented, this one simple request led decision-makers down a rabbit hole of elements they hadn’t considered before. And all of those considerations impacted cost, time, code debt, money, and productivity. Like a lot of things, when making software decisions for your company, it all comes down to communication.
It’s important to involve not just the key decision makers in the software purchasing process, but also those who will actually install and use it. How will it affect their jobs and the other systems the new technology will interact with?
“I think a lot of times people don't think about the minutia in the way that they really should think about the minutia,” Gustafson says. “Once you start to realize the complexity of each of those individual things, it can be like a ripple effect throughout your organization.”
