Pride before a fall - user involvement in software projects

I’ve been following the IT world and, more specifically, the games industry very closely for some 15 years now. Mostly as a consumer, wondering what cool jingamathingy I should try or get next, but the older I became the more I started to approach what one might call a greater understanding of what lies beneath the hood of one of my favourite pastimes. Like a moth to a flame, every mote of information pulled me deeper and I let them. My course had been set ever since a 7-year-old me ecstatically unwrapped a Super Nintendo with an accompanying Super Mario World for Christmas (or birthday, I can never recall which).

Digital experiences and stories in their various forms became a cornerstone of my life. It was this passion that led me to pursue a higher education in the field of IT and, eventually, user experience design. It seemed like the perfect amalgamation of doing nerdy stuff and understanding how and why we’re doing that nerdy stuff, not forgetting the storytelling side of things either.

After I had transitioned to the wonderful world of working full-time, I learned a great many things. Not only about design, user experience and project working, but also about a large number of things I was not expecting to. I’m sure most of you can relate. But the more I learned, the more some questions simply kept resurfacing in project after project and process after process:

• Why are we working as if we’re making this product for a faceless business entity instead of actual people?
• If we want to make a high-quality product, which coincidentally is one of our biggest marketing draws/promises as well, why are we doing just about everything in our power to NOT find out HOW to make it so?
• Seeing as no piece of software (or hardware for that matter) would exist if it did not have a user demography that had a need or desire for it, why are we treating the users as an excessive luxury instead of a critical necessity during development?

The answer to these questions was generally the same: money. Though there’s certainly a sizable amount of ego involved as well (“we know what we’re doing, we’re experienced professionals”), money always has the last word. It’s simply the world we live in and while it’s of course understandable to a degree (most companies are trying to make a profit after all), more often than not companies and people get blinded by it.

As a user experience designer, I absolutely, completely, unequivocally, utterly despise it.

I became a UX designer as it seemed to cater to a need I have had since I was a little kid: I want to create experiences and stories that make people go “Oh wow.” In software development, this means that whatever product it is I’m assigned to needs to be more than just functional, it needs to be aesthetically pleasant, intuitive and easy to use, among other things. Most importantly, it needs to satisfy the users’ needs and enable them to accomplish their goals with it.

I’m going to let you in on a little secret, as apparently that’s what it too often is: the best way to pursue these goals is to involve the people who will actually use the product. You know, the target audience whose day-to-day work will involve a hefty amount of clicking around with your product. Shocking, right? They are the experts of their own daily activities and have experience in how to handle their tasks. The users know what they need to do and approximately what they want and need (even though they might not always be able to verbalize it clearly) as well as what they don’t. No consultant, business manager or project lead will ever come close to that (despite what many of them will say).

Want to take a wild guess what few projects seem to have little to no time or money for? If you said “involving the users” give yourself a disappointed pat on the shoulder. For some unfathomable reason most projects completely ignore their most valuable source of information and instead make wildly varying assumptions and guesses about what their users would need based on previous experiences and similar applications. Most attempts to involve the end users seem to be happily received on the surface, but are ridiculously rarely encouraged or supported in such a way that they manage to come to fruition. The reasons vary, but one big one is what I mentioned in the previous paragraph: the people responsible for the project are afraid that the users will poke holes in their carefully constructed fantasy bubbles of “I know these things, I’ve been working here for X amount of time”. They might also be scared of admitting they don’t know something, because hey, one doesn’t elbow their way into management/leadership positions without knowing stuff, right?

I can’t believe I have to say this:

THE USERS ARE NOT YOUR ENEMIES.

Let’s dive into the wonderful world of metaphors for a moment: Let’s say you are building a house for a family of five who hired you to construct their new home. You’ve lived in a house before and see tons of houses every day. In your mind you have a clearly established mental model of what a house is and you are aware that you have a plethora of options to build more or less any kind of house within the budget you were given. In your almost sage-like wisdom you understand that even you can’t erect the building all by yourself in the given timeframe, so you go ahead and hire some carefully selected specialists to help you out with the construction effort.

You get an architect to draw the blueprints for the house. A single-story building, enough rooms for all family members, all rooms have windows to the outside, there’s even a little swimming pool on the yard, it’s going to be awesome. Next, you order the materials. Painted stone/concrete walls and solid foundations, sturdy, secure and efficient. You get people to set it all up and handle all of the necessary electricity, water and heating orders. Vóila, one house as ordered, all is well and done and it was all done within the limits of the budget so you present it to the family.

