The Insider’s Guide To Evangelizing Good Design
Do you wish you had more influence on product decisions? Or that more of your talents were put to effective use on projects? This is for you.
The tech world often uses the term evangelism but you should avoid it. No one likes to be on the receiving end of evangelism. The self-righteousness inherent in deciding ahead of time to convert other people to your views without knowing anything about them has a dubious history and is often self-defeating. The first lesson is to use a wiser approach.
I realized this years ago and wrote How Design Makes The World to give designers and UX pros more constructive ways to show regular people the value of what we do. If you want lessons on this approach, join my free live event on Wed April 7th, I use stories and questions as the primary methods and they are central to the book and my advice. These are the most powerful tools for engagement that we have. The advice in this post comes from the same spirit.
A common mistake repeated at events and in articles is to start by teaching design theory. Or starting methodology warfare. Grand theories are intimidating just like overly complicated user interfaces. They don’t meet people where they are. We fall back on jargon and methodology-speak because it’s a place of confidence and we presume it will convince people of our authority, when in most cases we don’t have any (if we did, we wouldn’t be reading articles about design evangelism).
Convincing people is a social process. It’s not based on intellect or superior arguments, and if you start there it is likely to backfire. No one likes to be told they are wrong. Instead you must first learn about the goals and problems other people have and find ways for your ideas to be useful on their terms.
Here are my ten lessons:
- A better model is to be an ambassador. Unlike evangelism, an ambassador has to learn the local culture and language. They are better designers of their message since they learn about who they are working with before they try to influence them. Ambassadors are not passive: they have an agenda. But they seem charm and positive action, not venting and bitterness, as the way forward. They study the locals before acting and see their fluency with local culture as a key advantage. They know that earning the ear of powerful people is one of the most effective ways to get things done. Being a leader is a good model too, but for that you must earn followers.
- There are three tactics: broadcast, personal and situational. Broadcast is when you give a big presentation: wide reach but shallow depth. Personal is when you talk to someone individually and try to persuade. The most effective is situational: your team faces a problem and you help solve it (using knowledge you hope they will adopt more in the future). You need them all, but situational is the most important as it’s the only direct credibility you can earn. Broadcast becomes more effective when you can refer to personal and situational evidence of success, but it can also be the way you learn about people and situations to focus on.
- Aim for small wins, not conversions to a belief system. No one transforms their beliefs all at once, except in movies. Instead of grand theories, find clear places where your idea solves a problem for one specific person. Pick the person who is most receptive to you (or least against you) and has some decision making influence. Ask about their problems. Find one your skills can resolve and offer to help. Provide value on their terms first and build from there.
- Common organizational situations UX design can contribute to solving are “how do we know what the right features are?”, “how can we save engineers time?”, “how do we improve customer satisfaction?”, “how can we increase revenue?” or “how do we earn customer trust?” Enter these conversations or initiate them, but use their language and goals first. If the title of your meeting request or first sentence of your advice is is one of these things, people will give you their attention. As opposed to “Give designers a seat at the table” or “You’re wrong because of the design thinking law of transverse usability matrices which dictates we re-initialize the project’s flux capacitor.”
- Allies matter more than ideas. Once you solve a small problem for one person, they are an ally. Everyone likes people who solve their problems. You can enlist an ally to help you convince someone you don’t know, but they do, to let you try and solve a similar problem for them. Eventually when it comes time to convince a leader, it’s your allies on their team that will make all the difference. Moving upstream in the decision process depends on allies more than your ideas or your charisma. Sometimes people have the same problem you do and they can become natural allies (who is equally frustrated by their lack of influence? Can you help each other solve the problem?). And don’t forget: your boss should be your biggest ally and share your goals.
- Your bigger goals require more powerful allies. Who has the power to make the organization change the way you want? It’s likely a VP, a director of engineering or a general manager. You often need smaller allies to gain medium ones and medium ones to gain big ones. But at some point you will need a relationship with whoever has the power to make the changes you desire. They have to know you personally and trust you. Before you try to persuade a powerful person, have two people that report to them already on your side (or who make the pitch for you).
- Design maturity grows one step at a time. Organizations only grow at a certain pace. If you expect to jump from level 0 to design nirvana in a month, you will never even get to level 1. Ambassadors are patient. They study the pace of change in their culture, and other similar cultures and define stages of progress (you should have a design maturity model). It’s demoralizing to the people you are trying to convince if you often express, even passively, how backwards you think they are.
- Engineers have more power than you realize. They have great influence over which defects they fix (including UI issues) and what the work estimates are on project tasks. They are a great source for small wins. Having even one engineer as an ally can make all the difference. How do you start? Express curiosity about their work, earn some trust, find out their frustrations and see if your skills can reduce them.
- The messenger matters as much as the message. We judge messages on how much we trust the person giving them. It’s hard to influence someone who barely knows you. Match the size of what you are asking for with their level of trust in you so far. As you grow trust, the size of your requests can grow with it.
- Like good product design, don’t blame the user. We’d never let an executive say “it’s the customers fault they can’t figure out how to use or product.” We should apply the same design ethos to our internal efforts as we do in products. Of course there are organizations that are so dysfunctional or poorly led that progress is improbable, but resist this judgement. You may have simply not found the allies you need yet, or developed the ambassadorship skills, to turn things around.
Often people ask me “Why should I have to do all this?” to which I say, you don’t! I agree that often designers are set up to fail by leaders of organizations. But recognition of this doesn’t change anything on its own and can be self-limiting. If you feel it’s unfair that your knowledge isn’t presumed to be valuable that’s fine, but do ask yourself, where does this feeling come from? Why do we expect regular people to know anything about good design or how to manage designers? How will they learn if a designer doesn’t teach them?.
The question is: do you want progress or not? Designers and researchers will always be minority professions. There aren’t that many of us. The word should implies there is some authority out there we can appeal to that will take responsibility but I don’t think there is one. The question is do you want progress? If you do, it’s up to us. If that’s you, I’m here to help.
Thanks to Tony Santos and Melanie Hambarsoomian.
Credit for arrow image: pixbay.
Scott: You make some excellent points. One of my terrible bosses downgraded me because I didn’t write many “If you don’t do X, your project will fail” memos. I responded by explaining that if I helped an engineer improve a design, within their schedule and budget limits, then they would come to me earlier for support on the next project. I called it invisible Human Factors, because the strategic task was to educate the engineers for long-term effectiveness, rather than making a fuss about every little thing.
Of course, sometimes we had to make a fuss, as when the designers didn’t want a fence around the high voltage and current, toxic chemical plating tank, because they wanted the workers to be able to reach into the tank and adjust things, even though the electricity was potentially fatal.
Thanks for the comment. I like your notion of invisible human factors. I think it’s common for managers to overlook how short term easy to measure things (like warning memos) work against their long term goals (a culture that naturally tends to do the right thing).