Issue 21 \\ Read past issues Issue 21 // Teams Vibes. Gut feeling. Instinct. These are fairly common terms we use to describe the process of assessing and evaluating people and situations. When we lived in caves and our toughest engineering feats revolved around fire and shelter, these instincts kept us aliveâ€”like other animals, we could ascertain friend or foe from the subtleties of a situation. In his best-selling book Blink, Malcolm Gladwell tackles these quick judgements in his description of "thin-slicing"â€”our innate ability to make spontaneous decisions even with a dearth of time, research, and preparation.



Building a team calls for a careful mix of rigor and intuition. Skills and experience will get someone in the door, but thin-slicing accounts for a good deal of the assessment. Once someone is "in the door," you have to ascertain if this person will grow or shrink, sink or swim, pull everyone up or drag them down.



In this issue our UX lead Aarron Walter tackles the skill seeking, personality sussing, and crystal ball gazing that are part and parcel of building a team. We're also up for some awards, we're hosting a killer workshop, and we conclude with links from the world of UX. Tweet Share Forward to Friend We've been nominated! The MailChimp team has been nominated for two net awards this year. The competition is stiff and we'd love your vote!

Vote for redesign of the year Vote for team of the year Editing: Gregg Bernstein

Illustration: Caleb Andrews On Twitter: @MailChimpUX Building a UX Team

by by Aarron Walter User experience is such a nebulous term. Itâ€™s a container that can hold almost any disciplineâ€”research, design, development, even customer support could fit comfortably under the UX moniker. How do you build a UX team when the profiles of the team members are so vastly different?



Back in 2008, when the MailChimp UX team was just me, I had to be a generalist. I designed UIs, wrote front-end code, built prototypes, interviewed customers, and conducted usability tests. Working on so many different things early on helped me see how it all fits together, and shaped my views of the type of UX team I wanted to build.



I knew I wanted to build a team of thinkers and makers. In big companies, UX teams often focus on wireframes and workflows but donâ€™t have the power to design or build the UI. Things get lost in translation as ideas are passed to other teams. A team filled with specialists but no generalists creates silos and division. Siloing lengthens iteration cycles, causes entropy and confusion, and absolutely pollutes the user experience. The team I wanted to build would combine both generalists with a broad vision of the user experience and specialists that can hone in on the details.



Over the past six years, my team grew slowly and methodicallyâ€”someone to design, then someone to code, then someone to run usability tests, and on and on. Only these weren't just "someones"â€”these were folks who could contribute, inspire, and thrive. Weâ€™re small by designâ€”just 12 people strong. We have 4 design researchers, 2 UI designers, 4 front-end developers, 1 expert HTML email designer/developer, and myself. Small teams make communication easy and leave no room for dead weight. We each have to be strong contributors to the team, which in turn builds confidence in oneâ€™s colleagues. Collaboration is easier when you know youâ€™re working with smart, capable people.



When I think back to how our group grew, I derive a few key lessons about building a sharp UX team. These lessons aren't a magic formula, but they allowed us to combine a bit of rigor with a lot of intuition. Over time, these lessons empowered us to divide and conquer our workload and then regroup to collaborate.

Easy to Hire, Hard to Fire Hiring is hard. It sucks up so much time, and it often feels like youâ€™ll never find the right person for the job. Even though itâ€™s not fun, hiring is the most important job of anyone building a team, UX or otherwise. Itâ€™s easy to hire someone whoâ€™s mediocre, but itâ€™s really hard to fire them. Mediocre people are a drag on quality and moral, but they tend to do just enough good work to stick around. Managers have a tough time justifying letting them go because thereâ€™s no actionable offense. The scent of mediocrity on your team will also scare off talented candidates. Mediocrity is an albatross we tether ourselves to when we donâ€™t give the hiring process our full attention. â€œ If you hire people just because they can do a job, theyâ€™ll work for your money. But if you hire people who believe what you believe, theyâ€™ll work for you with blood and sweat and tears. â€ â€”Simon Sinek When you hire, look for skill fit, but donâ€™t make it your primary evaluation criteria. Look for passion, curiosity, personality fit, selflessness, openness, confidence, communication skills, emotional intelligence, and intrinsic motivation. These things canâ€™t be taught, but skills can.



It sounds a bit airy-fairy, but I always look for the right energy fit. I once interviewed a candidate and knew from his crushing handshake and deafening greeting that he would be too overbearing for my team. As the interview proceeded, my hunch was born out. This guyâ€™s energy was alpha, aggressive, and it would instantly crush the open collaboration in my team. We spend more time with our colleagues than we do our families. Why would we *not* listen to our gut when deciding with whom weâ€™ll work?



