Menu Search
Jump to the content X X

Are Your Internal Systems Damaging Your Business?

The internal systems of many organizations have shocking user interfaces. This costs companies in productivity, training and even the customer experience.

Fortunately, we can fix this.

“How come I can download an app on my phone and instantly know how to use it, yet need training to use our content management system? Shouldn’t our system be intuitive?”

This was just one of the comments I heard in a recent stakeholder interview. People are fed up with inadequate internal systems. Many of those I interviewed had given up on the official software. Instead, they use tools like Dropbox, Google Docs and Evernote.

Further Reading on SmashingMag:

The problem seems to exist across the board. I am hearing the same thing from employees across many companies and sectors. I am also hearing it about almost all types of internal systems, from ones for customer relationship management (CRM) to ones for procurement. They are all painful to use.

Frustration will only increase as millennials enter the workforce. These people are digital natives, and they expect a certain standard of software. They expect software to adapt to them, not the other way around.

The result of this frustration is that employees are abandoning these systems. People use email instead of a CRM and put documents in Dropbox rather than on the intranet. This leads to systems being out of date and, thus, irrelevant to the organization.

How have things gotten to this state? Why is enterprise software so bad?

One Size Does Not Fit All

I think technology is often oversold. “A content management system is the solution to content!” “An intranet is the answer to improving efficiency!” “A CRM system will manage the customer relationship!” But that is just not true.

Unfortunately, in the eyes of senior management, once a piece of software is purchased, the problem is solved. Job done, move on to the next challenge.

One size rarely fits all. Organizations rarely work in the same way, even within the same sector. Even if a law firm purchases an intranet designed for the legal sector, the system won’t necessarily work well out of the box for that firm.

People work in different ways. The functionality required by the secretary to the CEO will be different from the functionality required by someone in accounting or HR. Yet many enterprise systems do nothing to streamline the experience for different groups.
People work in different ways. The functionality required by the secretary to the CEO will be different from the functionality required by someone in accounting or HR. Yet many enterprise systems do nothing to streamline the experience for different groups. (Image source: opensourceway5)

Many of these systems could be tailored to the needs of individual organizations or employees, but they are not so out of the box. They need to be configured and optimized, which usually does not happen — or else the wrong system is purchased to begin with.

There must be a better way.

Starting With Users’ Needs

The procurement process for these systems too often begins with a list of desired features. This is the wrong starting point. We should approach internal software in the same way that we develop external applications: starting with users’ needs.

Regardless of whether you already have a system in place, identify your different user groups. Who will be using each system? Once you know that, shadow them for a while. Understand how they work. What do they do each day, and what system do they already use to get their work done?

Look for pain points in that system, and talk to them about where they get frustrated. Identify the information they need to do their job, and be aware of any clutter that gets in the way.

Finally, identify your users’ top tasks. Which tasks do your different user groups do again and again. These need to be super-accessible.

You might think that you now have enough information to buy a system. But just because something has the functionality you need does not mean it is easy to use. Before leaping for expensive software, design the user experience. We can do that with some simple prototyping.

Prototype Your Perfect System

Creating a prototype of how your ideal system would work does not need to be time-consuming or particularly expensive. Best of all, it could replace a long-winded and abstract specification of functions.

Using nothing but a bit of HTML, CSS and JavaScript, we can build a working prototype that can be tested with real users. Does this prototype match their workflow? Does it give them quick access to key tasks? Does it accommodate the differences between groups? Which parts of the prototype are having the biggest impact on productivity, and which are just nice to have?

We can iterate on the prototype based on user feedback until it offers the optimal experience.

With that vision in place, you can compromise intelligently.

Informed Compromise

A working prototype is a good standard by which to measure different software — much better than a specification.

Could your existing system be set up to mirror the prototype? If it can’t exactly, then which areas would you have to compromise on? Based on your user testing, are these compromises acceptable?

If your existing system cannot replicate the key functionality of the prototype, look at alternatives. Talk to other vendors and show them your prototype. Ask whether their system can replicate it, and once again, decide on areas of compromise based on user feedback.

Do you see the difference here? The experience is designed around the user, not around what the software provides. Also, if you cannot find software that meets the needs of your users, consider building a bespoke system.

Buying software off the shelf makes no sense if no one will use it or if it provides no business value.
Buying software off the shelf makes no sense if no one will use it or if it provides no business value. (Image source: opensourceway6)

I know what you’re thinking. This makes sense, but senior management won’t go for it. They won’t pay for a prototype or a bespoke system. Well, that depends on how you sell it.

Selling The Need For A User-Centric System

