MailChimp UX team: Creativity and road maps [7th part of the book]

[ Tl; dr ]

[ 1st part of the book ]
[ 2nd part of the book ]
[ 3rd part of the book ]
[ 4th part of the book ]
[ 5th part of the book ]
[ 6th part of the book ]
[ 8th part of the book ]
')

Creativity and front end

Jason Beard

In the UX Newsletter, we often wrote about our template library and how it helps us perform quick iterations and ensure consistency of MailChimp's work. Developing on the basis of existing patterns is a bit like a game with Lego: when you start work, you know exactly how certain elements should communicate with each other - but sometimes it turns out to be useful to break the pattern and create an unusual solution. I would like to share a few examples of how this approach was implemented in MailChimp.

Text alignment icons



We had to add icons to align left, right, center, and width. I could just add 4 new icons to our set , but that would be too easy. I decided to approach the question creatively and created them in CSS. Using the CSS Shapes extension is a common practice, but such shapes are usually created by adding background colors to the modified elements. Instead, I used aligned dashes (long and medium) as pseudo-elements to enable them to inherit the size and color of the text in the same way as with other icons from our set. It was fun and took only a few lines in CSS (demo version of icons in Codepen ).

Animated clock icons



A more complex example of front-end creativity was the result of a single tweet. Mardav decided that a personal challenge for him would be Terry Blancpain’s proposal : “Considering their amazing copywriting, I’m a little disappointed that the icons for“ deferred ”MailChimp campaigns do not reflect the real-time sending of letters.”

Mardav had been tinkering around for some time in a JavaScript library called D3.js , which is usually used for complex graphs and data visualization. We have already planned to start using D3 for creating graphs, so the exercise with the clock icon was an excellent warm-up. Mardav made a prototype, and with the help of our amazing development team, it was turned into a custom Dojo widget that we use in many elements of our application.

If you now set the distribution time at 13:45 or 7:30, the clock icon will reflect this time.

We did not think that users would notice this funny detail, and were very pleasantly surprised when told about it in Little Big Details . Thanks for the idea, Terry (demo version of hours in Codepen ).

Animated GIF for new users



We have always used video tutorials to teach new users how MailChimp works. Most of these videos last no more than 2 minutes, but we found that in some cases we need even less time for our goals - just a few seconds. Animated GIFs are great for this, so since our redesign in 2013 we use them as needed to show how new interface elements work.

Unfortunately, if the video of the screen is saved in GIF format in Photoshop, the size of the resulting file can be quite large. When Federico created a series of short clips as part of the process of “organizational socialization” of our new editor, it turned out that even with the use of quite aggressive compression settings, the files took up more than 1MB. This is quite a bit for the video, but a bit too much for a quick animated tutorial. Therefore, he began to look for other examples of screencasting in GIF format and accidentally stumbled upon a letter from the platform for working with photo Exposure .

2 GIF-files from the letter Exposure, containing photo content, were created under the retina display and weighed only 171KB and 401KB. Federico asked Luke Beard (Exposure Luke Beard) that they used to achieve this, and he replied: "Only the best - cockos.com/licecap ."

At first we decided that it was funny: the site looked as if it had been created in the 90s, and since then nothing has changed there, and the company that made it chose the name “Cockos Inc.”, not to mention the product under the name “Licecap” (phew!) - all this did not inspire us any confidence that this would work. But under the unattractive title, free software was hidden, so Federico decided to try and overwrite the GIF file - and instead of 1MB it began to occupy only 182KB. The problem was solved (Thank you, Luke, and forgive me for doubting you).

Do not be afraid to spend a little more time thinking about possible solutions.

Budgets and deadlines sometimes make us incline to the most obvious solution to the problem, but this should not always be the case. Next time when you work on the front-end task, try to consider other solutions. Do something unusual. Use any opportunity to apply new technology and technology, especially if it can please your users. And do not be afraid to find out how someone else solved the same problem — you never know how new skills can be learned in this way.

Release cycles and roadmaps

Federico Holgado

We at MailChimp have to move forward quickly — this applies to the things we work on and the way we work. We need to bring projects into the plan that we can accomplish efficiently, and at every moment in time do the right things. If you combine the right ideas with a reliable and at the same time flexible software development process, you will be able to achieve really high speed work.

Our release cycle is constantly evolving, but right now it takes 5 weeks: 4 weeks to develop new features and 1 week to freeze and assess quality. We limit the time of developers to avoid the temptation to create monolithic solutions that can lead to serious problems in the work of MailChimp. Compared to solutions that are developed for half a year or a year, our 4-week projects are much smaller in volume, and testing them is much easier. In addition, due to time constraints, we prefer to work with more manageable and less “visionary” tasks. But it was not always so.

