5 Lessons learned working with a difficult client!

Point 01: Embrace the gray space between the defined scope and tangible interface

One of my clients was not sticking to the requirement, and we have seen a lot of scopes creep in the project. You might be familiar with the below conversation.

Designer/PM: We have not scoped for these flows/extended features. I guess it's scope creep.

Client: "I think we have covered this in our scope; Maybe you didn't understand our requirement well.

In one of my projects, the client requested to explore the feature of organization structure in the design. We have come up with a simple tree structure organization map. The design helps the user to examine the whole tree along with a search option to find out any employee in the organization. But the client was not aligned to it. They were looking for multiple filters & advanced search features which was not called out as part of the requirement. There is nothing wrong in it; As designers, we should be flexible to address these kinds of needs. Unfortunately, the challenge is we have not scoped enough time to address this requirement. And for the client, "explore" word was the point to push this new requirement. Your SOW will support you to some extent, but we can't bring the phrase SOW in every design review. And if we don't have a full-time PM allocated on the project, it becomes more challenging for the designers. So, we need to pick our battles.

In ordered to avoid such situations, we need to map the requirement in a way that it percolates down to page level and feature level details with acceptance criteria. It is also critical for us to make the client understand that a particular feature can design in multiple ways than they think. To make it more effective, you need to mention how many rounds of iterations you will do for each design. What is more important is to communicate the value of good design continually, and the associated time needed to create a high-quality design. This kind of situation becomes challenging in a fixed budget project, so time and money is an excellent way to deliver successful design effectively when you know the client has a different way of working.

Point 02 : How to handle when the client becomes a designer

It's a prevalent scenario that we come across in our design career. There are many books and articles about this topic. One of my favorites is "Articulating design decision -Book by Tom Greever." Some of the techniques mentioned in the book come handy when you are dealing with a difficult client. The book also throws light on how you can effectively sell your design decisions.But let's say you have tried all your arrows in the quire, and you are not successful in convincing the client. 

 In such situations, you can tell your client that "we believe we are truly immersed in the situation, and using our all of our expertise to solve the situation And if you are not giving enough value to our design inputs, then it will have an impact on the overall user experience."  Try to have this conversation separately with the vital stakeholder rather than during a review meeting or an argument. Sometimes it could make some improvements in future design reviews.Let's say the client has not changed a bit even after the above conversation. Make sure you document the design decision along with a disclaimer. You can mention the reasons of why the design has iterated in a certain way than what you have proposed.

As a designer, you need to take a call on how much you should listen to the client when it comes to design inputs from clients. For example, you are like a doctor treating a patient; the patient might ask you to give a tablet, but as a doctor, you might prescribe an injection because you know the right medicine for the disease. 

Point 03 : Invest a couple of weeks to get a sign off on the requirement. It will pay off at the end.

 When you work on a long-term project, it's always better you have a face to face interaction with the client during the initial phase of the project. If you already know what type of client you are dealing with, then its always better to plan the project considering your previous experience with the client.

 If you are working on a diversified giant product, there is a high chance different stakeholders will own different modules. You need to identify the critical stakeholders for each module. And spend at least a day with each of the module owners to understand, what are their expectations around the functionality/experience /features/challenges they foresee in their module, etc.

Once you have done this activity with all the module owners, you need to facilitate an internal meeting with all the stakeholders to get a final sign off on the requirement. At this meeting, stakeholders will understand the interconnections of each module in the product. They might refine their needs.

The tangible outcome of all these meetings will be a detailed requirement document. Maybe an excel sheet with stories/features/ comments/ challenges/acceptance criteria etc. which is signed off by each of the module owners/stakeholders. Even though this will be a high-level document, it will help you to estimate the project well if the client is finicky about the timeline and budget. This document will act as a bible for the rest of your project and help you avoid any scope creep.

 Point 04 : Experiment on your fidelity of the prototype to be efficient and effective

Your last client may be so smart, and even a paper prototype might help them to understand the message clearly. But some clients need to see high fidelity screens. With high fidelity screens, the design iterations become time-consuming. You can take two approaches, 

Approach 1. Try to educate the client about the pros and cons of high-fidelity wires and experiment with them, what level of fidelity they need to see when it comes to reviewing.

Approach 2. Let's assume the client does not agree to the first approach. Then tells them that the number of design iterations will be reduced. And if there is a high-level change after the second iteration, it will be considered as an additional requirement.  Once we establish this condition, then the client also will be mindful of the changes they request during the design review session.

Point 05: Maintaining the morale of the Design team/ how to keep your confidence up

When you are working on a long term project with a tough client, designers tend to lose morale very quickly. By the very nature, designers are high on emotions, and they are very close to the artifacts they produce. So, they get very defensive when someone talks about their work. There are multiple reasons for it. I have mentioned a few of them below.

 1. The client doesn't appreciate your hard work and the quality of the work delivered. It is not because the client didn't like your outputs. Some client keeps all the lovely comments until the end of the project. The problem with designers is that we think the solution alone makes a client happy. But we need to go beyond the solution. We need to hang around the clients, and we need to reduce friction. But this is something which most of us don't do. So, the problem is not just about the solution. We are very closed and too lost in our work. So, even after putting in a lot of hard work, clients may not say anything good. Maybe they also don't know how to express.

2. When the team addresses the concerns about the project internally, it might be internal team conflict/about the client or the process, most of the time, leadership avoids the conversation, and they say this is how some projects are, and we need to move on. Even though their point is valid, the leadership needs to keep the team motivated about the project. Designers need somebody to listen to them and understand their challenges rather than diplomatically dilute the case.

3.When its a long term project, there is a high chance to rotate the team. In such situations, the team needs to give a heads up about the client to the new members. So that they won't feel demotivated on the first review call itself, as a team, we must appreciate each other when people deliver a good job. We need to pat each other's back on the team, give each other constructive feedback. Ask PM to plan some team outing if you have a PM. Schedule an interim project retro. And allow everyone to speak up and listen to their concerns and make possible changes accordingly.

As a designer, every project gives us some learning. Some will be on the domain, and some will be on the soft skills. I am sure at least a few of the readers won't be able to resonate with few points until they come across through a tough client, so till then, wait for it :). Thank you for your time and feel free to add your thoughts on the comments.