Losing a Client, and Learning

A UX lesson on losing valued clients.

A welcoming image glowed upon the white projector screen at the far end of the dimly lit boardroom. Our team sat at the glossy elongated table, talking about random subjects in hushed voices, anxiously awaiting the moment we would present the first designs to the client. Suddenly, the client entered the room, and he was not interested in wasting time.

“Because of a breach in trust, we won’t be needing your services any longer. They are shutting this project down, so this meeting is now pointless.”

Full disclosure: This story is an amalgamation of two events that were strikingly similar in small ways. I utilized some creative liberty to glue the two into a single story, but the situations were similar enough that people present for either might not notice which of the details differ from the events they experienced.

A situation like this can be devastating to the moral of a design team, and can raise doubts about the team from all directions, even internally. Losing clients isn’t necessarily rare, and you might be in a place where it happens often, but eventually you might lose a client that is highly valued to the company and hopefully you won’t be blindsided when that happens.

REASONS FOR BREAKUP

..the offending team member decided not to go to the project manager first because they didn’t feel that he or she would listen.

There are many reasons that you might lose a client. Identifying and owning-up to the part you and your team played in the breakup is integral to the recovery process.

In the case of the events that inspired the intro story, the “breach in trust” was a breach of the Non-Disclosure Agreement. Both of the separate offending team members shared information with outside parties and potential competitors to the client, which they did out of frustration. In both cases, the offending team member decided not to go to the project manager first because they didn’t feel that he or she would listen.

MAKE-OR-BREAK

I’ll leave the details of what happened to the offending developer up to your imagination…

Both incidents were make-or-break moments but in one it pretty much spelled the doom of the project, in the other we were able to salvage our relationship with the client and make something from the ashes of the dead project.

In the case of the project that was done for, we pretty much just sat back and accepted that there was no way to salvage the product. I only saw the client one more time and the project manager had a closed exit meeting with him and it was over. Whether or not we could have done something to finish the product the client wanted will never be known. It nearly broke the team and completely broke our morale.

In the case of the project that we were able to salvage, we reacted very differently. To begin, we had an exit meeting with the client which included the entire team, even the offending developer. We helped to plan an exit strategy for handing over all assets and finishing things that might be too difficult for on-boarding the client. We showed our willingness to fix our mistakes and to continue working with the client during the breakup — I’ll leave the details of what happened to the offending developer up to your imagination (it’s probably more interesting that way). In a later meeting the project manager proposed some changes and improvements and, what seemed like a miracle at the time, the client had actually hired us to develop an alternate version of what we had started. In our postmortem meeting the client shared his contentment with the final product but also his regret that we weren’t able to complete the original work.

CONCLUSION

The best thing we got out of this experience when all was said and done, is that our team was then fortified by more than just similar types of issues. The team as a whole was more cognitive of the need for discovering the clients, the stakeholders, and the entire team’s needs and desires for every project.

I’m not saying that it is the UX peoples jobs to keep the team in line but we are a part of a team (if not several teams) and we do share the responsibility of the culture that exists within our teams. I would argue that being conscious of the end user’s needs and desires will only improve if we apply the same to every aspect of our lives and the people around us.