Flag

We stand with Ukraine and our team members from Ukraine. Here are ways you can help

Get exclusive access to thought-provoking articles, bonus podcast content, and cutting-edge whitepapers. Become a member of the UX Magazine community today!

Home ›› Usability ›› Why an Apple Fanboy Would Want to Work for Microsoft

Why an Apple Fanboy Would Want to Work for Microsoft

by Zachary Lym
5 min read
Share this post on
Tweet
Share
Post
Share
Email
Print

Save

Don’t try to play the institutional buy-in game better—just change the rules.

For most, working for Microsoft is like working for IBM, Motorola, or even Boeing. Microsoft is a stable, if boring, tech company that pays well and offers a generous benefits package. Just the place for a 30-something “knowledge worker” looking to settle into a long career.

However, Microsoft has never seemed to understand usability; to the user, the interface is the product. Microsoft’s monopolistic ability to ignore stability, usability, and every other facet of product quality but still dominate in the 1990s and early 2000s drove me insane. Ex-Microsofties I’d run into in Seattle described Microsoft’s culture as a soul-sucking corporate bureaucracy, suffocating every good idea with groupthink and over-management. Up until last night, listing Microsoft on my resumé would have been embarrassing black mark smeared across my Past Employers section.

However, the Xbox had always been exempt from my vitriol against Microsoft. The gaming division had elevated Bungie to a higher level, had put together an online console experience that was the best in the industry, and had fixed the majority of flaws of game controllers. In other words, Microsoft had finally managed to put the user experience first.

Recently, usability consultant Bill Fulton of Ronin UX explained just how he and his team at Microsoft’s Games User Research Group managed to get Microsoft to put the user experience first. Fulton had dropped out of his psychology PhD program and went to work as the sole in-house usability person for Microsoft Game Studios. Fulton assembled a team of “incredibly smart psychologist-gamers who were crazy-motivated” and they ended up treating the challenge of usability buy-in like a real-time strategy game. Fulton’s presentation outlined how Microsoft’s Games User Research Group (GUR) used a strategy of reciprocal buy-in to go from a one-man operation to a 35-person department with an annual budget of several million dollars in just seven years.

Traditionally, when it comes to institutional buy-in, the usability field has focused on tactics such as Jakob Nielsen’s early discount usability methods or Adlin’s ad-hoc personas. A large portion of our jobs is justifying usability to management while begging developers and designers to listen to us. As brilliant and powerful as these tactics are (and they regularly save my ass), they are just tactics used to gain an edge in isolated parts of a development cycle or a product’s design. Their core purpose is not to improve the overall perceived importance of usability within the organization. If a usability department enhances its legitimacy as a result of these tactics, it is only of secondary benefit.

Many usability departments are stuck focusing their energy at the end of a product cycle, where they have least impact. Coming in late in the design cycle can makes it difficult to fix even showstopper usability bugs. Forget changing the development workflow or overhauling the interface; we just get to fiddle with buttons and tweak wording. GUR, however, worked on the larger strategy: focus on a few big wins, generate demand, then demand reciprocity. By improving the perceived value of usability within the organization, GUR was rewarded with more resources, more respect, and more inclusion.

It was so successful that Bungie asked GUR to embed itself as early as possible into the development cycle to have maximum impact. Anyone in the usability field should know just how rare this is; how often have you brought up a usabilty flaw, only to have coworkers denigrate the intelligence of their customers rather than doubt the quality of their own work? I once asked one of my professors what surprises her the most about how the usability field has matured in the past 20 years, she responded, “I thought I wouldn’t have to keep having these conversations, that [the necessity of usability engineering] would be a given.”

The central thesis of Bill Fulton’s talk was that the perceived value of usability is what needs our attention. Instead of spreading the usability department thin trying to fix whatever we can, Fulton recommends focusing our efforts on specific departments, projects, or sub-projects that are the most receptive to usability recommendations and thus will produce high-impact results. Teams that actually value usability engineering will develop products that are shining examples that make usability look like key asset that can accomplish great things.

All too often, usability professionals spend their efforts trying to do whatever they can for any project across company. This often averts total disaster in key projects. Sadly, only the usability department knows that they just saved the ship; their perceived value doesn’t match up with reality. There is an opportunity cost in spending time with dysfunctional, anti-usability managers who don’t respect usability or, for that matter, the user. By focusing on projects where you can make one good product you are not cranking out a bunch of mediocre products. One highly visible “win” is worth a thousand tiny wins.

This all requires changes in the relationship between the usability and development teams. No company will tolerate a usability department refusing to work for business units that aren’t worthy of usability services. Fulton’s advised disseminating best practices and other front-line documents that tackle the most common usability mistakes. Secondly, after doing testing for a group, don’t test for them again until they have incorporated your feedback. Usability bugs are bugs; if programmers are not going to treat them as such, stop spending time finding and reporting them.

GUR policy was to cancel a usability test if the submitted build had usability bugs that had not been addressed. They were not being arrogant jerks, they were just reinforcing the reality of the situation: developers already knew what usability problems needed to be fixed and there were other projects needing usability services that properly incorporated the results of the last usability test. If the developers didn’t like it, they could hire outside contractors to do their usability testing. GUR wasn’t interested in finding the same issues over and over again.

The overarching theme of Fulton’s presentation was that usability departments should focus on projects that will showcase their importance instead of trying to convince everyone of it. When Fulton left the department in 2004, Microsoft had dedicated nearly the level of usability resources to games as it did to Windows—and Windows is a $4 billion cash-cow, while MS Games was losing money. How often does your organization question the need for developers, managers, or beta testing, or preliminary design specifications? If your company is questioning the need to properly support and integrate usability throughout the development process, don’t try to play the game better, just change the rules.

post authorZachary Lym

Zachary Lym
Zachary Lym was a freelance usability engineer who is attempting to apply usability engineering to political policy. He maintains an adjunct researcher position at Cognitive Policy Works and is double majoring in psychology and Informatics at the University of Washington

Tweet
Share
Post
Share
Email
Print

Related Articles

Join the UX Magazine community!

Stay informed with exclusive content on the intersection of UX, AI agents, and agentic automation—essential reading for future-focused professionals.

Hello!

You're officially a member of the UX Magazine Community.
We're excited to have you with us!

Thank you!

To begin viewing member content, please verify your email.

Tell us about you. Enroll in the course.

    This website uses cookies to ensure you get the best experience on our website. Check our privacy policy and