A good amount of the time, when Unstoppable gets called in to speak to a company about a custom software project, we enter the scene in “project turn-around” mode – meaning, the client has already worked with two or three vendors over the past few years, but they’ve consistently failed to deliver the product desired.
Sometimes the reason for this failure is that the developer couldn’t control costs and ended up burning through the budget, then coming back to the client with their hand out, asking for change orders for features that were already in the initial spec to begin with. Sometimes they simply weren’t hands-on enough, didn’t communicate well, or just plain didn’t have a true commitment to the success of the project (i.e., skin in the game) – and we all know that no matter what your goal is, unless everyone on your team is committed and excited about the business purpose, goals, and success of the project, you’re likely to fail.
Often though, what we see clients running into isn’t exactly a “full on failure” – the issue isn’t that the development vendor flat-out failed to deliver anything, but more that what they delivered just wasn’t user-friendly enough to actually work for users who need to get their jobs done.
Ultimately, software has to be a tool that helps a person accomplish a task in a way that saves them time. If your software isn’t user-friendly, it can actually take more time to use the software than to pick up the phone, or shoot out an email that accomplishes the same goal. So users might totally 
bypass the system and do things the “old way”, rather than using that bright shiny system you paid so much money for.
This is, in my humble opinion, the definition of software development project failure.
So, as software developers, how do we keep from running into these types of problems? What knowledge can we draw on to know what steps to take to avoid user un-friendliness issues?
The answer, is quite simply, experience in the field. Once you’ve walked into enough customers and seen the wreckage that people such as weak consultants, “cowboy” developer employees, and below-average talent leave behind, you start to recognize trends that you can later use to your advantage. Sometimes, hindsight is equal to foresight.
Below are a few stories that we’ve run into in our day from projects done by other development teams where, quite frankly, a lack of user-friendliness killed the project.
The ERP that was Old When it Was New
Several years ago, a friend of mine was working at a company who was in the process of rolling out a large ERP system to all of its users. This company was in the healthcare product space, and was way behind its competitors when it came to having a true ERP system that it could use to track its standard processes. For many years, and because of acquisition, this company had a number of homegrown, internal mainframe systems than handled all the various ERP-related workflows for the company, but no one system that could do it all.
Upper management wanted one system, because otherwise, they had to look at rollup reports from each of the different mainframe systems, which were often delayed, and because the data from the reports couldn’t be correlated, they often didn’t have the visibility into true output and production that they needed.
So after many years (over a decade actually) of implementation, the company finally had a system deployed that would solve all their problems. It was severely over budget, massively complex, and basically looked strangely a lot like the old mainframe systems.
There was only one problem – of all the hundreds, or even thousands of users in the system, no one could use it. It was laid out so differently from the custom processes they had all gotten used to over the years, that in order to do their jobs, they ended up having to jump between three or four screens just to get the data and accomplish what they used to be able to accomplish all on one screen.
So what was the solution? After spending millions for an off the self, out of box system that would meet all their needs, this company ended up having to build a custom system just to take all the data out of the off the shelf database, display it arranged in a better way on the screen, and then pump it back into the off the shelf backend. So, millions of dollars for a very fancy product that no one uses except through a custom interface (which itself was also very expensive).
There are a lot of lessons from this case study, but probably the most obvious one is that if your users are used to doing their jobs in a very particular way, you can’t just swap in any piece of software just because it “sorta” matches their flow. “Flow state” is very important to the success and output of a department, and if you interrupt it by making a user’s software too hard to use, you’ll suffer for it.
The Comments Not Welcome Button
A few months ago, another friend of mine was working at a large non-profit. They had hired an overseas software development vendor with money they had received from a grant, and unfortunately didn’t know what they were getting into because the vendor was now telling them the money was all spent, but the system wasn’t finished. Since the money was grant money, no further funds would be available to finish out the project.
The part where this relates to non-friendly software was that from the developer’s standpoint, everything was working perfectly, and there were no problems. One particular feature I recall hearing about was that users were supposed to be able to enter notes in the system in the form of comments at the bottom of a message thread. However, the developer had put the “Add a Comment” button at the extreme bottom of the page, so that instead of being able to click right under a message, users had to scroll down to the bottom of all of the messages (of where there might be hundreds) and click the button – all just to add a comment to the top message.
From the developers perspective, the feature worked fine and met the requirements, because it was true – you could indeed add a comment to the system. However, it was so incredibly time consuming for a user to go through and add say, 10 comments on the page, that it was obvious that no one would ever be able to use the feature. It was a dead feature before it was even launched.
And because this was only one example of the poor implementation of features in the system, it was likely that the company was going to need to resort to a legal battle in order to make any progress with this firm.
I think this also brings up another point around the concept of user-friendliness – that for any given software feature, there are truly 100 different ways to implement that feature, ranging from very difficult to use, to extremely easy to use. I often tell clients that part of the reason we need to dig in and “do our homework” before starting a project is because we need to figure out what level of solution they need for a given feature – the cheapest solution or the most expensive solution – and I think this pattern is similar here, in that without walking through the way a feature is going to work with a developer ahead of time, and really, truly making sure you are on the same page, you never know what you’re going to end up with.
Not the Right Fit
Sometimes, the user-friendliness of an application comes down to one simple problem: performance. If a system is too slow to return results to a user, they’ll get tired of waiting, and simply refuse to use the system.
Several years ago, I saw this exact case, when a system that a client had been using for a very long time began to show its age and was unable to keep up with the expectations of modern users when it came to response times. I think it was a true statement that the system had gotten slower over time, but it could also have just been the fact that users nowadays have a different expectations for how fast a system should be. Fifteen years ago, most people still had 28.8k modems that they accessed the internet with over dial-up, so they were used to waiting 20-30 seconds to download a JPEG image or access a database screen. But nowadays, that type of response time is totally unacceptable. I can pull up a live traffic map of my entire area on my smart phone in less than a second, so I’m not going to wait 30 seconds for a report to run.
So, that was the case with this old system my client was using. At one time it was considered “fast enough”, but over time it lost that title and became “too slow”. The problem was, of course that over that long period of time, a large amount of features had been added to the system, as well as a large amount of data, so the question the client had to ask themselves was, is it worth it to pay several hundred thousand dollars to replace a system that is 
working fine feature and bug-wise, but is simply slowing down our users? They sat down, did the calculation of the time that each user would save in an average week if requests took 1 second instead of 20, and the math didn’t lie – they would save a huge amount of money by replacing the system, even if it did cost six figures.
So in summary, there are three different paradigms I see when talking to people about systems that aren’t user friendly:
1. The system doesn’t match what the users already do for their daily job
2. The system technically supplies the feature, but not in a useable way because of how many clicks or pages you have to go to in order to use it
3. The system is too slow to appeal to the modern expectation of speed and response time
As you look at designing a new system or replacing an old one, ask yourself, how different is this from what my employees already do on paper every day? Is there a way to make it match their process more closely? Is the way the feature is being implemented going to require as few clicks, scrolls, or drags as possible? How quickly should this system respond? What is “fast enough”? Seconds? Milliseconds? Do we have the server infrastructure available to support that?
Ask yourselves those questions, and you’re halfway there towards avoiding some of these past mistakes other companies have experienced.
