Quil is an email newsletter app I built with a friend, TJ Krusinski. I'm always wanting to write more and always looking for good reasons to get better at it. So, I wanted to make a mega simple email newsletter app that let you write the newsletter in Markdown.
The world of email is a strange and hapless place. So many clients rendering so many different ways - It’s hard to account for. There are many companies working in the “email marketing” space, helping businesses churn the RedPlum of our digital mailboxes, but very few tools are designed for an individual. Designed around a strictly minimal set of needs, designed to create and manage and email list and allow you to compose in markdown.
To learn more about writers email decisions, I reached out to a few writers whose emails I had been getting. Here’s a little sample.
Q: Did you pick Mailchimp for any particular reason?
A: I picked Mailchimp because it's what immediately came to mind... It seems okay so far, though a bit overly complicated for my taste.
Q: What do you like more, something like Mailchimp for writers or more like direct blogging through email?
A: i like the idea of email as a medium for writing... i send out emails with my content first, and then put it on my site later on.
Asking writers who were currently managing an email list confirmed a few hunches I had. One specifically, MailChimp has more features than what's desired. That’s a sentiment I heard from each of the 3 writers I talked with.
Now that I was armed with some data, I went to work on some sketches and working out a few flows for the most used interactions. I had a baseline idea for the app dashboard/ui and moved forward with that system, a single page app with ~50% of the only view showing charts on email engagement.
Along with starting some definitions around visual distinctions and feature sets, I always find it helpful to start defining the main definition line for the product. The one sentence descriptor that quickly tell the story of it’s value and the intended user.
Quil is designed for writers. Clearly articulating that proved a bit more difficult that I had anticipated. Through exploring certain copy, I always find myself wanting to sacrifice playfulness and personality for clarity and simplicity. It's a hard line to draw when giving life to a product.
Publish Through Email
Testing this line in context of the landing page, I found it didn't quickly enough articulate exactly what the product did. I spent some time trying to stay away from saying Email Newsletters because I felt it had to heavy of an established connotation. Utimately though, I found it was the most direct solution, being married to the additional value proposition of the product.
Markdown Email Newsletters
I think there is a certain sensibility to use a line that could be a google search. If it’s something a potential user would end up searching for, It absolutely makes sense to describe a product with that few of words.
Really early on in the visual organization of Quil, I had a picture of the single view for the application. A simple approach to containing, in order of visual and interaction importance, the 3 main blocks of information a user would need to navigate in difference thought modes.
I recognized these three chunks as the main information blocks for each user. Organizing them into sections that makes sense is the challenge. I started sketching out the idea in my head for how the data could be laid out, and it felt right. This is the direction we went with the first, usable prototype and what’s live on the app right now.
For the very first version of the app, we shipped a completely usable, start-to-finish version that utilized SES for emails. It was awesome to get a working prototype working so quickly.
I’ve worked through a couple versions of the landing page/marketing site since then. Here’s the current breakdown, starting with the first version on the left.
Quil has seen lots of iteration in copy, description and on the landing page. The iteration I’ve worked through in the UI of the application has been in two primary places.
First - Making some tweaks to the organization of items in the header. Here are some concepts I sketched out thinking through how it should work.
I landed on an “add” icon taking the top right square area, for the purpose of building an animation that transitions the view to compose. The black header moves across the
header element and the compose section moves in from the top, with the “add” icon turning slightly to a “close” icon.
I’ve also iterated on the welcome/on-boarding message. Initially, I built a blocking, modal style welcome message with more of an ethos description of the app. There were two problems with that. One, It was way to long. Two, no one wants to read a book right after signing up for an app.
I still see a few problems, there’s a lot to get at both from the onboarding process as well as the overall interaction states for the data and compose views.
I love working on Quil because it's a never ending experiment in iterating a product. A big problem we're in the middle of fixing is transitioning from Amazons SES to Mailgun. SES requires the nasty, Amazon branded confirmation email. We’ve prototyped with Mailgun and know we can get around that. It’s a big hurdle in the onboarding process and has led to 6% of users not getting verified.
I've also started working on some big changes in a second version of the app UI. After writng some emails and getting a feel for how the product works in the browser. I've felt a big disconnect from each of the three sections I designed in the main landing page. The sections aren't talking to each other. Even more, there is a big lack of focus on the entire point of the product - Your content in writing emails.
In changing the structure of the app UI, I'm currently testing a really prominent list design, placing the emails you're working on or have sent, at the front and ceter of the UI. Looking back at the first version of the UI, it seems like a donkey move to block out each section so dramatically. I think the big takeaway for me there is learning that big parts of how a product should be designed, can only be learned through testing and prototyping. It's so essential to get to doing real testing as quickly as possible.