Designers, developers & clients: a pact for peace

computing-hand.jpg

In my varied work life, I spend time in each of these roles when it comes to websites. Sometimes I'm designing & building websites for small businesses, other times I'm working client-side on a large-scale project team that employs designers and developers, whether in-house or through agencies. Having experienced pain, frustration and the nagging question "Why oh WHY would you do that?" countless times in all of these roles, today I'm writing this post to people on both sides of the wireframes, to basically say "Why can't we all just get along?". I believe that if we could recognise 3 simple rules, our projects would run smoother and our relationships would be stronger.

1. There's no such thing as perfect data, so let's all stop pretending it exists.

Developers & designers: your clients are lying to you, and they don't even know it. They may tell you "yes, there will always be data in that field" and "it will always be in this format" or "our page titles will never be longer than 80 characters" but they're wrong. Maybe not today, but someday, somehow, there's going to be ugly data in there and if you haven't catered for it, then you're not doing your job properly. And clients: you don't get off the hook here, either. When your developer asks you to give her a set of test data, it's your responsibility to dig up the nastiest, shortest, longest, and most complex bunch of data you can find. The unruly-er the better. It has some empty fields and some ridiculously long ones? Weird characters like ampersands and accents? Even better. Because if you just pull a sample of the latest or handiest data, then you're not in any position to complain when things don't work as you'd expect them to.

Designers: do everyone a favour and kill the lorem ipsum. Designing content first is the only real way to see just how fugly that page layout is going to be when the client's text doesn't flow perfectly across three lines. Besides, with 26 different sizes of mobiles and 57 flavours of tablets, there's no such thing as "three lines long" anymore anyway. Clients: this means you need to get your content ready pronto. Because there's no excuse if you ask your designer to "just pop some placeholder text in for now" and then your real content doesn't fit nicely.

2. There's no such thing as the perfect brief, but we should still keep aiming for it.

Here are a few real statements I've heard uttered in different projects over the years:

"I don't really know how to explain what I want, but I'll know it's right when I see it."

"You really should have told me that earlier."

"Can you make it seem bigger without actually making it bigger?"

"It just needs more 'wow' factor."

"I know I never mentioned this part, but it's actually pretty critical to the project."

"Hmm, it just seems wrong somehow. You know what I mean?"

"No, it definitely doesn't do that. Was it supposed to?"

FAIL.

A brief is not a handful of bullet points. It's not a diagram and a meeting. And it's certainly not just a list of other websites you like (and if asked to provide examples of web sites for a project, don't you dare say BBC or Google!). Bad briefs lead to bad projects, full stop.

Clients: BE SPECIFIC. You gotta learn how to articulate exactly what you want, and why - or else you're never gonna get it. Not sure what you want? Start with something similar to what you need and break it down. Is it the content (text & images), the tone (language & style), the functionality, the visual aesthetics or the site structure that works? What specifically would you do differently? Why is that important to your customers/site visitors? You've got to put in some legwork before you even pick up the phone to your designer/developer. And when reviewing work, you better not use the word "wrong" or "kinda" without being able to back it up with solid reasons why.

Designers and developers: HELP THEM. Your client has hired you because you're the expert - and the she's usually outside her wheelhouse when it comes to websites. She can't explain what she wants? Ask questions. Give examples. Make analogies. Point out the difference between content, structure, and aesthetics. Develop a shared vocabulary. Teach her to recognize what resonates with her, and the reasons for it, and next time I'll bet she gives you better instruction.

If you give a hazy or incomplete brief, then you can't complain when you get something other than what you expected. And if you accept a hazy or incomplete brief, then you can't complain when the client asks you to do something over. We're in this boat together.

If your project involves user stories and acceptance criteria, then it's everyone's job to make damn sure they know exactly what every single word means, and that every single variant or edge case has been catered for. Developers: don't you dare write all the stories or acceptance criteria in isolation. And clients: it's your job to sense-check every criterion and make sure nothing has been missed. Developers aren't mind-readers: only you know about the weird edge case that's going to break everything. And any developer that's worth her salt will help you uncover it. No matter how crazy the deadline, we must all agree to be thorough and spend enough time getting the scope/brief right. And then stick to it.

3. There's no such thing as a perfect design, so let's all accept it and move on.

Designers: I'm looking at you. Yes, I know you have just produced the perfect design, but guess what? As soon as you hand it over to the client, it's not yours anymore. It's theirs, and no number of Design Guidelines or Style Rules will stop them making a mess of it. Your beautiful perfect baby is probably going to end up with 3 different sized H2 fonts, misaligned images, the wrong colours, and content blocks used in the wrong places, just as soon as the content editors get their sticky mitts on it. You need to learn to let it go.

Clients: You need to learn when 90% is good enough, because if you spend 30% of your project time trying to get that last 10% right, your project budget is going to fail. Building a website isn't the same as creating a business card; there's no such thing as "done". Websites are supposed to change over time, so accept that you can always tweak things later if it's really that big a deal. Chances are, it's not.

While we're at it, you've also got to accept that there's pretty much no way to guarantee your website will look exactly the same to you as it does to your customers. Trying to get something to look pixel perfect on your - or your boss's - particular laptop is a colossal waste of time. There's no longer any such thing as common standard browsers or resolution. In today's world, even the most popular screen resolution only makes up 20% of the total number of different ones used. The best we can do is design responsively, test on a wide range of devices, and accept when good enough really is good enough.

Well, there you have it. This isn't meant as a rant or complaint - after all, I am talking to myself here, too. It's just some observations that I think would make us all happier human beings. Group hug, anyone?