4. Evaluating Work and Giving Feedback

I was lucky enough to be raised by a seamstress. Admittedly, this meant being marched off to school in a series of plum-colored, home-sewn leisure suits in the late ‘70s. But for all the shame and inorganic fabric I endured, I got to watch my mom work. The way a seamstress approaches her craft isn’t too far off from a designer. They decide to take a client and discuss the client’s goals, which in my mom’s case was usually her specialty—wedding dresses.

Together, my mother and the bride would choose a pattern, feel out fabrics, and talk about modifications. As the dress moved from pattern to muslin mockup to the finished gown, the bride would come to the house to get fitted. Alterations were made, hems adjusted based on smiles and frowns. Both the seamstress and the client had important roles; without the bride’s participation, my mother had no way of evaluating her work. Just because something fit didn’t mean it was the right dress.

As a kid, I was getting a master lesson in client services. A lesson on how to treat clients and work with a client instead of for a client. I watched clients evaluate work. I watched them give feedback. And I saw how critical it was for both craftsperson and client to communicate and work together. (I also got roped into attending a lot of weddings.)

In this chapter, we’ll talk about how to tell if the work is going in the right direction and how to communicate with your designer to keep it that way.

We already went over this. Who cares? The project’s ultimate success doesn’t ride on your users knowing anything about design, but how they respond. It rides on how well the design helps your users effectively, efficiently meet their goals in a way that benefits your business.

Your job is to be the business expert. Your knowledge of the organization and your skill set aren’t things the designer can bring to the table. Your level of engagement in the design process and the quality of your evaluation of the designer’s work determine the project’s success.

Design is a series of checks and balances. The designer uses all of their intellect, knowledge, and skill to come up with so-lutions—and you need to come up with an equal amount of intellect, knowledge, and skill to evaluate and critique those solutions.

Challenging the designer’s work in the most productive way possible is the essence of being a client.

As I mentioned in the last chapter, no one, and I mean absolutely no one, comes to your site for the design. (A thousand designers just threw this book across the room. Hope they weren’t reading it on their iPads.) People come to your site to read articles, watch cat videos, see what their friends are up to, and scope out sales. They come because the site fulfills a need, whether it’s a physical need (pants), an emotional need (cat slide-show), or a logistical need (airplane tickets). The design needs to support that content or function in ways that make its use clear, delightful, and memorable. The better design does those things, the more people will return to your site when they have that need or desire. When you evaluate design, think of the person having their need fulfilled. Can they do it? Can they do it in a manner they’ll enjoy?

I don’t want to single you out. Keep an eye on your designer’s subjectivity too. Make sure they believe that whatever they put in front of you is the best way to solve the problem. They better back that up with solid research-based reasoning. You don’t want them doing things because they “like” them either.

Nobody here gets to like anything.

Is the designer showing you work that will meet those goals?

If you’re telling the designer how to meet goals, you’re dealing with a bad designer. If your designer doesn’t understand your goals, you may be dealing with someone out of their depth. And if the designer shows no interest in goals, you’re not dealing with a designer at all.

But say the designer is putting work in front of you and saying things like, “Our goal was to sell pants, so I made sure the product pages had nice photos of people wearing pants, an obvious way to buy those pants, and another way to get to different pants if these weren’t the pants they wanted.” That’s good rationale. Your job is to evaluate whether those solutions help you sell pants.

You may know from your decades of working in the pants industry that pictures of people wearing pants creep people out. That’s great feedback for the designer, and something only your experience can bring to the table. Don’t assume your designers have learned all the tricks of your industry. Cut them a little slack. It’s taken you a long time to learn what you have.

If the answer is “in the middle of a bookstore, trying to read a book for free,” go to the cash register and pay up. Otherwise, carry on.

The same holds true on a project. You can’t evaluate work unless you know where you are, because each project phase determines the kind of deliverable you get. Are you looking at a rough sketch to help set direction or a fully realized system? Are you supposed to pay attention to interface labels or are they placeholders? Do you care that the JavaScript isn’t working? Etc.

Your designer needs to set the stage for you. Remember my speech about hope in the last chapter? (Go back and reread it if you don’t.) Every design presentation should start with some form of: “Here’s what we need your feedback on today.” That may be followed by the helpful: “Here’s what we’re not ready to talk about yet.” If your designer doesn’t tell you these things up front, feel free to ask. Sometimes they need a little help. Otherwise, you may find yourself spending thirty minutes discussing JavaScript functionality that isn’t slated to work for another three weeks.

Once we know where we are, reacquaint ourselves with the goals, and can look at the work objectively, we’re ready to do some evaluating! But what exactly are we evaluating for? Excellent question. Here are general things to keep in mind.