Convincing management to spend money on a prototype can be hard. It’s hard enough when a clever salesperson says that their software will solve all of the company’s problems — harder still if management has already paid for a fancy system. Nevertheless, solid business arguments can be made for this approach.

If your company has a system that is not fit for its purpose, you should be able to prove this. Collect data on how users interact with the system. Combine this with user testing and stakeholder interviews. This should be enough to establish a compelling case — at least compelling enough to justify some limited prototyping of an alternative approach.

Remember that you are not asking them to replace the system. You just want to prototype a potentially better solution and see whether the current software could be set up to match it. When managers see a better way, they will usually be open to change.

If the company does not already own a system, then your position is even stronger. Enterprise software is expensive, and so ensuring the right fit is important. Getting it wrong could mean hundreds or thousands of dollars wasted. A prototype will prove more effective than a specification at measuring the suitability of different products. It will also make it easier to compare software.

Of course, management could take the position that employees will just need to get used to what they have. This argument has some merit. Given time, users would adapt to even the most archaic of systems. But at what cost?

The Cost Of Failure

Poor user interfaces require more training and support. Both are a cost borne by the organization, not to mention the frustration it causes. Even more significant is the cost in lost productivity. Organizations are keen to maximize efficiency, and systems that are easy to use go a long way towards this.

Unfortunately, some managers seem to care little about internal processes. But they do care about customer satisfaction, which is becoming one of the most popular factors for organizations to measure. We now live in a world of consumers who are connected and have a voice through social media. That makes organizations sensitive to negative comments and experiences.

Internal systems weigh heavily on the performance of your employees. And they have a massive impact on the customer experience. These systems ensure timely responses; they help deliver the product; and they facilitate customer relationships. This is why internal systems are becoming the next big competitive advantage.

