"Why do we fall, sir? So that we can learn to pick ourselves up."

To introduce this issue, we're not above paraphrasing a line from arguably one of the finest pieces of modern literature: the screenplay for "Batman Begins." Making mistakes and overlooking details are part and parcel of software development. Try as we might, we're going to fall down from time to time. These falls are also opportunities: how do we respond in the aftermath? Do we learn from our mistakes, or hope that they go undiscovered?

In this issue, Design Researcher Gregg Bernstein explores how trust erodes when mistakes compound into serious experience gaps, and Developer Federico Holgado walks us through our removal—and hasty reinstatement—of plain-text email campaign editing. We conclude with links of interest from the world of UX.

I’ve judged books by covers, against the warnings from parents, teachers, and my own common sense. Yet I’d rationalize this decision with Olympic-level logic leaps:

– Fact: This cover looks amazing.
– Assumption: Likely, the author had the good sense to approve this design.
– Deduction: The author is smart and has great aesthetics.
– Ergo: This book must be well written.

I’d repeat this logical sleight-of-hand numerous times, and I was burned by my decisions more often than not.

These days, I repeat this pattern with apps, branding, and experience design. And just as the connection between the cover and the content is tenuous, so too is the relation between form and function. When the promise of a great experience is undermined by small imperfections, the experience—and our trust—erodes. Imperfection scales quickly.

