Why Enterprise UX Design Grinds to a Halt (and Why It Shouldn’t)

Why Enterprise Design Grinds to a Halt (and Why It Shouldn't)
Throughout the many years that Fuzzy Math has been practicing UX, our team has worked on hundreds of projects, many of which have been in support of enterprise software. While all projects and clients are unique, we’ve found that many teams behind enterprise software share similar concerns (and successes) when implementing a user-centered design process for their organization.

The ecosystem that supports enterprise software is exceptionally complex; it includes complicated relationships between the buying and selling organizations, legions of support teams on both sides of those relationships (think: sales, product, support, development, implementation, etc.), and decisions being made to purchase the software without including input from actual users. While there are plenty of other reasons that the enterprise UX design process is complicated, these reasons alone help explain why it’s not all that surprising to find that enterprise software rarely delivers the best user experience.

When Fuzzy Math is brought in to help course-correct UX issues in our client’s enterprise software, we always have our user-centered design process in tow. Given the existing challenges of working within the enterprise, it isn’t a complete shock when our suggestion to follow a user-centered design process is met with a sideways glance or two. Below you will find the three most common concerns we’ve heard, along with ways our user-centered design process has proven successful time and again.

“Actual users? Oh, no, I don’t know about that”

Sourcing the right research participants, particularly when dealing with large enterprise clients, is sometimes a challenge. When we request that we speak with true end users as part of our work — one of the fundamental parts of our work, to be exact — the request may be met with some resistance. They say things like:

  • “The users don’t have time to speak with you, especially since you’re a third party.”
  • “Our users are so broad in their usage of the tool, it will be impossible to learn about their needs.”
  • “The users will be so negative that you won’t learn anything from them.”

Some clients try to get around this last example by cherry-picking only the happiest clients, but this limits what we can learn about the system. “Everything’s great!” tends not to lead to great innovation.

After speaking with a variety of users, ideally many more unhappy than happy ones, the general feedback is that:

  • Users love being a part of the process to improve the tool they spend a good portion of their day using.
  • Users enjoy speaking to a third party, as we promise confidentiality (though some make it clear they would be happy to complain ‘on the record’) and provide a structure for capturing the feedback.
  • Sourcing users is typically easier than expected, since it is well known who the new and expert users within the organizations are.
  • This process is usually so well received by our clients’ customers that it is continued once we are off of the project.

“They’ll want us to change too much”

Once we get the go-ahead to conduct user interviews, our clients’ concerns shift to, “What is going to be asked from our customers?” and, “How is that going to be supported?” Examples include:

  • “We have tens of thousands of existing users. We can’t just blow it up and start over!”
  • “We don’t have the resources at the moment for large-scale feature additions.”

In reality, what we’ve seen has shown us that these are valid concerns, but not the outcome of speaking with real users. Using this process has shown us that:

  • Nearly all research leads to discovering quick-fix, low hanging fruit as well as larger changes, such as new features from which clients and their customers can benefit.
  • Prioritizing the captured feedback into a roadmap is a critical step in the process, and leads to quicker development timelines.
  • Changing enterprise software is a lot like turning an aircraft carrier — there’s a lot of momentum, so large, fast changes probably aren’t all that wise to begin with. We’ve found that having multiple small changes batched with a larger one in the release cycle keeps both customers and development teams happy.

“I’m not sure if adding more process is going to help us”

The idea of adding more process to an enterprise organization is rarely well-received. You find processes pretty much anywhere you look in the enterprise — between teams, employees, customers, vendors, etc. For that reason, it makes sense that adding more isn’t the first priority. This is especially true when the suggestion also includes pulling in a new group of people: end users. Typical concerns include:

  • “We already have processes for everything else; we don’t want any more.”
  • “We definitely don’t want to include a whole new group of people into our process.”

However, applying well-run enterprise UX design services leads to many wins for the organization:

  • Well collected feedback will assist in building a UX and development roadmap that both users and the development team will appreciate.
  • This process will include other teams of stakeholders (sales, product, etc.), helping to get the larger team on the same page and making sure everyone is pulling in the same direction.
  • Time will be saved later on through the reduction of change requests, support calls, and training.

Where complexity reigns, it makes sense that any suggested changes to the existing structures will be met with a certain degree of hesitation. We’ve found, however, that the most common concerns tend to lead to the most positive results.

Want more content like this?

Stay up to date on all things UX with our newsletter.
envelope mail-envelope-closed file_pdf arrow-up chevron-left arrow-left close x linkedin twitter facebook mailbox search