Good Client Relationships Start Before the Design Work

A client joins the call. You have your questions ready.

You want to understand the product, the users, the business model, the current problems, the goals, the timeline. So you start asking.

It makes sense because this is what a good discovery call is supposed to do.

But I think there is one thing designers often miss.

Before the client starts explaining the product, they are already deciding what kind of person they are talking to.

Can I trust this person?

Will they actually understand what I am trying to build?

Will it be easy to work with them?

Can I tell them when something is going wrong?

Will they listen if I disagree with their idea?

Those questions rarely get asked out loud. The client answers them by watching how the conversation starts.

That is why good client relationships often begin before the design work does.

Your first job is not to get information

When a client comes to a designer, they usually bring a huge amount of context with them.

Maybe they have been working on the product for six months. Maybe for five years. They know the users, the business, the internal politics, the previous design decisions, the things that went wrong, the things they tried before, and the things they are worried about. And now they have to explain all of that to a stranger.

This is an unusual situation.

The client came because they needed help. At the same time, they have to become your main source of information.

If the first ten minutes feel like an interrogation, that relationship can become uncomfortable very quickly.

• “Tell me about your users.”
• “What are your main pain points?”
• “What research have you done?”
• “What are your business goals?”
• “What are the technical constraints?”

All of these are reasonable questions. The problem is the sequence.

If I immediately start extracting information from someone, I can accidentally make them feel like an information source rather than a person I am going to work with.

And that changes the conversation.

The client becomes careful. Answers get shorter. Some details stay unsaid. The conversation becomes very professional, very polite, and strangely unhelpful.

For me, good client communication starts with making the other person feel comfortable enough to actually talk.

Small talk is part of the work

I don't see small talk as something you do while waiting for the “real” conversation to begin. It is part of it.

Ask how someone prefers their name to be pronounced, where they are joining from, mention something about your own day. Talk about the weather, traffic, a weekend plan, a football match, or something completely ordinary.

It can take two minutes but those two minutes can change the rest of the call.

Why? Because the client starts seeing a person instead of a role.

They don't just see a Product Designer who is about to run through a UX design process. They see someone who drinks coffee, gets stuck in traffic, follows football, gets excited about a new iPhone, or has some completely random thought about their weekend.

That may sound like a small thing. To me, it isn’t.
People build trust through human interaction. And trust changes how freely people communicate.

If I share something small about myself, I make it easier for the client to do the same.

The conversation becomes less formal. And once that happens, people often tell you much more.

The best product details are not always answers to product questions

This is probably the biggest reason I prefer a more relaxed start.

The most valuable information is not always hiding inside the questions you prepared.

A client might casually mention that the company is going through a difficult period. Or that the product is especially important to them personally. The deadline could be much more serious than they initially said. Someone inside the company might strongly disagree with the current direction. Or the feature everyone calls “a small improvement” could actually be connected to a much bigger business problem.

You rarely get these details from: “Can you tell me about your product?” People share them when they feel comfortable.

This matters for product design because context is everything.

A designer who only looks at the interface sees screens, flows, components and interactions. A designer who understands the wider situation sees why those things exist.

That difference becomes especially important in SaaS product design, where a single interface can sit inside a much larger business process.

A dashboard can be tied to sales targets. A workflow may exist because of a compliance requirement. A confusing approval step could be the result of internal politics rather than bad UX. And a “simple” table may be used by three different teams with completely different goals.

You cannot see all of that from Figma. You learn it through conversation.

Formality can create distance

There is nothing wrong with being professional. But being professional does not have to mean sounding formal. In fact, excessive formality can work against you.

If I speak to a client only in terms of tasks, requirements and deliverables, they will probably do the same. We create a very clear professional boundary. And once that boundary is there, some useful context may never cross it.
The client might think:

• “I probably shouldn't mention this.”
• “That's not really related to the design.”
• “I don't want to distract them.”
• “I'll bring this up later.”

But “later” is often too late. The designer has already formed an understanding of the problem. The team has already started thinking about solutions. Maybe even the first concepts are already in Figma.

