Developing the User Experience in Your Enterprise Applications

This article was sponsored by Incapsula. Thank you for supporting the partners who make SitePoint possible.

The user experience (UX) is vital to the success of an enterprise application. According to a recent study, by Forrester Research, a well-designed user interface could raise your website’s conversion rate by up to a 200 percent and a better UX design could yield conversion rates up to 400 percent.

Until recently, the user experience (UX) was an afterthought when designing enterprise applications. In the days before web-based applications, a handful of software behemoths developed, bundled and sold applications that didn’t always consider the user experience.

But as applications moved to the web, many more developers could create and market application to reach a wider customer base without having to adapt to the behemoths’ platforms. These start-ups were more nimble and more competitive and soon learned that to advance competitors, it had to start listening to customers and UX design was born.

Developers often conflate UX with usability. They are not the same. UX is the experience, emotion, intuition and connection a user feels when using a site or product. Usability is more about the effectiveness of a site design and how user-friendly it is. Usability is a key component of overall user experience.

Today, designing enterprise applications, particularly those that are hosted on the web start with the end user in mind and asking a lot of user-centric questions.

• Who is the user and what are the user’s skills, experiences, and use cases/scenarios?
• What are the user requirements for task sequencing, usability, training, responsiveness, performance, and interoperability with external applications and data?
• Is the user a dedicated employee who can tolerate usability quirks or inconveniences, or are they a consumer who may not buy any products if the user interface is not easy, reliable, and efficient?
• How much feature documentation and help will the user need? Will they have the patience to read documentation?
• Will the user require product support? Will they pay for it?
• How many users will be using the application at any one time?
• How powerful is the user’s desktop computer, and how fast is their network connection?

Incapsula, a leading DDoS mitigator, is currently revamping its own graphical user interface and is currently asking four fundamental questions in when considering the UX:

• Who are our users?
• How do we want our users to feel?
• What Scenarios are we designing for?
• Did we miss our target?

Who Are Our Users?

The answer to that question will be different every for each customer. And even within that customer there may be several subsets of of answers. For example, the Incapsula development team found that it had UX user working alongside customer experience (CX) user. The CX user was the customer who would not necessary use the product day-to-day, but are the platform peers and managers who will actually be the ones making the purchase. The CX is best represented during presentations. It’s really a tool for sales teams. Incapsula learned that NetOps, system admins and security professionals preferred functionality to presentation, but CX was no less important.

How Do we Want Them to Feel?

Like I said, UX is the experience, emotion, intuition and connection a user feels when using a site or product. The developers at Incapsula cite five emotional states that users have when using an enterprise application:

• Power – Users want to affect real change while using the application
• Control – Users want to be the ones directing their application.
• Assurance – Users want a secure application that performs as intended.
• Pride – Users want to view their application as superior to market alternatives.
• Accomplishment – Users want their application to help them achieve their goals.

In its customer reviews, Incapsula discovered that one of the recurring emotional states that its customers needed a sense of assurance.

But how do you communicate assurance with software? Well consider that we are working in a hybrid environment of Windows-based and web based application. And both handle input differently. In the Windows-based environment, typically a change is only written when the user clicks “save,” In Microsoft Word for example, a person could be writing all day, and if they don’t choose Save at some point all that work is lost.

Google Docs works differently. Google Docs is committing each change in near real time and saving major version. Changes to font, style header are all automatic and backed up. There is no Save button.

Each has its own merits and neither a wrong, but their approach to change management has left the users with the uneasy feeling that the change they’ve chosen may not be saved.

Incapsula found that the use of an animated check mark, which appears when a configuration is changed using auto-save provided that sense of assurance.. “We saw that this small verification was important to many users who were looking for confirmation that an action correctly took place,” said Lior Atzmon at Incapsula.

What Scenarios are We Designing For?

Again, with the user’s emotional state in mind, the development team needs to consider how a user would interact with specific tasks, like in the case of Incapsula, how someone may to purge cache on on its Content Deliver Network (CDN). Incapsula considers the emotional state of someone who has come to purge cache. Would they ever be anxious? Would it be an emergency? It’s it part of a larger process that requires change management? All these and more need to be considered for a simple task of purging cache.

“Once your scenario has been defined, said Atzmon, “it needs to be broken down and analyzed from all angles (e.g., user knowledge, technology, limitations, user goals and needs) in order to craft the best possible UX.”

Did We Miss Our Target?

The testing and feedback circle is critical to the testing phone. You never stop listening. “Three to five volunteers should then be recruited to test your application and provide feedback. Here you can use Validately,” said Atzom.

Are You Eating Your Own Dogfood?

The people who design the product are very different from the people that use a product. It’s rare that it happens. Ideally, your developers also use their product from day to day. When Microsoft was developing Internet Explorer, the developers had a new build on their desktop every day. As they compiled mistakes, they would put the fixes in the next build. They called it. “eating their own dogfood,” or “dogfooding.”

It isn’t likely that the developers for Incapsula are also in charge of cache management, but they do have a group of employees down the hall that they can query. The closer the developers are to application use the better the application will be.

With such a competitive landscape, UX is critical in enterprise applications and a successful UX comes from listening to your customers.