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.

Option 1: Typed servers.
Option 2: Message Streams accessed through filters on the existing Server pages.
Option 3: Message Streams are added as a new level in the UI hierarchy.

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

Message Streams wireframes to explore creation and management flow.
Mockups for the new Message Streams navigation, showing multiple variations for different stream types.
Message Streams navigation mockups for mobile.

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).

Sharing work in Basecamp to gather asynchronous feedback from the team.

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.

Creating a Message Stream
The Message Streams overview page highlights top-level stats.
The Statistics page for a Message Stream with a navigation drop-down for quickly switching between Message Streams.

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.

The updated Servers page with the new deliverability health status.
It’s important that people can quickly get from the main Servers page they’ll see after logging in, to the activity or statistics page for a specific Message Stream. I added these "Jump to..." menus on the main Servers page to help facilitate that.

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.

Selecting the deliverability health label on the Servers page would launch a modal containing a summary of issues across all the Message Streams for that Server. This helps customers identify issues faster and provides a direct link to the relevant place in the application from them to investigate further.

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.

Remote user testing the new Message Streams creation flow.

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.

Matt West