Issue 30 // Ready, Set, Build

In his talk, "From Muppets to Mastery,Russ Unger shared core UX principles embodied by the life of Jim Henson. Russ explained how sketching and prototyping were a constant part of Mr. Henson's thinking process and how he continually iterated on his work, hacked things together, and—most importantly—made things up as he went along.

In this issue, the UX Dev team (AKA: Dozers) give an in-depth look at how we live out those ideas at MailChimp. Federico Holgado explains how a new feature makes the journey from rough concept to production code. Jason Beaird follows up with a justification for the "UX Developer" job title. As always, we wrap up with a few great links we've discovered since the last issue.
Forward to Friend
Editors: Laurissa Wolfram-Hvass, Aarron Walter, Gregg Bernstein
Artwork: Michaela Moore
On Twitter: @MailChimpUX

From Idea to Product

by Federico Holgado
The process of refining ideas is one of my favorite parts of what we do. I love hashing out the approach to a problem, then nailing down the details. From uncertainty comes clarity. From research findings, products and features emerge that solve real problems for the people that use them. 

Traversing the path from idea to product can be an unpredictable journey—it certainly was for us as we fleshed out our new Automation platform. Insights gathered from countless interviews helped us see the value of automation to our customers and many of the use cases, but there were still a lot of questions to be answered as we began the refinement process.

The idea: By providing workflows that align with how people work, we could make automation “for the people."


Talking gets you started

It took a couple of months and many discussions between UX, Research, Support, and Engineering to conceptualize a feasible automation product. At first, without clear guidelines or concrete goals, it was a nebulous and difficult topic to talk about. What workflows could we create? Is it possible to generalize the way people automate a business function? Where do we even start?

After talking, and talking, and thinking, and talking some more, the pieces of the automation puzzle started coming together—our ideas focused into a shared vision, pushing us from discussion to action.
When your idea feels unclear, it means you need to talk more. Use your team members to help you gain clarity, and don’t stop until you've reached the “aha!” moment.

Learn from the past

When redesigning a feature, it’s important to audit the current iteration to avoid repeating mistakes. We took our automation workflows idea as an opportunity to become intimately familiar with how our Autoresponders worked and pinpoint what was great and lacking. The UX design team spent several days experimenting, talking with engineering, and looking at existing code. We learned what functionality already existed in the app that we could use as a base for the new Automation feature.

We also had to explore how people were using the existing Autoresponder feature, and found that use cases ranged from extremely simplistic welcome emails to intricate webs of logic and conditions that triggered Autoresponders from website and email activity. Doing our homework helps us weigh our design decisions against the potential effects they might have on existing users.
Learn from what already exists. History is a valuable resource.

Rationalize the present

Our old Autoresponders had some very specific limitations based on constraints at the time they were built. Part of our job was to understand those limitations and overcome them while building the new system.

We also had to rationalize how those limitations affected the way people used existing Autoresponders. People use our tools in unexpected ways, creating workarounds to accomplish goals we didn’t initially consider. These outliers helped us discover better ways of doing things when we rebuilt Autoresponders as Automation.

Another important source of information was the vast quantity of feedback we received from our users over the years. For example, we knew people had a hard time visualizing the path a subscriber took from one email in a series to the next with our Autoresponders. We learned this and more by talking with the UX research team, reading through their reports, and looking at some historical data from the support team.
Gain context by understanding why past decisions were made and questioning all previous assumptions. 

Attempt to rationalize the future

Armed with a deeper understanding of our Autoresponders and how people use them, we started to brainstorm. We knew our Autoresponders could be triggered by many different actions within MailChimp. We also knew that we wanted to give people the ability to visualize their business logic in one single place. As we filtered through the possibilities, we began to see where our ideas and existing features overlapped.

The truth is, nobody on the UX dev team is a marketing wiz, so we turned to our Marketing and UX research teams and asked them to help us come up with a list of “automation workflows” based on user feedback—like welcome messages, onboarding series, and event reminders. This list reminded us of what our customers actually need and kept us focused throughout the project.
Ask the right people (or teams) with domain expertise to help shape your concept.
The initial list of automation workflow ideas that we got from our marketing team.

Musts, nice-to-haves, and somedays

