Why Most Corporate Software Stinks, and How Contextual Inquiry Can Improve It

Corporate software usually consists of layers on top of layers of legacy systems, each with its own look and feel, none of which are designed to support how people really work. To improve the often dismal experience of using corporate software, I recommend observing customer-facing employees firsthand using contextual inquiry, and using the results to supplement and reality-check your business requirements. In this blog, I will detail the steps needed to improve internal applications using contextual inquiry.

For consumers, the open market fosters quality and sets experience standards for apps, websites, and mobile devices. As a consumer, if you aren’t happy with the experience a product or service offers, you can look for a replacement. In the consumer space, the availability of choice and the freedom to switch puts pressure on consumer technology companies to constantly measure, assess, and improve the quality of the experiences they offer.

However, there is no similar experience quality ecosystem for corporate software—the tools companies provide employees to use to serve the company’s bill paying customers. These tools are leveraged internally—typically as employee portals, intranets, and internal applications—and play an important role in enabling your employees to provide a high quality customer experience (CX).

Corporate software usually consists of layers on top of layers of legacy systems, each with its own look and feel, none of which are designed to support how people really work. To improve the often dismal experience of using corporate software, I recommend observing customer-facing employees firsthand using contextual inquiry, and using the results to supplement and reality-check your business requirements. In this blog, I will detail the steps needed to improve internal applications using contextual inquiry.

Corporate Software: It Is What It Is

Use of corporate software is mandated: if you work here, you must use our systems. Traditionally, corporate software teams are not incentivized to provide quality user experiences in the way that consumer technology teams are. Why should they? Employees have nowhere else to go even if the experience is rotten. Besides, measuring experience quality is not something corporate IT departments are trained to do.

In the corporate world, incentives and rewards are most often based on delivery metrics such as budgets and release dates. Software quality assurance teams measure software quality, but only in terms of reliability and throughput, not in terms of utility or ease of use. For organizations that lack a strong customer experience team there is rarely a department charged with measuring how well their internal software helps employees serve customers.

Contextual inquiry improves bad UX

The user experience (UX) in employee applications often leaves much to be desired.

Corporate technology teams rarely measure the quality of the experience they deliver because there is little incentive or accountability to do so. Without measurement, there are no experience baselines so it is difficult to determine if the latest release of the corporate desktop has improved the quality of the experience. Assuming anyone bothers to look, that is.

Until the recent attention on customer experience, if corporate software works at all, then it’s been good enough. As enterprises automated paper-based processes, there was usually enough of an improvement in throughput or cost savings to justify rolling out whatever the IT department cobbled together. But times have changed. The improved quality of consumer technology experience has reset everyone’s expectations about what technology can do, and how easy it ought to be to use.

The younger you are, the higher your expectations. College graduates entering the workforce have never known a world without GUIs, broadband networks, and mobile devices. If your corporate software is convoluted and difficult to use, not only will your customers receive sub-standard service, but it will become increasingly difficult to attract and retain the best new employees.

It’s Not Enough to Align the Business with Technology

Instead of focusing on experience, I have found that most corporate software design processes focus on aligning the business and technology teams, or at least getting them to play nicely together. Certainly there are always significant challenges, misalignments, and differences in expectations between these two groups. But the optimal experience design, the one that will make the corporation the most successful, cannot be achieved or even discovered unless the employees or the customers are included in the process.

As a User Experience (UX) Architect, I am always in the middle of the business and technology fray. It’s common for my client’s employees and customers to question CX and UX consultants about how we can analyze issues related to their particular vertical.  The value that I add is to bring users, whether they are employees, customers, or both, into the design process so that their requirements are not ignored, and so that the design is grounded in reality, not in the sterile world of home-office process models. To surface employee and customer requirements, I recommend observing customer-facing employees firsthand using contextual inquiry.

How to Use Contextual Inquiry to Reveal Employee and Customer Requirements

