Any responsible organization that wants to stay in business listens to its customers. The feedback comes in many formats: online reviews, support requests, emails and phone calls, face-to-face interaction, client satisfaction surveys, usage statistics… We want to know what’s trending and standing out, what are the pain points in the system, when does a user drop out or stop using the system, what are the most common system issues. This systemization is self-evident and likely happening in most organizations. 

This process can be quite pleasant especially when the client feedback, requests and sourced data align with the overall business direction and with the already identified system issues. Project management will give out time estimates for new system launches and the client can be kept informed. In the ideal case, ideal day and ideal week, the lists and tasks are processed, organized, prioritized, and developed into specifications based on multiple agreed factors. We got this.

But we know that this is not the full existence of software development. There will be days of bold fonts, red color indicators for priority, and early morning phone calls: “Urgent / By next week / As soon as possible.” Are we prepared for these moments? Can we anticipate them? And most importantly, how do we move forward when this happens? 

Let’s say that the cause for the uproar is a feature that the client doesn’t understand how to use or cannot agree that it has any value. Something is not working as expected and needs to be changed to consolidate the situation. This is the pivotal moment. As an organization, do we respond as first responders and put out the fire as fast as possible or do we take the time to analyze the situation, and come up with something sustainable?

Many Ways to Put Down the Fire

Your organization’s first step may be to put out the fire. Fix it. To help in the emergency, upper management often steps in with ideas and requests. These requests may come across quite authoritative.

Typical band aid requests that you may commonly hear are: Add “how to” instructions to the interfaces. / Educate the client more. / Code system improvements fast. 

Offered solution 1: “Add “how to” instructions to the interfaces.” This idea assumes that more instructions will somehow lead to a different outcome. True: if the client takes the time to read, the client may be able to complete the task without an error. However, the user experience of the interface remains equally faulty and perhaps even worse due to the added clutter. “The best interfaces are almost invisible to the user.”

Offered solution 2: “Educate the client more”. This idea is based on the notation that somehow educating the client improves the user experience; if the client is trained or instructed more, they will learn to use the interfaces correctly. While training may be very much needed to improve the overall understanding of the purpose and core functionality of the software systems, conducting specific tasks should be easy and user intuitive. “If your particular user is used to doing interactions in a certain way, you should think very hard before breaking with her expectations.”

Offered solution 3: “Code system improvements fast”. For a user experience designer this request leads often to “UX sacrifice”. Something needs to get done fast and the UX process is the first one to be thrown out of the boat. The fix request gets pushed to the programmer fast and you’ve skipped some valuable brainstorming that could have yielded to many different solutions.

Asking for more time for UX may not be so well received by upper management if providing a solution to the customer is time critical.

Gain Understanding – Be Active

I have the following suggestions to offer to foster a sustainable software development process during the storm of dealing with negative feedback:

Dialog and respect. Redirect quick fix ideas. For instance, try to validate the following arguments: The core issues need to be addressed and changed for the entire outcome to turn to positive. / Training all users to use all interfaces is not practical as users come and go. / Let’s acknowledge that the quick fix will lead to design and/or UX sacrifice that need to be addressed later.

 No blame. If the issue is caused by poor design or fast coding, don’t spend time giving out historical reasons why that is the case, but just get busy. Pointing fingers in fire drill situations leads to more frustration and clogs much needed communication.

 Foster solid customer support. A solid customer support management is a rock for the organization. The customer support needs to work with the client to make sure that reactive or negative feedback is addressed fully. Revisit the notion that the development team needs to participate in customer service situations. While team interaction is important, remind the organization about your role and tasks.

Preventive measures are:

Anticipate. Preschedule some development time for future crisis situations. Develop different feedback scenarios with the management and how they will be processed to the development and handled in the organization. If there is a true fire, there needs to be a full planned out emergency response by the software development team in place that the organization can reference to.

Align all teams to share the same message. The development, marketing and sales need to be aligned enough so that the organization doesn’t sell, communicate, or give out an implication of system features or functionalities that don’t exist. Take time to identify the causes. As a development team member, make sure that you have communicated your share.

Humans can be reactive. Clients will express their opinion especially when they face disappointment. A mature organization makes sure that this feedback, or even a crisis, is managed skillfully. An agreed development process for software development needs to be recognized even in a challenging situation. Quality control and UX parameters need to be put back up. Rebuilding must take place. After the fire storm, you still need to be able to see the shared vision. Trust between the teams takes a long way and needs to be maintained.