Then a new piece of context appears and changes everything.

The way you communicate with a client from the first call affects everything that comes later, from design reviews to feedback. If the conversation feels open from the start, clients are more likely to share what they really think.

Discovery is not just a questionnaire

There is a tendency to treat design discovery as a collection of questions. I understand why.

A structured discovery process helps us avoid missing important information. It gives the team a framework. It makes conversations easier to organize. But a framework should replace the conversation. It should support it and let it flow naturally.

A good discovery call is a conversation where both sides start getting to know each other. You learn about the product, while the client gets a feel for how you work.

That changes how I approach client discovery.

I still want to learn more about the users, to know the business goals, to understand constraints, existing workflows, technical limitations and previous research. But I also want to understand the person sitting across from me:

• What are they worried about?
• What do they care about most?
• What part of the product are they particularly attached to?
• What has already frustrated them?
• What do they expect from this collaboration?

Some of these questions may never appear in the formal discovery script.

They can still shape the entire project.

Client trust affects the quality of the work

There is a practical side to all of this.

Trust affects the quality of information you receive rather than just making meetings nicer. And the quality of information affects design decisions.

Imagine a client who feels completely comfortable disagreeing with you.

They might say:

• “I don't think this direction works.”
• “This feature is politically sensitive inside the company.”
• “Our CEO really wants this, even though users don't.”
• “We tried this six months ago and it failed.”
• “The deadline is actually much tighter than we told you.”

Those statements are super valuable.

A client who doesn't trust the relationship may simply say: “Looks good.” And that can be much more dangerous.

You can have a beautifully documented UX strategy, a perfect workshop structure and an impressive design process.

But if the client doesn't feel comfortable telling you what is really happening, your process is working with incomplete information.

This changes the role of a designer

I don't think a designer's job is to arrive as the person with all the right questions. Especially when working directly with clients.

The designer needs to be able to create the conditions where useful information can appear.

That requires communication skills for designers, but also something more basic: genuine curiosity about people.

When I work with a client, I want to understand their product. But I also want to understand the person who is responsible for that product. Because those things are connected.

A founder might describe a feature in one way because they are thinking about investors. The Product Manager may be focused on customer requests. A designer could spot a usability problem, while someone from sales sees a missing feature that is holding back deals.

Each person brings a different piece of the picture.

Good stakeholder communication helps you bring those pieces together. But people need to feel comfortable enough to share what they know, including the things that may seem unrelated at first.

Look at the client broadly, and you will look at the product differently

This is probably the main lesson I have learned from working with clients.

You cannot separate the product from the environment around it.

1. If the company is changing quickly, that affects the product.
2. If the team is under pressure, that affects decisions.
3. If a founder is personally attached to a feature, that matters.
4. If users are asking for something different from what the business wants to build, that matters too.

The designer does not have to agree with every stakeholder, become the client's friend or avoid difficult conversations. The job is to understand the situation well enough to have useful conversations.

Sometimes that means challenging an assumption, asking a question nobody expected or saying that the requested UI change will not solve the actual problem. And sometimes it simply means listening.

Good UX consulting means looking beyond the design itself. You are helping the client understand what is actually happening inside their product.

Client collaboration starts before the first screen

We usually think about the designer client relationship in terms of feedback, revisions, approvals, and handoff. But by the time you get to those things, the client has already made up their mind about what it feels like to work with you.

And that starts with the first call.

They are listening to how you talk, how you ask questions, and how interested you seem in their situation. They are also deciding how much they can share with you.

So there’s no need to rush straight into the question list about the product. Spend a couple of minutes on something that has nothing to do with it.

Let the conversation breathe. Then start asking questions.

You may get better answers. More importantly, you may get the answers that were never going to appear on your questionnaire. And those are often the ones that completely change how you look at the product.

I like that this is how we work at UITOP too. Before thinking about screens, we want to understand what’s happening around the product and what the people behind it are trying to achieve. It makes the whole design process feel more like a conversation and less like a handoff from a client to a designer. And in my experience, that usually leads to much better work.