case study
Designing in a Team:
Skills, Attitudes, and Success
Last week Cameron sent an e-mail to gather some ideas about how to succeed as an in-house designer. Aside from the more obvious (and individual) necessities of technical skill, graphical ability, and general smarts, how do you succeed in a team environment, where people have different ideas, biases, and approaches to meeting the team’s common goals?
In thinking about this, I focused on the following questions from Cameron:
- What soft skills are important to our craft and why?
- What does it take to overcome obstacles, make concessions, and push through a successful project?
- How do you define “successful” when you have to make concessions on your preferred design?
What follows is a moderately more polished version of my response to Cameron.
“Skills” vs. “Attitudes”
When we talk about “having skills,” we are really talking about proficiency at manipulation—whether of the medium, of our tools, or of the people we work with. If someone says I have “people skills” or “soft skills,” they might mean I am a good manipulator; I can apply my “skills” in such a way to make others behave the way I want them to. This Machiavellian approach might get results… but there is no guarantee they will be the right results for the customer or end user.
So while soft skills are important, I think motivations and attitudes are even more important, at least if you are really in it for the proverbial Greater Good. Hence my focus below is as much on attitudes as on actions, or skills.
Develop humility
This attitude enters in to almost all of the other points I mention below. “What is right” is more important than “Who is right.” This perspective is core because without it, you hold on to the wrong ideas, or hold on too tightly to the right ones, without being able to see successful variations that might meet more needs, or the same needs better. Executing perfectly on the wrong idea is worse than executing “just OK” on the perfect idea.
Look for the good
By this I do not strictly mean optimism, though that is certainly helpful. Rather I mean actively searching for what is right in my co-workers and their ideas, instead of looking for what is wrong with them or their ideas, or focusing overmuch on my own ideas.
For example, find the kernel of truth or value in a co-workers “bad” idea or criticism, rather than tossing it out because the way it was communicated was not precise, or aesthetically pleasing, or 100% user-focused—or whatever. I frequently find that even when I do not fully agree, I am able to refine my understanding of problems and possibilities when I get past my knee-jerk reactions and look for the good. Every idea (including your own) has pros and cons; honestly examining alternatives not only improves your own decision-making, but also builds political capital that you may need down the road. Stakeholders can see that you are really weighing their ideas rather than shutting down the ones you don’t like. Later on, they may extend you the same courtesy, to everyone’s benefit.
I think it is also important to look for the positive motives of your co-workers, even when you think their idea or approach is wrong. This is easier to do here at the Church where I find it much easier to believe that everyone means well and wants the end product to serve real needs, more than they care about how they come out looking or some other hidden agenda. But I find this is a good approach in any situation, because when you treat people like they care about the right things, I find that many of them truly start to care about the right things. If on the other hand you assume others are motivated by self-interest or some other negative agenda, it quickly poisons team dynamics, creating a self-fulfilling prophecy where each team member assumes the worst—and sure enough, gets the worst.
Think “Synergy,” not “Compromise”
“Compromise,” implies that someone gets something they really don’t like, but are willing to put up with. I prefer to think in terms of synergy. Working together, the whole team can come to see what is rock-bottom required, vs. nice-to-have, vs. not-really-that-important. This requires aligning to the same goals; if team members don’t have the same vision, they will naturally feel that deviation from their own vision is to some degree a failure. If we work instead toward building a common vision, then priorities start to align and most conflicts smooth out with sufficient communication.
“Making a concession” should mean that the team together agrees than X is truly less important than Y, or that approach A will really meet the core need better than approach B—even if there are other (less important) advantages to approach B. There are of course times when one discipline or another has to make a decision contrary to the consensus, because they have that stewardship and have to be accountable. But if that trump card is played too often, morale goes down, team members retreat to their own domains, and silos get erected. Far better to persuade than compel (see Doctrine and Covenants 121:39-46).
Success is when the customer is happy
Customer happiness is highly correlated with whether they feel “listened to,” and that in turn has a high correlation with whether they can see their ideas filtered through your design process and manifested in the product. That doesn’t mean that the customer designs the product, but it does mean that they can see their concerns and ideas have been addressed. Good communication skills help, but you must also be able to transform what you hear into what you design.
This matters more than met timelines, executing exactly to plan, or anything else. Failing on those measures could certainly affect customer satisfaction, but it is important to me not to confuse those things with the ultimate goal, which is people happier using your product than they were before. The more happy, the better.
Wear the hat that needs wearing
Each project and team is different, even in-house. So wear the right hat for the job, and don’t get too used to your favorite one:
- You may need to focus on one area of design more than another (mapping the workflow, or graphic design, or interaction design, or typography, or whatever) depending on project needs.
- Maybe you should let someone else (like a front-end developer who is an HTML, CSS, and javascript wiz) run with the technical side of things while you focus on interaction design.
- Sometimes, for the good of the project, you can pick up the slack in areas where other roles are typically primary (business analysis and project management come to mind). This might be because that role is not represented on the team, or because the person in that role is still growing into it. Don’t run rough-shod over them, but offer help, accept delegated assignments, help them succeed— because in the end, it is not the “interaction design” or “project management” or “data architecture” that earns accolades or dissatisfaction. It’s the product as a whole.
That’s how I see it. What do you think?