UX&UI / 2019

Exploring Customer Requirements for Slice-based Network Services Fulfilment Process

Responsibilities: Customer Research, Exploratory Interview, Observation & Reporting Writing

The Challenge

To enable Communication Service Providers (CSPs) to modify or cancel service orders in progress when service requirements change, Nokia developed the software called OrderHub. We kept receiving functionality requests for OrderHub from the customers. They made urgent change requests and escalated feature requests to Nokia. These resulted in a flood of new “requirements” to the R&D. However, we’ve found out those demands were essential ‘failure demands’ that were caused by a failure to do something or to do something right for the customer in the current process. They didn’t solve the customers’ problems. We lacked a holistic understanding of the ‘value demands’ that OrderHub should exist to provide.

My role

As a lead UX designer, I conducted field research at the customer’s site including exploratory interviews and observation, Afterward, I wrote a research report, which was used as a product development guide.

If I had asked people what they wanted, they would have said faster horses.

- Henry Ford

#Think

When the customer requirements are not defined rightly…

Why We Start Customer Research

We have seen a big problem in product development that R&D was in a passive place where they received endless feature requests from the customers, and too much effort was wasted when requirements changed. The root cause was that the customer’s problem was not figured out in the very beginning so the R&D couldn’t decide precisely what to build for the software system. Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements.

Contextual Interviews

To create a better and validated understanding of the customer needs to support the OrderHub design work, I conducted field research at the customer, Telenor, in Oslo. Together with another designer, I led the interview with 5 back-office engineers to gain a better understanding of users and explore their work and requirements for OrderHub.

#Key Findings

When asked about the specific user requirements, they responded by complaining about the problems in the current process and systems and suggested features as “requirements”. For example, one participant reported that when improving services, he needed to export the service specification to Excel, design the service configurations there, and then import them back to Catalog. The whole process was very slow. Therefore, he suggested faster imports and exports. I kept asking why to explore the given “need”. I found out there were many errors after importing service configurations from Excel to Catalog. What users really want is to minimize time and errors to reach the desired end result (i.e. refined service configurations), which means they need a Catalog with which users can design and edit service configurations easily rather than a faster import and export. But they couldn’t step back far enough to recognize what the solution must do and why.

#Insights

The customer’s problem (or need) is not what they complain about! What customers complain about and call a “problem” is indeed a problem – but it’s a problem in the current solution. Not the “problem” that the solution is supposed to solve. Customers ask for features to solve their particular and most pressing problems. Feature ideas are dependent on a customer’s current processes, which are often suboptimal, siloed, and typically incomplete to solve the whole problem. Processes must be designed together with the product.

Observation

To further understand how users perform tasks starting from the first trigger to completion within current processes and systems, I invited 2 back-office engineers who have participated in the previous interviews in a session where I observed they performed given tasks at their own desks. The whole session was recorded through video, photographs, and notes.

#Key Findings

I saw the participant using a system, IB (Inventory Browser) except OrderHub. It turned out that the team used it all the time. Software developed by the end-users as a side job, which was strong evidence that it was very valuable for them. But IT did not even know about this most important tool! Based on information from IT: our technical specialists have put together a document that lists 54 different current systems. But not the most important system that the users actually use! IT and technical people focus on back-end systems and architecture, not the users. IT doesn’t like unsupported systems that depend on one critical employee, so users hide these systems and don’t tell IT how they actually do their work.

Feature Space

Persona Refinement

Based on the research findings from the interviews and observations, I updated the OrderHub personas to precisely define the right target users and goals for the OrderHub redesign.

Trigger Analysis

One of the major outcomes representing customer requirements was the validated trigger analysis where task triggers, motivations, circumstances, desired results, and criteria for the desired results were systematically defined, which gave the R&D team a precise vision for iterating OrderHub.

#Make

Report

After the field research, I documented and wrote a research report to support the redesign of OrderHub. From this, we’d agree on the direction of the iteration and the timeline.

#Reflection

When talking to the customers, it is easy to confuse what users “want” with what users “need”. On their own, users do not usually elicit what they “need”. When asking the specific user requirements, they respond by complaining about the problems in the current process and systems and suggested features as “requirements”. They couldn’t step back far enough to recognize what the solution must do and why.

Customer’s problem (or need) is not what they complain about! What customers complain about and call a “problem” is indeed a problem – but it’s a problem in the current solution. Not the “problem” that the solution is supposed to solve. Customers ask for features to solve their particular and most pressing problems. Feature ideas are dependent on a customer’s current processes, which are often suboptimal, siloed, and typically incomplete to solve the whole problem. In Systems Theory, this is Failure Demand caused by a failure to do something, or do something right, for the customer. They aren’t Value Demand that is what the service/product exists to provide. Building products only based on customer requests doesn’t create a competitive advantage.

Competitive advantage comes from unique solutions that provide value to the user and customer’s business. It requires learning about context, needs, and expected outcomes to identify unique opportunities and unmet needs. Processes must be designed together with the product. We need all the information about the underlying customer’s problem:

starting circumstances;
their criteria for the end result; and
the current process as a whole and the current end result.

My advice to research customer requirements is to ask questions (Why) until you get to know what the solution must do and why is that. Designers need to go out of the office to see what the customers and users do now, and then interview them on why they do it: what are they trying to accomplish (criteria for an optimal end result); and where does the process originally start from the first trigger to completion.