Except that all is not well. The family would have wanted two floors so they could have enough room for their upcoming baby and various indoor hobbies instead of simply bedrooms for everyone and the bare essentials. They would have wanted a sauna and a small gym since they don’t want to use public ones during the pandemic. They’re not really fans of the construction materials either as they prefer the aesthetics of wood construction nor do they like the color so they’re going to have to paint it again. A fireplace would have been nice as well as a garage instead of a swimming pool as none of them particularly like swimming but do enjoy hanging out together and a couple of them are quite enthusiastic gearheads.

Are you starting to see the problem? The finished house technically satisfies all of the necessities of a house, but is terrible for the users it is meant for. You spent all of their money on something they don’t want without ever actually involving them in the process or asking them what they might want, instead relying on your own vast general understanding of the topic. Now transfer this situation to an IT project. I regret to inform you that all of the above still applies. But that’s not all. You know what the worst part of it all is?

The users HAVE TO use whatever monstrosity came out of the production pipeline, regardless of if they like it or not. Money and time was spent on it, so now it will be utilized because those two resources simply HAVE TO have been transformed into value for the users, regardless of the actual outcome. The truth is, they may not have been. Even if they were, they may have done so in the most minimal way possible where the result only just checks off all of the boxes necessary for a product of that type and the users actually draw lots to see who has to suffer through the agony of using it.

You know what would make for a fantastic competitive advantage in today’s IT business?Actually utilizing modern working methods instead of those of the turn of the millennium. We’ve all seen examples of the so-called “engineer designed” user interfaces and I’m relatively confident that most of us don’t miss them. We now have an entire field of experts dedicated to designing for the modern era, use them. And well, you know, DON’T TREAT YOUR USERS LIKE THEY ARE KRYPTONITE. 

Because you sure as heck ain’t no Superman. You, as a software/service provider, are the Robin to the end user’s Batman. Luigi to the user’s Mario. A Red Shirt to the user’s Captain Kirk. Getting the picture yet?

Oh alright, I admit I exaggerated ever so slightly for effect. The real issue is that people look at numbers, budgets and dollar signs over people the vast majority of the time. Just about nobody thinks it is the right way to make the best products, yet very few people feel compelled to stand up to the process because their paychecks are riding on it and, well, “this is the way it has always been done”. Which on its own is one of the most horrid excuses for just about anything. Every time I hear that phrase without any additional context tells me that the person who uttered it does not know what they are talking about.

Let’s look at a couple of examples. I could provide a few from my own experience, but it might be better to look at some more well known blunders and successes so you can dig deeper should you so choose.

“Don’t you guys have phones?”

Some of you may already know exactly what I’m talking about. Funny how a single sentence can become so iconic when voiced at the right place at the right time. For the rest, let’s go back to November 2018. Blizzard, a globally known game company, organized their annual Blizzcon-event where they announce their new games and projects and organize tournaments and competitions.

Diablo is a fan-favourite PC game series from Blizzard and had its latest installment, Diablo 3, released back in 2012. It did receive some expansions and additional content after its launch, but fans were hoping for the fourth game of the series to be announced at this year’s event. Anyone could go look at various discussion forums and see them ripe with speculation and hope as the fans truly love the series. Seriously, the amount of anticipation and the users’ desire for a new title in the series was through the roof and as obvious and palpable as anything can be.

In Blizzcon, there was news of a new Diablo game. However, what Blizzard announced was NOT Diablo 4 for the PC, but instead a mobile game by the name of Diablo Immortal.

The fans were shocked. Diablo as a series had always been firmly PC first (though for example Diablo 3 has been ported to consoles as well) and its fan base was, and still is, largely PC players. The fans’ assumption was, quite understandably, that a new Diablo game would be for the PC. When Blizzard revealed their mobile project, the reception was lukewarm at best and quickly deteriorated from there, with a fan famously asking in the Q&A section of the event “Is this an out of season April fool’s joke?” with no hint of irony whatsoever. Blizzard had even prepared a hall with a large number of mobile devices to test the game with, yet images from the event showed this hall mostly vacant as people simply did not wish to play Diablo on their phones.

Blizzard had utterly failed to capture its audience’s desires or listen to their users’ feedback. Instead, they had allowed a lucrative market and a relatively easy development pipeline to sway the course of their entire franchise. To this day, Diablo Immortal is still an on-going project slated for release… eventually, yet the only thing worth noting about the calls and wishes for it is their absence. In the video games industry you sometimes do just need to follow your vision, but this debacle is an excellent example of a company operating purely based on business decisions (the game was/is clearly aimed at a certain market which is NOT the current fanbase) in hopes of making a big profit and completely ignoring their users.

Google Translate

To put in a success story as well so this doesn’t turn out too ranty, Google revamped their Translate-service in the latter part of 2018. Most of us have most likely used the service at some point or another so I’m going to skip the explanation and jump right into the meat of it.