You need to evaluate tone throughout the project’s lifecycle. From the initial structure and color palette, to the navigation language later on, to decisions like whether you’re the type of organization that puts everything in a slideshow (please don’t be). You have to review details on how to treat bylines, manage comments, and handle offsite things like the way you speak on social media platforms. Which thing to focus on depends on where you are in the project. But you should continue to evaluate the tone after the project launches; periodic check-ins ensure your organization’s tone is true.

1. Can you make it?

2. Can you run it?

We’re driving toward a deadline. When a designer puts something in front of you, especially if it’s technically tricky, evaluate the effect that piece of functionality has on your deadline. If you don’t know whether something is technically tricky, ask. Here’s a secret: they will always say no. But if it’s tricky, they’ll hesitate for a second before saying no. At which point, ask for an hourly estimate of how long it’ll take to build it. Then double the number and ask if there’s an easier way.

So you have the resources to build something. More important, can you run it? During the discovery phase, we find out how many people and how much of their time you can dedicate to maintaining the site. We call this the Oars Test. We’re building a boat, and we need to know how many oars to include. Because the Queen Mary may be a lovely ship, but if it only has two crew members, it’s not going anywhere. Yes, I know the Queen Mary doesn’t have oars. Let’s move on.

Along with research, a bit of empathy for your users goes a long way. No one will use your product because you think it’s awesome. They’ll use it because it makes their life easier or more fun. So if you’re evaluating work and you find yourself saying, “This makes sense to me,” you’re in trouble. Instead, ask yourself if it would make sense to the people you’re building it for. At some point, you and your designer should test the product with those people. Let them evaluate it. Make sure they can accomplish common tasks. Make sure the language on your labels makes sense to them. Remember that testing early and often is better than putting your testing eggs in one basket toward the project’s end. You want to iterate throughout, not freak out when you’re out of time.

When you evaluate a design’s flow, ask yourself if things happen in the right order. Think of how people flow through the system. Does the design guide that flow? How do people enter? Are we sending them directly to what they need? Are we springing a pop-up ad on them three sentences into the article? (Please don’t.) Do we let them enjoy the thing they asked for and then offer further places to go at the right time? Or are we pushing them through the front door while anxiously shoving a million other options that grab their attention?

The correct order seems obvious in some cases, like buying a movie ticket. You decide what movie you want to see, find out where it’s playing, get a showtime, and buy a ticket. Unless you choose a movie based on what’s playing at a certain theater, in which case, you swap the first two steps. The system needs to work both ways. The order isn’t ever as obvious as you may think, because people are weird and wonderful and do things in all manner of ways.

A good design accounts for unknown knowns. The best systems don’t need to change how users behave but bend to suit your users’ needs. They’re informed by how users already behave. Pave the cowpaths and all that.

Simplicity is the key to success—and the hardest thing to pull off in design. When you do manage the feat, it looks like you’ve done nothing! Because, oh my god, it’s so simple. Which is why the main ingredient of achieving simplicity is confidence. A good designer finds an elegant way to put everything you need on a page. A great designer convinces you that half that shit is unnecessary.

The more crap I remove from a website the more likely a user sees the thing the client needs them to. The clearer our path to the goal, the more likely we are to reach it.

If you take something away and the site still meets its goals, you don’t need it. Burn it with fire. Let’s define what we mean by “need”: does it meet a major goal of the business or user? Is this the right place to meet that goal?

Internal real-estate battles are some of the biggest challenges to simplicity, especially in larger companies. One department gets upset that another was allotted more space, so they demand more space. Which is the tragedy of the commons. Let’s say you have a common field where all the farmers bring their sheep. Your neighbor decides to bring ten more sheep than he did yesterday, which means less grass for your sheep. So you say screw that guy and get yourself twenty more sheep. Meanwhile Bud, the herder up the road, decides you both suck and gets himself fifty more sheep to graze. Now the sheep don’t have enough grass, the field dies because it’s overrun, the sheep die of malnutrition, and your town dies because there’s no more mutton for stew.

This kind of internal territorial battle destroys your website (you realized I was talking about the website, right?). You’re in a much better position to keep it from happening than your designer. Your designer can, and should, make a stand. But when push comes to shove, you’re the one who needs to keep it from turning into a sheep show.

We want people coming to your site to feel like a receiving line exists. Look at this first, then this. Now shake hands with the countess. You get what I mean. Things have an order, and we’ve thought them through. Feel free to replace nobility titles with user needs. (This is the most socialist line in the whole book, Mandy Brown.)

Hierarchy lets you know the important things are important, and the lesser important things are less important. (We got rid of everything that wasn’t important, remember?)

When you evaluate the hierarchy of the site or app, where does your eye go first? Where does it go next? Are those places it needs to go? And how many of those places were ads? (I’m not against you making money, and I know those ads butter both our toasts, but when the first five places that draw your attention are ads, you have a problem.) Take the Bunny Colvin test: look at your screen. Do you know where you are? Do you know what you can do there? Do you understand how things relate to each other?