Our list of workflows contained a lot of great ideas, and we could tell right away that some of them were going to be really easy to build, while others would be a major effort. A fast way to prioritize ideas is dividing them into groups of “must have,” “nice-to-have,” and “ someday.” These lists help us focus on the important (and feasible) ideas, and put off the other stuff for later.

The “somedays” are pie-in-the-sky ideas that are often really hard to build—we don’t want to even spend time considering them for a first iteration. The “musts” and “nice-to-haves” are the bulk of usable ideas. Along with our new ideas, we are careful to prioritize existing functionality as a "must have," so it doesn't fall through the cracks. Taking away existing functionality can be extremely painful for customers. 

It’s important to remember that these lists aren’t necessarily set in stone—they’ll shift over the course of a project. You might find that ideas move between the “must have” and “nice-to-have” groups on a regular basis. Things you thought would be easy to build turn out to be more challenging, or vice-versa.

You also might find that a "someday" item you originally put off might turn out to be a “must-have.” Yes, this is frustrating. And no, there’s probably no way of avoiding it! We encountered this with the idea of time-based email triggers (like sending an email on a subscriber's birthday). We knew this would be hard and initially postponed working on it, but we later realized it was a critical feature—a “must have” for many people—and we scrambled at the last minute to make it work.
Prioritization is all about understanding feasibility. Your engineering team should be with you every step of the way, helping you make these decisions.

Making lists

A list can take many shapes or forms—a diagram, a map of relationships, a bunch of post-it notes, or a stack of sketches. For this project, we started by mapping out how our workflow ideas related to each other. The map was rough, but we were able to see which ideas logically fit together, which gave us a picture of how our new Automation feature would operate.

Once relationships between ideas start forming, it’s important to figure out how we might build those relationships out. We use patterns heavily for designing MailChimp, because they provide a consistent user experience and help us create things more quickly. Sometimes a new idea fits into an existing pattern easily. For example, we immediately recognized that a user’s process of building an automated email series fit well within our wizard pattern.
A list is the easiest way to prioritize a group of tasks. Organize ideas first, and the path to developing those ideas will become clearer.
The master list of workflows after being consolidated.

Sketches and wireframes

Next, we moved on to sketches. Sketching is our favorite way of thinking through ideas. It allows us to quickly build dozens of concepts without heavily investing in style, hierarchy, or presentation. We sketched different versions of each step of the Automation wizard, and after thinking through each workflow’s UI, we realized how similar some of them were. We ended up narrowing down the list from 30 or so workflows to 9 generic ones.

We arranged our sketches into an entire workflow on a rolling wall and used them to walk people through the process of creating an automated email series. In the early stages of an idea, when things can change quickly, sketches save a lot of time. It seemed like every time we ran someone through the process, they brought up something we had completely missed or offered a brilliant suggestion. Ripping out a drawing and creating a new one takes minutes, versus several hours in Photoshop or Sketch.

Since we had sketches we could point to, our engineering team had a really solid idea of what we were thinking. This meant that they could start working on the back-end of the feature, while the UX team fleshed out the visual details with Photoshop.
Stay at the sketching stage as long as possible to remain nimble and not too bound to your ideas.
A stack of wireframes that we hung up on a wall to help us visualize flow.

Interactivity is a valuable tool

Because this feature was so vast, we parallelized some of the design work and designed several steps of the Automation process at once. Some of the simpler pages came together quickly, but other parts took much more effort. We knew it would be a while until we had a functioning design to show anyone—but we really wanted feedback!

Early on (like during the sketching phase) precise details aren’t necessary; but as a project moves forward, visual elements and interactivity become more important. Michaela Moore, one of our UI designers, had experience building interactive prototypes with InVision and volunteered to put together an interactive prototype based on our comps. The prototype was an amazing way to share our progress. With the Invision prototype, people could click around and get a sense of how Automation would operate.

We also ended up using our prototype to explain the feature to our support team, so they would be ready to answer questions our customers might have after the release of the new design.
A picture is worth a thousand words. A functional prototype is worth a thousand comps.

Last second refinements

Often there are nagging issues you think you’ll solve later in a project, only to realize later that there’s a fundamental flaw in the design.

Shortly before shipping the Automation project, we discovered a section that was dense and prone to complex validation errors. Just three days before the release, a group from several teams gathered around a GeekDesk and decided that we needed to split the section into two steps. Thankfully, the UI was built with modularity in mind, and we were able to make the change quickly.
Always assume you forgot something big and plan accordingly.

A recurring theme

The keen reader will notice that at every step of the way, our design team works closely with another team to make decisions. We love to work fast, and in order to do that, we must share information and keep everyone in the loop—we talk early and often.

It’s tough to work on a complex programming problem while also stopping every ten minutes to answer an ever-growing list of questions, but it’s worth it. Our support and KB teams are also always hard at work, but they rally their troops at a moment’s notice to carefully listen to how a new feature works. We know the pain that comes from missing a key aspect of a feature far outweighs the cost of an interruption. 
The cost of change increases exponentially with time. Keeping everyone in the loop helps you figure out the most important details early—even if it means going slow in the beginning. Don’t worry, you’ll make up the time!

A product

Ultimately, there is no right path nor framework nor set of rules about where to start and where to end. But I hope getting a glimpse of how we do things at MailChimp will help you refine your own process.

Blurred Lines:
The Rise of the UX Developer

by Jason Beaird
The engineers call us designers. The UI designers call us developers. The research team calls us when they uncover changes to make in the application.

When I started at MailChimp 4½ years ago, my job title was User Experience Designer. Jumping from a career in web design and front-end development to a UX position meant catching up on essential skills like information architecture, content strategy, and user research—which were largely absent in the agency world. I've read books, gone to conferences, and participated in workshops on all things user experience. But even when our team was relatively small and we all wore a lot more hats, my primary role was front-end development. Over the years, the UX department here has grown steadily, and so has the need for developers with an applied understanding of user experience design practice. 
UX Devs
The MailChimp UX Dev Team: Jason, Federico, Mardav, and Alvaro
There are currently four devs on the UX team, along with two brilliant visual designers. While we all work together to plan UI changes, the four developers rarely push pixels around. Calling us all UX Designers is a bit misleading, as the developers rarely do big "D" design. UI Developer or Front-End Dev is more accurate, but it neglects the sensitivity and skills from the UX profession the we employ regularly.

There's also some ambiguity about whether or not we only work on the front-end. Our team is located in a big open room with our QA and Engineering departments, which has led to some great collaboration. Our pattern library has given the Engineers the freedom to do more on the front-end, and they've encouraged us to dive deeper into back-end development and advanced javascript.

In light of all this, I recently changed my title on LinkedIn from "Senior UX Designer" to "Senior UX Developer." 
Pro Tip: Don't ever change your job title on LinkedIn unless you want a flurry of undue congratulations.
Since then, I've come across a few articles from UX professionals I respect who are angry about the growing number of UX Developer job listings. I'm admittedly paraphrasing, but the controversy seems to be that the practice of user experience design is well established, and that "UX Developer" is just a trendy misnomer that will somehow dilute and tarnish the UX industry. Baloney. Just look at Center Centre's holistic curriculum to see that UX is a multi-disciplinary field with a lot to grok. 

It's a requirement that all MailChimp UX developers have a broad understanding of UX industry
 skill-sets, principles, and techniques. Speaking the same language is what allows us to fill in the gaps and get things done. In the end, what matters most isn't job titles, but the unique combination of skills people bring to the table, and how those skills fit together to solve problems we couldn't tackle individually. To quote our Director of UX, Aarron, from his article about building a UX team in Issue #21:
“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.” 
—Aarron Walter, MailChimp Director of UX

As a user experience designer who does far more coding than visual design, I'm proud to call myself a UX developer. If you are too, and would like to join our team here in Atlanta, we've got a fresh job posting with your name on it.

UX Around The Web

Ask Us Anything

We want this newsletter to be a dialogue. If you're curious about our thoughts on the force touch interaction, our ideas for Jonny Ive monologues, or even our team's phone size preferences, let us know. Seriously: hit reply and ask us anything. We'll try to answer every email and maybe even share our conversation in future newsletters.

© 2001-2014 All Rights Reserved.
MailChimp® is a registered trademark of The Rocket Science Group

view in browser   unsubscribe   update subscription preferences   

Email Marketing Powered by Mailchimp