Close (X)

Blog

Email Marketing, Business & Monkeys

Inside the MailChimp Interface Design Process

May 8th, 2009 | by Aarron

sketches of interface ideas

sketches of interface ideas

We’re a bit fanatical about user experience and interface design here at MailChimp because we know that no matter how many fancy new features we dream up, they’re no good if they aren’t easy to use and relevant to the needs of our users. Our philosophy is that a great user experience is a feature itself. It’s kind of the secret sauce that makes MailChimp stand out from the crowd.

How We Work

When we start planning for a new feature, we first try to identify user goals, and the tasks that have to be completed to reach those goals. For example, we recently added Autoresponders to the app, which required some research into how people want to use them in their email marketing workflow. Across the board people said they just wanted some basic automation to save time, and they wanted to stay in touch with their audience while making messages more customized and timely to a situation.

We identified the most common situations in which users would want to send automatic messages (on birthdays, anniversaries, after signup, etc.), pinned that to the wall, then proceeded to break down each subtask required to create an autoresponder with the least amount of effort.

Prototyping

autoresponders prototype

autoresponders prototype

There’s actually a lot of complexity involved in setting up an autoresponser. If you pick certain options the interface has to react to the new context. For example if you want to send an email to new subscribers upon sign up, the interface shouldn’t let you send before that time because that doesn’t make a lot of sense (we can’t predict future sign ups you know – yet). In order to sort out all of the different contingencies in the interface, wireframes and sketches just weren’t going to cut the mustard. We had to build a quick prototype so we could play with it and really wrap our heads around how it would behave in different use cases.

We build our prototypes using HTML, Bluprint (a CSS framework), our own custom CSS framework, and jQuery (a JavaScript framework) to simulate fancy animated interactions. Frameworks help us build really fast and generate interfaces that act very much like the real application would.

When a new prototype is built, we usually pile into my office and kick the tires, discussing all use cases and how to refine the interface so users can accomplish their goals as quickly as possible. This is useful for our engineering team too, as they can tell us what sorts of challenges they’ll face when building it. This is usually where I say, “it should work this way, can we do that?”. Then Chad, our lead engineer, almost always says, “Yah, we can do that”, which is music to the ears of any user experience designer.

Wireframes

A wireframe that didn't make the cut.

A wireframe in OmniGraffle - this concept didn't make the cut.

We create wireframes to concept simpler interfaces that might only require static forms and some well written copy. Wireframes are simple drawings of an interface that are entirely focused on the inventory and organization of elements in an interface. They don’t illustrate color, typography, grid layout, or other visual design bits. They help you focus in on solving user tasks, and because they are so simple, they can be quickly created to flesh out ideas, then iterated upon to refine an interface. We do a lot of wireframes just with pencil and paper first, then get a bit more detailed using OmniGraffle – a popular wireframing tool with interaction designers.

Launch, Get Feedback, Refine Some More

After we launch new features, we work very closely with our Customer Service team to identify where users are struggling so we can solve usability problems quickly. Customer Service and User Experience teams really must have a tight relationship, because they help one another solve their respective problems. Customer Service identifies patterns in support tickets, which might indicate a usability shortcoming in the app. They then pass that over to the User Experience team who identify the underlying problem, refine the interface, update the app, then stay in touch with Customer Service to see if the problem has been resolved. It’s fun to watch the results of interface refinements, because if the problem was really solved, the flood of support requests coming in will shut off like a faucet, and Customer Service can take an Xbox break.

When time does not permit a detailed usability study for each tiny new feature, collaboration with Customer Service is essential to ironing out the kinks fast. We’re always refining the application interface to remove what’s unnecessary, make language and labels intuitive, and ensure that each task can be completed with the least amount of effort. We want your experience with MailChimp to be fast, easy, and fun.

Have some ideas of your own on how we can improve the interface? Please get in touch!

Spread the monkey love:
  • TwitThis
  • Digg
  • Facebook
  • del.icio.us
  • Reddit
  • StumbleUpon
  • description
  • Google
  • LinkedIn
  • Ma.gnolia
  • MisterWong
  • Netvouz
  • NewsVine
  • Slashdot
  • Technorati
  • YahooMyWeb
  • BlinkList
  • Design Float
  • Mixx
  • Pownce
  • Propeller
  • Webnews.de

10 Comments

    • Jon Lackey @zuno says:

      Nice post. It’s always good to see the insights of good companies. Thanks for sharing!

    • Chris G says:

      great post. thanks for sharing.

    • Eric Rasch says:

      Nice writeup! I noticed you’re using Mercurial for your source control. What are your thoughts on using it (vs. SVN/CVS/Git) as part of your process? I’m not trying to start a Mac vs. PC type of argument… I honestly want to know since I’m looking at implementing a system for my team and this is the first I’ve heard of Mercurial.

      • Chad says:

        To add to Aarron’s comment, the primary benefit of using Mercurial over SVN/CVS is that is adds tons of flexibility in how our developers branch and reintegrate new features into the codebase. It also does much better with merging over changes without conflict during releases. We also fell in love with BitBucket for hosting the master repository with an excellent interface. Git will behave almost exactly the same, but I found Mercurial’s language and approach slightly easier to understand and use.

        However, decentralized version control has a couple of issues. The team will tend to hold back changes longer, committing in bigger chunks. This is a good thing for keeping the repository clean and working, but bad if you’ve got somebody that commits locally but never pushes to the master. Also, because there’s no centralized timeline of commits, each developer will increasingly need to merge changes together as a part of normal development, filling the commit log with empty merge commits.

        Hope this helps.

    • Aarron says:

      We like Mercurial because it lets us all commit to our local copies, even when we have no internet connection, then we can merge back to the main repository. We find we get fewer conflicts with Mercurial because of the general workflow.

      We’ve used SVN and liked that okay as well. Our designers liked it a little bit better because they could use Versions (http://versionsapp.com) rather than a command line to manage their local copy.

    • Nancy says:

      I am a new user of Mailchimp and really appreciate your good work! Suggestion: in “Form Design” page, the user interface implies one can build and design each of the different forms. In fact, it only applies to the Subscribe Page. The left blue box called “forms & response emails” has a drop-down menu below it and arrow to the right. Makes user feel one needs only to choose the form, and then design it. I’d love that! Thanks.

    • Aarron Walter says:

      @Nancy – thanks for the feedback. Maybe I’m misunderstanding your suggestion, but that is in fact the way the interface works. Could you clarify?

      • Nancy says:

        Hi Aarron – thanks for your reply. When I try to add a multiple choice, mini-survey on our UNSUBSCRIBE page, it places “radio buttons” etc. on the SUBSCRIBE page. I went to Live Support and Raul confirmed for me that one cannot add these design features on anything but the SUBSCR page. Please advise. Thanks!

        • Aarron Walter says:

          I see. Yup, right now you can’t do that on the unsub page, but we might add that feature in a future version. Thanks for that feedback.

          You are right that the interface is actually misleading in that spot. Either way, we’ll do our best to clarify and improve.

    • mrdata says:

      what’s the difference between designing prototypes using HTML or Photoshop?

      It’s a fact that using HTML you save time on coding hours, but, don’t you have to get back to Photoshop to design shapes and colors?

Leave a Reply

* indicated required
http://www.mailchimp.com/nonrestrictiveocean.php