When building a new UX team, your instincts might draw you to industry rock stars. Unfortunately, rock stars often struggle to collaborate and can intimidate colleagues (even when thatâ€™s not their intention). When hiring, ask yourself, Can this person say "we" instead of "me?" Can they let someone else have the glory? Can they put in their best work, then relinquish control to someone else to take it further? If yes, youâ€™ve got a strong candidate worth considering.

Respect Few things are as demoralizing as seeing your work mistreated. Researchers throw themselves into studies that uncover insights that can change a company, but their findings go unheeded. Designers labor over pixel-perfect UIs, but the build-out cuts corners. Developers write brilliant code, but the release gets spiked. You probably have a few stories of your own that sound very similarâ€”itâ€™s the stuff that resignation letters are made of.



This dynamic is bad for individuals, teams, and for the companies they serve. So why does it happen? Itâ€™s simple: thereâ€™s a lack of respect for peers and their contributions.



Respect comes when we take time to understand one another and our areas of expertise. Specialists that have mastered their craft are ineffective if they donâ€™t have a general understanding of how their contribution relates to those of their colleagues. Great designers understand engineering enough to empathize with the people who will build what they design. Theyâ€™ll listen and make changes when a developer points out technical problems with a UI. Conversely, great developers see value in making an app as usable as it is powerful. Theyâ€™re willing to go the extra mile (within reason) to make a UI a little more elegant, a little more efficient for users.



Respect between design and development is the most critical ingredient when making great products. Itâ€™s rare that respect between design and development happens organically. It has to be a core value of a company, demonstrated by leadership daily.



Respect fosters a can-do attitude. Ideas are freely shared when theyâ€™re valued by colleagues, even when theyâ€™re not necessarily a winner. We could do a lot better if we started with â€œYes, and..â€ instead of â€œNo.â€

Autonomy Even when operating in a respectful environment, teams can become demoralized when they have to beg for permission. Itâ€™s hard to experiment if you have to get sign-off first, and itâ€™s hard to make giant leaps forward if you donâ€™t experiment. If failure is not an option in your organization, then neither is success.



Teams need autonomy to make decisions quickly, to follow their gut, and to explore. Autonomy empowers people to do their best work on tight deadlines and with limited resources. Hire great people, provide vision, then get the hell out of their way. Sooner or later, we have to trust each other.



Our UX team is tiny. Twelve of us do the research, design the UI, and build the front-end of the app. The engineering team we work with is equally small. But our size is not a shortcoming; itâ€™s an advantage. Communication is easy when teams are small. Planning happens quickly so we can get back to making.



Each little team has the autonomy to make decisions about their work, and when thereâ€™s uncertainty, they can go discuss with another autonomous team that can provide more definitive direction.



There is a balance to be struck, though. Absolute autonomy can lead to chaos. Though each team operates independently like a cell, we never forget that weâ€™re part of a larger organism. Our decisions often affect the work happening in other teams. When big decisions need to be made (like redesigning the app), team autonomy has to give way to the perspective of the whole company.



Meetings are often vilified, but thereâ€™s great value in short, regularly scheduled meetings. Independent individuals in autonomous teams need to be aware of the activities of colleagues. A quick round table report of what everyoneâ€™s working on creates opportunity to collaborate, and inform. Brief chats in the hallway or by the espresso machine are equally as effective at keeping people moving on a common trajectory.

Parallel Cycles Lean and Agile methodologies are the religion of technology companies trying to gain competitive advantage by iterating quickly on their products. The problem is, too often fast iteration happens at the expense of research. Things get done fast, but theyâ€™re not always the right things.



The MailChimp team is agile and lean, but in lowercase. While we believe in many of the tenets of these methodologies, weâ€™re never keen to subscribe to dogma. We move fast and fix things. That pretty much sums up our beliefs.



For a while we tried to tie the research workflow to the five week release cycle that UI design, front-end devs, and engineering follow. That works okay when doing usability testing to find areas to refine, but itâ€™s too great a restriction for deeper studies.



The design research team is often engaged in long-term studies about key issues that might shape company strategy or make us rethink pieces of the app. The work requires lots of customer interviews, surveys, ethnographic research, and most of all, time. The work cycle for deep research is considerably longer, and happens in parallel to the rapid cycles of app development.



Though the two cycles operate autonomously, the work of the teams has to remain connected. Research that goes unapplied is of little value. Rather than waiting for months to report back their findings, the research team shares salient insights with designers and developers as they find them. They share not expecting immediate action, but simply to provide context and meaning to the work already underway.



