By Scott Berkun, November 2001

Unless you have the power to make business and development decisions for your project, some of your energy will be spent influencing those that do. Talented usability engineers or interaction designers may have limited skill in influence, despite how this can constrain their ability to influence design decisions. It’s the most effective designers that work to understand the human to human interaction within their project teams, as part of their work towards better human to computer interaction.

Focus on the key players

Step back and examine the dynamics of how decisions are made on your team. Who are the leaders, and whose opinions are respected? Before you pitch an idea or ask questions at group meetings look at the big picture. Who has influence and how do they exercise it? Sometimes one or two developers have more clout in the processes of an entire team than any project manager or executive. Perhaps your energy is better spent influencing one of them directly, rather than trying to respond to activities of the group as a whole. In a full room, you have 5 or 10 people to convince: one on one, your energy can be used more effectively to respond to questions and make your points.

Should you decide to become more active in group settings, become aware of the dynamics between the key players in the room. Who responds well to humor? Who gets defensive, or offended, when challenged? Who thrives on it? What styles of conversation or debate are most supported by the group? It’s not necessary to collect a CIA dossier on each person and their traits, but the more aware you are of what’s really going on in meetings, the more effective you’ll be at communicating within them.

Know your design allies

Out of all of the developers or other team members you work with, which ones do you get along with the best? What about the project managers or Q/A team? These allies can be your strongest asset in obtaining honest and useful feedback. They can give you perspective on the other engineers or managers points of view, and help review your work out of band of normal process. If your project manager friend from another group has the same response to a design idea that your developers did, maybe there’s more to that point of view than you thought. Even if you don’t have any strong relationships, or are new to the group, start with the best ones you have, and invest time in growing them.

Speak their language, know their concepts

A prototype of your new search page design reflects a set of design choices you think should be made. But what are the business impacts of those choices? How long will it take to build? How will it effect advertising rates, or partnerships? What code changes are needed to make it possible? In the abstract, some designers feel these are not design considerations, and instead are just matters of implementation for someone else to figure out. This is a trap. While it’s great to ignore constraints to inspire creative thinking, if your want your work to reach people’s web browsers or desktops, you have to plan to involve yourself in the practicalities of realizing your ideas. The more skilled you are at assessing those aspects of a design, the more welcome you’ll be to participate in the process.

Use your allies and key players as sounding boards before you go into more formal team reviews. Sit down with the development lead for 5 minutes, and get her quick feedback. You’ll learn enough from this brief interaction to re-evaluate your direction, and improve your thinking about the full spectrum of issues in the design. She may tell you that certain things are harder to build than others, or surface ambiguities in the design that you have not yet considered. (You look at designs differently if you have to figure out how to build them).

Coming out of these informal meetings, you might not even make any changes. It’s guaranteed, however, that you’ll know more about how to effectively present your ideas to people without your background. If you collect feedback from several different people, preferably from different disciplines, improving your work and how you present it each time, you’ll feel more confident and prepared when you show it to the larger team or in a more formal review. In a sense, that formal review, will really be your 4th or 5th time around. All of the questions that come up will have already been considered by you. The team will have no choice but to see you as a smart, confident, and prepared, because you will be.

Divide and convince

Key players, as described above, can often be more receptive to discussion when you meet with them one on one. People behave differently depending on the social situation they are in. In a group meeting, team leaders have to take responsibility for the entirety of the discourse taking place. They are careful about how and when they express their opinions, because of the different effects it may have on people in the room. If you take that same person out of the group situation, and talk to them in a personal setting, their behavior and openness to ideas may change dramatically.

In my own experience, I once presented a prototype to an entire team of developers, including the group manager who had a reputation for rejecting new directions. It didn’t go well. There were too many questions I wasn’t ready to answer, and I hadn’t done a good job of setting their expectations. Towards the end, one of the developers made a joke, indirectly about my prototype. The room broke into laughter, including the group manager. I was devastated.

The next day, when I was ready to regroup, I decided to talk to the group manager alone. He granted me 20 minutes after lunch the following day. I did everything I could to prepare, reviewing my slide deck, asking friends for feedback, and revamping how I made my points. The time finally came to meet with him, and once I closed the door, and was alone with him in his office, his demeanor changed. He was curious and inquisitive. He asked tough questions, but he seemed to honestly want good answers to them. We talked about the prototype for almost an hour, and I ended up earning his support, including commitments to the development resources for most of the work.

Not everyone will respond so differently one on one, but many do. If you’ve already been rejected, or turned down, what is there to lose by getting clarification on why? At a minimum, you’ll improve your abilities to approach the situation next time. Also remember that sometimes your own skills as presenting ideas are better when you are in a one on one situation, instead of standing in front of a large group. Know your strengths and play to them when you can.

Perfect later, good now

Formality takes time. In many informal situations, there are opportunities to express ideas through whiteboard drawings or hand sketches. Take these openings when you can, and run with them. It’s in the discussions, the brainstorming, and the hallway banter that people are most open to hearing new ideas, and to considering challenges to their assumptions. Typically, the designer’s offhand sketches and quick whiteboard drawings will look better than anything the rest of the team could produce. Being comfortable with informal discussions of ideas, and free flowing dialog around designs, opens you to easier situations for influencing peoples thoughts. Take the pressure off yourself. People may not have the same expectation of design perfection from you that you think they do. Know when speed and flexibility in communication are more important than precision.

Promise and deliver

