Technical Problem or Wrong User Experience?

I'm going to start off with some general statements:

• Programmers by their nature love solving problems, the harder the problem the more satisfied we feel when we have the solution.
• Programmers also love to try new things, new programming languages, frameworks or technically challenging features we've seen somewhere.
• Product owners have a tendency to want to use familiar features they have seen in software or websites they use often.
• When designing software with any kind of UI it's surprisingly easy to forget that it needs to be used by another human being.
• Many technical problems aren't obvious until a solution is exposed to production size data and load.

Why do any of these statements matter?

A couple anecdotes from my professional career:

How many soccer games are there in the world at any one time...

I worked with a great team on a sports betting website for many years and soccer was (and probably still is) the most popular sport for most of the year. One day we had to look into some performance problems with the site, it wasn't loading quickly enough and our clients were complaining. To give you some rough numbers to put things into perspective:

• 1 League on average is ~ 21 KB of data to display the games and odds
• 50 Leagues would take ~ 1 MB
• 1,024 users getting that much data would consume ~ 1 GB
• 1,048,576 (~100k) users would consume ~ 1 TB

These are very conservative numbers for this site but they're nice numbers to work with to illustrate the problem and how quickly it can grow under production load.

The solution the team was given in order to solve the problem was to use infinite load (made popular by Twitter and Facebook) in order to keep the initial transfer small and fast. A quick discussion with the team identified a few problems with this approach so it was tweaked a bit, implemented and released. In most teams, this would have been the end of the discussion but at this point, my team had been listening to me (and once converted helping me) evangelise User Experience for a few years and this turned out to be a bit of a catalyst. We put ourselves in our user's shoes and asked as a user if I've never bet on soccer and probably never will, can we load the sport, league or game I'm most likely there to place a bet on by default. By going straight to what the user wants and not loading something the user had no interest in we were able to provide a better experience and save on that wasted transfer and load time. The resulting change in how we looked at our site, UI and UX affected many of the projects that came afterwards.

How many commercials are being sent to broadcasters at any one time...

Years later I'm at a new company in a completely different part of the world and industry and I find myself in a familiar situation. I'm working with another very talented team on some interesting and complex problems and I see my old friend the infinite load. Without getting into too much detail about the overall process it turns out when creating and delivering TV commercials to broadcasters there are many people interested in whether or not the commercial has been delivered. To solve this problem there was a tracking page which loaded everything the user had access to and may be interested in. To avoid overwhelming the browser this page also used an infinite load to keep adding deliveries as the user scrolled down. I'll try not to go off on a tangent on why infinite load is a horrible user experience, suffice it to say that the most popular uses of it are on sites where people go to essentially waste time and don't really know what they're looking for. So I started looking at this page and asking, from a users perspective is this really a good experience for me?
For example, as someone who has created an order and is trying to deliver multiple files to multiple broadcasters, I'm probably very interested in those deliveries as a group.
Now change takes time and there's always more work to be done than time to do it so at the time of writing this I can't say whether or not I've been able to incept the same type of change in the company but I'm happy to say that I can see a change within the team members and the questions they ask.

At this point, I hope you're nodding along and thinking about some of the less than ideal experiences you see, use and may have even built and you're now considering how they could be improved. There are many influencing factors, the statements I made at the start are some of the easy ones to identify in order to see why a particular design, solution or experience has been chosen. I've found that when a technical problem is hit it's a good time to take a step back and re-examine what it is you're trying to achieve.

TL;DR

If you hit a technical limitation in software intended for use by a person ask yourself if you should be solving the technical problem or changing the user experience and design so it's actually usable. Usually, by giving the user a better experience you also eliminate the need to solve that technical problem.

Here are a few questions you can use to get the wheel turning:

What is the user trying to do or what information are they most interested in?

Do you currently have the data needed to give them a customised experience (if not can you get it)?

When you use the software/system are you shown information or intermediate steps that you really don't care about?

When working with software for work and business the user is trying to accomplish something as quickly and efficiently as possible. As someone who builds software, you should always be asking if the user is being given the best possible experience to achieve their goal.