シェアする
Building a Website from Scratch (2): Tips for Client Negotiations - Images: Japanese
Hey there, everyone!
Picking up from last time — let's take a look at client negotiations, the organizational structure on the client's side, and all that good stuff. So this article is going to be more business talk than HTML and CSS.
We're continuing in role-playing mode, so please imagine yourself as:
"I'm a front-end developer and I'm on the job! Let's do this!!"
When you first receive a project request, one of the first things you need to do is "understand the organizational dynamics of everyone involved in the project."
Here's why: problems and missing requirements will inevitably come up as a project moves forward. When that happens, if you don't already know "who's in charge of the design decisions" or "who to check with when something is unclear," things can get messy fast.
A classic scenario is getting confirmation from someone low on the totem pole, doing the work, and then having a senior person tell you "actually, we don't want that." That's wasted time — so it's always best to go straight to whoever's calling the shots from the beginning.
For a simple website project, the client team often consists of just a director (or producer) and a designer. The director handles planning and management, while the designer — as the name suggests — handles the design.
In our role-play, let's say we've confirmed that the director has final say on copy and functional elements like links, while the designer has full authority over all design decisions. That means we only need to negotiate and check in with these two people for the entire project.
There's one more thing to confirm: "What's the skill level of the people involved in this project?" This is a critical factor in any professional relationship, not just in IT.
For example — if the director doesn't have much technical knowledge, they might set an unreasonably tight deadline, quote a suspiciously low budget, or casually ask you to build something as complex as YouTube or Twitter as if it were nothing. And if the designer lacks web knowledge, they might design without thinking about how the browser resizes, forget about mouse hover states, or specify fonts that simply can't be used on websites. These situations aren't super common, but they do happen.
Catching these issues early on saves everyone a lot of time and headaches, so setting up a preliminary meeting before starting work can be incredibly valuable.
If you've worked with the client before or you know their skills are solid, you may not need it. But for a first-time client, having an initial face-to-face (or call) is a safe move to prevent problems down the road.
So in our role-play, let's say we've arranged a meeting before starting the project.
At that meeting, make sure to run through the following items. Taking notes is a good idea when you're not yet used to it.
- What's the background of the company running the site?
- What's the name of the website?
- Who is the target audience?
- What is the purpose of the website?
- Is readability or visual design the priority?
- What is the deadline?
- Are the copy, design, and other materials ready, or do they still need to be prepared?
- What programming language(s) will be used? What are the available options?
- What OS is the server running?
- Is this a desktop site, a mobile site, or both?
- Which operating systems need to be supported?
- Which browsers need to be supported, and how far back do we go with legacy browser support?
- How do we handle retina and other high-resolution displays?
- What character encoding will be used?
- What software will be used to create the design?
- Will links use relative or absolute paths?
- Who handles publishing the website?
By the way — the list above is based on what the author typically checks in these situations, adapted for this context. As you gain experience, you'll develop your own checklist that works for you. The questions you ask will also vary depending on the client's industry, so that's something to develop over time.
As you work through these questions, pay attention to how well the other person answers them. The reason is that directly asking something like "What's your technical background?" or "Can you walk me through your experience?" would be extremely rude to say to a business contact or someone you're meeting for the first time.
(oﾟДﾟ)＝◯)`3゜)∵ ·
...yeah, that would not go over well professionally. So instead, you need to run a quiet little psychological assessment on the side.
"Understanding the other person's skill level" is a genuinely important factor in business, and while asking directly is out of the question, you can't just ignore it either. So here's the move: ask those questions with a friendly smile, and while they're answering, quietly gauge their competence level. Time to be a savvy adult.
If you want some inspiration for this kind of strategy, the author recommends checking out Yu Yu Hakusho (the later arcs), Hunter x Hunter, or Tomodachi Game — they're full of sharp characters running excellent psychological games. Highly instructive.
In the next article, we'll take a closer look at why each of those questions matters. See you there!
This article was written by Sakurama.
Author's beloved small mammal |
桜舞 春人 Sakurama HarutoA Tokyo-based programmer who has been creating various content since the ISDN era, with a bit of concern about his hair. A true long sleeper who generally feels unwell without at least 10 hours of sleep. His dream is to live a life where he can sleep as much as he wants. Loves games, sports, and music. Please share some hair with him. |
If you find any errors or copyright issues, please contact us.
