|
|
|
|
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.
|
|
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!
|
|
|
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.â€
|
|
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.
|
|
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.â€
|
|
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.
|
|
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.â€
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
|
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.
|
|
|
|
|
|
|
