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 MailChute.io?
MailChute.io 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.
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.
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 MailChute.io 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 MailChute.io—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.
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.
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 MailChute.io 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.
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.