[ 11 ]

How Executives Can Help Designers

There are other people in the organization besides designers who are interested in learning to talk about design. Stakeholders from every level see a gap in communication with their own team and seek out resources to help them work with us and make better products together.

I’ve had teams ask me, “How can we work together more effectively?” Executives ask me, “Can you teach me to work with our designers?” These people understand the value of having good working relationships, and the key to maintaining it in a technology-driven sector is to focus on clear communication. Most often, people become upset and projects become difficult when two or more people fail to communicate. Miscommunication results in missed expectations. Missed expectations lead to disappointment and distrust. We want to prevent this from happening!

Even when communication doesn’t appear to be constrained, the way you approach and talk with designers has an impact on their productivity, attitude, and creativity. More than just clear communication, you need to be sure that you’re getting the very best from designers.

This chapter is devoted to helping the other people in the designer’s path to better understand, communicate with, and thrive on teams with designers. Whether you’re a developer, executive stakeholder, product owner, project manager, marketing type, or customer advocate, this chapter is for you. If you’re a designer, tear out these pages and hand them to your boss or favorite developer. (Or you can read along and pat yourself on the back as I affirm you and call out your suspicious quirks.) The goal of this chapter is to bridge the gap and help everyone on the team be more effective at communicating with one another. We want you to learn how to get the very best out of us.

To do that, we’ll:

• Identify several key areas where stakeholders can help us be more successful.
• Provide a list of tips for working with designers on a regular basis.
• Make a checklist of questions that most projects need in order to start off on the right foot.

The King and the Blind Man

Once there was a king who had a blind man as an advisor. When the king was returning from a hunt with a large party, he became very thirsty and spotted a field of watermelon. He called to his servants to fetch some to quench his thirst, but the blind man began to laugh.

“Why do you laugh?” asked the king.

“Good king, there are no watermelons here!” he replied.

The king was surprised. “You’re blind! How do you know there are no watermelons? I can see them with my own eyes. You cannot!”

And the blind man responded, “My lord, one does not require eyesight to know these things. The season of watermelons is over. There may be some left rotting in the fields, but all the good fruit has already been harvested.”

You see, the king saw watermelon, and that’s what he wanted, but the blind man knew better. It seemed so obvious to the king that this was the solution to his thirst. It was also so unlikely that the blind man could understand the situation enough to help him with his problem. Yet the blind man’s perspective allowed him to help the king and ultimately spare him from collecting rotted watermelon. I suppose there are worse fates!

Obviously, this is an amusing story, but the point is this: you have people on your team to make you successful, to help you do your job better, and to provide a perspective that you don’t have. There might be times when it seems like the designers don’t know what they’re talking about or couldn’t possibly contribute meaningful solutions to difficult problems, but that’s not true. Designers are problem solvers, whether it’s addressing business concerns or proposing coding solutions. I’ve seen designers turn heads when they make suggestions that everyone else thought was outside their realm of understanding. So in order to make the most of your time with designers, you need to remember the Four “izes”:

• Realize we have expertise in this area.
• Prioritize our needs so that we can get to work.
• Authorize the entire team to move quickly.
• Recognize that we are people, too.

Realize We Have Expertise in This Area

One of the biggest challenges we designers face is with other people believing and trusting that we’re actually good at what we do and that we make good choices. What’s strange is that so many of those same people will also compliment our work when they like it. However, when people disagree or question our design decisions, there can be a lot of distrust—or at least a lack of complete trust. Many people see the designer’s role as merely to make things look nice, and they often aren’t afforded the opportunity to have a seat at the table when it comes to decision making.

As you work with the designers in your life, realize that they have expertise in design and that their job is more than just making your project look pretty. They are equipped to find design solutions to business problems. You hired them and have them on your team for a reason: because they’re experts in design and are better at it than you are. They have expertise in understanding what makes things easy for users. They’re trained in usability techniques and best practices. They know the right patterns and design elements. You need to trust them to do their jobs without telling them how to do it.

