The following is an excerpt from You’re My Favorite Client, a manual for hiring and working with designers. Written by our Design Director. Available now from A Book Apart.
Before you hire a designer, set up the situation this person needs to be effective. Bringing any employee into an unprepared environment where they don’t have the tools or authority to succeed is unfair to them and a huge waste of your hard-earned money. It also burdens the other employees who aren’t sure what to do with this new person.
A few years ago, I made plans with a friend for breakfast. She was late. When she finally got there, she apologized, saying she’d been cleaning up for the housecleaner.
“Why in the world would you clean up for a housecleaner?!?” I asked.
“So she can actually clean, you idiot.”
This made no sense to me, but I let it go. Otherwise, we would’ve argued about it for hours. About a year later, I got busy enough with work that my house looked like it could star in an episode of Hoarders, so I hired a cleaner. After a few visits, I found myself cleaning up piles and random junk so that she could get to the stuff I actually wanted her to get to.
I called my friend and said, “I get why you had to clean up for the cleaner now.”
“I told you you were an idiot.”
(My friends are great.)
The moral of this story is you can’t drop a designer into your environment and expect them to succeed. You’ve got to clearly lay out your expectations, but you also have to set the stage so your designers come in and get to the stuff you need them to do.
Let’s assume you don’t have a designer on staff. People have been going about their business and getting their work done, and now you’re introducing a designer. Even if your employees have been begging you to hire a designer, this creates a challenge. People are creatures of habit and comfort. As difficult as they claimed their jobs were without a designer, having one still means giving up control of things. This isn’t easy. All the complaining about having to do someone else’s job is about to turn into complaining about giving their work to someone else. People are awesome.
A designer will absolutely change what your company produces, and they’ll also affect how your company operates.
You’ll need to adjust your workflows for this new person, as well as being open to having them adjust your workflow once they arrive.
Before you throw someone into the mix, sit the company down and explain why you’re hiring a designer, how the company benefits, and what the designer’s role and responsibilities are. Explain how adding this skill set to your group makes everyone’s job easier. (Including possibly going home earlier!) Thank them for going without a designer for so long. Talk to them about things that they no longer need to undertake because of the new designer. Tell them to expect some bumps as the designer gets integrated into the fold.
Then back your designer up when those bumps occur.
Your designer can’t do shit without support from the person up top. If their job is to go in and change the way people work, the way the product behaves, and the way people interact with each other (all of which design will do), that’s gonna ruffle a few feathers. When a colleague runs into your office and says, “The designer is changing things!” a well-placed “That’s exactly what I’m paying the designer to do” sets the perfect tone. Remember, designers aren’t out there doing it for their own well-being. They’re your representative.
As tough as introducing a designer may be, it’s infinitely easier than introducing a designer into a workplace where a bad designer has been nesting. We’re talking industrial-sized smudge sticks. I once took a job where coworkers would walk to my desk and ask me to whip up signs for their yard sales. When I informed them that wasn’t my job, they replied that the previous designer always did that stuff. I reminded them that the previous designer got fired for not meeting his deadlines. Eventually, they stopped asking. Had I been more willing to bend to their requests, we would’ve forever established that designers are the people who make yard sale signs for coworkers.
Clear the table of any shenanigans like that before your new designer starts. Delivering this message is much easier coming from you. Don’t pass it off to the new person.
This may sound obvious: a designer is responsible for design, right? By design, I’m talking about not just how something looks, but also how it manifests the solution to the problem it solves. Remember that nice young designer who worked at a big company — the one who wasn’t invited to strategy meetings? By the time work got to him, the decisions were set down to the smallest details and all he did was execute. He wasn’t designing. He was executing on someone else’s design.
In truth, he needed to assert himself. But this chapter is about you. Design is the solution to a problem, something you pay a professional to handle. A designer is, by definition, uniquely qualified to solve those problems; they’re trained to come up with solutions you may not even see. Your designer should champ at the bit to be involved in strategic discussions.
Make sure to use your designer’s skill set completely. Make sure they’re involved in strategy discussions. Make sure they’re involved in solving the problem and not executing a solution that’s handed to them. Most of all, make sure they see this as part of their job. If they don’t, your design will only ever be as good as what people who aren’tdesigners think up.
Just as it’s absolutely clear what authority your office manager, accountant, and engineers carry, make sure your company understands what authority your designer has. Let’s go ahead and extend the definition of authority to “things they own.” In the same way the bookkeeper owns the books and the engineer owns the code. (Yes, I get that technically you own it all. Work with me here.)
Trust your designers. Give them the authority to make decisions they’re singularly qualified to make. Before you bring a designer into the company, decide what authority they have over parts of your workflow or product. Do they have the last call on user-interface decisions? Do they need to get input from other stakeholders? (Always a good idea.) Do they need approval from every stakeholder? (Always a political shit show. Trust me.)
The right answer depends on the type of organization you run and the skill level of the designer. But whatever that call is, empower your designer with the maximum amount of agency to do their job well. No one tells the accountant how to do their job, but I’ve been in a hundred workplaces where people told the designer how to do theirs.
A designer with backbone and experience won’t have any problem carving out the room they need to work, but they can’t do so if you don’t grant them the authority. Otherwise, you run the risk of bringing someone in to follow the whims of those around them. That’s not a full member of the team. That’s a glorified Xerox machine, an asset used by the rest of the company whenever they need some pixels pushed around.
That’s how someone who’s supposed to work on your website’s UI ends up making Lost Cat flyers for Betty in HR.
This should go without saying, except I once spent the first two weeks at a job spinning through a draconian requisition process to get copies of Photoshop and BBEdit, which the company considered nonessential software. Someone from IT gave me a one-hour demo on how I could harness PowerPoint to do anything I needed Photoshop for. (I know I should’ve stopped him, but at some point my annoyance faded in favor of fascination at how much he’d thought this out.)
Like any craftsperson, your designer is only as good as their tools. Make sure they have what they need. Yes, it’s fair to ask them to justify their use. No, you don’t need to understand what everything does. Trust that they do.
How well you prepare your team for a designer, how well your designer gets along with everyone, and how professionally they behave means exactly jack squat if your designer doesn’t succeed in their goals. Before bringing any employee on board, you should know how you’ll measure their success. Will it be hard metrics? Do you expect sales or conversions on the website to increase a certain number? Is the goal to deliver a big upcoming project on time and under budget?
Your business needs vary, so I can’t give you a magical equation for design success. But I can say: whatever your success metric is, make sure your designer both knows about it and has the authority to accomplish it.
I do have a story for you though. I took a contract-to-hire job once, and the creative director sat me down on my first day and told me that he wasn’t sure what to expect of me and how I’d fit in with the rest of the studio. (Someone didn’t get their house in order.) At the end of the contract period, he’d evaluate whether to keep me around. I was young and stupid, so I didn’t press much and decided to blend in as much as possible (rookie mistake). When my contract was up, the creative director called me into his office and said I hadn’t performed the way they’d expected. Which was odd, because neither of us really understood what had been expected. I felt shitty, wondering what I could’ve done better. And honestly, I’m sure the creative director felt shitty too, because he realized he hadn’t properly set expectations for success.
So yeah. Don’t do that. It should never be a surprise to anyone working for you that they’re doing badly. Or doing well for that matter. Let them know what they need to do to succeed. Let them know they’re succeeding. If they’re not succeeding, help them adjust course. And finally, let them know once they’ve succeeded.
The most important thing about readying for a designer is figuring out how your company or organization benefits from their involvement. What will you be able to do once they’re here? Picture yourselves a year in the future. What do you hope to accomplish? Write those things down. They’re the basis for the job description you’re about to write.
Make a list of what you need this person to do. Not the technical skills they should have, but the needs you hope those skills will fulfill. Do you need branding? Interface design? Illustrations? Forms? What kind of business are you in? Is it editorial? Are you a retailer that needs a catalog designed? Don’t forget to take care of your mobile needs. Trust me, you have mobile needs. (Trust me, you’ve had them since yesterday.)
The result of this exercise may look something like this: “We need a designer with mobile experience that can do branding and interface design for complex data.” The longer that list gets, the more you’ll pay for a designer, and this exercise may help you realize that you need more than one person. A capable illustrator who can build a responsive site and understands agile workflow is a rare unicorn indeed.
Most people have never hired a designer in their lives. They will live good, fulfilling, happy lives. They will throw birthday parties for their children, they will mow their lawn, they will upgrade their car at a reasonable pace, and they will grow old and happy surrounded by people they love, knowing they’ve lived a good life.
And then there will be people who have to hire a designer at some point in their lives. Maybe just once. Maybe on a regular basis. This article is for them. Because I want them to be able to do all of the things in that first paragraph. I want them to be happy. I want to give them the tools to choose a designer well. And still get home in time to inflate the bouncy house for Tristan’s birthday party this Saturday.
Selecting a design partner is a pain in the ass. Designers can be difficult. And the process is a mystery. And let’s face it, designers do a crappy job of explaining it. But for those who have to do it, getting it right can mean the difference between their organization doing well and going under. I want to help you do it well.
For the record, I am a designer. I run a design studio. I have a motive in explaining how the process works. The more at ease people are with hiring a designer, the easier it is for a designer to get hired. Namely me.
Chances are if you’re looking to hire a designer you have a goal that you’re trying to accomplish. Which means you need someone who understands goals. Here are some good goals:
These are business goals. And you should hire someone who understands business goals, how to evaluate possible solutions and then measure the results. A good designer will listen to what you are trying to accomplish, reflect it back to you, and then research the landscape, as well as the constraints on the table, and then offer solutions that meet your goals. They’ll do this in a way that reflects your understanding of your own business.
A designer should never make you feel stupid for not understanding their craft. A large part of their craft is figuring out how to communicate with you about your business.
This isn’t an opportunity for anyone to express themselves, or reinvent the wheel, unless reinventing the wheel helps you sell sprockets.
Remember that time you threw out your back and found a doctor on Yelp and they turned out to be a quack? And it set you back a few grand and prolonged your misery? And then your friend Alice recommended a doctor that took good care of her when she threw out her back?
Chances are you know someone, somewhere, who’s hired a designer at some point. Put some feelers out. There’ll be a friend of a friend who had a good experience with someone. (And possibly a bad experience. Keep a list of those, too.) That will at least give you some pre-vetted people to talk to, as well as some background about what these people are like to work with.
That doesn’t mean the same designer will be right for you, but it gives you a place to start. And designers are a tight bunch. If your friend’s designer isn’t right for you, they’ll probably know someone who is.
For the record, most of the work we take on at Mule comes in through referrals. And we love our clients, so when one of them recommends us, we want to take good care of their friends, too.
Once you find yourself some designers to look at, you’re gonna look at some portfolios. Portfolios are useful because you get to see some of their previous work, and who they’ve done it for. They’re also useful for pointing to something and asking, “What were you solving there?”
And that’s where it stops.
The design you are looking for is not in the portfolio. Their portfolio is a record of problems they’ve solved for other people, with those other people’s constraints, and those other people’s budgets. And it reflects those other people’s brands. But hiring a designer is like hiring a tailor. You look at their previous work to see the quality of their work, to inspect the stitching, and you study the posture previous clients, but you’re not here to grab one off the rack. Those are all datapoints to help you decide if you’re going to let them take your measurements.
When you’re interviewing designers, you’re going to get two types of people: Those who can’t stop talking about themselves and their prior achievements, and those who sit and listen to you describe what you need and then reflect it back to you. Hire the latter. Look for people who ask you good questions about your goals and your audience, people who want to know more about your company workflow, people who actually seem interested in helping you, rather than selling themselves.
True, both groups are trying to sell themselves. But the ones who are asking questions about you have already started working. Their natural curiosity is their best selling point. And they value solving the problem more than getting another customer notch in their belt.
This is a financial transaction. You’re paying money to get something of value in exchange. Don’t get weird about it. Let’s go back to the tailor for a second. You can get a suit for $200 and you can get a suit for $2000. And many points in between. But if you tell your tailor you have $500 for the suit, he’ll still make you a quality suit, but he’ll move down to the less expensive fabrics, and maybe forgo the vest. (Also, don’t buy a $200 suit.)
Your budget is one of the most important constraints you have.
Knowing it up front means that a designer can factor it in when suggesting possible solutions. And if you don’t know your budget, it’s because someone is withholding it from you. There’s always a budget.
Depending on the size of your project and the complexity of your organization, you’re going to spend a lot of time with these people. In cramped quarters. And in the darkest reaches of your basement going over content matrices. They will find out things about you that not even your mother knows. There’ll be frustration and pain, interspersed with moments of clarity and joy.
Obviously, you want to hire someone who’s good at what they do. But equally important is working with people who actually make you feel at ease, have your back, and want to have a drink with you at the end of the day.
They’re also more likely to be honest with you, which is important because…
People get testy during projects. And ultimately you want to be working with someone who has your best interests in mind and is looking out for the project goals. Even if it means pissing you off once in a while. Your designer’s goal should be your success, not your happiness. So don’t work with anyone who just automatically bends to all of your whims and wishes.
Think of it this way, you’ve got ideas you want to try. The designer doesn’t think they’re going to work, but they don’t want to argue with you so they do them anyway. Your site launches and fails. So you call the designer into your office and you tell them the project failed at which point he tells you:
“Yeah, I thought it might because some of those things you asked me to do were not so great.”
“So why didn’t you tell me?”
“I didn’t want to argue with you!”
So yeah, get someone who’s willing to argue with you. It might save your company.
For years, people thought of design as something nice to have, but not yet crucial to what they did on the web. They didn’t view design as the underlying system of a product or process that started at the product’s conception. They saw design as a luxury. Like investing in art or Star Wars figures that you never took out of the packaging. Like if you held onto it long enough, design would appreciate.
Designers, in turn, tripped over themselves to write essays on design’s ROI (return on investment). These were dark times.
We were selling design as a cost of doing business. A sunk cost. A necessary evil. I’m here to tell you a better story: design is a profit center. You’ll make more money from your website than the designer ever will.
So when you’re looking for a design partner, don’t think about how much you’re going to spend — think of how much you’re going to make!
The hardest part of design is presenting work. You can’t even argue about this. I’ve seen people who did amazing work get up in front of a client and lay eggs. I’ve also seen people do alright work and work clients around their little finger. Optimally, you want to do good work and present it well. But I’d rather have a good designer who can present well than a great designer who can’t. In fact, I’d argue whether it’s possible to be a good designer if you can’t present your work to a client. Work that can’t be sold is as useless as the designer who can’t sell it.
And, no, this is not an additional skill. Presenting is a core design skill.
The first time I presented design to a client I absolutely choked. I put the work in front of them and stood there like an idiot. It was humiliating. The next time was a little easier. And the time after that, well, you get the idea. I have done every one of the things on this list. I’m sharing them with you in the hopes that they’ll spare you a humiliating experience or two. It’ll take time.
Your client hired you because you are the expert at what you do. They are the expert at the thing they do. And you have been brought in to add your expertise to the client’s expertise to help them accomplish their goal. (If you’re presenting work and unclear on what that goal is we have a bigger problem than this article is going to address.) What they didn’t hire you to do is make them happy, or be their friend. Your decisions should revolve around achieving that goal, not pleasing the client. And while you should do everything in a professional and pleasing manner, never conflate helping the client achieve their goal with making them happy.
They will ask you to do things that run counter, in your expertise, to achieving the goal. Your job is to convince them otherwise. In the end, they will be better served if you see yourself as the expert they believe they hired. And while this may result in some unpleasant conversations during the project, having unpleasant conversations is sometimes part of the job. Doing the wrong thing to avoid an unpleasant conversation doesn’t do either of you any favors in the long run.
This is your room. Your first job is to inspire confidence. Not just confidence in your work, but also confidence in your client that they hired the right person. Every interaction is an opportunity to reaffirm their decision in hiring you. Get off your ass and lead this meeting. You’ll seem more confident if you’re standing up. Your voice will carry better. Be the authority on design your client hired. Work the room. Walk to where you’re needed. Being on your feet will allow you to walk from person to person as they ask questions, simultaneously making you look more confident and allowing for more intimacy.
It should go without saying that you dressed nicely and your hands are out of your pockets. Now run your presentation, sport.
Do not start the presentation with an apology or disclaimer.
No matter how much more you had hoped to present, by the time you get in that room, whatever you have is exactly the right amount of work. Any resetting of expectations should have been handled before the meeting.
Obviously, don’t do anything that you’ll need to apologize for. Like showing up late. Or forgetting an adapter. Or spilling coffee on your new white shirt.
And if you’re really not prepared for the meeting, then better to cancel it than to waste your clients’ time. (You can get away with that exactly once during a project.)
But by the time you are in that room, be ready to present strong and to exude confidence.
You have gathered all of these busy people together. They probably have other things to do. So let them know why they are in this presentation. Let them know they are a necessary and important part of the conversation. People like feeling needed. And they hate having their time wasted.
Start the meeting by thanking them for their time. Let them know what their role will be. Why they’re here. What you’ll be showing them. And what kind of participation you need from them. This is your opportunity to make them feel like the experts they are.
Let them know what stage of the project you’re in. Give a very brief reminder of what the last stage was, how it helped you get to this stage, and how the presentation you’re in now will help move the project forward.
Never explain what they can obviously see right in front of them. They can all see the logo on the top left. They can all see the search box. There is absolutely nothing more boring than a designer walking a client down the page, listing all the things they can already see.
Pull up. You don’t sell a house by talking about sheetrock. You sell it by getting the buyer to picture themselves in the neighborhood.
Sell the benefits of the work. Sell how the work matches to the project’s goals. Sell how their new site is going to crush their competitors and make them all rich beyond their wildest dreams.
And while every decision on that page should have been made with the benefit of data and good research, people are irrational creatures who don’t make decisions based on data and research. They make them based on stories. So find your story and tell it.
You’re too busy giving a presentation to take notes. You’re on stage. Ask someone else to take notes for you. And then post them for the client to review after the meeting so you can agree you heard the same thing.
I’m already asleep.
You need to convince your client that you’re excited about what you’re showing them. Let’s be honest here. This is a show. There’s a little smoke and mirrors. There’s a little Barnum. Not so much that it’s a clown show, but enough that you’re building up some excitement. Work towards a crescendo. There’s little difference between a designer presenting work and a DJ working a crowd. You are selling design.
So have your facts straight. Have your homework done. Have your data at hand. Know why you’ve made the choices you’ve made. Have notes nearby if you need to refer to them, but you shouldn’t be sitting near your notes anyway. (Remember, you’re walking the room.) But work all of these around an exciting narrative. And practice it enough that you know it going in.
Be a scientist when you work, and a snake charmer when you present.
You are not your work and your work is not you. It is not an extension of you and it is not your personal expression. It is work product done to meet a client’s goals. The client is free to criticize that work and tell you whether he believes it has met those goals or not. You are free to disagree with him. And you are expected to be able to make a rational case for those disagreements. But you are not allowed to get all butthurt about it. This is a job.
There’s a difference between defending the work, and getting defensive. The latter is personal, it happens when you’re seeing the criticism as a reflection of yourself. Guess what, sport? Good people do bad work sometimes.
So when the client starts critiquing the work, listen to what they are saying. Don’t feel like you have to defend all of their decisions then and there. You also don’t have to promise them anything then and there. Sometimes it’s best to sit on it for a while. It’s perfectly fine to say something like “That’s interesting feedback. Let me think about it.”
Clients don’t give a shit about typefaces. And if they do, they’ll ask.
The thing I’ve heard most often from clients is “I don’t know anything about design.” (They’re wrong, btw.) This is their way of telling you they’re uncomfortable. They hate feeling uncomfortable, and you do too. It’s on you to get them back into their comfort zone, which is the thing they’re experts in — their business. Which is great, because that’s something you are not an expert in. It’s great to have one in the room. There’s already a design expert in the room — you!
So when presenting the work, talk about it in terms that relate to their business. Talk about how the decisions you made as the design expert match up to the goals of the project. Then your client can judge those as the subject matter they are.
But the color, the type, the design shit — you’ve got that. If you ask them for their opinion on design don’t come crying to me when they give it to you, and you’re all like, “They don’t know anything about design!” They warned you!
The worst feedback you can get from a client is “Wow. It looks like you worked really hard on this!”
Stop using your work like a time card. If you did it right, it looks like it was effortless. It looks like it’s always existed. And the client will probably be irritated that they paid you for 30 hours of work to do something that looks like it took an hour. Which it did. They’re just not seeing the 29 hours of bad design that got you to that one hour of good design. And for the love of god, please don’t show them those 29 hours of bad design. A presentation is a shitty place for a sausage-making demonstration and you’ll just come across as a defensive, unsure person needing validation.
Sell the fuck out of that one hour of good design — most people can’t do ten minutes of it.
“Why is this green?”
“I can change it!”
I don’t really need to go any further into this one, do I? Just answer the question as asked. You should be able to answer that.
There’s only one question worse than “What do you think?” (It’s coming up.)
Ever hear a designer scream about a client giving them the wrong type of feedback? I have. At which point I ask them if they told the client what kind of feedback they were looking for and they just pull the panda hat over their head to hide their anger.
Most clients have absolutely no idea what kind of feedback you’re looking for. And there’s no reason why they would. They do not do this every day. They don’t have the training that you do. Nor do they need it, because guiding them towards the right type of feedback is part of your job. (Anything that helps you do your job is part of your job.) Know what you want before you call the meeting, and then guide the meeting toward that goal.
So during the presentation feel free to slap your hands together and say “This is the kind of feedback I’m looking for today!” Here are some suggestions for guiding questions:
Keep the feedback questions about things that they’re the subject matter expert in. I have absolutely no doubt that they’ll give you feedback on color and type and all the other stuff you didn’t want anyway. Which you should take with a grain of salt. But that other stuff is the feedback you can’t move forward without.
Which brings us to the absolute worst question of all:
Dear sweet lord in heaven above and all his angels, you just gave away the farm. They are no longer viewing you as an expert. You are no longer their equal in expertise. You are no longer the person they feel comfortable enough writing a check to. Even if they don’t realize it, all of these things just happened. You are now reduced down to a small child showing your dad a picture of the cat and hoping he deems it worthy enough to put on the fridge anchored by his magnetic Las Vegas bottle opener.
The client didn’t hire you to make something they liked, and something they like may not be the thing that leads to their success. So do not conflate the two. This point needs to be driven home from the very beginning of the project. And nowhere is this message more undermined than using language that leads them down a subjective path.
Learn the client’s goddamn name.
Yes, it definitely was a blast and now we’re a bit sad that it’s over. It’s the same feeling every year, every conference kind of becomes a dear friend, who explodes.—The Conference
If someone invites you to participate in a design conference held in a former slaughterhouse in Malmö, Sweden, you say yes.
The Conference (yes, that is the maddeningly un-Googleable name) takes a delightfully holistic approach, organizing sessions around human behavior, emerging technology, and methods for moving from ideas to action. And while there were a handful of 45-minute keynotes, most of the sessions were sets of 3 15-minute(ish) talks followed by a Q&A, time allowing. (It’s really difficult not to run over into some of that -ish time). This I found to be a really fantastic format. Conference days can be quite long. And attention drifts. If people are going to bother coming together in person to learn from each other, you want to make the most of that opportunity.
“Light” is the word I would use to describe everything about this event. While the topics varied from playful to quite serious, the brevity of the talks, the venue, and the overall tone contributed to an easy airy feeling uncommon at conferences. There was genuine joy in bringing together an eclectic international group of people, emanating in particular from The Conference Director, Martin Thörnkvist.
And have you seen a conference schedule so clear and pretty? No, you have not.
In addition to the live-stream of all the sessions, photos and videos were live on the website the same day. Who does that?
My talk was part of a session called Paying Attention. My mission was to remind everyone that because we are human, we must be realistic about the limits of data-driven decision-making. Human beings will never reduce to an engineering problem.
If you have 18ish minutes, you can enjoy my talk right now.
I also recommend you enjoy the following:
One of the clearest explanations of Bitcoin I’ve ever heard by Sarah Jeong.
The origin of Media Evolution, the parent organization, and community building by CEO Magnus Thure Nilsson.
Really, those talks are like potato chips and you can watch one after the other.
And finally, you should see this fantastic video about how the remarkably unified and beautifully hand-crafted event design came together.
My work at Mule doesn’t free up too much time to travel for conferences. I’m lucky this year I’ve had the opportunity to participate in some fantastic ones.
Forget what you know about the lonely researcher toiling away in isolation. In design and medicine, good research takes teamwork.
I recently came across a story on NPR about the increased role of medical scribes during doctor-patient visits. They do data entry in real-time, taking detailed notes directly into a patient’s file for the doctor to sign off on later. The approach came about as a response to the government’s mandate for electronic medical records by 2015, and the partnership frees the doctor up to listen to the patient and eliminates the double-work of taking notes by hand and logging them after the fact.
As a design researcher, I can’t imagine doing interviews any other way. At Mule, we always conduct design research interviews in tandem. I lead the conversation, while my partner takes notes, though there’s much more to the role than that. Similar to the medical scribe, my interview partner allows me to focus on what the subject is saying (or not saying) and to let the conversation flow naturally, rather than running through a list of questions, half-typing, half-listening. And without that focus, I am likely to miss out on some really valuable stuff.
What kind of valuable stuff? For example, if an interviewee hesitates, laughs, looks down, cuts themselves off, or starts to editorialize, this points to something deeper, potentially the real gold of an interview. When I’m completely focused on listening—not staring at my screen or scribbling in my notebook—I have the ability to pick up on these hints, and my scribe will, too.
One of the most important benefits of having a scribe is the shared knowledge and what we at Mule do with that knowledge. The scribe—content strategist, designer, developer, project manager—isn’t just taking notes to help me in the moment. They internalize these conversations and contribute to a shared knowledge base that creates a fuller, more nuanced, understanding of the stakeholder and user needs.
I learn a lot from my teammates. Throughout the discovery process—and sometimes during an interview—they’ll have questions for the subject that hadn’t occurred to me, or an angle I hadn’t considered. Right after the interview, we might spend a few minutes sharing things we found interesting, e.g., a turn in the conversation, a surprising revelation, etc. And if there’s a question that isn’t working how we’d hoped, we’ll talk through it and find another way to get what we’re after.
Once we’ve had some time to dig into the interview notes and transcripts, the entire project team meets to share our findings, raise perplexing questions, and start constructing our strategy. The key here is that this knowledge doesn’t reside solely with the researcher. By taking part in the discovery process together, we’re all researchers, contributing to a shared understanding that is championed through the life of the project.
In the medical profession, missing a detail from an interview can lead to an incorrect diagnosis and potentially devastating consequences, so having that extra assistance can be crucial. Designers also diagnose and treat problems. As design expands to include solutions that we depend on for both our physical and mental well-being, the repercussions of our mistakes expand as well. We have a responsibility to the people we’re designing for, and this starts with asking about their habits and needs. Then really listening, together.
The Healthcare.gov rollout was a big setback for client services in both execution and perception. The site tanked, and the end result, for hundreds of thousands of site visitors, has been error messages, slow response times, the inability to log in or create accounts, and an overall unpleasant user experience. Every designer’s, developer’s, and client’s worst nightmare.
Why did this happen? Part of it stretches all the way back to the process of selecting the firms that participated in the project. Prescriptive RFPs and exhaustive procurement processes have created barriers to entry on government projects that many top design firms are unable, or unwilling, to deal with. And these unfortunate circumstances are not unique to government work. Many organizations believe that an orderly RFP process can help them find the right design partner, when many times, it simply proves that they can successfully execute an RFP process and that design studios can follow directions, the right fit be damned!
If you’re not required to write an RFP, don’t. A concise project summary and some conversations should be enough for prospective agencies to scope your project. But if organizational regulations force you to turn to the dark side, here is a list of some dos and don’ts to consider:
1) Don’t use a template
Start with a clean slate and define the problem from scratch. On the chance that you miss something, a good design partner will ask the right questions to extract any info that is missing.
2) Do keep it brief and define a purpose
Brevity is key. Define your purpose clearly and succinctly. To do this, ask your team questions like:
Why are you redesigning the site?
What does the current site do well? Where is it lacking?
What business requirements must be met?
How could user needs be better served?
Who are your audiences and what do you want them to do?
Who is your team? What will their roles be on the project? Who manages the project? Who makes decisions?
Who will maintain the new site after it launches?
How will you measure success?
What are the project risks?
What challenges have you faced in previous work with design partners?
After launching the new site, what will change for your organization? What will change for your users?
3) Don’t be prescriptive
Stick to defining the challenges and goals of the project in the RFP and avoid offering, or asking for, solutions at this stage. This allows the respondent to reply with their thinking on the best approach and strategy rather than specific solutions, which should only come after adequate research.
4) Do ask for references
There’s nothing better than talking to the people who’ve been in your shoes. Talking with reference contacts from previous projects is a great way to get unfiltered thoughts on working with a design firm.
And don’t put it off until the end as a formality. As soon as you begin to feel that an agency may be a good fit for you, gather some reference feedback and use it to inform your discussions with the design agency.
5) Don’t ask for spec work
Design is a solution to a problem within a set of constraints. It serves to support the content on a site and help the users complete the desired tasks. A good design process begins with a Discovery phase to define the problem, audiences, etc. Layout or design created without this is simply decoration.
6) Do allow for questions and conversations
Keep the Q&A process open and be available on an as-needed basis. Many times, a key question may not come up until the final stages of an estimate or proposal prep, sometimes right before the response deadline. If you want the best proposals, you’ll want to provide potential partners with the freedom and flexibility to ask questions at any point in the process. RFPs that define a strict cut-off point for questions make me think that the client cares more about the RFP rules being followed (the checklist approach) than finding the right design partner for the project (the best fit approach).
A good team fit is an essential criterion for a successful project, and that is best evaluated through conversations or in-person meetings. You’re going to be working with these folks on a daily basis for months. You should enjoy each other’s company, be able to have fun, and be able to argue. We never take clients we can’t argue with.
7) Don’t invite the whole world
Do some research and ask some people who you trust for referrals. Find sites you like and track down who made them, or pick out some firms that you’ve always wanted to work with. If you decide to invite multiple agencies to reply, keep it to five or less.
8) Do share your budget
Knowing the budget helps us guide you toward solutions in your price range. There are a lot of moving parts that come together to determine the final cost of a project: scope, features, project activities, etc. We’re always open to discussing money and fitting our approach to a budget threshold or range.
9) Don’t define the project timeline
Definitely include target milestone dates or deadlines, but don’t lay out a complete timeline for the project, with deliverable due dates, etc. Let the agency build their process and timeline around your targets.
10) Do define the RFP process timeline
Set clear expectations of when things are due. Allowing a few weeks for the distribution, Q&A, response, meeting, and selection process should suffice, but it’s somewhat dependent on the scale of the project, how many firms you invite to respond, and the formality of the process. You want to make sure that your team has enough time to field and respond to questions (through calls or email) alongside their other job responsibilities. So, if you are inviting five firms or less, four weeks should be enough time for the entirety of the process. If it’s 10, you may want to push it to six weeks.
So, before you issue an RFP for your next design project, consider these guidelines. Think about what’s best for you, your organization, and your users. Ask yourself what approach will help you find the best design partner for the project. Because an RFP can be like a mammothly expensive website that throws error messages, has slow response times, and doesn’t allow users to log in. It’s fancy and follows the rules, but if you can’t get what you need out of it, then it’s a waste of everyone’s time—and money.
A few months ago, we started using the Sass preprocessor to help make our projects easier to manage. I wish we’d had Dan Cederholm’s excellent, just released Sass for Web Designers before we did. (Quick note: the good people at A Book Apart sent us a copy last week so, yes, we’ve had a chance to actually read it).
Sass for Web Designers, the 10th in A Book Apart’s series for web professionals, continues the tradition of being the Seal Team 6 of technical books. It gets you in, gets the job done, and gets you out, without anyone knowing you were even there (stealth helicopter not included). It’s a quick, approachable read and Dan makes what could be a thorny, dense topic easy to understand.
The book starts with a chapter asking “Why Sass?”, which you may be tempted to skip if you’re already excited about CSS preprocessing (I mean, who isn’t!). Resist this urge because even if you know why Sass is great, you’ll likely need to convince a client or someone else on your team, and Dan makes a great argument for you. Borrow from it liberally.
Because Sass involves a bit of one-time setup before you can get started, there’s a chapter dedicated to setup and workflow. For designers not accustomed to the command line, this is essential reading and Dan makes it simple, for both Mac and Windows. He also details several desktop apps that will make setting up Sass even easier, though he left out my personal favorite, Hammer for Mac, probably because Hammer does more than just compile Sass files.
Next, Dan gives an overview of actually using Sass, which will be the chapter you return to the most. Instead of getting into the minutiae of every single feature of Sass, Dan provides a detailed look at the parts you’ll likely use most: nesting, variables, mixins, import, and extend. It’s an excellent overview and covers everything you’ll need to really make effective use of Sass in your projects. Keep in mind that Sass has a lot of advanced, programming-like functionality (if statements, loops, functions, etc.) that Dan (wisely, I believe) chooses not to cover for the sake of keeping the scope of the book compact. Fortunately, the Sass documentation is quite good.
The final chapter is dedicated to using Sass for responsive design, specifically media queries. This chapter alone is worth the price of the book. At Mule, we’ve been using a similar approach in order to make our stylesheets more modular and it has made our work much easier to build, maintain, and, dare I say, more fun.
I can’t recommend this book more highly to anyone who’s interested in writing better, easier-to-maintain CSS. If you’ve been reluctant to use a preprocessor, Sass for Web Designers will set you along the right path.
XOXO 2013 wasn’t so much a conference as a pep rally. It brought together 500 people for two days in Portland to talk, learn, and share about the process of making and to have a good time together. The organizers promised focused sessions and great fellow attendees, and they delivered. It was more fun than any conference than I can remember going to and the quality of the speakers was high across the board. But even by that yardstick, two really stuck out for me.
Max Temkin is one of the creators of Cards Against Humanity, which has achieved the fairly astonishing feat of being both completely free to download and one of the best-selling games on Amazon (if you count the expansion packs, it qualifies as four of the best-selling games on Amazon). I wasn’t sure what to expect from Max. I have never played Cards Against Humanity (I’m not much of a game player) and really only knew about it as a phenomenon. But he was great! He told the story of how he and his friends started making games in college, had some success, and after seeing how much people liked their downloadable “party game for horrible people” decided to see if people would pay for nicely-made, boxed sets. In the two and a half years since that project was successfully funded, the game has generated millions of dollars in sales.
Max talked about how he and his friends have managed to keep their heads during all of this. His advice was to make sure you know your values before you start the project, or at least understand the values that will inform the project. Let those values guide your strategy, and then figure out your tactics from there. Writing it down now, it seems so simple—like something you’ve heard over and over from other people. But this is thing about XOXO. If you know these people’s backstories, very few of them will surprise you. But when you have engaging speaker after engaging speaker telling you that they succeeded by doing these things, it starts soaking in. You start to actively think about the values that you bring to your projects. Are they values you have in other parts of your life? Do they make sense for this project? Can you stand behind them?
Jay Smooth was the other speaker that really resonated for me. Jay is the host of the longest-running hip-hop radio show in New York, and posts social commentary at illdoctrine.com. Jay and I have very different backgrounds and very different lives, but we have some common ground in how important outsider music was to us in our younger days. I came of age just as American punk rock reached a peak, and it was in that network of underground communities that I became an adult, and the spirit and attitude I learned there has stayed with me, even as the idea of punk as I knew it has transformed into something else. Jay grew up in New York City in the middle of the invention of hip-hop. He became a part of that and has stayed a part it. He’s been doing a lot of thinking about what it means to be an adult rooted in an art form that has maybe not aged all that well. As you might imagine, that train of thought spoke to me.
Jay told a few different stories. One was about reaching out to some acquaintances in the NYC Asian hip-hop community to mobilize people in response to ongoing racist humor by some radio DJs and how some good friendships came from that. Another was about playing some old ‘70s funk for a record producer who then sampled it on a Jay Z record, and how that helped the original composer of the source material—who had just turned 88 and fallen on hard times—pay off his house and help a few other people. His point was that you can’t always tell which actions in your life are going to have lasting effects, and that it pays to always act with intention and integrity. Again, this is not an earth-shaking revelation. But again, sitting there in that environment, it was a good “Yeah!”, fist pumping moment.
Jay also addressed one of two major problematic issues with XOXO: diversity. It was a largely white, largely male audience and the speakers where largely white and male, too. Not exclusively, mind you, and it was great to see groups outside those two represented on both sides of the stage. But when you go out of your way to set yourself apart from other conferences, you set some expectations. It was a topic of conversation among the attendees and was acknowledged by the organizers, and I’m confident that if they decide to put on XOXO again next year, we’ll see some efforts made in both speaker and audience diversity.
The other major issue is how that audience got there. The filter/screener/application that people had to fill out before getting put on the list to buy a pass has received a lot of attention. Both of the organizers have written about how they decided to try this approach: Andy Baio and Andy McMillan. In a nutshell, they wanted to ensure that people coming to the purposely-small gathering (only 500 attendees) were there because they were excited about making things, and specifically not just about marketing to the other attendees. I think that’s great and in the end, their approach worked. However, there were two things that I hope are improved if there is another one.
First, they have to communicate the intention of that kind of screener much more clearly. It was way too easy to skip over it. I did, and I know several other people who did. This is not entirely their fault. It’s not like they hid it. But getting these passes had developed a little bit of a land-rush feel, partially because 2012 was so highly regarded and reported and partially because of the trickle of information coming out from XOXO HQ. So when people (myself included) plowed through that form to get that pass before they all disappeared and ended up with a “Thanks, we’ll be in touch” message instead of a field for their credit card number, it was a confusing letdown, which was made worse the multi-day wait to hear whether you would get to go. To be clear: those of us who did not read carefully are responsible for not having read carefully. But there is also a design problem here for the organizers to solve next time. If they go with the same filtering mechanism, I believe they will handle it a little differently.
Second, the one-ticket-per-person rule has to be addressed somehow. At least four of us in the Mule office wanted to bring someone who we thought would benefit from the conference, people who for various reasons likely wouldn’t have gotten through the filter. Because of the risk of one person being accepted and one not, three people at Mule decided the conference wasn’t right for them. I ultimately decided to go, and I’m glad I did. But I also think my wife would have gotten a lot out of attending even part of it. I think it would make XOXO an even better event if it could help put more people on the maker path, not only to serve those already on it.
I’ll close with some ways that I would like to see XOXO grow.
Have I mentioned that I liked it? I really did. I have two different projects that I’ve been working on for several months that I’ve been hemming and hawing about taking up a level (my podcast, It Might Get Personal and my band). This kind of enthusiastic and upbeat group of people was just what I needed to feel like my projects are worth putting the effort into, and helping me figure out where to focus my energy to make that happen.
But after two days of pep rally I wanted a little bit more scrimmage, or at least some discussion of the play book. The single track of speakers is great, but I would really, really love to see some kind of option for attendees to get practical advice. Maybe from the same people speaking, maybe from a different set. Some kind of smaller sessions, whether running in parallel with either the speakers on Saturday and Sunday or the social events on Thursday and Friday, or changing the format to one day of inspiration and one day of perspiration.
Andy and Andy have created something good and special. I hope they decide to see if they can make it even better next year. I left Portland charged and excited, with dozens of ideas competing for my attention, and I’ve already acted on some of them. If everything goes according to plan, I’ll be telling you about them from the stage of the next XOXO.
Today on Twitter I asked for examples of all-too-common or uncommonly pathetic reasons for skipping research on a design/development project. We’ve all heard some variation of these before, but I am always amazed. Many were some variation of “not enough time and money”, as though research comes in standard units of $100k/month. Apparently, a manager who won’t try a new sandwich place without scouring Yelp for hours will happily plow forward investing major resources in unexamined assumptions.
This is how people make business decisions?
I thought I’d quickly share some of the responses here as a virtual wall of shame—something you can print out and tack to your office refrigerator. In a future post, I’ll get into strategies for overcoming these objections, starting with considering research as a set of activities you can do quickly, inexpensively, and incrementally.
The cargo cult:
The research was finding a profitable business model in a case study and stealing their website via screenshots.
— carolinecblaker (@carolinecblaker) September 20, 2013
The split-test bake-off:
— Stephen R. Fox (@F6x) September 20, 2013
Thinking is hard:
@mulegirl “Can’t you just use best practices?”
— Derek A Rosenstrauch (@derklbot) September 20, 2013
Unclear on the concept:
@mulegirl “we want to wait until we have more content on the site” <- seriously!?
— Crispin Bailey (@cspin) September 20, 2013
Next you’ll ask for champagne in the break room (wait, some startups probably have that):
— Clay Fenlason (@khomotso) September 20, 2013
Shut up and keep paddling:
@mulegirl “We didn’t allocate time in the project schedule.” “We’ll miss our launch date.” “Everyone just knows.” All on the same project.
— Kaleem (@kaleemux) September 20, 2013
Odd use of the word “target”:
— luísbatista (@fr3aky) September 20, 2013
The winner, for pure fatalism:
@mulegirl *Knowing, sympathetic glances around the table and a gentle laugh* “That’s not how things work around here. You’ll learn.”
— Den McHenry (@DenMcH) September 20, 2013
And, of course, geniuses don’t ask questions:
@mulegirl “Steve Jobs never did research.”
— Jean MacDonald (@macgenie) September 20, 2013
In response to this last one, I highly recommend watching even the first three minutes of this internal NeXT video of Steve Jobs talking product strategy.
Are there other excuses you’ve heard and would like to demolish? Leave them in the comments.
@mulegirl HOW DOES THAT ARTICLE NOT CONTAIN A LINK TO YOUR BOOK? MARKET GODAMMIT!!
— Mike Monteiro (@Mike_FTW) September 20, 2013
Buy Just Enough Research today and you’ll be defeating these weak arguments in minutes.
All of the hype lately about “designer-founders” makes me really itchy, even more than all the other hype. Just because a few people in khaki pants suddenly noticed someone in a black turtleneck cashing big checks, “thinking like a designer” is not new, nor is it a secret weapon. Of all the things the intensely secretive Apple has done to become outrageously successful over the past decade, their emphasis on design is absolutely the least secret. That said, what is considered good design isn’t necessarily always a business advantage.
Reading Khoi Vinh’s recent post about his experience as the designer-founder of Mixel brought this to mind again. As usual, he writes with a tremendous clarity and transparency:
Building a great UI, while almost always important to a technology startup, might not always deserve to be the central focus of the business itself. Because startups always have extremely limited time and resources, prioritizing the UI comes at an enormous cost to the company. Sometimes it’s the right thing to do, but when it’s not, when it gets top priority because it’s the challenge that the designer founder might be most comfortable with, or simply the one that he or she prefers the most, that can be disastrous.
This passage contains two very important ideas.
In my experience working with early stage companies, these are generally true and applicable regardless of the professional background of the founders—engineering, business, design, snake milking*, whatever.
Prioritizing the user experience is expensive, both in terms of cash money and opportunity cost. This does not mean startups should blow off the front end. It does mean that a startup (or any business for that matter) should invest in the interface design at the time and to the extent that interface design matters to the business. This point is different for every single company, product, or service. The right time depends on the business model, the audience, the competition, and the context of use.
To make a gross generalization, engineer-founders overvalue UI design when they’ve been led to believe it’s magical. Designer-founders do, because, as Khoi pointed out, it’s a familiar and pleasant challenge.
Over the course of a few painfully educational projects, we’ve learned when and how to talk startups out of hiring us because they won’t benefit from the type of strategy and design work we offer.
The second idea above applies to every single design project ever, no matter what stage the business is in. When you are creating something for use by others, you need to be outside of your comfort zone. The place you feel most comfortable may be alienating, confusing, or just plain boring to your target users. This is where I generally flog research as the most comfortable means to keep yourself productively ill-at-ease.
So, let’s try to put aside the founder-hyphenates and focus on the fact that being a founder is a damn hard journey into the unknown and we should be grateful to every one of them, like Khoi, who is willing to share their experience and allow us all to benefit from it.
* Totally a real job. I’ll take the risks of running a company over that, any day, no contest.