Contextual inquiry is a user research method whereby subjects are interviewed while they do their jobs. Unlike a traditional interview that follows a sequence of scripted questions, a contextual interview does not have a script. Instead, the interviewer controls the interview by directing the user to work the types of tasks that are interesting for the current project scope. The role of the interviewer is getting the employee to do actual work instead of merely describing what he does.

contextual inquiry process

In contextual inquiry, the interviewer observes the subject working in real-time, rather than just Q-and-A sessions.

1. Ask the Right Questions

A skilled contextual interviewer asks questions to confirm his understanding of what has been observed and probes to uncover the attitudes, motivations, and concerns employees have about their work. Unlike focus groups or conference room interviews, contextual interviews yield rich data about what employees really do. This is often very different from what employees tell you they do, or what employees think that they do, and often what the business expects employees to do.

Contextual inquiry gives businesses a tool to understand the current state of their employee/customer experience and to establish baseline metrics so that they can measure how much the experience improves over time. While contextual research is most often done as part of an already funded or in-flight delivery project, it can be done on it’s own in order to identify and prioritize new projects in response to observed pain points for customer service.

 2. Don’t be afraid to go off the beaten path.

Some of the most interesting project work I have ever done has resulted when contextual inquiry revealed a work practice that was substantially different than what the home office business team or process mastery group mandated or expected. It is not uncommon for a business team to acknowledge that some employees do not follow the expected business process, but often they insist it is because the employees have some devious intent, are gaming the system, or are plain lazy or stupid.

While I am sure there are some bad apples, I find that process deviations are often for sound business reasons and have the company’s or the company’s customer’s best interests at heart. Here are some examples:

Example: Insurance Industry

Corporate Software: Desktop application for generating auto policy quotes.

Business Process Expectation: Employees enter data into the application while speaking with a prospect on the telephone. Employees deliver a quote in one conversation.

Observed Reality: Some employees write all the customer information down on paper, enter the data into the application after hanging up the phone, and then call the prospect back with a quote.

Employee Rationale: Some employees found the quoting software too slow, too intrusive, or too rigid to allow the conversation to go as the employee or customer wished. Some employees thought they could provide better service, and thus, close more sales, when they took the time to work up multiple quotes and give the prospect options.

Example: Distribution Service

Corporate Software: Bar code scanner for placing orders at the warehouse

use contextual inquiry to assess reality

Assuming that employees update scanner software continuously is unrealistic.

Business Process Expectation: Employees vigilantly update the scanner software so that it always contains the only the active products.

Observed Reality: Employees rarely update the scanner software, or update it only if they think someone from home office will visit and see that it is out of date.

Employee Rationale: Software updates are so slow and unreliable that they may not complete by the start of the next business day which leaves the employee unable to place orders. Employees would rather risk having the potential to order an out-of-stock product than not being able to order anything at all.

Contextual inquiry will unearth what employees really do, so you can find the gaps in your employee and customer experiences

In both of these examples, the employee was observed doing something different than what the process specified, but for a compelling and perhaps even sound business reason. In both cases important new requirements were identified that would not have been apparent without direct observation of employee behavior. This type of unexpected finding occurs regularly with contextual inquiry, especially when an organization’s business function does not have a culture of conducting user research with its employees.

When my team did the report out on the bar code scanner interview findings, the lead business analyst in the room blurted out “But she’s doing it wrong!” Well maybe she is doing it wrong, but this particular interview subject happened to be the leading producer in her territory. If someone could not follow the process and still be a top producer, it makes one wonder how sound the process really is. Feeding observed behaviors and rationale into design will make for a more realistic, robust, and ultimately implementable and governable business processes.

Organizations need to recognize that customer-facing employees can help identify requirements that can trump a top-down business process that was created in a conference room. Contextual inquiry is a proven technique for identifying what employees really do, and how and why they do it. By understanding what employees really do and designing experiences to support it, corporations can gain an advantage by equipping their employees with the best possible tools.

Improve your applications with our Experience Design Services.