During the re-design, one of the designers’ biggest worries was handling change aversion. People who have become accustomed to using something and have worked out the kinks of it tend to be reluctant to change and may rate your transformed product more poorly than they would if it was a completely new one. In Google’s case this was a very prominent issue as their services are used worldwide by hundreds of millions of people on a daily basis.

To combat their troubles, the designers’ did what any logical person would do when designing something for someone else: they asked them. Not only that, but they got users to actively participate in the design process from start to finish. The design team spent hours and hours reading through the feedback the users left for both the old and the new iterations of the service and adjusted their designs based on it. They gave the users new versions of the service to test and then worked on the next iteration according to those results and what comments the testers gave back.

The entire process is a great example of how you should utilize your most valuable assets and be ready to listen to them, even if it means scrapping your own assumptions, ideas and designs. In Translate’s case, a good demonstration of this were the visuals of the translation boxes. The team had made the translated text to appear as white text on a blue background, but due to feedback from both within the team and the users through simple A/B-testing, this was scrapped and replaced with a simpler, black text over grey background solution.

Listening to actual users’ actual needs and opinions on something they use constantly can be a game changer for your product. It is far too easy to rely on assumptions and incomplete, inaccurate data and make wrong decisions that will see your product fail. You have to be willing to abandon even some of your glorious “golden egg”-ideas if the evidence simply mounts against them and I can speak from experience that it can be tough, but needs must. As Google Translate demonstrated, taking end users aboard from the very start can cause you some discomfort, but it will drastically improve your product’s quality and reduce costs as your team does less fruitless labor and fixes the problems later when it has become more expensive and difficult.

The importance of listening

I like talking about games, so here’s another example from that corner of the world. Valve, another mammoth of the video games industry and the operator of the most popular PC gaming platform/store, Steam, decided to jump into the booming card game business with Artifact, a new title that utilized the existing, popular Dota 2 landscape in its content with unique, new gameplay mechanics designed by some famous names of the card game industry.

The game was opened up for closed beta testing in early 2018 with a respectable number of pro players, streamers and the like participating. This closed beta test lasted almost until the end of the year when the game was properly released. During this time, the beta testers continually played the game and gave their feedback about its various aspects and what they thought were right and wrong about it.

Unfortunately, this is not an example of how everything worked out. Despite having these testers, these actual end users, present and voicing their opinions, for some reason the team at Valve refused to act on the feedback they received. They made some minor changes, like adjusting the use costs of cards and such, but the biggest complaints the testers had fell on deaf ears and, as many of the testers have said, not a lot of changes happened during the testing period. Clearly, the team behind the game was fixated in their own views being the correct ones and were not inclined to change them.

Fast forward to the game’s release at the end of the year. It enjoyed some early success as it was the new, hot novelty product from a big name developer and even had some tournaments as well. However, within two months of its release, it saw its playerbase drop by 95%. The game never recovered and despite a reboot being in the works and currently in beta testing, it is widely considered as the company’s biggest failure.

This is an example of when the design team, and the company overall, refuses to cooperate with its users and stick with their own visions despite constant feedback to the contrary. Granted, every now and then it might even pay off, but for Valve and Artifact, it led to a massive fumble. Getting users involved in your development process and then ignoring them is arguably even worse than not doing any user research at all, as you are giving false promises to these people that their efforts will be important to the project. Neither of these options is a good one and it only goes to show that half-baked measures do not lead to much success.

Conclusion

User research is a key part of most good IT development processes. Every piece of software, hardware or other products exists because someone, somewhere, currently has or has in the past had a clear need for it. Removing or ignoring the research and replacing it with assumptions and guesses may not always backfire as horribly as for example in Artifact’s case, but the risk is always there and tends to materialize, to some degree or another. Especially in the modern software development scene you will never have a shortage of competitors, so you need all the advantages you can get. Omitting UX is taking on a handicap of your own free will.

What makes it absurd is that we have all the tools necessary to neutralize and minimize the aforementioned risks from the very start. We have professionals who work on user research and UX/service design for a living and who are willing and able to do the legwork. You can go search the Internet and you’ll find plenty of studies and articles about how UX can save you money, how the return of investment, or ROI, of UX is excellent and how you can, imagine this, satisfy the needs of your users. It’s like running a restaurant. You can certainly make a cheeseburger for everyone that comes through the door and get OK ratings, but aiming for anything more than that does require you to actually ask what kind of a burger your customer would actually want and then fulfill that specific need.

The people who can give you the absolute best feedback are people who are in no way associated with your company or part of your production pipeline.

Stop ignoring them.

Some related links:

Blizzard and Diablo Immortal: https://www.youtube.com/watch?v=YhqWaqL2N7A

Google Translate: https://medium.com/google-design/3-ux-takeaways-from-redesigning-google-translate-3184038f43bf

Valve and Artifact: https://www.eurogamer.net/articles/2019-07-03-how-artifact-became-valves-biggest-failure