The old approach: planning for the occasion

When I first started managing releases in the MailChimp development department, updates were usually designed and developed in a single release release cycle. At that time, one cycle took 4 weeks instead of 5 - this meant that we had only a week to create a design, which we could send to UX-designers and developers. When design and development are carried out in one cycle, it becomes difficult to prepare for this morally: the details are missed, the volume and time increase for unknown reasons, all this makes the work more nervous. In addition, it was quite difficult to abandon the idea of ​​making interim releases, because we had to go back to designing again and again.

New way: we know what will happen next

Things have changed a bit since those early days of release planning. One of our last goals was to improve our understanding of our next steps. Now we strive to "dissolve" the processes of development and design. Programmers and CEOs feel much more comfortable knowing that they take on the development of an important function only after they have been thoroughly studied by UX designers, designers and developers - this approach allows us to find as many flaws as possible in the original idea and correct them.

Major tasks are now designed with the involvement of developers, providing valuable insights to designers from the very start of the cycle. Involving them in the design process at the earliest stages means that we are less likely to waste energy on thinking about ideas that simply cannot be realized. It turned out that we have several amazing programmers who are no less useful than UX designers when it comes to generating ideas, discussing the progress of the work and the functions of the product (I did not immediately understand it!).

Correct goal setting

Rapid progress means that every effort you make to accomplish a task should contribute to the work. We have to carefully evaluate what we undertake, because abandoning an idea costs us a lot of time. The only way to quickly come to an agreement on what to develop is to talk to those who can best help us answer this question. Usually we are worried about the following things: “Is it possible to realize this idea?”, “Is it right to do this right now?”, And the most important question: “Is it worth it to do this at all?”

To release this release, I collect MailChimp chief engineer Eric Münz (Erick Muntz) and our CEO, Ben Chestnut (Ben Chestnut), to discuss possible features and improvements that we can undertake. Sometimes ideas come from research and projects of the UX-team, sometimes they are based on the findings of programmers, sometimes new ideas are thrown by Ben himself, who often communicates with clients. The three of us think over the high-level functionality and try to estimate the amount of work relative to the chosen direction. We try to answer the same questions, discussing every new big idea.

The key is that let this and high-level ideas, but they are based on those things that we have been thinking about for some time. For example, we decided to add the ability to comment and collaborate in MailChimp many months after the launch of the application, which we called OnStage, and which duplicated some of the functionality we were interested in. We figured out what worked well on OnStage, and what didn’t really, used these ideas and included them in the MailChimp improvement plan. As soon as we decided to bring it to life, we were immediately able to formulate what we want to do - this allowed us to focus our efforts and quickly release an important update, which, as we knew, would definitely work.

If we turned the wrong way

Sometimes, of course, what we are developing does not reach the final release. If we understand that we “turned the wrong way”, we decide to stop working as early as possible, so that we can quickly transfer resources to other tasks. Usually, if we stop working on a task over which we have already begun work, the cause of what is happening is the lack of time, and not the wrong choice of direction. Whenever we decide to stop development, we add what we have done, to the “parts basket”, to other projects that we can revive at any moment.

So let's do something.

Below is a more detailed overview of what it means to work in a five-week development cycle. For me, this process is akin to writing coursework at a university: in the beginning it seems to me that I have a lot of time; then I begin to realize how much I have to do and on the last night before the deadline I’m trying hard to write a good job.

1 week: release and planning

We have spent the last couple of days deploying the code since the last release. We constantly communicate with the support team, check Twitter and mail in order to learn feedback as soon as possible and react quickly in response. We probably missed a couple of bugs that need to be fixed in the first couple of days after the release. We are talking and trying to determine what to do during the next cycle and we are holding our meeting on the latest release this week.

2 week: more planning and a bit of development

We, as a rule, have a couple of tasks from the previous cycle, which we can immediately tackle while we solve issues related to the design details of large projects, which we will work on in subsequent release cycles. Sometimes, if we end up working on a design, we take on new tasks.

3 week: we pretend that we are developing something

Here things start to take shape. During this period, we communicate a lot and try to outline the details of the implementation of the new functionality.

4 week: really developing

We are approaching deadline. It's time to start developing.

Week 5: freezing! Planning again

Every time we want to completely “freeze” the development in the last week before the release, but our quality assessment team works so well and finds so many bugs and errors that only this week our work finally gets a finished look.

I have heard stories about companies that force entire teams to engage in development only to minimize the project at the last minute. Stopping the work of an entire team is perhaps the most demoralizing thing that can be done with people involved in programming, not to mention the fact that it is completely unproductive. We do our best to carefully carry out what we subscribe to. We respect the time and energy that our teams invest in what they do - but, in addition, we like this exciting feeling of speed.