In fact, design is really difficult. It seems easy and simple to you because you only see the final result. There is a lot that goes into the design process: defining use cases, mapping flows, writing requirements, and a ton of ideation and iteration on wireframes and prototypes. You aren’t seeing everything we threw away or the time and angst we put into finding the proper solutions. By the time our designs get to you, we’ve been working diligently at checking all the different angles. There’s far more to it than just putting some elements on a page.

If we’re coming to you with our proposal, you can assume that we believe it’s the best solution. You don’t need to ask us if we like it or not: we do! We made it! If you disagree, it’s absolutely appropriate for you to engage us in that conversation, but don’t begin with a posture of skepticism about whether we know what we’re doing. Instead, draw out our decision process, seek to understand our perspective, and ask a lot of questions to be sure you’re on the same page.

Also, because design can be complex and many elements are interrelated, realize that any changes you suggest will affect the rest of the project. There’s a ripple effect that may require us to rework the other parts. It’s not isolated. Many stakeholders make well-intentioned suggestions, expecting the changes to be simple or only take a few minutes. It’s not unusual to hear, “All you have to do is move this over there, right?” But the process of updating one part of the design requires that we step back and evaluate our decisions. Moving one thing requires that we also move another. Sometimes, changing elements can break the flow of the application. Not always, but often.

So, you need to realize that your suggestions are more than they seem and that they may not be as easy as they appear. Even simple changes will require a certain amount of rework. I’d suggest first asking about the impact of the changes you’re suggesting. Try to understand how your recommendations affect the team before insisting that changes be made. Getting alignment on the effort involved is an important part of the conversation.

Prioritize Our Needs So That We Can Be Successful

Easily the biggest blocker on any project is not giving designers everything they need to do their jobs. When you ask us to design something, we need a lot of things from you to be able to do that effectively.

It’s much more than you expressing your vision and letting us loose. We need business requirements to be documented and timelines to be established. Technical needs, too, are critical: access to servers, contract approvals, or sharing your analytics and data. Often, we need permission and access to other people within the organization: gatekeepers, domain experts, and customer service advocates. We can’t work unless we have these things from you, so make it a priority to track down what we need. Let us help you be successful by equipping us with what we need to get the job done. Do the work necessary to set things in motion so that we can hit the ground running.

This means that you have to prioritize our needs in order for us to get stuff done. You should be prepared when you meet with us. Review the designs we sent you in advance so you know what your feedback is. There’s nothing worse than someone showing up, saying they didn’t have time to review our work earlier, and then riff on a handful of knee-jerk reactions from seeing our work for the first time. No, we need you to be better than that. Value our time in the same way we value yours by being prepared.

You should have already jotted down your list of questions or concerns. You might even find some reference material, like other apps or data from a different project, that will help us understand your perspective so that we can deliver what you need. Most importantly, do this within a reasonable window of time. If you take too long to review and respond to our work, it might shorten the time we have available to implement your changes. We lose time waiting on you, and then we’re rushed to get it done. You’re not going to get the best from us in that scenario. Please value our role on your team by prioritizing our needs so that we can be successful.

Usability testing and research

One resource that we often need but don’t get is permission and budget for doing usability testing. We need to check your project with other people to verify that it will work as expected. This isn’t a focus group; we’re not asking users what they want. This is taking the time to observe people using our website or app, and then taking notes about ways we can improve the experience. It’s task based and mostly observational. We don’t do this enough because we often don’t have permission to spend our time on it. It’s not expensive, and the result will more than pay for itself in uncovering problems earlier or optimizing tasks for a better app. Give us permission and the budget for usability testing, and even encourage us to do more of it.

Authorize the Entire Team to Move Quickly

Projects become stale or move slowly when decisions aren’t made quickly. The best thing you can do for the project is to make quick decisions, stick to those decisions, and empower other people to make decisions on your behalf. This will allow your entire team to move quickly and deliver the best product with a great user experience. I can’t emphasize this enough. The main difference between a scrappy startup and a bureaucratic behemoth is how quickly they make decisions and move forward. It has little to do with talent, resources, or ideas, and everything to do with the team’s momentum. Projects fail or languish when the leaders don’t make decisions or don’t stick with the decisions they made. This is completely within your control.

