Redesigning the Small Improvements emails

During Ship It Week, I took the opportunity to redesign our emails. The goal was to deliver a more modern and fluid layout in hopes of strengthening trust and creating a more pleasant user experience among our customers.

Before and After

email-blogpost--before-after-01.jpg
Before and after images of Small Improvements emails

Design

According to research1, aesthetics play a big role on how people interact with things. And while the old email template is usable and performs the task well, it was outdated and not as attractive as the current state of the app itself.

“Attractive things make people feel good, which in turn makes them think more creatively”

Emotional Design by Don Norman

There are many factors that affect how a person feels when interacting with an email from Small Improvements. The key is to simplify it by making it easier for people to understand what the email is about. And since emotions change the way our mind operates – the happier we are, the better we can provide valuable feedback!

We want our users to feel excited when they receive an email feedback request, or whenever a feedback has been made available to them. In the end, it’s not just about how a part of the tool looks – it’s also a way to connect individuals to special events that may happen during their time in a company.

email-blogpost-03.jpg
Different mockups of invitation email

Technical Details

Automatic inline styling

Emails are best structured in tables and styles work best when inlined. Inline styles can be a pain to maintain so I looked for a way to make it easier to update these templates in the future.

The great thing about working in the tech industry is that solutions to some problems are just a few clicks away because you can almost be certain that people have gone to the same problem already. We used a little library called gulp-inline-css that does exactly what it’s supposed to.

Before inliner:

<table class="table-reset">
  <tr>
    <td align="left" class="logo-container padding-copy">
      <!-- header -->
     </td>
   </tr>
   <tr>
     <td align="left" class="article-container padding-copy">
       <!-- content -->
      </td>
   </tr>
</table>

 

After inliner:

<table class="table-reset" style="border: none; border-spacing: 0; padding: 0; width: 100%;">
  <tr>
    <td align="left" class="logo-container padding-copy" style="color: #353535; font-family: 'Avenir Next', 'AvenirNext', Helvetica, Arial, sans-serif; padding-bottom: 20px;">
      <!-- header -->        
    </td>
  </tr>
  <tr>
     <td align="left" class="article-container padding-copy" style="color: #353535; font-family: 'Avenir Next', 'AvenirNext', Helvetica, Arial, sans-serif; font-size: 16px; line-height: 25px; padding: 20px 0 0 0; text-align: left;">
       <!-- content -->
     </td>
  </tr>
</table>

All templates get a .responsive file extension so that the script knows which files to transform. It then outputs them with the correct filename that the accompanying java file needs in order to render correctly. Now everybody can make a CSS file, as they are accustomed to, and the script will automatically inline those styles!

Testing

During the entire process, I used a combination of a local mail server and online email testing platform. The benefit of the local mail server (which we’ve already set up) is that I get to see the email come in through my inbox when triggering events in the app, and can immediately see if something went wrong. Testing on the email testing platform, on the other hand, makes sure the templates are rendered correctly in as many email clients as possible.

Testing on different email clients

Next Steps

Changing the look and feel is just the first step to making our emails more pleasurable to interact with. The next step would be getting rid of the long links and replacing them with buttons and then revisiting emails that need a text overhaul!

Conclusion

Coding a template for emails is, without a doubt, very tricky. With hundreds of email clients and devices available within our grasp today, it’s no wonder that designing emails can quickly turn into a mess. But it can be done! The key is to make it simple and as straight to the point as possible. By combining it with rigorous testing, emails can be made almost as responsive as any website.

Endnotes

1  Apparent Usability vs. Inherent Usability Experimental analysis on the determinants of the apparent usability by Masaaki Kurosu and Kaori Kashimura;

Aesthetics and Apparent Usability: Empirically Assessing Cultural and Methodological Issues by Noam Tractinsky

Building the Activity Stream. Part 1: Product Design

We recently launched our new Activity Stream. What began as a small idea turned into quite the large engineering undertaking. The results are astonishing, but it was a lot of hard work. In this part we’ll share how the design took shape.

 

Whiteboard and paper drawings

Each larger project at Small Improvements begins with a rough written draft, and a kickoff meeting that involves PM, developers, designers and a customer-team person. User stories are extracted, prioritised and then broken down into manageable MVP plus one or two “expansion releases” so it’s clear they are not part of the original release. Then the product design work starts (and if needed, we’ll conduct  some code exploration too to rule out major obstacles)