Earning credibility with project teams comes from one primary behavior: making solid commitments and delivering good work on time. Without this, your design skills or powers of influence will only go so far. When you finally convince someone to believe in you, or your ideas, and you don’t follow through, it can be worse than never having convinced them at all. The granting of trust is a complex human process, and nothing damages it more than working to obtain it, and then betraying it. Certainly things may go wrong, and many kinds of problems won’t be your fault, but you should always hold your commitments and promises as intimate, precious things. Be specific about what you can produce by when. Identify the risks you see, communicate them and ask for what you need to protect the team against them. If you communicate how seriously you take your work, and include considerations for how your work effects the work of the rest of the team, everyone will start to take your work seriously too.

The power of the video (and the prototype)

The two most powerful forces of influence in the interaction designers toolbox are the video and the prototype. Humans are visceral creatures. We respond to things that call on our senses. Specs, code, and even bitmaps are all static, limited attempts to represent what the experience of interaction will be like. It takes an inventive imagination to read these things and accurately visualize anything. It’s typically only those few individuals with practiced imaginations, regardless of job title, that can do this well.

If you need to convince someone that the current design has problems, you must show them. Put together a highlight video tape from the last usability study, showing people struggling to complete important tasks. In 5 minutes, you’ll have changed the minds of everyone in the room. There is something every human being feels when watching someone suffer because of something they made. It effects the most callous business men or misanthropic technologists. No usability report or presentation can have this effect. Be careful not to go too far: be honest about how representative the failure cases shown are, and offer the supporting data to those who have questions. (Most importantly, be prepared with a plan and resource demands for what you need to happen to improve the product). But if you want to get people’s attention around your work and the user experience, there is no better way.

The prototype offers you another form of direct influence. It’s almost a secret weapon. While everyone in the room is debating in front of the whiteboard about what the design should be, or how it should behave, you can show the group a real live working example of your ideas . They can even interact with it depending on what you’ve done. It’s a huge advantage. No one needs to imagine anything when looking at your prototype. If you have visual design skill, or talent with Flash or JavaScript, you’ve probably made it more attractive and responsive than anything others in the room could envision, much less build.

For periods of time on some teams, the prototype is the virtual specification. If you are making the prototype, and are responsible for adding alternatives and new concepts to it, you have influence in the decision making process. Suggestions from executives or key players have to be interpreted through you. Discussions with marketing or business development center on your work, and how their needs can be met through your design, not the other way around.  While it’s true that you may need support from developers or other key players, driving the development of a prototype can afford you more influence that any other investment you can make. Be careful to build in support for your prototype as you develop it. If you show up one day with something that blows everyone away, you might be seen as a heretic. Rely again on key players to give early reviews, and endorsements of your prototype. Present it to the group as something you and the key players have been working on, instead of the result of a lone designer.

The voice from outside

Credibility can be a funny thing. Sometimes the same idea presented by a respected outsider, can carry more weight than any number of people within your team. Forwarding a recent article, or journal report, may gain you more support than anything you can say yourself. Inviting a speaker in from another team, or another company, can have similar effects. Even if everyone knows that you invited them to come, the psychological effects of hearing new voices can make them more open to having their minds changed. Like all opportunities, this does have it’s risks. If things don’t go well, or are spun in the wrong way, it can end discussions and close issues. It’s the quality and skills of that outside voice that goes a long way towards making this work.

Priming the feedback and review process

Many teams or clients have review meetings, where designs are presented and decisions are made. Before you go into any review process, understand the opinions of one or two of the key players. Invest time in showing them smaller samples of your work along the way, so that their feedback is already built in when you present to the group. Doing this informally takes the pressure off, and reduces the possibility of wasted investments. You won’t spend a week going in the wrong direction if you are getting feedback on it every few days. If you do this well, when the time comes for the larger review, the most important people in the room will see no surprises. They’ll see decisions and agreements they’ve already discussed with you in private, and will therefore want a speedy and positive review, so that they can move on to other work. You have to build in your support along the way if you want things to go smoothly.

Sharing goals makes everyone your ally

It’s very important to see everyone you work with as having the same direction, and the same high level goals. The more you’re able to align yourself with your counterparts in other disciplines, the easier all forms of work on the project will be. Product or release goals should include aspects of the user experience, usability or design, along with business or technological objectives. If no one else asks for these to be included in the planning process, it’s your job to raise the issue and suggest items for inclusion. On good teams, everyone has a chance to give feedback on the project goals before the team is fully committed. With shared goals, there is less reason for conflict or adversarial relationships. When debates occur, you can refer back to the project goals, and use them to help prioritize or resolve conflicts. Without clear goals, it’s much harder to settle disagreements or get anything done, since basic assumptions have to be re-established too often. So when concieving your designs, rely as heaviliy as you can on whatever project goals their are. The more your work reflects the intended directions of the entire team, the greater the support you can build for your ideas.

You have more users than you think

An excellent way to consider your relationship with your team, is to see them as your users. The work you create as a designer, or usability engineer, is consumed by your team before it is consumed by your true customers. What goals does your team have? What are their needs? How can you craft your output so that it fits into their system of understanding? If you feel that their goals should change, or that they need new skills, how can you be effective in making that happen? Those needs are at a level too deep to be reached by specs, Photoshop files, or usability reports. You may need to become a student of your company’s business, project and development process, in the same way that you study the habits of your users. Design happens at many levels, any the more active you are at examining them, the more successful you’ll be at making positive changes.