You can make us successful by being decisive: make decisions, stick to them, and move on. Being wishy-washy or delaying a decision will cost you real time and money. Either we will be waiting idle for you to make up your mind or we’ll be working and reworking our designs to accommodate the changes. It might seem like waiting a few days for the next meeting is completely appropriate, but in those few days we could be already working on the next thing or finding the flaws with our current thinking. The best projects I’ve worked on were those where we met with stakeholders daily. That’s right, every day. I would spend the day designing, show my work to the client in the afternoon, get immediate feedback, and then do it all over again. That sort of rhythm is empowering and exciting. Sometimes, I propose daily design reviews with larger clients and they groan. Why? Because they already have too many meetings and can’t seem to wrap their minds around a process that iterates and moves so quickly. Yet, it is these projects that always take longer and yield inferior results. When stakeholders are involved only once a week (or less!), I can anticipate that it will take almost twice as long as needed.

The better you are at making good, fast decisions, the better off we’ll be. Not just more productive, but also happier and more satisfied with our work. We feel good about what we do when we know things are moving forward. It would be better to do something (even if it’s wrong) and keep the project moving rather than do nothing and flounder in ambiguity. Indecision and changing decisions are the killers of an effective design process, so authorize your designers and your entire team to move as quickly as possible. I promise that whatever you risk in the process of empowering them with decisions will be made up for in morale, speed, and momentum.

Empowering the team

One of the best ways you can keep your project moving quickly is to authorize us (the designers!) to make decisions and extend a reasonable amount of authority to us. Let us make some of the calls. When you’re unsure what to do, allow us to inform the decision. Trust us when we make a good case on our decisions, even if you disagree. Ask us what we would do and then let us make the final call. This level of empowerment will result in a better product, happier teams, and quick movement.

I recognize that not every product decision can be entrusted to the designers. There are other factors, business considerations, and even other teams or people involved. However, often those other considerations cloud your own judgment and prevent you from seeing that the simpler, more obvious solution is really the best. In my experience, the designer’s recommendations often come back as the solution we eventually land on anyway. I’ve worked with large clients whose multiple teams and executive meetings slow the process for weeks at a time. We might toy with a handful of ideas, perhaps even implement the one that the VP liked best, only to eventually (months later) rework the design to accommodate our original recommendation. What seems like a great idea in a meeting isn’t always what works best in practice. Not always, but frequently enough to be a memorable waste of time.

One of the most rewarding websites I ever built was one in which I convinced my boss to let me focus exclusively on this one project, and to also make the final decisions. It was risky. Other stakeholders in the organization were concerned I didn’t know enough about their areas. People were worried I would screw it up. I had been at this organization for several years and understood many of the needs, but not all of them. However, it was enough to create the next version of the website, even if imperfect. After three months, I presented a finished product that was significantly better than the existing site.

Were all the stakeholders happy with what I did? No, but some were. Did it solve all of the problems we had? Somewhat. But that didn’t stop us from putting it in production and then immediately iterating on making it better. We were able to get an improved experience online very quickly and then expand decision-making authority on the next version. You see, if I’d had multiple decision makers telling me what to do, it might have taken me a year or more. Instead, we chose to value making quick decisions. We refused to let perfect be the enemy of good. That kind of trust and empowerment is rare, but you’d be hard-pressed to find a faster way of getting things done.

My challenge to you would be to purposefully allow your designers the freedom to make design decisions. Start with some low-risk decisions at first but quickly work your way toward the larger overall product vision. Begin by agreeing with them as frequently as possible, until you feel you can let them decide on their own. Find the level at which you start to be uncomfortable giving over control, and then push past it just a little. I believe that the sweet spot of good leadership empowerment in decision making is just past your point of comfort. Leaders should always be just a little uncomfortable giving over decisions to their team.

Recognize That We Are People Too

One big missing ingredient from stakeholder–designer relationships is the recognition that we’re all people. We need to remember that the people we work with are human. We need to focus on the relationship and communication. But mostly, we need to be kind, use helpful language, and create a conversation that yields positive results.

