MailChute postmortem

This is a story of both success and failure. I’ll spoil the ending of the project for you and just say, off the bat, that this project has hit a dead end and won’t be happening any time soon. However, I found that the process has helped me grow as a designer in many ways, and it deserves a journal post. The entire project from start to stop took about a week and a half. Warning: this is a long one, so buckle up.

What was was a side project we at H.Engage decided to pursue almost spontaneously one day. After conducting multiple product interviews with both current and potential clients of H.Engage, as well as other interested parties, we found that many employers, unsurprisingly enough, have no idea if communications with their employees were actually being read. Employers wanted feedback to make sure that people got their emails, and, if they had to follow up with unresponsive people, have a quick way to do contact them without weeding through recipient lists and whatnot. Our proposed answer was to create an easy tracker that could be attached to any email and provide reports on responses.

Whiteboard sketches

Coming up with the actual product

The first step we took was to call a meeting and figure out what we wanted to build. We had some initial disagreements about what MailChute should even do, but after some furious whiteboard-ing and listing of pros and cons, we settled on an idea for the first version of the product.

Wireframes showing the flow for an admin

Our solution was elegant—except for one small hitch which would end up killing the project. The idea was this: as a new user (someone, anyone, who was interested in receiving reports about their outgoing emails), you go to and give a name for the email that you’ll want tracked. Our app will then generate a URL for you to place into the body of your message, as well as an email address to add to the BCC field. You then send your email in the client of your choice to whoever you want, and that’s it!

From a sender’s standpoint, it was a dead simple process from start to finish, even if they were a first-time user of—and it was thinking through this signup/onboarding process that I’m proud of. Just by adding our email to the BCC field, our app could then gather all the necessary information without having to bother the user for extra steps. We would know the sender’s address (which we could then automatically use as the admin account username) and all the recipients of that email. I even thought of the case where the employer would want to quickly get in and out of our site. If they wanted to quickly generate the URL/BCC address and closed the site afterwards, the app would send a message to the sender notifying them when there is a report ready for their email. If the sender hadn’t set a password yet for their account, they’d be asked for it here, but again, they wouldn’t have to enter their email since we already have it. Every new report for any new emails the sender sends will be appropriately grouped under their account, all because they should share the same “From:” address.

Mock showing URL and BCC email generation

How about those feedback reports?

So how do we get stats and provide actual usable reporting to these senders? What happens once the sender attaches the URL to their email and BCC’s us? The recipients would get their sender’s email, and in it, it’ll have instructions telling them to click the link MailChute generated. Once a recipient opens the link, the resulting page would then ask the person to enter and submit their email address. When they do this, it’s like they’re “checking in” to the email. I wanted to make this part as quick and painless as possible too. If the sender had previously sent emails to the same recipients, this check-in page would help by autosuggesting once the recipient starts typing. Once recipients start checking in, a report for the sender will automatically be created showing the number of people the email was sent to, the response rate, and a list of responders. We also give the sender an option to quickly copy the emails of those who have yet to response, in case they want to send a follow-up email.

Mailchute reporting mock

Time to validate our ideas a.k.a. when we learned to stop

Before we progressed any further, we needed to validate our thinking. It was important to make sure that the users we were going to build this product for would actually find it useful. We quickly created mockups and a 2-minute video to send to our interviewees, and a couple of the H.Engage team members took these materials out to the streets to do some quick tests with the public. Conceptually, for the homepage, I played off the idea of letters and actual mail chutes. The message icons start at the top of the page, get slipped into our “chute” (the orange bar), and then sent out to different groups. The app pages recalled old-school envelopes set on a calming blue grid background. The video was quick and straight to the point that went over the problems we wanted to solve and explained how MailChute worked.

Mailchute homepage

The general response was good, but most people said that they wouldn’t continually fill out their email addresses as a recipient—even with the autosuggestion feature. Honestly, this feedback didn’t surprise me as I too thought that that step was cumbersome and initially aired similar concerns. However, since we couldn’t embed unique IDs to each email and each recipient, there wasn’t much more we could streamline. Unfortunately, this would be the fatal flaw to our product that caused us to stop development on the project.

The lesson here…

Even though our product never made it past the validation stage, I’m still extremely happy we did this exercise. In the grand scheme of things, we spent only a short amount of time on it but I learned from it. It was one of the first times I’ve successfully followed a complete process of ideation, rapid product conception, and then validation. Yes, we’ve failed our validation tests and had to kill our project, but isn’t that the whole point of testing? I’ll take this as a win.

An identity for Splashscore

What is Splashscore?

In a nutshell, Splashscore is Facebook game that rewards you when your friends Like or comment on your posts. The app gives you a score in relation to how popular your posts are over time, as well as a scoreboard of all your Splashscore-playing friends. It builds competition to put out more relevant/funnier/wittier content, which is probably a win for everyone who is tired of posts about what their friends ate for lunch. As your points go up, you’ll be able to unlock more and more prizes—such as credit towards stores or discounts off products.

Coming up with ideas

For me, the most important and obvious aspect to this app is its utilization of a person’s social network. So, I started by tackling the lowest, juiciest, hanging fruit. What better way to communicate the idea of your post becoming popular and spreading to friends than a drop of water that starts an endless ripple? Especially since the name of the app is “Splashscore”. I knew that this would be the starting point for the mark. For the logotype, I wanted to give the word “Splash” more oomph, as if a big wave was the result of a person’s popularity, but keep “score” more uniform and static since numbers mean business! In all seriousness, score implies a standard that things are measured against, and so it should be more neutral and, for me, more geometric.

Initial ripple explorations

Refining and dialing it in

As you can see in some of the early sketches, I started incorporating checkmarks into the logotype. I had realized that another huge value point for users is the feeling of warmth when you see your friends’ approval of your posts. A checkmark is a classic way of showing validation and we’ve probably used it in every form we’ve ever filled out. Needless to say, I wanted to combine the two ideas and after many more sketches and tweaks, I landed on the mark’s final form. The final product depicts the moment a drop hits and a ripple starts on the surface. The resulting splash forms a nice thick checkmark, with the ripple doing double duty and working as a checkbox.

Refining the logo

Although I was initially interested in using expressive typefaces for the logotype, I decided to tone it down and use different weights of Gotham. I felt that the contrast between the weights get across the feelings I had intended without competing with the unique shape of the mark. When it came to rendering the mark and logotype in color, I elected to give both a subtle 3D effect. The treatment of “score” was inspired by light reflecting off of water.

Final Splashscore logo

Final thoughts

This was one of my earliest projects while working with the fine folks at Bionic Hippo (now defunct) and it was through them that I got to meet and work with the guys at Splashscore. The Splashscore team was great, both really receptive to ideas and giving solid feedback. Since we finished this piece back in June 2011, Splashscore has made a few changes to their logo in the rendering and typeface. But in the end, I think that the mark fits the app nicely; it marries the illusion of water with a universal symbol of approval to capture the interactions and functions of this social networking game.