Corporate software usually consists of layers on top of layers of legacy systems, each with its own look and feel, none of which are designed to support how people really work. To improve the often dismal experience of using corporate software, I recommend observing customer-facing employees firsthand using contextual inquiry, and using the results to supplement and reality-check your business requirements. In this blog, I will detail the steps needed to improve internal applications using contextual inquiry.

For consumers, the open market fosters quality and sets experience standards for apps, websites, and mobile devices. As a consumer, if you aren’t happy with the experience a product or service offers, you can look for a replacement. In the consumer space, the availability of choice and the freedom to switch puts pressure on consumer technology companies to constantly measure, assess, and improve the quality of the experiences they offer.

However, there is no similar experience quality ecosystem for corporate software—the tools companies provide employees to use to serve the company’s bill paying customers. These tools are leveraged internally—typically as employee portals, intranets, and internal applications—and play an important role in enabling your employees to provide a high quality customer experience (CX).

Corporate software usually consists of layers on top of layers of legacy systems, each with its own look and feel, none of which are designed to support how people really work. To improve the often dismal experience of using corporate software, I recommend observing customer-facing employees firsthand using contextual inquiry, and using the results to supplement and reality-check your business requirements. In this blog, I will detail the steps needed to improve internal applications using contextual inquiry.

Corporate Software: It Is What It Is

Use of corporate software is mandated: if you work here, you must use our systems. Traditionally, corporate software teams are not incentivized to provide quality user experiences in the way that consumer technology teams are. Why should they? Employees have nowhere else to go even if the experience is rotten. Besides, measuring experience quality is not something corporate IT departments are trained to do.

In the corporate world, incentives and rewards are most often based on delivery metrics such as budgets and release dates. Software quality assurance teams measure software quality, but only in terms of reliability and throughput, not in terms of utility or ease of use. For organizations that lack a strong customer experience team there is rarely a department charged with measuring how well their internal software helps employees serve customers.

Contextual inquiry improves bad UX

The user experience (UX) in employee applications often leaves much to be desired.

Corporate technology teams rarely measure the quality of the experience they deliver because there is little incentive or accountability to do so. Without measurement, there are no experience baselines so it is difficult to determine if the latest release of the corporate desktop has improved the quality of the experience. Assuming anyone bothers to look, that is.

Until the recent attention on customer experience, if corporate software works at all, then it’s been good enough. As enterprises automated paper-based processes, there was usually enough of an improvement in throughput or cost savings to justify rolling out whatever the IT department cobbled together. But times have changed. The improved quality of consumer technology experience has reset everyone’s expectations about what technology can do, and how easy it ought to be to use.

The younger you are, the higher your expectations. College graduates entering the workforce have never known a world without GUIs, broadband networks, and mobile devices. If your corporate software is convoluted and difficult to use, not only will your customers receive sub-standard service, but it will become increasingly difficult to attract and retain the best new employees.

It’s Not Enough to Align the Business with Technology

Instead of focusing on experience, I have found that most corporate software design processes focus on aligning the business and technology teams, or at least getting them to play nicely together. Certainly there are always significant challenges, misalignments, and differences in expectations between these two groups. But the optimal experience design, the one that will make the corporation the most successful, cannot be achieved or even discovered unless the employees or the customers are included in the process.

As a User Experience (UX) Architect, I am always in the middle of the business and technology fray. It’s common for my client’s employees and customers to question CX and UX consultants about how we can analyze issues related to their particular vertical.  The value that I add is to bring users, whether they are employees, customers, or both, into the design process so that their requirements are not ignored, and so that the design is grounded in reality, not in the sterile world of home-office process models. To surface employee and customer requirements, I recommend observing customer-facing employees firsthand using contextual inquiry.

How to Use Contextual Inquiry to Reveal Employee and Customer Requirements

Contextual inquiry is a user research method whereby subjects are interviewed while they do their jobs. Unlike a traditional interview that follows a sequence of scripted questions, a contextual interview does not have a script. Instead, the interviewer controls the interview by directing the user to work the types of tasks that are interesting for the current project scope. The role of the interviewer is getting the employee to do actual work instead of merely describing what he does.