This is going to seem obvious, but designers are people, too. In business culture, projects and deadlines are often (unintentionally) valued more than the people delivering on them. Remembering that your team is made up of people who have lives, families, and interests beyond the conference room is important in any organization, and it’s no different with designers. All of us have different personalities, original ideas, and a unique perspective on life. There are other things going on in their lives besides this project. Someone is caring for an ailing mother, another has to shuttle kids from school to sports, and someone else will go home lonely. This human-centered leadership approach is nothing more than remembering and recognizing that the people you interact with are real. They have feelings—they can be built up and encouraged or they can be torn down and discarded. You can ignore them or you can show an interest in them. As you can imagine, you’ll get the best results when you approach people with a mindset that recognizes their humanity. So as often as you need to, stop, look around the room, and remember one thing: they are human.

After you’ve done that, the next step is to focus on building good relationships. Although it’s important to recognize how our specific roles as designers shape our identity, the foundation of good communication is a good relationship. No amount of organization, management, or empowerment is going to make up for a personal/relational disconnect. Too often, meetings are about projects, projects are about tasks, and tasks are tedious and unhuman. The end result is a robotic approach to projects that has no flesh, no excitement, and no life. So, in addition to being organized and making projects a priority, you also need to work hard to establish a rapport that will speak more for you than the words that come out of your mouth. Be kind and get to know us. Show a genuine interest in us by asking questions about our hobbies, pets, or favorite sports team. You don’t need beanbags and foosball tables at your office; you need to be nice and interested in people. It doesn’t take much to create a sense that you truly care about the people you work with.

Use helpful language

Recognizing that we’re all human, then, naturally leads us to a place where we are better equipped to use language and communication styles that are helpful when discussing design. When you provide feedback for our designs, focus on the designs themselves and not the designer who created them. Don’t be terse and don’t attack our work. Instead, ask lots of questions in an effort to understand our perspective and approach. Be direct but be kind. Focus on the problems and potential solutions, not on the people and their decisions. Design is already a difficult thing to talk about because people (designers) can get wrapped up in their work. When you criticize people for their decisions, you back them into a corner and cause them to become defensive. Design, more than many other disciplines, has the propensity to be divisive and polarizing. Recognize this at the outset and strive to use words that will help the conversation along rather than pit people against one another. The way you choose to talk to designers about their work will have a dramatic effect on their ability to be agreeable and productive for you.

Also, be patient when things change. We can’t always know how our designs will work in the real world, so it’s natural that we need to modify our work even after it’s in production. It’s common for us to believe we’ve made all the right choices with our designs, but when we test it with users for the first time, we find that we made the wrong assumptions. Those kinds of challenges are part of the process. In fact, I always feel a little self-conscious and sheepish when I have to go back to the developers and ask for a change. Even though this is part of the design process, I’m admitting my mistakes and taking the blame for something I caused. Because it’s my fault, it can be hard to own up to it, but that’s necessary if we’re going to create a great user experience. You should expect, even encourage us, to embrace these unexpected challenges and help us to prepare the rest of the team for the changes. As much as possible, support us through these changes and clear the path so we can feel good about doing the right thing for the user and the product.

Ten Tips for Working with Designers

To briefly summarize, here are 10 short tips to help you work with designers more effectively:

1. Focus on what works. Remove the word “like” from your vocabulary and always talk about what works or doesn’t work. Your personal preferences are less important than the needs of the user or business.
2. Don’t provide solutions. Tell us about the problem you see and describe the issue that needs to be addressed, but don’t tell us what to change first. Let us find the solution.
3. Ask lots of questions. This is the key to seeing from our perspective and understanding our motivations. Ask questions to uncover our thought process.
4. Don’t claim to be the user. The truth is that every user is different, and you don’t represent the target market any more than the designer. Claiming to be the user of your app or website does not add value to the conversation.
5. Let us explain our decisions. Don’t offer your own perspective and walk away. Allow us the time and space to form an adequate response.
6. Empower us to make decisions. Even if you disagree with our choice, learn to trust us in areas where we have expertise and then hold us accountable for the results.
7. Use helpful language. It can be difficult to receive feedback without becoming a little defensive. Avoid harsh or extreme language and focus your feedback on the designs, not the designer.
8. Ask if there is data. We should all use data to support our decisions, but just because the designer doesn’t have data doesn’t mean he’s wrong.
9. Be prepared. Review our work in advance and have a list of questions or concerns ready. Don’t wait and provide knee-jerk reactions in the moment. Your feedback should be purposeful and thoughtfully considered.
10. Give us what we need to be successful. Whether it’s logins, access to analytics, or permission to do usability testing, we need things from you to work effectively. Make it a priority.

