I’ve found (and you can too) a lot of articles, books, seminars around getting to know the users. And I couldn’t agree more with them (or most of them). To make a successful product, you have to know the people who will use it and you have to know what they need and, maybe even, (gulp) talk to them.
What I don’t always see a lot of mention of is getting to know the middle-man in between you and the user. You know, the company behind the product? AKA your client? Their organization? To build a successful product, I think it’s just as important to get to know them for a lot of reasons. Like:
Oh, you don’t respond right away (understanding how they work)
We all have our ways of working. There’s the type that keeps rigorous notes to share with the group and document next steps, RIGHT after a meeting. Then there’s the type that isn’t good about following up, AT ALL. Or the type that doesn’t provide a lot of insight into their thinking or opinions, just short responses, with the occasional “I don’t like that”.
Understanding how your client partner works (and communicates) helps you do your job, better. It helps you say the right things in meeting (or ask the right things. It helps you to determine the best channel to interact (Is it easy to make decisions on phone calls or video chats, in-person meetings or quick slack messages?). It helps you to know how much guidance and follow up to give - and when - to ensure you keep the conversation going (and the project).
I’ve worked with colleagues who didn’t understand how their client worked, and became disengaged if they didn’t respond right away, or offended by the brief to-the-point response. Don’t stop short because your client doesn’t work they way you do. Learn how they work, so you can both succeed.
Oh, you’re new here (understanding their motivations)
Sometimes there are a few things that keep making their way into the project, like certain features (that seem out of scope) or new deadlines (that weren’t discussed before). Understanding what is (or even who is) behind the changes and requests could provide greater meaning.
Sometimes a motivation for them to add more features is because they are new, and they just want this project to make them shine in their organization - so the more bells and whistles, seemingly, the better? Or sometimes someone higher up all of a sudden wants to see something now (now not being the scheduled launch date) - so the motivation is a vocal stakeholder. Sometimes a department has a louder voice and therefore all of a sudden what you’re designing has a lot of plugs for their group. Understanding the motivation can help you understand the underlying issue to solve. If it’s a tighter deadline because a stakeholder has taken an interest, maybe it’s time for a brief walk-through of where your team is at with all stakeholders so they can see progress (delaying an actual launch) - admittedly these walk-throughs should already be scheduled, mitigating that problem in first place. If it’s added features, keep everyone’s focus on the goals; stress the importance of staying focused on the design, and remind the team of your agreed scope. Scope creep doesn’t help anyone. If it’s a stronger department’s voice, try to determine what their goals are and how the design can help them meet those goals, without it being arbitrary.
Oh, you’re not the one that makes the decisions (understanding their organization)
You might have had projects where you had a main point of contact making “decisions.” Yet, weeks or maybe even months later, you realized they weren’t really the ones making decisions. And the one that had hadn’t been giving any feedback...after all...that...work.
Some rules of advice:
- Find out who all the stakeholders are in the project.
- Find out how your client’s team and organization is structured (ie. who reports to who, what are their roles, etc.)
- Get to know everyone who will be involved in the project.
- Make sure all stakeholders (especially decision makers) are involved at key points of the project (like the discovery meeting, kick off, decision points etc).
Oh, you are a little shy at first (understanding who they are...as people)
This may be one of the more important things in my job, and gets more to the social connection. A lot of what happens during the cycle of a project is communication: meetings, emails, phone calls. Getting to know the person on the other end not only makes this more enjoyable, it also makes decisions (even the hard ones) a tad easier. And that’s because I understand who they are and, because I’ve gotten to know them, and they me, and...they trust me.
This doesn’t mean I need to invite them over for a dinner party, but it does mean having a casual conversation about their weekend, their fly fishing hobby or their attempt at yoga the other day, or where they like to camp. Every now and then, just shoot the shit. Listen to them, share stories. It breaks the ice, and it confirms that notion that “we’re in this… together.” Just getting to know who they are as people (and I suspect vice versa) you get more comfortable with communicating needs. What’s more, we are able to understand what the other person is trying to say, and we can sense if something is not right. It’s never a bad idea to remember that they are just a human trying to get something done, and together you can create something great.
So yes, get to know the end users (the people using the product) - but don’t forget the middle man. Get to know your client partners too. It makes the work that much more delightful.