(al, il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6

↑ Back to top Tweet itShare on Facebook

Paul Boag is the author of The User Experience Revolution and a leader in digital strategy with over 20 years experience. Through consultancy, speaking, writing, training and mentoring he passionately promotes digital best practice.

  1. 1

    In my company we use a CMS that is a pure abomination. To manage content we use pretty nasty mix of an online tool (php/mysql), java admin tool that runs on virtual machine with win xp and IE6 and separate .NET solution to manage another part of the system. It’s hard to use, slow, full of errors but still better than our own solution that’s been discontinued few years ago. Present solution is supplied by an industry leader and products of their competitors don’t even come close in terms of functionalities. In order to change that we would need to create our own system again and it’s just not possible as the costs would be enormous.

    I think your points are good but are easier to apply on initial stages of choosing the right system 

  2. 3

    So true!! Great article! If only companies would invest in good software that fits around the user and their process, they would realize that it would help solve a lot of their problems with client turnover, communication confusion, employee boredom/frustration, etc. Instead, unfortunately, they try to force employees to fix problems, but don’t dare tackle the root of the problem.

  3. 4

    Well said, Paul. I happen to be in the process of rebuilding some ugly user interfaces for our events and job posting pages on our site and this is all very true. The better the interface is built, the less hand-holding I’ll have to do and I’ll be less likely asked to do it for them.

  4. 5

    It is my job to develop internal systems. I come from web development background so try to make the sites as easy to use, as if it was for a customer. I make an important distinction in my business that i’m not part of IT. I can add value in a totally different way when it comes our internal system.

    When an IT team implements a system, they don’t care about user friendliness; they look for amount of features, as typical nerds do. Just this week I saw a data warehouse that’s being put in, and you have to install java, set your browser to allow the plugin, then allow some other override, just to be able to look at the damn reports!!!

    • 6

      Great assessment of how IT evaluates systems for purchase! There are a few different ways I’ve seen this process play out…

      There’s often a list of features that are desired for the software, and whatever solution can check off the most boxes on that list is the one that’s selected. But we overlook the fact that 20% of the features will be used 80% of the time, and there is huge benefit in identifying those top features and making sure they’re implemented well in the product.

      Or… IT will be in charge of everything, and IT people just don’t think the same way as non-IT people. I worked on a website redesign where IT insisted on focusing exclusively on search. They wanted the site to look similar to While doing some research I found that only 5% of visitors actually used the existing search on the site, which was in a very prominent location on every page. Some additional research found studies that showed how IT people are very search-centric, while the general population prefers to browse websites–similar to people browsing in a store instead of asking a salesperson for a specific item. (Of course, all this depends on the specific website, etc.)

      Or… IT will have a preferred vendor or approved vendor list, and they do whatever it takes to choose that vendor’s product.

      There’s definitely value and benefit to having the actual users involved in the selection process, and identifying the top tasks the solution must perform well.

  5. 7

    What’s really difficult is the implementation/usage of multiple systems under one roof. The hardest part sometimes is to get everyone on the same, single database and interface. The challenge is to mold a CRM system context into a purposeful use for each person’s role in a organization. Transparency as well…whew, its a tough one to tackle! But having one single ‘hub’ is often a hard battle to overcome.

  6. 8

    Geert-Jan Brits

    September 14, 2014 4:17 pm

    Great article.

    Although only part of the solution, do you believe this “one size doesn’t fit all” problem can be mitigated with solutions like Zoho Creator, which essentially let’s u build custom forms and logic around your workflow instead of the other way around?

    Seems to be better at least, then letting everyone getting back to hacking in excel, etc. because their off-she-shelve products don’t work.

  7. 9

    Great article Paul. I would also like to mention that another area which never gets attention is authentication systems. Besides a CRM, there are usually other tools within the organization that required you to have a username/password. Why not design and build a cohesive system that allows for SSO across applications with 2FA for strong internal and external authentication? Having a system that only works in IE is one thing, but having 12 systems with quirks and their own set of credentials is just brutal. True usability and security always seem to “take a back seat” when it comes to internal systems.

  8. 10

    I respectfully disagree.
    Most off-the-shelf or out-of-the-box solutions already have reasonably good UI.

    The problem is really how people mis-use the system and refuse to transit out of the familiar but outdated mindset and into the new system with more features.

    Take the example of an intranet system. It has file-sharing, search, discussion boards, surveys, version controls, permission controls, integration to the mail client apps, file management systems and instant messaging.

    But the people in the company still cling on to the old network shared drive technology, still work with as many versions of documents as the number of people in collaboration, still choose to get frustrated when others overwrite their work or can’t find the documents they need.

    You can try to get the users into a focus group to create a sexy UI layer, but they are more likely to hint that they don’t want to change the system or ask for the new system to work as inefficiently as the old system.

    Bottomline, great UI isn’t a silver bullet. You still have to contend with the why-change-it-if-works mentality.

    • 11

      I respectfully disagree.

      The only people who can accurately judge the UI are the users of it. A significant problem in most projects which intend to improve the user experience, is that people other than the users decide how good the experience is. This introduces a large margin of error.
      It also makes my job of delivering good UX harder as the methodology looses credibility when it is used incorrectly and fails to deliver results.

      Secondly, the problem you describe is where an intranet has many features but nobody uses them. This is probably because the user experience is poor. This can either be because the UI is below their expectations OR the data / content in the intranet is not valuable.
      The latter cannot be fixed by changing the software, it can only be fixed by improving data quality, or increasing adoption (in the case where collaboration is a function).
      The latter can be a dangerous “death spiral” when multiple systems are used to solve an issue, but when the underlying problem is data quality or low adoption, then this makes the underlying problem WORSE.

  9. 12

    I think you’re absolutely right, Paul, that the proper solution is to start with the user’s needs, and then work outwards. Make software decisions – not on features – but on how well that software can meet the needs.

    My experience has taught me that there are two major blockers to the approach which you recommend:

    1. Non-users of the system purchasing the system
    2. Long-term commitments/ relationships to “Vendor[X]”

    In the case of #1, that’s where I see IT executives or Marketing directors deciding unilaterally that an organization is going to switch to a certain software. They’ve made this decision because the sales-person at Vendor[X] saw *their* face on the website, or found *their* profile on LinkedIn. Sales people often go to decision makers, not software users. And the selling point is on the features of the technology, not the usability. It’s like ordering the same meal for everyone at the table after the waiter tells you about the daily special. This is where you have round holes, and you get round pegs that are too small, or square pegs that fit just right.

    In the case of #2, this is where an organization has a long-term commitment to Microsoft, Adobe, IBM, or some other vendor. That commitment is either contractual, or political. Instead of looking for the best software, that best meets all the needs, you look at the cheapest software that “kind of” meets a few of the needs. It’s like asking for a premium steak at a seafood restaurant. This is where organizations end up shaving a square peg so that it can fit in a round hole.

    In both cases, there is little we can do as the “boots on the ground”. In instances of #1, we can try to influence our leaders to not make decisions without us. In cases of #2, well… the #2 roles down hill…

  10. 13


    Really great article. I’m in the process of writing a blog to give advice to executives who are looking to invest in a commodities trading and risk management (CTRM) system, and I had a question.

    – In order to get information on the blog I’m writing, I interviewed a couple of CTRM experts who have implemented more than 18 systems at different organizations. One of them advised that executives formulate high level requirements for the system, THEN poll users and IT to add more detail to those requirements. This seems to contradict the advice in your blog. What is your view on this way of approaching the situation?

    I appreciate your information and your time!


↑ Back to top