Design Project Checklist

To help everyone be better prepared, here is a checklist of the most common web and product design needs. If every stakeholder provided these things at the beginning, projects would move faster and create a better-quality experience every time. I use this list with my own clients to ensure that we have what we need at the beginning of every project. Following a checklist like this ensures that everyone is on the same page and makes ongoing communication about the project much easier. It establishes a good foundation for talking about design decisions going forward.

This is just a tool and should be used with a degree of flexibility appropriate to the project, company, or team. Some of these aren’t necessary for every project; some projects might have additional needs, and throughout the life of a project, these things naturally change as the team settles into a rhythm. Use this as a guide, but don’t be afraid of changing it (or your answers) as the project progresses.

Management Vision and Goals

• What is the purpose of the product, website, or app? Define the primary use or need. Why does this exist?
• What is the overall vision for the product, website, or app? A clearly defined vision helps us understand how this project affects the future roadmap.
• What are the short-term goals for the business overall? What does the business want to accomplish, and how does this project fit with those goals?
• What metric can we track? How will we know we’ve succeeded? We need a way to measure our success.
• What is the strategy for accomplishing the goal? This is what needs to be done to accomplish the goal: the tasks, tactics, or deliverables for the project.
• What are the business requirements for this project? Having documented requirements at the beginning is important, but we can also work together to create them.

Users or Customers

• Who are the users? What do we know about them? This could be a starting point for writing personas and user stories.
• What is the primary problem we want to solve for them? What are the biggest pain points for users right now? This might not be the goal of the project right now.
• How do users interact with the site or app? What is their context/location, device type and size, entry and exit points, or frequency of engagement?
• What is the plan or budget for usability testing and/or user interviews? We need to work with real users in order to design for them.

Workflow and Communication

• What tools should we use to communicate? What is the best way to get answers? Everyone has different preferences for email, text, video, and phone.
• What should our meeting cycle look like? We’ll want both short, frequent updates, as well as longer, in-depth progress reports. For example, 30 minutes daily, plus a weekly hour-long (or more) design review.
• What is the timeline for the project? How frequently can we release? Establish a pattern for when tasks should be completed. Take the deadline and work backward on the calendar. This can inform resourcing or scope, too.
• Who makes the final call on decisions? Identify one person overall and/or assign one individual per role, for Business, Product, Design, Engineering, or Content. No committees.

Access to Information and People

• What technical resources will we need? Who can provide us with access? This includes login credentials, email accounts, VPN, or access to servers.
• What existing data is available? Access to analytics, usability studies, A/B tests, or any business reports or slide decks.
• Is there an existing website or app that we can use for reference? Is there another product that we can use as a basis for this project?
• What is the org chart for the company? What people are important for our project? A list of relevant people, including names, titles, relationships, and areas of expertise along with contact information.
• Do we have permission to work with these people? Necessary introductions or permissions need to be given for us to contact other people in the organization.

Design and Technical Requirements

• What design guidelines already exist? Branding guidelines, logo standards, design language documentation, style guides, or visual UI libraries.
• What is the tone or style of the design? This might be defined by the design guidelines. If not, we can discuss.
• What are our ground rules or design goals for guiding the design? A short list of limitations, best practices, or focused priorities to guide design decisions.
• What other websites or applications are similar or relevant? A list of competitors, similar or unrelated products that are of interest.
• What technical requirements will influence the design? Accessibility, browser/operating system version, device or viewport size support, responsive/adaptive/mobile.

