Postmark Message Streams

A new way to seperate email streams and protect inbox placement.

Postmark is an email provider that’s always been known for its focus on transactional email. In 2018 we decided to expand into sending all types of messages for our customers. This was a big, engineering-heavy project that involved standing up dedicated infrastructure for sending these new non-transactional messages so that we could protect the high delivery rates for transactional messages. We knew that we’d need a way of determining which messages were transactional and which were non-transactional so we could send them through the correct infrastructure. How we would present this to customers through our API and web app was an unknown though.

I joined the project early to experiment with how we could present these different paths for sending messages to customers. Working closely with a product manager and engineering I mapped out the current UI hierarchy in the web app and how this could be adapted to separate transactional and non-transactional messages. We looked at multiple options:

  1. Expanding Postmark’s current server feature to include typed servers that were used for sending either transactional or non-transactional messages.
  2. Adding filters to Postmark servers enabling customers to send everything though a single server but filter the activity views based on the type of message.
  3. Introducing a new entity within Postmark servers that enabled customers to create groups for messages of the same type.

We decided to go with the third option, a feature we later called Message Streams. Customers would be able to create multiple Message Streams within a server. Each stream was to be used for sending either transactional or non-transactional messages. We later started referring to non-transactional messages as broadcasts.

With the new feature scoped out I started work on UI wireframes and mocked up changes to the app navigation to accommodate Message Streams.

As a remote-first company, design reviews are done asynchronously at Wildbit. I’d present design work in a Basecamp post along with a write-up and video walkthrough where I explain all my design decisions. The team the responds in comments within Basecamp or directly on designs (at this time we were using Sketch + Abstract).

Once the wireframes were finalised I created high-definition designs for the new Message Streams page and creation flow. Regularly sharing them with the team via Basecamp to gather feedback and make iterative improvements.

The Servers page in Postmark is crucial for providing an overview of sending volume and delivery problems related to bounces and spam complaints. With the introduction of Message Streams we needed to figure out a way to preserve that overview while reflecting that multiple message types were now being sent through a single server.

I designed a new deliverability health feature that highlights when a Message Stream is experiencing high bounce or spam complaint rates. This is displayed on the main Servers page, making customers aware of problems as soon as they log in to their account.

Designers at Wildbit are responsible for frontend development. Once the designs were approved I built out the UI and did a minimal Rails implementation to create a working prototype I could test with customers.

Feedback from the user testing sessions helped inform further iterations of the design until the work was ready to be handed over to a developer for a more thorough Rails implementation.

The introduction of Message Streams and Broadcast sending was a major milestone for Postmark, enabling customers to send all their application email through Postmark for the first time. After a phased rollout, Message Streams were enabled for all customers in October 2020.