Going further, can you tell what the title of the page or screen is? Do the photos belong with the text? If there’s an order to what you need to do or read, is that order obvious? As you flow down the page, do related items look related or seem like some random stuff to the side?

If you’re looking at your homepage, can you tell what you should do within a second or two? Is that description as clear and concise as humanly possible? Has it been dressed up in corporate or hipster speak? Can someone who’s not in your industry understand what it means?

As you evaluate, beware a tempting hierarchy fallacy: “Make it bigger!” Our reflexive response to not seeing something is to make it bigger. If you can’t see text, make it bigger. If you can’t see photos, make them bigger! Of course, now you can’t see the ads. So we have to make them bigger. Which means we can’t see the Buy button, so we have to make that bigger. This has made the logo almost invisible, so we make that bigger as well. Before you know it, you have the equivalent of a roomful of people shouting at you. And you can’t hear any of them. All you want is to get the hell out of that room, because these crazy people are screaming so much. You want to go to a nice website where you can shake hands with a countess.

If you want people to notice something, make the things around it smaller. Your logo is big enough. Trust me on that one.

Now that you’ve evaluated the work, you need to communicate that feedback to the design team. I once had a client start their feedback with, “This makes me want to stab my eyeballs out.” Let’s find a better way, shall we?

It takes designers years to learn how to guide clients on giving good, helpful feedback. In my experience, the first few (hundred) times I gave a client presentation, I was just happy to survive the ordeal. It didn’t even occur to me that you may need help in evaluating the work. (It’s fun to be young.)

An empathetic designer realizes that clients don’t give design feedback for a living and don’t really know what designers need at this point. Then they realize that it’s part of the job to guide clients there. Because in the aftermath, you’re alone with a stack of work that will affect the health of your organization, and your design team is returning to their office after a stop at the nearest Fluevog store.

So ask for feedback guidelines. “What kind of feedback do you need? What should I focus on and what should I ignore?”

Make sure you’re clear on which elements you’re supposed to evaluate. Are you looking at the overall brand, page structure, or typography? Did your designers use actual content, or did they take the easy way out and fill the comp with ersatz Latin and Flickr photos? (Guilty: I sometimes comp with Latin.)

If you’re looking at code, is it production-level or prototype code? If it’s the first, make sure to run it by the people in your office responsible for implementing it.

Let me cut to the chase and tell you what the next thing out of my mouth should have been: “What do you mean by extreme?”

Unfortunately, I hadn’t learned that lesson, as I found out when I presented the next round of concepts. My idea of extreme and their idea turned out to be two very, very different things.

Language is fun. It’s also flexible. As one of our greatest philosophers, Inigo Montoya, said: “You keep using that word. I do not think it means what you think it means.” Clients and designers have different vocabularies. They sometimes use the same words to mean totally different things.

Before you do any meaningful work together, you need to learn how to understand each other. All professions have their own idiosyncratic language. Design is no different. Even within various design fields, words take on a range of meanings. A template means different things to a user experience designer and a developer.

Personally, I feel it’s the designer’s responsibility to learn how to communicate with their client. They are, after all, communication professionals, and a good designer will have no problem asking you to clarify something you said. But as we know, people are less than perfect and often feel like asking a question makes them look stupid. (Au contraire!) It’s in your best interest to learn a bit of their language too. Luckily, I’ve tacked on a handy glossary in the back. Enjoy. With some care, we can all learn how to use language to better achieve our mutual goals.

Your designer should be able to give you a reason why they made the decisions they did. They should tie those decisions back to your goals. That’s the logic you need to evaluate.

For example, “I’ve placed this ad so that it intersects the article body, thereby placing it within the reader’s reading flow and increasing the ad’s visibility and odds of the reader interacting with it.” That’s expert reasoning. It shows experience with reading models and business needs. “I put the ad here, because it fit.” Not so much.

Your feedback should be based on how the designer’s decisions reflect an understanding of your business plans. You may disagree with their decisions, but as long as both of you agree on the ultimate goals of the project, you’ll have a productive discussion. If the designer can’t explain their decisions, you’re left with nothing but subjectivity to guide you, and you have nothing to give feedback on. Get them back in the room.

If push comes to shove and your designer cannot explain their decisions, you have a real problem—one that only gets more difficult as the project goes on.

The most important thing to keep in mind while evaluating design: what you’re looking at isn’t art, not even close. It’s a business tool in the making and should be looked at objectively like any other business tool.

Your feedback for your designers is based on the same stuff you care about with any other person you interact with at work: how is this going to help your business succeed? That’s something you are very good at evaluating.

The right question isn’t “Do I like it?” but “Does this meet our goals?” If it’s blue, don’t ask yourself whether you like blue. Ask yourself if blue will help you sell sprockets. You just wrote your first feedback question.