A few years ago, I highlighted the disparity between Apple’s overall design sense and the presentation of their terms of service when installing software (http://www.fastcodesign.com/1665000/how-to-fix-the-nightmare-of-apples-terms-of-service). From the design of their website and apps to the layout of their stores, and from the packaging to the products, Apple exemplifies a consciousness about aesthetics. Yet they seemed to overlook a crucial touchpoint in their legal documents. Granted, it’s legalese; but why not make this as beautiful as every other facet of their brand? The incredibly cohesive Apple experience unravels just a hair when I install or update software. When each subsequent iOS update diminishes my battery life or makes my calendar more unusable, the imperfections mount and the experience erodes further.

These imperfections and anomalies are everywhere, and they scale. Take, for example, the handy smartphone apps that replace shopping rewards cards. I divide my grocery shopping between two large chains—Kroger and Sam's Club. Kroger offers a loyalty card, which earns me a discount in exchange for any sense of my privacy (I’m ok with this—kale is expensive). I swipe my card at checkout, and Kroger discounts my groceries. Easy enough.

The card takes up space in my wallet, and I was excited at the launch of the Kroger iOS app. The app promised to replace my card with a digital copy, which I could scan at checkout. Again, easy enough. Except that it wasn’t easy: the register couldn’t read the digital version of my loyalty card. And because I use self-checkout, help was not immediately available. The promise and outcome of the app weren’t aligning, and the imperfections were scaling quickly.

Finally, a cashier assisted me, and advised me that the digital cards are not compatible with the cash registers in use at Kroger—many customers have tried, and many customers have resorted to asking for help. By releasing an app that raised but did not meet expectations, Kroger had only succeeded in lowering the overall shopping experience for—and trust of—a number of their customers.

I went through this exact scenario again at Sam’s Club, where they offer low gasoline prices to members. Having replaced my card with their iOS app, I stopped by to gas up my car and found that the pumps don’t even have card readers. Puzzling, and frustrating. The attendant on duty actually laughed at me and my app, acknowledging that she had no way to scan it. No card, no gasoline, and an incredibly aggravating experience with an unhelpful store employee. Imperfection strikes again.

This is how bad experience goes from a one-off to an epidemic—the app that was supposed to empower me instead made me helpless; the staff now has to stop what they’re doing to assist me with something I should be doing on my own. The imperfections have a domino effect: if the staff is being taxed with unnecessary work, morale drops, and service worsens.

I continue to shop at Kroger and Sam’s Club, but I do so begrudgingly out of habit and convenience. Now that I’ve been burned by unmet expectations, I feel little loyalty to Kroger (ironic, considering the loyalty card started this whole chain of events) or Sam’s Club. If their respective apps had worked flawlessly, I would have taken pleasure in the novelty and convenience of no longer needing my card. Instead, I’m more likely to consider alternative stores where my perception isn’t diminished.

We see this scenario play out across industries: apps with killer marketing but little function; stores with great branding but poor quality; large musical events with tons of headliners but only three port-o-johns. And at MailChimp, we’re the first to admit that we’re not immune to these scaling imperfections. As Federico Holgado explains later in this issue, by removing a crucial step in building a campaign, we eroded trust and functionality in favor of what we assumed was a streamlined experience.

When trust is damaged, an opportunity exists to—if not make everything perfect—at least begin reparations. Late last year, FitBit launched the Force fitness tracker. The Force was an evolution of their previous products, and by all accounts they had nailed it: the product looked good, the software worked, and customers were happy. . .until they began to report skin irritations from wearing the band. At this point, FitBit had a choice: hope that the irritations were limited, and work with (literally) irritated customers on a case-by-case basis, or own up to the issue and announce that anyone with a Force could send it back for a replacement (which is what they did). The former would have been easier, but it would have shaken the faith of current and potential customers; the latter is a broad demonstration that FitBit wants to do right by the people who buy their products.

Kroger or Sam’s Club could have taken a cue from FitBit by having protocols in place at stores for customers with digital cards, or by emailing the folks who loaded their apps to explain that it might be best not to ditch the printed cards just yet.

Acknowledging the situation hurts, but maintaining imperfections hurts worse: customers will defect for the promise of a better experience elsewhere.

Looking at the current state of email, you'll be hard-pressed to find many mentions of plain-text emails. This holds true whether you're looking at an email through your iOS device (the most popular email client in the world right now), Android, Gmail, Outlook, etc. The bottom line is that the golden days of plain-text emails are numbered, and the majority of people just don't know what it means to send a "plain-text" version of an email. 

In the midst of observing Kirk struggle with the plain-text step, I had a revelation: I quickly theorized that there must be other people just like him, new MailChimp users who get to this step in the campaign wizard and have no clue what to do!

When I returned to the MailChimp office the next day, I excitedly shared my theory with MailChimp's lead engineer, Eric Muntz. After discussing it, he agreed that plain-text might not be that important anymore, but we needed some data to confirm this. Eric quickly got to work to see if we could tell whether anyone was significantly modifying the plain-text campaigns MailChimp automatically creates from the original HTML emails.

After crunching the numbers, we concluded that less than 1% of campaigns being sent through MailChimp had a manually edited version of the plain-text email and differed from what the app could have automatically generated. We took into account that this 1% also included folks who might have replicated a campaign, edited the HTML email, and then forgot to update the plain-text by hitting the "generate plain-text" button. This was a common scenario within the current workflow at the time, and it left folks with a new, updated HTML email but an old, outdated plain-text email. Yikes!

After lots of discussion, we determined the best thing for almost all of our users was to completely remove the plain-text step from their workflows. Instead of being an explicit step in the campaign wizard, we removed it and configured the server to automatically generate a plain-text version whenever a campaign is sent. This would ensure that the most current content from the campaign HTML is used for the automatically generated plain-text.

New users who were not tech-savvy would no longer have to think about the plain-text part of their emails. Existing users would no longer have to remember to hit the "generate!" button in the plain-text step. It would all just happen automatically, and we would reduce the overall cognitive load on a person as they sent a campaign. This one was going to be a winner, we thought. It's in the bag!

We knew the automatically generated text from our converter wasn't perfect, but it was pretty good. Even though we wanted to make it more accurate, we couldn’t specifically identify its shortcomings. When people had easy-access to editing plain-text, they’d go in and fix any errors they noticed—rather than reporting the errors to us as bugs. We figured that since folks wouldn’t be able to fix imperfect plain-text emails themselves, they’d start telling us what was wrong, so we could fix the converter for them.

Fast-forward to 9.0 release day. We deliberately release to just a fraction of our users first to make sure that if something goes wrong during the release, it doesn't affect the entire MailChimp ecosystem. After the release went out, we were all a bit anxious and asked our awesome support team to keep close watch on the plain-text issue. Volume started to grow a bit, but we were still feeling like things were OK.

As a little more time passed, however, we started to see some not-so-positive feedback through Twitter, support, and the blog. People were confused about where the plain-text step had gone. Those who regularly used replicated campaigns as starting points for new campaigns were particularly worried. They feared that because they weren’t able to see the plain-text and manually update it, they might be sending out old plain-text content. Realizing our mistake, we responded to each of these folks individually. Once we reassured them that the plain-text versions of their campaigns were being automatically generated and updated upon send, they were relieved and went about their business as usual. 

After day two of the 9.0 release, we made few tweaks inside the app to make it clear to users that yes, plain-text was gone, but they didn't have to worry; it was going to be handled for them automatically. Although the volume of questions about where plain-text had gone decreased, we started to see some serious volume from folks who did not agree with our decision to remove the plain-text editing feature. 

At this point, Eric and I became concerned that maybe our decision wasn’t the best. According to support, the number of people affected by our change wasn't huge, but those affected were deeply concerned. Many of the folks who edited plain-text emails were making their emails more accessible for their subscribes who use screen-readers. Others brought to our attention that government regulations require emails to be accessible from older devices, and therefore plain-text emails are necessary. We didn’t consider either of these situations while we were making our design changes.  

Needless to say, we agreed that we needed to bring plain-text editing back. Though our initial data was correct in terms of percentages of users, our mistake was discounting folks who actually depended on plain text editing. We took something away from them that was a crucial part of their workflow.

After some quick brainstorming, we decided to bring back plain-text editing, but we'd do so in the "Confirm" step of the campaign wizard. This revision had a few of benefits:

- First, the option to edit plain-text would still be available for those who do need to make edits.

- Second, people who don't care to edit plain-text wouldn't be forced to even think about it.

- Third, the logic we scripted to automatically generate the plain-text email on send would still be put to good use: As long as we don't detect that you've edited the plain-text part of a campaign in any way, we'll automatically generate it for you.

After making these changes and testing them thoroughly, we pushed them out and anxiously awaited feedback. Immediately after going live, we started getting reports from support that the plain-texters were now just fine after being instructed of the new location to edit their messages. We retroactively responded to all the blog comments that had voiced concerns about plain-text being gone and informed them that it was back. We released a collective sigh of relief that our little ecosystem was starting to stabilize again.

Lesson learned: Always be looking out for the 99%, but never forget about the 1%.

P.S. Thank you to all our loyal users who continue to stick with us as we try new things. We love you!