We use whiteboards and paper drawings to try out ideas, discuss and iterate quickly. Here are some of the many initial ideas for how to represent complex concepts like our cycles in a changelog:

as-paper.jpg

Wireframes

Lots of future problems can be avoided by coming up with good quality wireframes. So after the paper scribbles were done, we went to paint proper wireframes. Here are two examples of how we described the overall architecture of the activity stream, then followed by an actual sample wireframe.

wireframe 1.png

wireframe 2.png

 

We don’t take wireframes too seriously of course. Wireframes are a plan, not a committment to the future product, and everything is still up for change.

Also, quite often the real challenge lies in the user flow, not just in screen design. Some flows can be simulated at the whiteboard or by moving paper pieces around, but we typically move to InVision quickly. Using a web-based tool allows us to create actual clickable prototypes, and get insight from other (possibly remote) staff easily.

 

Mockups

A high fidelity image can raise unrealistic expectations (“oh look we’re almost done”) or draw attention to the wrong details (“why are there 20px margin, shouldn’t it be 30px?”). But on the other hand, the more realistic our mockups look like, the more and better feedback we get from outside the core team.

It’s not about pixel perfection at this stage, everything can still get adjusted. But it is about making things feel “real” sooner than later, so that staff feel encouraged to give feedback about the flows, and so that early access customers feel they are actually commenting on something we are serious about. So we quite like our high fidelity mockups!

 

mockup-comment.png

(The above is just a screenshot, but we typically make mockups clickable so it’s clearer what action takes you where)

Code level prototypes

We prefer to not write lots of “real” code before there has been some agreement on the flows between screens. Yes we’re agile, and yes we can make changes down the track. But starting to code user flows without first sketching them has failed us too often.

So once we start coding the frontend, we have a somewhat good grasp of a feature, and this makes coding quicker, and styling is also more fun when you don’t have to fear everything changes totally next week.

As designers we love to get down and dirty at the UI level too. But it’s not scaleable to be positioning every button ourselves. We invest time teaching design principles to frontend developers, and make everyone follows our living style guide, so we can focus on the advanced stuff, not on placing basic buttons.

 

User testing

Once a feature has been developed to alpha stage, it’s time for user testing. We aim for conducting some some 5 to 10 “successful” user tests for larger features or changes. If user tests show there are major problems in our designs, then we reset the counter, keep adjusting the design, and schedule further user tests.

We prefer a combination of tests. On one hand we like watching experienced customers explore their existing content with new features enabled. On the other hand we like scenario-driven tests where we present users with concrete tasks, using a synthetic demo content setup (so people aren’t afraid to break things). Both have their place, but usertesting is such a complex beast that we’ll blog about it separately. 🙂

 

Launch

When the tests confirm that a feature works, it is time for the polishing phase, and we’ll gradually enable features to our beta program customers. After another round of feedback, answering questions and polishing, it’s time for a wider rollout to clients who didn’t sign up for the beta. Now proper documentation needs to be written, blogged, and announced in-app using Intercom or home-made hints.

And then it’s time to roll out for real and celebrate!

celebrate.jpg

 

Creating a SI Style Guide

After a significant project involving making Small Improvements responsive, we came up with some UI ‘rules’ that we in the design team or (‘UI Taskforce’) agreed upon. The longer we worked on this refactoring and ‘cleaning up’ of the app’s style, the more we realised the importance of (finally) having a Style Guide.

IMG_20160526_152845.jpg
The UI Taskforce! Adrienne, Kristof, Kolja and Timur. (I took the photo).

At Small Improvements, we often have the front end developers implementing UIs faster than we (the design team) can keep up, so it’s important that they can access this guide.

Continue reading

AMUSE Conference in Budapest

IMG_2403

In October Kristof, Kolja and me visited the AMUSE conference in Budapest. First UX conference for all of us! We went to stay for a whole week and used the first days for a ‘User Interface Retreat’ in our apartment.

arbeit

The AMUSE partners with the CRUNCH conference about big data and shares a lot of the infrastructure like catering. As a visitor of either of those conferences you could visit the other one. We used the chance to watch a talk by Andrea Burbank about A/B Testing.

In my opinion, some of the talks where not that convincing – shallow, full of buzzwords but lacking meaningful content. I came here to learn about UX, I do not need a motivational talk encouraging me to do it. I want guidance, case studies and new trends. Luckily, there also were really good talks. Here are the ones we enjoyed most:

Continue reading