The problem with like is that it places the emphasis on success on someone’s subjective mood rather than quantifiable data. When you hire me to do something, my job is to make sure it’s successful. While I can’t guarantee its success, I can significantly lessen the chances of failure by doing solid design research and making sure the work I do follows that research. But make no mistake, you’re hiring me to make something succeed.

A good client knows the difference between personal opinion and goal-driven, informed evaluation.

I realize this may be hard for you to hear, but I honestly don’t care whether you like what I do. (Don’t throw the book across the room yet. Stick with me.) Obviously, if you like something, my job is easier. But what I can’t do under any circumstances is make decisions based on whether you’ll like them, instead of whether they’ll succeed. And you honestly don’t want me to.

Making you happy is never a project goal. If I’m focused on making you happy, I’m ignoring the real goals, and the project is more likely to fail. Are you still happy? (Now you can throw the book across the room. It’s okay, you can buy another one.)

Let’s face it. When we hear, “I like it,” our minds go crazy and get filled with weird pheromones or something. (I’m making this up; I’m not a scientist.) We enjoy hearing it! We want to hear it again. It’s human. And designers are human too, so we start doing work that gets you to say it again. Six months down the road when the project has failed and we’re all wondering why, we won’t get much relief from the fact that we all liked it. So let’s not use it. Wean your designers from using it too. If your designer is trying to wean you from using it, well, this is why.

Try “This works” or “This seems correct” instead. Yeah I know, it’s kinda dry. But it leads us to a better place. In the same vein, avoid words like great, pretty, and happy.

Good feedback isn’t synonymous with positive feedback. If something isn’t working, tell the design team as early as possible. Will they be hurt? Not if they’re professionals. A good designer will argue for their solution and know when to let go. (Note to designers: the time to let go is when it’s clear that the solution isn’t sufficiently effective, not as soon as a client expresses a negative personal opinion.)

Be respectful, but don’t hold back to spare an individual’s feelings. Taking criticism is part of the job description. The sooner your designers know, the sooner they can explore other paths. Ifyou see something that you are absolutely, positively sure isn’t going to work, and the designer hasn’t convinced you otherwise, let them know. It’s not going to grow on you. You’re only going to get more irritated when you see it again.

We were pretty happy, because that level of detail generally means things are going in the right direction. Then, buried about two-thirds of the way down on page eight: “Overall, the design feels sterile.”

No amount of tweaking will turn a potato into a schnauzer. If it doesn’t work for you at a big-picture level, don’t sweat the details. Get with your designer and hash it out.

Avoid personal preferences like, “I hate scrolling.” I can do absolutely nothing with that statement. If research shows that your readers enjoy larger type and are comfortable scrolling, we’re scrolling. You’re not every reader. Building things to your own preferences makes one person happy: you. That’s not enough people to make your site a success.

Prescriptive feedback is along the lines of: “Move the buttons over here.” And everyone’s favorite: “Make the logo bigger!” These may be decent ideas, but if we talked about the problems you’re trying to solve with these prescriptive solutions, we may come up with better solutions or possibly uncover a larger problem in the design system.

It’s akin to walking into your doctor’s office and demanding a prescription for penicillin. You may need that, but there’s no way you’re walking out of that office without the pants coming down.

Nothing is less helpful than getting feedback in the form of a comp (whether committed in Photoshop, PowerPoint, or Word). Nothing. I mean it. We’ve been in business at Mule for almost ten years now, and this is the only thing we’ve ever fired a client over. (It happened once. The client refused to stop after we told them on numerous occasions that it was counterproductive, not to mention a contract violation.)

If something isn’t working, point it out and go into as much detail as possible as to why. Tie it to the goals we agreed to earlier in the project. Understanding your reasoning is critical to solving the problem. Being told to do something a certain way, or worse, getting a comp of it done that way only means we have to reverse-engineer the whole thing and find out what you were trying to solve. Lost time. Lost budget.

Think of it this way. If a solution I came up with doesn’t properly address your business goal and you’re correcting me without saying why it’s wrong, I’m going to remain ignorant of what’s wrong. Which means I’m likely to keep doing it. Which means you’re going to have to keep correcting me. That’s a terrible way for you to spend your time.

No. We cannot compromise.

If you tell your barber that you like it short but your significant other likes it long, you’re gonna get a mullet.

Listen to your team’s feedback, weigh the plusses and minuses, and then compile a clearly written document full of strong decisions. We can’t design a solution to an internal debate. Nor should you pass that debate along for your customers to suffer through. If members of your team have varying ideas on something, iron it out. Invite your design team to join the debate. They should be eager as it informs their work. Reconciling feedback moves the process along. Sorting through ten pages of internal disagreement means lost time and budget.

Solid decisions, well communicated and well executed, are the path to success.