contextual inquiry process

In contextual inquiry, the interviewer observes the subject working in real-time, rather than just Q-and-A sessions.

1. Ask the Right Questions

A skilled contextual interviewer asks questions to confirm his understanding of what has been observed and probes to uncover the attitudes, motivations, and concerns employees have about their work. Unlike focus groups or conference room interviews, contextual interviews yield rich data about what employees really do. This is often very different from what employees tell you they do, or what employees think that they do, and often what the business expects employees to do.

Contextual inquiry gives businesses a tool to understand the current state of their employee/customer experience and to establish baseline metrics so that they can measure how much the experience improves over time. While contextual research is most often done as part of an already funded or in-flight delivery project, it can be done on it’s own in order to identify and prioritize new projects in response to observed pain points for customer service.

 2. Don’t be afraid to go off the beaten path.

Some of the most interesting project work I have ever done has resulted when contextual inquiry revealed a work practice that was substantially different than what the home office business team or process mastery group mandated or expected. It is not uncommon for a business team to acknowledge that some employees do not follow the expected business process, but often they insist it is because the employees have some devious intent, are gaming the system, or are plain lazy or stupid.

While I am sure there are some bad apples, I find that process deviations are often for sound business reasons and have the company’s or the company’s customer’s best interests at heart. Here are some examples:

Example: Insurance Industry

Corporate Software: Desktop application for generating auto policy quotes.

Business Process Expectation: Employees enter data into the application while speaking with a prospect on the telephone. Employees deliver a quote in one conversation.

Observed Reality: Some employees write all the customer information down on paper, enter the data into the application after hanging up the phone, and then call the prospect back with a quote.

Employee Rationale: Some employees found the quoting software too slow, too intrusive, or too rigid to allow the conversation to go as the employee or customer wished. Some employees thought they could provide better service, and thus, close more sales, when they took the time to work up multiple quotes and give the prospect options.

Example: Distribution Service

Corporate Software: Bar code scanner for placing orders at the warehouse

use contextual inquiry to assess reality

Assuming that employees update scanner software continuously is unrealistic.

Business Process Expectation: Employees vigilantly update the scanner software so that it always contains the only the active products.

Observed Reality: Employees rarely update the scanner software, or update it only if they think someone from home office will visit and see that it is out of date.

Employee Rationale: Software updates are so slow and unreliable that they may not complete by the start of the next business day which leaves the employee unable to place orders. Employees would rather risk having the potential to order an out-of-stock product than not being able to order anything at all.

Contextual inquiry will unearth what employees really do, so you can find the gaps in your employee and customer experiences

In both of these examples, the employee was observed doing something different than what the process specified, but for a compelling and perhaps even sound business reason. In both cases important new requirements were identified that would not have been apparent without direct observation of employee behavior. This type of unexpected finding occurs regularly with contextual inquiry, especially when an organization’s business function does not have a culture of conducting user research with its employees.

When my team did the report out on the bar code scanner interview findings, the lead business analyst in the room blurted out “But she’s doing it wrong!” Well maybe she is doing it wrong, but this particular interview subject happened to be the leading producer in her territory. If someone could not follow the process and still be a top producer, it makes one wonder how sound the process really is. Feeding observed behaviors and rationale into design will make for a more realistic, robust, and ultimately implementable and governable business processes.

Organizations need to recognize that customer-facing employees can help identify requirements that can trump a top-down business process that was created in a conference room. Contextual inquiry is a proven technique for identifying what employees really do, and how and why they do it. By understanding what employees really do and designing experiences to support it, corporations can gain an advantage by equipping their employees with the best possible tools.

Improve your applications with our Experience Design Services.

Interested in partnering with us?

Send a message and we will work with you to understand your needs.

UX360 - Enterprise Journey Mapping Platform

Power Platform

UX360 - Enterprise Journey Mapping Platform
Related Insights
2017-08-10T17:19:52+00:00