When big studies are completed, we talk about how to fit recommendations into the roadmap. Having in-depth research continually trickling into rapid iteration cycles helps ensure weâ€™re not only moving fast, but weâ€™re also moving in the right direction.

Create a Culture of Empathy â€œ The best product companies in the world have figured out how to make constant quality improvements part of their essential DNA. â€ â€”Phil Libin Making new features is fun. Fixing bugs and refining workflows is not. But to make a great product, you have to do both with equal measures of enthusiasm.



Refinement work requires a bit of motivation, and nothing is more motivating than watching users struggle with your app. From time to time we invite users to the office to conduct usability tests. The UX, engineering, and QA teams watch real customers doing real work in MailChimp, and we squirm in our seats as they struggle. The outcome of these tests is always the same: weâ€™re made so uncomfortable that weâ€™re compelled to make things better immediately.



We also do remote usability testing, conduct in-person customer interviews, answer some support related tweets, and read thousands of account closing surveys and customer feedback emails. The research team is largely responsible for this sort of work, but even the front-end devs visit customers in-person to watch them use the app.



As your customersâ€™ experience becomes more visible, your team will become more empathetic. Theyâ€™ll not only be motivated to refine, theyâ€™ll do it with speed, passion, and without being asked.

Tell Stories Turning research documents into short videos makes the findings more accessible to the whole company. When we started to fold design research into our UX practice, I thought it was enough to collect the findings, and make recommendations. But I was wrong. Research cannot create change in an organization until itâ€™s turned into a compelling story.



Weâ€™ve been known to write fifty page documents filled with interesting insights about our customers and how they use our app. Itâ€™s stuff that can help us make a better product, and could shape the direction of the company, but very few people are willing to pour over giant tomes of research. Itâ€™s time consumingâ€”and letâ€™s be honestâ€”itâ€™s not much fun. On our quest to understand how we can make our customersâ€™ experience better, why not do the same for our colleagues?



Weâ€™re experimenting with creative ways to turn high-level findings into posters, videos, and elegant web page layouts. In these forms, our research can be grokked in seconds, and shared easily between teams. Research is much more influential when itâ€™s made accessible to others.

Conclusion In all truth, building and managing a UX team is something Iâ€™m still trying to figure out. From what Iâ€™ve heard from other UX team leaders, Iâ€™m not the only one fumbling in the dark for answers.



In our industry, it seems like we know a lot about how to do research, design, and develop, but not a lot about how to sync it all up. Making these three crafts operate in harmony is what this nebulous user experience craft is all about, I suppose.



While the magic formula for leading a UX team still eludes me, I do know this: when smart, capable people with complimentary skills are united by a deep desire to help customers, you can create great things and have an awful lot of fun along the way. Switch Workshop at MailChimp To help customers requires an understanding of why they come to you in the first place, and why they leave. MailChimp is excited to host the Switch Workshop on March 6, 2014 at our Atlanta headquarters. Youâ€™ll participate in live customer interviews.

Youâ€™ll learn new techniques for unearthing the deep insights that most companies never bother to dig up.

Youâ€™ll understand why people switch from one product to another and how you can increase the odds that the switch goes your way.

And youâ€™ll be able to put everything you learned to immediate use. Seats are limited to 32 people, and tickets go fast. For our UX Newsletter subscribers, we're happy to provide a discount of $100 off the price of admission. At checkout, enter the promotional code THE-UX. Sign up for the Switch UX Around The Web We've joined the W3C's new HTML for email Community Group. If you think HTML in email can be improved, you should join too!

Seth Godin's Self service requires information, which requires design has been on our minds lately.

Tim Berners-Lee urges the public to re-decentralise the web.

There are lots of quotable points in Move Over Product Design, UX Is The Future.

Joel Marsh just wrapped up his Daily UX Crash Course â€” 31 short tutorials to get more people started in User Experience Design.

We're currently drooling over the minimal design and nuanced interactions of Peek Calendar. Ask Us Anything After Issue 20, Atticus Q. Redghost, Esq. of Evil Supply Co. replied to say, Your amazing research enables me to continue the war against the forces of Light and Good.



We didn't reply because, well, we just didn't know what to say to a self-proclaimed, professional villain. We want this newsletter to be a dialogue. If you have questions for the MailChimp UX team about what events we're attending next, what's in our coffee grinder, or even what the DesignLab currently has on our Krog Street billboard, send them in! Seriously: hit reply and ask us anything. We'll try to answer every email and maybe even share our conversation in future newsletters.