I have an opportunity to speak to a large and well mixed group of web designers and developers plus _clients_ of designers and developers. Part of what I want to cover is what affects the client/professional relationship and project(s) in both positive and negative ways. I want to include your (dev/designer) real world perspective on that. So, please share a positive and/or negative client behavior or experience that typifies how hard it is to work with some clients and/or easy it is to work with others. If you have a solution that works well for bad situations, I’d love to add that to my presentation as well. THANKS!

People who don’t listen, and people who think they know better despite knowing practically nothing at all (the Dunning-Kruger effect). This is typical of clients, but can affect devs, too. It’s something to watch out for, and especially to watch out for in yourself.

Contract contract contract. Get everything in writing, and do not deviate from it.

Estimates are hard. Like, seriously hard. Accurately estimating required development effort is at least as difficult as the rest of the field combined. Why? It requires the experience and intimate understanding of every aspect of development, plus industry trends, prediction of issues and outside elements, etc. to pull off. Estimates are only estimates, and will be wrong more often than not. Typically the more experienced the dev, the longer their estimate, and the more padding it has. Besides, “ahead of schedule” sounds better than “late.”

Beware cheap devs. The cheaper they are, the lower the quality, security, and customer service you will receive. Caveat emptor, but you often get what you pay for.

The “in for a penny, in for a pound” fallacy, or: “I’ve already paid this much; if I back out now, it’ll be for nothing!” This is something many people fall for; more common in clients.

Beware frugal clients. Projects are typically expensive, and if the client is expecting profits from it, cheaping out is a sign of limited understanding and business savvy. If you’re planning a long road trip, you don’t skimp and buy a Kia instead of something comfortable and reliable.

Related: prototypes are not release candidates!

Don’t be a magpie. Shiny isn’t always better. Nor is new tech. Don’t fall victim to magpie antics, either.

Security security security. This should always be the primary concern. To help convince stubborn skimps, just say: “legal costs.”

The second most important concern is reliability, with ease of maintaining third, and usability fourth. Why? Rewriting is expensive.

What momma @Root says.

I'd add...

Open communication - no filtering (they won't be able... I don't think this can work... I'd guess that's too expensive), just laying it out like it is and giving a description of what the goal should be.

The two negative things would be:
- over anticipation - when the client is hellbent that something has to work __this__ way because they already discussed this (without anyone else...)
- being unprepared - have at least some goals and define what's important

Minimize the group of involved people. While it's necessary to discuss things, it makes no sense that developers sit in an meeting with design guys _and_ clients to discuss colors.

Last rule: The longer the meeting the less successful it will be.

Noone can keep focus in 8h - make meetings short. If it must be long, make it like this: meeting - break - recap and decision protocol (fixed time) - break - continue

@Root These are all FANTASTIC points. Thank you!

@IntrusionCM Awesome! I agree with (and have experienced) all of this. Thanks!

To add onto / generalize some of what @IntrusionCM said: state the goal, not what you want. There are many paths to achieving a goal, and yours might not be the best approach — or even work.

“Agile” works best. What this really means is good communication, and using prompt feedback to iterate on features. The methodology the dev shop uses is completely irrelevant as long as they deliver on this.

Clients: Keep an open mind. Feel free to “pivot” if your initial plan doesn’t work out. A depressing fact is that the overwhelming majority of startups fail. However, if you are flexible and willing to change and adapt, your chance of success is significantly better! After all, a dev shop doesn’t want to just build another website; they want a lasting customer.

Designers:
Do not design exactly what they customer wants. Guaranteed, they won’t want it. Likewise, do not overwhelm them with 10-20 choices. Make 3-5 different designs and let them choose. (one almost exactly as they asked for, one somewhat similar, the others/rest very different). They will pick one, not like some aspect of it, and after a change or two, are usually content.

Placeholder text: hit or miss. Usually a hit right in the “I can’t read this stupid language, what the hell is this?” Why they can’t get the concept is utterly beyond me.

Clients: Lorem Ipsum placeholder text allows you to see what text would look like on the page without getting distracted by what it actually says. Figure it out! Mini rant complete.

Hosting/domains.
Clients: unless you know what you are doing, allow the dev shop to pick this for you. Godaddy is not a good place. Also, hosting can be expensive, especially if you don’t know what you are buying.

Devs: legal area here. Clients own the site, and therefore must have access to its hosting. Dissuade them from changing anything, or better: hide it via “access to your hosting is available upon request.” Disaster averted.

@Root Yes, very true. Clients often feel like Devs are hustling them to make a quick buck and leave. They don’t realize that we want to keep them as clients for a long time. Because of their fear, the client will not communicate correctly what they want in the website or software, or they’ll try to dictate how it should be done (Dunning Kruger) and so it falls short.

Prompt feedback is a good point @Root ...Everyone should commit themselves in the project.

The word popping in my mind is netiquette - and some people seem to ignore any kind of that at all.

So I want to elaborate abit about that...

1) Time. If someone starts a meeting with the famous phrase: We need to rush....
It's rude. Unexpected things might happen - but please, get the planning right. A 30 min break between meeting one and two should be minimum imho.

2) No finger pointing, name calling or blame game. That's just a no go.
Keep it civilised and friendly.

3) Please ... Please... Please... Do not turn a meeting in a lunch break. It's a meeting.
Drinks / beverages okay - but eating is for many people a red flag. Don't do it.

4) Don't ask to ask - ask.

5) It's polite and usually prevents disaster to ask _before_ (like in 24h before) the meeting if / what needs to be prepared and what material / hardware might be necessary.
Just send it with the agenda 24 hours before.

6) When communication takes place via E-Mail, keep it sane. While text mails might be hard to explain for non tech staff - keep HTML to a minimum. (No Emoji bombs, no fancy background, no esoteric fonts...)

7) Keep information precise. The worst example are emails which are 10+ DIN A4 pages which consist of unstructured text. _NEVER_ do that. And when information spins out of control - anyone should step up and ask for clarification.

8) When you realize any non technical staff is having trouble or doing something wrong (sending PDFs without embedding fonts so PDF looks weird... CM measures for webpages... Anything like that).

Don't be a dick. Yes. It is annoying. But explain it without patronizing or shaming - and in private. Noone likes to be called out in front of a group like in a meeting.

9) Don't expect others to have the same knowledge as you. Explanations might be boring - but prevent a lot of fatal mistakes.

10) Abbreviations / Acronyms are fatal. Do not use them unexplained