Collaboration makes design better. In fact, I’d argue that without collaboration, great design isn’t possible, particularly in our world of the wide web.
It’s impossible to be an expert at everything. Even within the discipline of design you never have one designer that’s a really fantastic typographer, information designer, illustrator, visual designer, UX specialist, UI designer, CSS expert, animator, data visualiser and production designer. So why would we expect anyone to be a world class designer, and developer, and writer, and content strategist, and photographer and – okay, you get it.
The problems designers and developers face today are big. They have us all hitting up against the wall of our limitations. There just aren’t enough hours in the day for any one person to master all of the skills and technologies necessary to do what we need to do. But have no fear: there is an easy solution. People are meant to work together. It’s how our Neolithic ancestors survived saber-toothed tigers, and it’s how we’ll survive our crazy internet jobs, too.
Before we can effectively work with others, we have to understand ourselves. How can you have an effective collaborative process if you can’t explain it to other people?
As a design student, I somehow concluded that design was driven by a magical, ineffable thing called The Creative Process. As far as I knew, you were handed a list of project requirements, disappeared for a few weeks and banged your head against a computer monitor until something (fingers crossed) good popped out. Once I entered the professional design world, this 'process' gave me a lot of anxiety. And then it occurred to me: design is just a series of choices. It may be hundreds or thousands of choices. But that’s all it is.
The question is: how do you make good choices? What’s the right typeface? What colour should my headings be? Should my navigation be horizontal or vertical? To answer all of these questions we need to ask another question: what is the purpose of the project?
Good design has a role, it solves a problem, it makes our lives better. It isn’t driven by aesthetics and personal preferences. You like it? I don’t like it? Who cares. Liking has nothing to do with it. Good design isn’t like-driven – it’s purpose-driven. And purpose in design comes from two primary concerns: branding and functionality.
Branding isn’t just about logos, letterhead and marketing reports. A good branding profile defines the core concerns for an organisation and lays the groundwork for all projects to come. Branding cares about three things: audience, message and tone. Who are we talking to, what are we trying to say, and how can we say it to best communicate and connect with our audience? Answer these three questions well and you’re on your way to creating successful designs.
The second component necessary to determine purpose is more project-specific, and for us at Bearded, it takes the form of a project specification document. The spec doc starts as very general and gradually gets more specific. Before we start thinking about approach and implementation, we need a good solid project definition. In other words, what’s the point of the project? If we’re making a website, why are we making a website? How will the world be different once it’s finished? Ultimately this should read like a victory list for the project. It doesn’t say how we’re going to do it, but it lets us know what we’re going to accomplish. And as we write the rest of the spec, and later work through the project itself, we can always refer back to this section to see if what we’re doing is supporting our central goals. If not, it’s probably time to rethink what we’re doing. (Also see Writing Better Project Specifications).
Once the project’s high-level purpose is defined, we can start defining features that will help us achieve those goals. Let’s take the latest Bearded site re-design, for example. One of the big goals of the website is to convince potential new clients of our capabilities so they’ll hire us to do work for them. This ends up breaking down into a number of practical features:
- A Services section that describes our capabilities and approach.
- A Portfolio of work that provides examples of previous projects and their outcomes.
- A Contact form so they can tell us how much they want to hire us.
Each of these more practical features can be more fully described. For example, the Portfolio is made up of Projects. Projects are made up of a title, client, service types, images with captions and a live site link. We also should describe the desired behavior of these objects. When viewing the Portfolio, a user can filter the Portfolio’s Projects by service type (web, applications, branding, print). Individual Projects can be featured on the home page, and so on.
Once features have been defined, the spec can move on to technical implementation. This is particularly useful when multiple people are working on the technical phases of the project (which, you may have guessed, I also think is a good idea). This makes sure everyone knows the plan of attack before they get started, and helps avoid a lot of uncomfortable potential toe-stepping.
Defining the project this way before we jump into designing things makes sure we’re actually designing the right project. But how do we figure out what the purpose of the project is, anyway? One of the great conundrums of design is that designers are often ignorant of the profession we’re designing for. Whether it’s a chemical engineering organisation, an organic farming cooperative or a synagogue – I don’t really know the first thing about their organisation or industry. Luckily for us we have at our disposal a very special collaborator to help us with this part of the process: our client.
In the design world, as in many others, clients get a bad rap. Everyone has bad client stories. You’ve told them, I’ve told them – they’re a part of design culture. But here’s the thing: it’s not helpful. Talking about clients this way sets up an adversarial tone, and even if we’re “just kidding around,” repeating these stories eventually makes them part of our personal narrative. It starts to define what it means for someone to be a client. So let’s try on a little empathy, and look at it from another perspective. How must it feel to be the client of a designer?
Just as we don’t understand the field of custom vacuum pump manufacture or the inner politics of plumbers’ unions, clients don’t really understand design. They didn’t go to design school, they’ve never been to a critique – all they know is they need a website, and they need you to build it for them.
So after the long and arduous vetting process they hire you to do just that. They agree to give you a lot of money. (And let’s be straight about this, whether it’s a small business paying $5,000, a mid-sized non-profit paying $40,000, or a giant corporation paying $250,000 – it’s a lot of money to them.) And now you’re going to disappear for a month or two, and come back with a design that may or may not be anything like what they’re expecting.
This can understandably be a nerve-wracking process for a client.
And they need to give you feedback. What should they be looking at? What’s the right thing to say? Maybe the logo should be bigger? Or maybe a different colour red?
Involving the client as a collaborator from the very beginning of the project allows you to properly set their expectations, and help them act in a vitally important role. It gets their knowledge of their audience and expertise in their field into the team’s collective resources, and gives them an understanding of how to contribute.
Making them part of the team also helps set up a better mental model for everyone. Clients are on our team. They want what we want: for the project to be successful. When a client gives feedback like “make the logo bigger” or “change that colour red,” remember that they’re not a military general barking orders; they’re a team member offering suggestions. And suggestions are the beginning of a discussion where everyone can bring their specialised knowledge to bear on the challenge at hand.
Listen to your client’s comments carefully and try to understand the things that are motivating them. Do they really want the logo bigger – or do they just feel that the brand isn’t clear enough? Or maybe that the tone of your design isn’t on target, the way the logo is? Blindly following your client’s feedback without trying to understand what they’re saying first won’t get anyone what they want. The more a client’s comments result in collaborative discussion with successful outcomes, the more they’ll understand that this is how the process works. Their job isn’t to tell you how to design, it’s to make sure you have the knowledge and insight that you need to make good design decisions. Once they get into the rhythm of these interactions, they’ll feel included and important to the process because, in fact, they are.
They’ll also have a deep understanding of what the designs are meant to accomplish. After helping you complete the branding profile and project specification document, your client may not know what the designs are going to look like – but they shouldn’t be surprised when they see them, because they’ll be addressing the goals you set out together.
I’ve often heard the sentiment, “I’m the designer, so at the end of the day shouldn’t a client just let me make the design decisions?” The problem with the “I’m the designer” approach is that it relies on (relatively arbitrary) title-based authority, and arbitrary authority is easily countered. “I’m the designer” is easily canceled-out by “I cut the checks.” And here we are, stuck back in an unproductive adversarial relationship.
Let’s look at a little parable. Say you go to a new doctor for a check-up. She says “I don’t have time to explain why, but I need to cut off your arm and I need to do it now. Trust me, I’m a doctor.” Your next move probably involves sprinting for the door.
Now let’s say you’ve been working with your doctor for a little while. She routinely listens to your concerns and observations, and incorporates them into her recommendations. You feel listened to, respected and important to this doctor. Then one day the doctor says “I know this is hard, but I need to cut off your arm. I need to do it now, and I don’t have time to explain why. Later I’ll tell you everything, but right now you just have to trust me.” Hmm … now you might just let her cut off your arm.
That’s earned authority. Every time you show your client that you’re listening to their concerns, including them in the process, and making better work because of it, you earn more of their trust. And when emergencies do happen, and you really need to, you’ll be able to cash in those credits because your client knows you’re acting in their best interest.
OK, now your clients are happier, your work is better, and you’ve got a warm fuzzy feeling about the people who pay the bills. Now that we know how to work with clients, co-workers are a snap, right? Right?
Being part of a team
If only it were that simple. Working with others is one of the most rewarding activities we can do in life. We’re wired for it. Humans are social animals – heck, it’s how we’ve survived this long. You think one person can fend off a giant sloth? Think again, my friend.
When we feel connected to others, we feel better about our lives and ourselves. Even our life expectancy goes up when we have rewarding social relationships. Collaboration is actually so essential to who we are as a species, that our biology responds positively to it. That’s convenient, because it just so happens that collaboration is an extremely successful strategy.
If the mix of personalities is right, groups often “hit it off,” and work really well from the beginning. They enjoy each others’ company, and compromise easily. Everyone is more accommodating at the beginning of a relationship. Over time however, egos inevitably emerge, convictions push past generosity, and emotions bubble to the top. Maintaining good working relationships over time can be hard. Particularly when you have a creative industry like ours.
Not long ago I was on a panel for a local AIGA discussion, and a young student asked the popular question “what do you look for in a new hire?”
One of my fellow-panelists gave a very reasonable answer: “passion.” He went on to say that “I can teach someone to design, but I can’t make them care about their work.” This is true, and I believe that passion is essential. After all if you’re in the design business for the money, you have made a poorly-researched decision.
But how fast do you generally arrive at consensus when you put five fiercely passionate, skilled, intelligent people in a room and ask them how to proceed on a project? Spoiler alert: not very quickly. Passionate also means opinionated, tenacious, and emotional. And it’s all too easy to get worked up about something and hurt the feelings of your would-be collaborators in a fit of passion. Hurt feelings, left unchecked, quickly turn into resentment, and pretty soon you don’t have a team. You can’t get work done, no one’s having fun and everything falls apart.
So how do we avoid all this passionate in-fighting? A collaborative team has to have a commitment to each other. They have to agree to a shared group of principles that guides their interactions, and ultimately becomes a corporate culture that encourages collaboration.
At Bearded, we identified the following ideals as essential to the health of our team:
- Everyone in the group is as smart and skilled as anyone else, and all our ideas are worth equal consideration.
- When two people really feel strongly about approaches, stop arguing and try both.
- The health of the team and its relationships are the most important things.
The first one’s easy. Everybody else is just as good as you are. This means that when your teammates are disagreeing with you, listen to them. They may be seeing things that you aren’t. It also means you don’t need to micromanage. You can trust your teammates to make good decisions. Even if they don’t do things exactly as you would, they’ll probably do something just as good, or better.
Point number two: every once in a while people feel that they really need to put their foot down. They know they’re right and don’t want to back down. When this happens everyone else will usually defer and follow their lead. But what happens when two people have opposing views and both feel strongly? You can have a stalemate that leads to debate, which turns into argument, which turns into hurt feelings.
These scenarios can also eat up a lot of project hours without actually getting anything done. So we decided to put those hours to better use: if we can’t reach a consensus, just try both approaches. Often something that seems unclear during an abstract discussion becomes obvious when we’re interacting with a prototype or looking at an actual design. This kind of approach leads us away from destructive competition (argument) and toward constructive competition (pushing each other to create better solutions).
That brings us to the third and most important principle: that the health of relationships of the team members are more important than any single project decision, feature, approach, or project. We can screw up a feature or tank a project by making bad decisions. We can even lose clients. But if the individuals in the company lose their ability to compromise and work together, that’s it. It’s over. No more clients, projects, features, or decisions. That’s why it’s essential for everyone to value their relationships with each other above all else. Be generous with each other. Assume that your teammate’s ideas are worth giving careful consideration, that you may not even get the full meaning of their words right away. Who knows, they may (occasionally) be smarter than you.
Just remember: these people make your work better. With their help, you can do more than you ever could on your own. But for that to happen, you need to trust and rely on them. There has to be give as well as take. It may not always be easy to temper passion with trust and generosity, but I can assure you it’s worth it.
Now smile, grab your friends, and let’s go build some internet.