Download this checklist at http://tomgreever.com/resources

A Seat at the Table

The way that businesses approach design has changed dramatically. Design used to be something that only made the company look professional or projected an image for the product or brand. Today, design is being used to solve real business problems, and more and more companies are seeing that value. Entire organizations are pivoting to make design the center of their process because they recognize it’s good for the bottom line. The most famous and popular products now are those that are well designed and provide a superior user experience.

To meet this demand, a lot of companies are hiring designers, building teams, and modifying their processes to more clearly value design—yet, a lot of these same companies still fall short when it comes to delivering a product. Initially, it might seem like their designers aren’t talented enough or there’s a disconnect between customer needs and the design team. This is what leads managers and developers to seek out resources (like this book) to learn how to better talk about design or to improve their communication and working relationships with designers. I wrote this chapter because difficulty working with designers is a real concern, and every stakeholder can benefit from understanding their designers. But when it comes to overall business practice, there is an underlying issue. Better communication will help, but it’s not the main problem.

Companies that struggle to incorporate design thinking into their organization have one problem: they don’t have designers at an executive level. The problem of delivering poorly designed products isn’t one of talent, but of design leadership. These companies lack a vision that’s inclusive of the user experience. They have talented designers, but not design-thinking decision makers. Companies that consistently fail to deliver the products that they believe they should offer need a new seat at the table: a designer.

Think about the most popular products, websites, or apps with which you’re familiar. Who started the company? Who is its CEO? In most cases, the people leading the organizations that create great products are people with a design-centric mindset, even if they aren’t technically qualified as a designer. They are designers in their own right, but they surround themselves with other talented designer-types, too.

These organizations don’t need to “pivot” to make design the center of their culture, because design is already valued at the highest level. They simply are organizations that value design.

If you’re serious about wanting your company, product, or service to be known for great UX, put a designer at an executive level. It’s no longer adequate to hire a contracted freelancer through a sales manager to create your website. You can’t just invite the designers to a meeting, inspire them with your vision, and then wait for them to bring back the best product ever. You are going to fail if the only designer you have sits at a desk with the marketing people down the hall. Designers need to be involved at the highest levels of the organization if you expect to succeed in a marketplace driven by design. They need to be empowered to make difficult decisions, they need the autonomy to create the best product, and they need the trust and support of the other executives.

How can you do this? In an ideal world, you’d have the authority, money, and time to create an organizational structure that reflects these values. Create a role for chief design officer or vice president of design. Involve them in all the details, let them decide on product and design direction, and give them a team. Unfortunately, that’s not something every company can do easily. More practically, designers and executives need a deeper level of engagement and trust. The people designing the products, website, or app need to be meeting with the CEO. They need frequent communication with other executives. This might just be about proximity: give them a desk in or near the executive suite. It’s amazing how much easier design and communication are when a VP walks by your desk occasionally to say hello. This is “management by walking around” (attributed to Hewlett-Packard1 and described in the book In Search of Excellence2).

One of the best (and simplest) models I’ve seen was a former employer who moved the creative director to a desk with the other executives in an open-office environment. Just sitting next to one another greatly improved their thinking, made a political statement about their values, and firmly established the organization’s vision. The designers weren’t off in another room; they were integrated into the senior leadership team.

The only way to truly incorporate design thinking into your company values, processes, and products is to put designers in positions of authority. Everyone says they want to be like Apple, but few are willing to make the leadership choices required to create that kind of environment. If you find that your team isn’t living up to your expectations for creating great products and designing incredible user experiences, take a look at your own part in that process. Before you go through another reorganization or replace your design director, take a serious look at the people in authority (yourself included) and ask if they’re really equipped to lead a design-centric product company. If not, you have an open seat at your next meeting that needs to be filled.

The fact that you’ve read this chapter speaks volumes about your desire to work more effectively with designers. When you follow these best practices, you create an environment in which designers are free to create, are comfortable expressing themselves, and feel empowered to design great products. Whatever your role, I hope that you’ll apply these principles in your practice on a daily basis so that you can get the most of the designers on your team and deliver the best possible user experience.