← Archive // RSS

Building on email

by Nathan Pilkenton

July 2022

Summary: Most of my side projects have been email-based services. I believe products that use email as a mode of engagement have great benefits for users compared to app- or web-first solutions.

The benefits of email-based services

I’m committed to building products that use email as the primary mode of engagement, as opposed to the web or an app. Many of my side projects have been built this way—everything from daily news digests to blogging to team pulse checks.
If you're curious: Bulletyn sends custom news digests, weejur is an email-based blogging platform, and Chekkin sends team pulse surveys and anonymized results via email.

I’ve chosen to build on email because I am making products for myself first, and in my opinion, email is a tremendously user-friendly way to engage with a service.

Here are some of the benefits I've personally enjoyed as a user of email-based products:

Email has benefits for developers, too

In addition to the upside for users, I have also experienced some benefits as a developer of email-based services:

The drawbacks of developing for email

Unfortunately, for creators, building on email does come with several drawbacks when compared to apps or websites:

Losing control

That big list of disadvantages makes it seem like building on email may not be worth it after all. But many of those issues can be boiled down to a simple statement: Building on email means giving up some control over your product.

My guess is that this feeling of losing control is what prevents most creators (and especially most companies) from considering email-based products and services. If you can convince people to come to your website or download your app, you get to control the entire environment and how those users relate to your product.

But on the other hand: giving up control over the product means the users are getting more control instead. In fact, some of those "disadvantages" for creators mentioned above seem like pretty big wins for the user. Fewer ads? Less tracking? Easy to create multiple accounts?

User-centered (and company-centered) design

User-centered design (UCD) is a popular philosophy of product development which keeps "the user as the center of focus".
(Jeffrey Rubin, Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests, John Wiley and Sons, Inc., 1984)

The UCD approach typically involves listening to and observing users to understand their needs (both stated and unstated) and then designing products or services to best serve those needs.

Many product organizations claim to be user-centered, and the language and toolkit of UCD is pervasive in the software development industry. However, few major commercial websites seem committed enough to the UCD philosophy to actually give users more control over their experience. In fact, it seems to me that many practice something more like "company-centered design", at least for the big stuff.

What exactly is user-centered about showing ever-proliferating ads, locking up user data, using dark patterns to prevent cancellation, putting up a paywall after letting search engines index the full page, tracking users across multiple sites, or any number of other behaviors common on the web? It's hard to imagine any of these "features" being built in response to an important user need discovered in research.

Building on email is user-centered

I’m not saying email-based services are the panacea to fix all these problems—and as mentioned above, they involve clear tradeoffs compared to web- or app-first approaches. But I do think giving the user more control is almost by definition user-centered, and it's simple to provide an alternative front-end on the web for those who may prefer it.

In short: I choose to build on email because I believe it’s fundamentally a much more user-centered design choice. 

← Archive // RSS