shreya-headshot

Shreya Gupta

## Before Starting
GitHub Repository: [https://github.com/shreythecray/infiltration](https://github.com/shreythecray/infiltration)

**The hackathon ends soon,** and we are giving away over $1K in prizes! Join us in building a cool project and winning any of the following prizes. 🏆

- **Courier Hacks 1st Place:** Top submission for use for notifications and demonstration of proper app-to-user notifications with the Courier API will receive $1000 via Zelle or PayPal.
- **Courier Hacks 2nd Place:** 2nd Place submission for use for notifications and demonstration of proper app-to-user notifications with the Courier API will receive the Apple AirPods Pro.
- **Public Favorite:** Public favorite winner will receive a Keychron Keyboard.
- **Runners-Up:** Runners-up submissions will receive a Hydro Flask.

Additionally, everyone who submits a project successfully integrating the Courier API will receive a $20 Amazon gift card! Submissions close on **September 28th**. Register now to submit this project for a chance to win some cool prizes.

Register for the Hackathon: [https://courier-hacks.devpost.com/](https://courier-hacks.devpost.com/)

Not sure where to start? In this tutorial, we will create a Discord bot that sends daily automated messages encrypted in Morse code with Node.js and the Courier API.

## What is Going On?

### Recap
We are secret agents, and we previously built an application to send secret messages encrypted in Morse code to communicate with our spy network. [Learn more >](https://www.courier.com/blog/hackathon-courier-api-nodejs/)

Last time, headquarters told us that one of our spies had leaked sensitive, top-secret information to our enemies, so we built a lie detector that alerted our spy network when we identified the mole. We used Azure's Cognitive Services to perform facial recognition on everyone on our team and Courier to broadcast the identity of the mole to our spy network. [Learn more >](https://www.courier.com/blog/serverless-lie-detector-facial-recognition/)

### What’s Next:
We have successfully identified the mule and have alerted our spy network! In an unfortunate turn of events, the mule happens to be our partner, Agent X, and now we are being suspected as a traitor as well. Since we are highly skilled, Headquarters knows that the Lie Detector won’t work on us, but we have been placed off-duty until we can prove that we are innocent.

Before we were removed from duty, we were able to use the Lie Detector to find out that the enemy had thousands of civilians under control in a secret Discord server. The civilians are being brainwashed with enemy propaganda every day. To prove our innocence, we decide to go undercover and infiltrate the enemy’s Discord server. With the help of Agent X, we have been added to the server as an administrator. Our plan is to create and install a Discord bot that automates encrypted messages to the civilians and alerts them about the situation so that they can escape.

## Let’s Build

### Pre-reqs:
- Admin access to a Discord server
- A cool undercover Agent name for our Discord bot
- Optional: a cool undercover Agent profile picture for our Discord bot

### Part 1: Set Up Node.js Project
Today, we will be building this with Node.js. If you’re curious about how to build this project using Ruby, cURL, Powershell, Go, PHP, Python, or Java, let us know: `https://discord.com/invite/courier`. You can also access code for these within our [API reference](https://www.courier.com/docs/reference/automation/invoke/). Let’s get started:

- Create a new project folder.
- Create three new files: “index.js”, “.env”, and “.gitignore”.
- Install [dotenv npm package](https://www.npmjs.com/package/dotenv) to store variables: `npm install dotenv --save`

    Import and configure dotenv by adding to top of index.js: `require("dotenv").config();`

- Similarly, install [node-fetch npm package](https://www.npmjs.com/package/node-fetch) to make API calls: `npm install node-fetch@2`

    Import and configure node-fetch by adding to top of index.js: `const fetch = require("node-fetch");`

### Part 2: Create a Discord Bot
- [Sign up for (or log into) Courier >](https://courier.com/hack-now)
- Open Discord provider in Channels. Here we will need our Discord bot token to continue.
- In order to access a Discord bot token, we’ll create a Discord application and add a Discord bot.
    - Click on “New Application” within the [Discord Developer Dashboard](https://discord.com/developers/applications).
    - Type the app’s name and click “Create”.
    - In the left menu, open the “Bot” page and click “Add Bot”. We can update the icon and username (bot icon file can be found in the GitHub linked above).
- Once the bot has been created, copy the bot token provided and paste it in Courier (make sure to keep this token private).
- We will need to give this application permission to post as the bot within our server. Check out the [Bot permissions documentation](https://discord.com/developers/docs/getting-started#adding-scopes-and-permissions).
    - Within the application, head over to OAuth2 and click on URL generator
    - Select the `bot` scope
    - Select the following permissions: `View Channels`, `Send Messages`, and `Read Message History`
    - Go to the generated URL below. This URL will invite the bot to the server and authorize it with the permissions chosen.
- On Discord, click on User Settings (next to username on the bottom left). Access the Advanced settings page and enable Developer Mode ✅.
- Back in the Discord server, right click on the channel and copy the channel ID (bottom of list). Add this as the value of `channelID` in the .env file within the project and save it as a variable within the index.js file:

    ```json
    const channelID = process.env.channelID
    ```

Now, Courier has access to sending messages to this server as the bot.

### Part 3: Send Messages
- Create a new notification within the [Notification Designer](https://app.courier.com/designer)
- Add the Chat notification channel with Discord as the provider
- Select on the Chat channel on the right to edit the message

![image6](//images.ctfassets.net/z7iqk1q8njt4/5VaUY0gl7ILbrIf5I6ib3x/c579d27b7ec6c0f0782ffbc71bd3c25f/image6.gif)

- Write and publish the message. We need to create a clear message that will indicate to our civilians how to escape. Our message will be: `Run while you can. You can find shelter here: https://discord.com/invite/courier.`
- Copy the notification template ID from the notification’s settings and add it as the value of `templateID` in the .env file within the project and save it as a variable within the index.js file:

    ```json
    const templateID = process.env.templateID
    ```

![image3](//images.ctfassets.net/z7iqk1q8njt4/3uNICG76LUrNFmJ8XWzkfw/6774fa85e51e866436c82957ad6353ce/image3.gif)

- Create a test event and replace the `channel_id` in the JSON with the `channel_id` we received from Discord earlier.

    ```json
    {
      "courier": {},
      "data": {},
      "profile": {
        "discord": {
          "channel_id": "768866348853383208"
        }
      },
      "override": {}
    }
    ```

- Test a message to ensure that the Discord provider integration is working correctly.

![image4](//images.ctfassets.net/z7iqk1q8njt4/5GfnsGxTYn4iEAhKnheqIb/41c562b0811dbac8dae8bf3bfe7f60ec/image4.gif)

- Replace the message with a variable `{secretMessage}` so that, later, we can edit the message from our code directly.

![image2](//images.ctfassets.net/z7iqk1q8njt4/RBa7sDpfdeamGi1b2WpoV/57ccc96254356889c55da8676b732d15/image2.png)

### Part 4: Encrypt Message with the Morse API
- Create an asynchronous function called `encryptMessage()`, which takes `originalMessage` as a parameter. This function will call the Morse API, which will allow us to translate any message from English to Morse code. The enemy will have to spend more time and resources into decrypting our messages, which will give our civilians time to escape from the server.

    ```jsx
    async function encryptMessage(originalMessage) {
    }
    ```

- Let’s define the GET API call options:

    ```jsx
    const morseOptions = {
    	method: 'GET',
    	headers: {
    		Accept: 'application/json',
    		'Content-Type': 'application/json'
    	}
    };
    ```

- We need to attach the `originalMessage` function parameter to the Morse API endpoint:

    ```json
    const morseEndpoint = "https://api.funtranslations.com/translate/morse.json?text="+originalMessage
    ```

- We need to be able to access the translation from this API call in the body of the Courier API call. To call the API, we can use node-fetch as we did before.
    - Create a variable called `morseResponse`, which will hold the entire response from this call.
    - Convert the JSON object into a JavaScript object `morseResponseJSON` so that we can read it within our code.
    - Get the translated message out of that object and save it in a new variable called `encryptedMessage`.
    - Return `encryptedMessage` so that we can call this function to access it elsewhere.

    ```jsx
    const morseResponse = await fetch(morseEndpoint, morseOptions);
    const morseResponseJSON = await morseResponse.json();
    const encryptedMessage = morseResponseJSON.contents.translated;
    console.log(encryptedMessage);
    return encryptedMessage;
    ```

![image1](//images.ctfassets.net/z7iqk1q8njt4/3xp8SErhajuhxiMVB2iX2W/43ce98adc0c2c64ca833e46e304b7779/image1.png)

*NOTE: The Morse API has a rate limit, which may give you an error if you run it too many times within the hour. In this case, you will have to wait for some time before continuing.*

### Part 5: Automate Messages
[Learn about Automations >](https://www.courier.com/docs/automations/)

[Check out the Automations API reference >](https://www.courier.com/docs/reference/automation/invoke/)

- Create a new asynchronous function called `runDiscordAutomation()`, which will call the `encryptMessage()` function to translate a message and use the Courier API to automatically send messages to the enemy Discord server everyday.

    ```
    async function runDiscordAutomation() {
    }
    ```

- Before we can run our message through the Morse translation API, we need to ensure that it is in the correct format, with all spaces converted into their URL encoding, `%20` as shown below. We can call `encryptMessage()` with `originalMessage` as a parameter to translate it. `encryptedMessage` will evaluate as the translated message.

    ```jsx
    const originalMessage = "run%20while%20you%20can%20you%20can%20find%20shelter%20here";
    const encryptedMessage = await encryptMessage(originalMessage);
    ```
- Add the link to the safe server in the notification template within the designer: “[https://discord.com/invite/courier](https://discord.com/invite/courier)”

- Let’s define the Courier Automation endpoint and options. Here we will need access to our Courier API Key, which can be found within the [Courier Settings page](https://app.courier.com/settings/api-keys). Save the first value in the .env file as apiKey and access it in this file as process.env.apiKey.

    ```jsx
    const automationsEndpoint = "https://api.courier.com/automations/invoke"

    const courierOptions = {
    	method: "POST",
    	headers: {
    		Accept: "application/json",
    		"Content-Type": "application/json",
    		Authorization: 'Bearer ' + process.env.apiKey
    	},
    	body: JSON.stringify({
    		//next steps
    	}),
    };
    ```

- The body object within the options will encompass two objects: `automation` and `data`

    ```json
    body: JSON.stringify({
    	"automation": {
    	},
    	"data": {
    	} 
    }),
    ```

    - The `automation` object will include a `steps` array, which will consist of all steps required for the automation. Our automation consists of reminders that are sent once a day - in this case we will be adding three steps: a send step, a delay, and another send step (so on).

        ```json
        "automation": {
        	"steps": [],
        },
        ```

    - Each step will need to be defined with two objects: the type of `action` (send, delay, cancel, etc.) and `message`. The `message` consists of the notification template ID (we saved this in the .env file earlier) and information about where this message is being sent. A Discord message requires either a `user_id` or a `channel_id`. In order to reach as many innocent civilians as possible, as quickly as possible, we will directly send messages in a channel.
    - This is what the send and delay steps would look like:

        ```json
        {
        	"action": "send",
        	"message": {
        		"template": templateID,
        		"to": {
        			"discord": {
        				"channel_id": process.env.channelID
        			}
        		}
        	}
        },
        ```

        ```json
        {
        	"action": "send",
        	"duration":"1 day"
        },
        ```

    - The data object would need to contain the `encryptedMessage`:

        ```jsx
        "data": {
        	"secretMessage": encryptedMessage
        }
        ```

    - [Learn more about sending to a channel via Courier >](https://www.courier.com/docs/guides/providers/direct-message/discord/#sending-a-message-to-a-channel)
- For testing purposes, it’s easier to either remove 1 delay step or keep it at a short period like `1 minute`
- Finally, we can use node-fetch again to call the Automations API and trigger this automation

    ```jsx
    fetch(automationsEndpoint, courierOptions)
        .then((response) => response.json())
        .then((response) => console.log(response))
        .catch((err) => console.error(err));
    ```

![image5](//images.ctfassets.net/z7iqk1q8njt4/DToIls5IJymsGD2WVpqNr/1eff78ca95f8a643f6bfbcab2cfc3cdc/image5.png)

## Conclusion

Our Discord bot is ready to save some civilians. Try building a Discord bot of your own and tweet a screenshot of your Courier automated messages in action, and we will send a gift to the first three Secret Agents to complete this task! Head to [courier.com/hack-now](http://courier.com/hack-now) to get started. Don’t forget to submit your project to our [Hackathon](https://courier-hacks.devpost.com/) for a chance to win over $1000 in cash and prizes!

### Quick Links

🔗 GitHub Repository: [https://github.com/shreythecray/infiltration](https://github.com/shreythecray/infiltration)

🔗 Courier: [app.courier.com](https://bit.ly/3QPiFg3)

🔗 Register for the Hackathon: [https://courier-hacks.devpost.com/](https://courier-hacks.devpost.com/)

🔗 Discord Application and Bot Guide: [https://discord.com/developers/docs/getting-started](https://discord.com/developers/docs/getting-started)

🔗 Courier Discord Provider Docs: [https://www.courier.com/docs/guides/providers/direct-message/discord/](https://www.courier.com/docs/guides/providers/direct-message/discord/)

🔗 Courier Automations Docs: [https://www.courier.com/docs/automations/](https://www.courier.com/docs/automations/)

🔗 Courier Automations API Reference: [https://www.courier.com/docs/reference/](https://www.courier.com/docs/reference/)


Get ready to join the first ever Courier hackathon to win over $1000 in cash and prizes. 

Calling all secret agents!

Brunette woman (spy) sits at a desk, hacking a computer.

serverless-lie-detector-header

Our plan is to create and install a Discord bot that automates encrypted messages to the civilians and alerts them about the situation so that they can escape.

serverless-lie-detector-thumbnail

Create a Discord Bot that Automates Secret Messages with Node.js

Anwesa Chatterjee

As a product manager, have you ever had to say no to improving your app’s notifications because of how complex the project seemed?

If yes, you’re not alone. At Courier, we frequently see product teams deciding not to work on notifications. And PMs aren’t making that decision because a good notification experience is not important for their SaaS product or service — quite the opposite.

The reason is that changing notifications, in their experience, requires a lot of work between engineering and product due to how closely the notifications are tied to the rest of the application. If PMs are tasked with adding a new email campaign that all new users of the app will receive, that can usually be done outside of the core app. But sending more unique notifications, like alerting a Slack channel when someone @-mentions their colleague in a shared file, can be complex and require significant engineering work. And still more work is needed when the text or the design of such a notification needs to be updated.

We believe that changing notifications doesn’t have to be so difficult. In this article, we explain how decoupling notifications from your application’s codebase can help make notification projects less complex and less risky for product teams.

## Why PMs believe notification projects are hard

![image1](//images.ctfassets.net/z7iqk1q8njt4/6kGqayxYctQyy0qkn5MolS/74f523a316788e845e22186ca06c979e/image1.png)

Usually, the task of improving an app’s notification experience — like adding or changing notifications, or connecting additional notification channels — falls to the engineering team that’s responsible for the main product. Such teams have lots on their plate, which makes it necessary to prioritize some tasks over others.

Notification projects tend to be high-value for product managers, as a bad notification experience can have a negative impact on a SaaS app’s customer base, while, conversely, a [good notification experience](https://www.courier.com/blog/pm-product-notification-experience/) can drive growth metrics and delight customers.

However, notification projects also score high on complexity and risk at most companies. That’s because different notification channels, which are quite different by nature (think email versus mobile push), require a lot of individual engineering.

With so much complexity involved, product managers have to make a tough call: is it really worth taking on notification work when there are easier projects to work on with more tangible benefits? Because task backlogs frequently have other items in them that don’t carry as much complexity or risk, it’s logical for product managers to postpone rather complex notification projects. And so notification projects get moved down the priority list, again and again.

## The limits of common engineering solutions to notification problems
To try and make notification changes less difficult to implement, engineering teams use open-source tools that are well supported within their framework or programming language of choice. For example, those working with Ruby on Rails applications often use Rails’ built-in email sending module, [Action Mailer](https://guides.rubyonrails.org/action_mailer_basics.html), which includes functionality for sending plain-text and HTML emails.

While tools like Action Mailer are convenient to use and well-maintained, they can’t handle more complex tasks like expanding beyond the standard notification channels. If you want to add Slack or SMS notifications, for example, choices like Action Mailer can become a limiting factor, rather than an enabler of new product functionality.

The next logical option for a software team running into tooling limitations is to go with a fully customized notification system — but such a system brings its own challenges.

## Even a custom notification system is a bottleneck for notification improvements
It may seem that the solution to the limitations of open-source tools is to simply build your own custom notification system. But a custom notification system is still code that implements notification logic, supported channels, and templates for specific notifications, and this code lives inside the application codebase in a version control system like Git. Any changes to this part of the codebase have to follow the steps of the software development process, which becomes cumbersome when making many small changes, as is the case with notifications. (Not to mention that engineering time needs to be allocated to the maintenance of such systems in the long run.)

For example, if the task is to update the wording or the design of a notification across all channels, the engineering team tasked with the work might have to:

* Change the HTML email template.
* Change the Slack notification template.
* Change the Microsoft Teams notification template.
* Test all three changes.
* Wait for code review on the changes.
* Once the code is reviewed, deploy all three changes to production.
* Hand off to the PM for a final confirmation.

And every time a PM wants more changes implemented for notifications, the process has to start over again, even for trivial content changes. The standard development process, which is totally reasonable for code changes, is too much overhead when working on notifications, and the additional overhead takes the engineers’ time away from working on more valuable things.

## The result: notifications rarely get updated
Because of the additional delays introduced by the development process, the friction for implementing notification changes ends up being so high that PMs often choose to not implement notification changes at all. 

Instead of focusing on building the best possible notification experience, they settle for the default notifications that are built into their application already, because anything else becomes too difficult to do. They might think “If it took two weeks to change the simple design on my notifications, we're just not going to change things anymore.” And so notification experiences stall out indefinitely.

## There is a better way: enable PMs to work with notifications without involving the engineering team
Courier’s point of view is that the way notifications are handled in most SaaS apps today — templates stored in code, notification functionality changes requiring code deployments, etc. — is outdated and, as we have seen in the examples above, ineffective.

Instead of having to go through the development process for each notification change, we need to give PMs and other non-technical stakeholders the right tools to work with notifications directly. Here are the core practices that act as enablers for non-technical audiences.

**Making templates accessible to non-engineers.** Notification templates in the form of text, HTML, or programming-language-specific template files need to be located outside of the application code, and PMs as well as other non-technical teams need to have access and be able to make changes.

**Making notification logic configurable without needing to re-deploy the app.** The logic involved in deciding which notifications to send when should not be located in the application code, but rather sit next to it and be configurable without needing to deploy the application. The configuration can live in a text file, a web interface, or another config format. PMs should ideally be able to change the configuration themselves.

**Enabling self-serve analytics.** Besides notification functionality, PMs need to be able to track how their changes are doing — and be able to follow the statistics without the need to ask engineering or data teams for the numbers. Analytics can be presented as a custom dashboard, but can also be an export of a business intelligence report, or even a dump of application logs that show which messages were sent, depending on which option is easier.

## What are the results of PM enablement?
To show that PM enablement works as a way to make notification projects easier, we want to share two examples from Courier customers that have experienced this change.

Bluecrew, a marketplace for hourly jobs, [has seen its business grow](https://www.courier.com/blog/courier-bluecrew-multi-channel-notifications/) after decoupling notifications from application code. The company was able to improve the onboarding experience for new users in part by taking advantage of notification templates and making them accessible to non-technical stakeholders.

Within Bluecrew’s notification system, “anyone can add a content block and insert a custom attribute like ‘shift start time’ or ‘cancelation reason.’ We also have the flexibility to add custom code anywhere in the notification,” says Cooper Newby, the Chief Product Officer at Bluecrew. 

Another company that’s been taking advantage of the enablement approach is [Expel](https://expel.com), a provider of security services. The Expel team has enabled its UX designers to use the template designer UI directly and make changes to the product in real time.

“We can get our UX designers working directly on the templates and we can make updates and have them live in seconds,” says Yousuf Ashparie, Principal Software Engineer at Expel.

Does enabling PMs to make notification changes sound appealing at this point? We hope it does — as we believe it’s a significant improvement over the current practices at most companies. Let’s look at how you can enable PMs to work with notifications in your own team.

## So, how can you enable PMs to work with notifications?
Looking to enable PMs to do more notification work, but not sure where to start? Here are our top recommendations for companies looking to get started on the PM enablement journey.

**1. Get analytics in place.** Having analytics for notifications is a key tool for PMs to measure any notification changes. While metrics can be difficult to come by for some notification channels, it is usually possible to have at least some numbers in place. Once the PMs get the data, they can use it to avoid accidentally making the notification experience worse, and to make sure the rest of the organization can see the benefits for larger changes to notifications.

**2. Make it easier to change notification templates.** While it’s ideal to make all notification channels and notification types configurable by PMs, it’s not always realistic. Instead, at least make it so that PMs can change existing notifications without much involvement from the engineering team. Even if that’s all you allow, you will still need to add functionality to adjust notification designs to fit the updated content, and likely implement internationalization and translation workflows if you’re interested in supporting multiple languages.

**3. Build guardrails to prevent notification issues from escaping to production.** Ideally, all notification functionality should be covered with automated and, possibly, manual tests so that the organization can be confident in the product’s notification experience at all times. The areas to check include: notification text fitting within the display area; possible internationalization glitches; technical issues like app crashes resulting from changes in notification text size; handling of unexpected characters if notifications include user input.

## Courier can help
Instead of building everything yourself, use Courier — and get our recommended steps 1–3 done almost instantly after some brief initial implementation work.

Using Courier frees up your team to focus on other valuable things in their backlog. For PMs, UX designers, and other non-technical stakeholders, Courier helps by:

* providing a drag and drop designer, including a staging environment, with the ability to make changes live without deploying the app
* offering a UI that allows users to add new notification channels without needing to update code
* including an Automation UI that allows users to build out notification workflows visually (no application code)
* Implementing the guardrails in point 3 above, so that you can reduce the effort involved in changing notifications without increasing the risk.


Check out how Courier has completely removed any need for product managers to mess with the code for notification content, logic, and design!

PMs shouldn't be writing code...

pm-guide-2-header

In this article, we explain how decoupling notifications from your application’s codebase can help make notification projects less complex for product teams.

pm-guide-2-thumbnail

How Decoupling Notifications from Your Application’s Code Empowers Product Managers

Your product’s notification experience can make or break how your users perceive your application. That’s why getting the notification experience right should be at the forefront of product managers’ minds. But what, exactly, is a great notification experience for a mobile or web app? Here at Courier, we often hear this question from product managers.

In this article, we’ll do a deep dive into what contributes to a great notification experience. We’ll talk about various notification types, which notification channel is best suited for what kind of message, and how to make sure that your users don’t leave your product due to wrongly timed notifications. After reading this article, you’ll have the confidence — and the tools — to set up a notification system that delights and doesn’t annoy.

## What is a notification experience?
In this article, we use the term “notification experience” to include everything your users see, hear, do, and feel when they interact with notifications from your app or software service — from emails to push notifications to Slack messages and beyond.

![pm-1-1](//images.ctfassets.net/z7iqk1q8njt4/7EK4zCoBASw1pcFUTJcCfc/eeaa0911f8533e864f0642d7b76d34ee/pm-1-2.png)
*Image: email, push, and Slack notifications for an HR application.*

**Notification channels** are a central component of a notification experience. Each channel is a way to reach the user through a particular technology, platform, or service that is able to deliver notifications. Here are some examples:

* Mobile push (including banners, badges, sound alerts)
* Email
* Chat (like Slack or WhatsApp)
* SMS
* Phone call
* In-app notifications

In many cases, it’s not sufficient to only use one notification channel, so most notification experiences would also include notification logic. In addition to defining which channels to use under which circumstances, the logic would process user preferences, pick the right language based on the user’s profile, and so on.

## How different notification types contribute to the overall notification experience
There are two broad types of notifications used by software products and services: transactional notifications and marketing notifications.

**Transactional** notifications are directly relevant to a specific action, like creating a post or placing an order, that a user takes within your app. Examples can include a delivery app that sends them an immediate confirmation of an order, or a marketplace app that notifies them of a new message about a product they’re looking to sell.

**Lifecycle** notifications are designed to encourage your users to return to and interact with the product itself. An example is sending a user who hasn’t been in the product for three weeks a reminder email that their work in the app is waiting. Or sending a weekly digest of statistics to a user by email and having them return to analytics within the product for more details.

While the boundary between these notification types can sometimes be blurry, the core concepts are defined quite specifically [in law](https://www.law.cornell.edu/uscode/text/15/7702).

![pm-1-2](//images.ctfassets.net/z7iqk1q8njt4/5MDpTUst0073rooipedWJy/68594b245d11bace5ce954bca397ab42/pm-1-1.png)
*A transactional push notification and a marketing push notification. Similar format but different purposes.*

In general, you could use any notification channel for both transactional and marketing purposes, but some are more suited to one or the other. We offer some examples in the table below.

<table>
  <tr>
    <th>Channel</th>
    <th>Advantages</th>
    <th>Disadvantages</th>
    <th>Best suited for</th>
    <th>Not suitable for</th>
  </tr>
  <tr>
    <td>Email</td>
    <td>Wide adoption.</td>
    <td>Can take days for the recipient to read an email. Possibility of hitting deliverability issues. Possibility of getting lost in the inbox.</td>
    <td>Important information that the user shouldn’t miss, like pricing changes, account updates, security alerts; marketing messages that are not time-sensitive.</td>
    <td>Time-sensitive alerts — as email is not designed to be read instantly.</td>
  </tr>
  <tr>
    <td>Mobile push</td>
    <td>Received quickly by the user; can take the user directly to the app to perform an action.</td>
    <td>Alert fatigue; limited settings on the user side.</td>
    <td>Timely alerts.</td>
    <td>(Arguably) marketing messages.</td>
  </tr>
  <tr>
    <td>SMS</td>
    <td>Wide adoption.</td>
    <td>Doesn’t work without a mobile connection. Length limitations.</td>
    <td>Timely alerts about appointments, events, etc.</td>
    <td>Most app notifications.</td>
  </tr>
  <tr>
    <td>Chat (Slack, Discord)</td>
    <td>Reaching chat app users with less interruption; giving users an opportunity to see messages in the app when browsing other activities.</td>
    <td>Can get lost in the chat. Possibility of not reaching the recipient if they are not checking the chat often.</td>
    <td>Context-specific notifications — for example, work conversations or gaming conversations.</td>
    <td>Time-sensitive notifications outside of chat hours. Security alerts.</td>
  </tr>
</table>

There is no single channel that is perfect for all uses. A good notification experience should take advantage of each channel's strengths.

## A bad notification experience can frustrate users
Based on our experience speaking to Courier customers and prospects, product managers understand that notifications matter, but sometimes they don’t see how much they matter. In reality, lots of bad things can happen if the notification experience for your app or service is not good. For example:

* You could lose users due to incorrectly using notification channels, like sending marketing notifications via channels like mobile push which are normally only used for time-sensitive, transactional alerts. Such application behavior can feel unprofessional and spammy, causing users to lose trust in your product or service.
* You could upset users due to sending notifications at the wrong time. For example, someone who gets an avalanche of notifications might decide to completely block them for your app. This means that even your important messages can’t reach them. Also, needlessly sending out notifications at night could cause users to literally lose sleep. Who would want to do that to their customers?

## What does a good experience look like, in contrast?
Let’s contrast the potentially serious consequences of a bad notification experience with the more positive aspects of a good experience. Based on what we see at Courier, here are the key aspects that contribute to a good notification experience.

**Right channels.** Choosing suitable channels for your notifications makes it more straightforward to build and improve your notification experience later on. For example, in a banking app, using mobile push for transaction notifications would likely be a good fit due to this format’s timeliness, while email wouldn’t be so suitable. However, if there is a suspicious transaction, it might be better to send an SMS, or even escalate to a phone call to make sure the customer doesn’t miss the notification.

**Right timing.** It’s better to avoid sending some notifications like mobile push at night, as that might wake your customer up unnecessarily if they don’t have the right alert settings. A local marketplace app, for instance, should thus try to avoid sending mobile push (or other intrusive) notifications at night. Instead, it could send a summary email in the morning. On the other hand, mobile push notifications could be totally right for a security-related alert.

**Right customizations and preferences.** In addition to allowing notifications to be fully on or fully off, applications should offer ways for users to customize notification settings to their needs. For example, a weather app might offer a separate setting to turn rain notifications on or off independently of low temperature notifications. Some of us dislike rain less than others! 

**Following platform best practices.** A notification experience that seamlessly fits into the platforms you use for notifications, like iOS push, in-app notifications, or Slack, will add delight into your customers’ day. An HR app like the one we showed above, for example, should make use of Slack’s [various built-in “blocks”](https://api.slack.com/reference/block-kit/blocks#section) when it makes sense, rather than using the basic text-only format and shoehorning various content types into that format’s limitations.

## Common objections to building a good notification experience
At Courier, we frequently talk to product managers as part of our support, solutions, and sales conversations. We’ve noticed over time that there are a few key issues that are blocking PMs from improving their product’s notification experience. Below, we list some of the most common concerns. Have a look if any of those resonate with you!

### “I can’t control the notification experience the same way as I can control the app experience.”
Yes, it’s true that you don’t have as much control over how the notifications in your product look and feel, compared to the app itself. This is because the notifications on platforms like iOS and Android need to look like iOS and Android for consistency, rather than your brand colors and font face. Your app can only customize parts of the notification experience on these platforms.

Another way to look at this limitation, however, is to recognize that there is a smaller UX hurdle for users to overcome when relying on an existing notification system, where users already know how notifications look and feel. Moreover, modern notification systems on iOS and Android, as well as other channels like Slack, Discord, and email, are flexible enough for companies with such unique products as Uber, Airbnb, and LinkedIn to offer a good notification experience — so you can do a good job too despite platform limitations.

Our advice is to explore what different notification platforms have to offer: Slack, for example, has multiple message “blocks” that your application can send, and you might find exactly what you need in one of the pre-built blocks. And in iOS 16, the new [Live Activities](https://9to5mac.com/2022/07/27/ios-16-live-activities-api-available-beta-4-developers/) feature for notifications can change how notifications work for time-sensitive events.

### “I don’t know what a good experience for my users looks like.”
It can be challenging to identify exactly which notifications need improving for an optimal app experience, or how you can make a notification’s content or format more valuable to your users — and lack of in-depth notification analytics can be a contributing factor. While it’s straightforward to measure engagement on a website with tools like Google Analytics or Matomo, analytics of users’ notification experiences are harder to get.

Our recommendation is twofold:

Try to get quantitative data on notifications — for example, open rates and clicks across channels. On some platforms, like email, this is easier; on platforms like iOS this is more challenging but still possible.
Support the quantitative data with [user research](https://productschool.com/blog/product-management-2/product-management-skills-user-research/). Send surveys to your users and ask them which notifications they find most valuable, and which they find annoying (if any).

For inspiration on good notification experiences, consider apps that you use frequently yourself. Are there any apps where the notification experience feels “just right” — delivering messages at the right time and pace, with relevant and engaging content? 

### “Designing a good experience is too hard.”
Because there are so many different platforms involved in a notification experience, PMs can feel overwhelmed by the number of decisions they have to make when it comes to designing the notification system.

Our advice is to focus on fixing aspects that are wrong and getting the basics right, rather than trying to implement advanced notification techniques from the start.

For example, the basic steps can include:

* Getting basic analytics on notification interactions to better understand how your notifications are used by your users
* Making sure notifications don’t crash the app
* Allowing users to customize their notification experience using basic preferences
* Adding relevant channels — as outlined in our table above — so that users can receive the kinds of notifications they need

Each of these items should be small enough to be able to implement with your team. By focusing on smaller, tangible deliverables you can slice the ambiguous “notification problem” into manageable chunks.

## Tips for building a great notification experience
To summarize, the way to build a great notification experience is to consider notifications a core part of your product and treat them accordingly.

Apply user research, design thinking and other product techniques to notifications too, not just your application. Test your notifications the same way as you test the rest of your product, to ensure that they are functional and look good. Measure the impact of notifications on user behavior via analytics.

It can be a difficult process, but this series will provide you with the information you need! Or, if you'd prefer to buy a great product notification infrastructure out of the box, check out Courier.

Hey PMs, are you having trouble building notifications with great UX?

pm-guide-1-header

After reading this article, you’ll have the confidence and the tools to set up a notification system that delights and doesn’t annoy.

pm-guide-1-thumbnail

How PMs Should Build a Great Product Notification Experience

nica-headshot

Nočnica Mellifera

Or, how we’re destroying users’ trust, and how to get it back. Check out the first post in this series as well: *[Building a Great UX Outside of Your App](https://www.courier.com/blog/building-ux-outside-of-app/)*.

There is a direct connection between all the unnecessary notifications you get on your phone and the sub-prime financial crisis of 2008. The connection is human behavior in a large and anonymous marketplace where bad behavior is rarely punished.

In a recent [Hackernews post](https://news.ycombinator.com/item?id=32692884), I posited the same connection: that apps that send notifications are facing a systemic collapse where users will be so overwhelmed with mass notifications that most of them will opt out entirely. One user responded with a great synopsis of the problem:

> Unfortunately if it drives engagement of 2 people at the expense of becoming annoying to one person the app developers will keep over-using notifications.

I’d add one further sad corollary to this observation: as long as other app developers are over-using notifications, it’s irrational for you the app developer not to. As you compete for attention on users’ devices, you will fall behind your competitors if you don’t emit a few notifications a day. So even though your individual action hurts the user experience overall, it can be irrational for you to avoid doing so.

As any fan of financial crises can tell you, the subprime bubble, where lenders created AAA-rated securities out of extremely shaky mortgage lending, was not an evil scheme dreamed up by nihilists. Rather, it was the act of rational people acting in their own best interests. As long as other banks were selling junk securities at high markups, it wasn’t rational for one bank to stop, even when they knew the system couldn’t go on forever. As former Citigroup CEO Chuck Prince infamously said, “as long as the music is playing, you have to keep dancing.”

## What the crash would look like
Any time I start a discussion on Reddit or Hackernews about what users want in notifications, most commenters say that they want out of notifications entirely. It was only three years ago that most users got ‘do not disturb’ mode on their phones, and more and more users are deciding to stay in Do Not Disturb *forever*.

Can notifications ‘crash’ the same way that the mortgage market did? Absolutely. The sequence looks like this:

* Increased awareness of unnecessary notifications
* Government regulators request that OS producers limit unnecessary notifications
* All notifications become tightly restricted
* Contacting users via push notifications becomes unreliable 
* Application developers no longer invest the time in timely notifications
* With users no longer expecting notifications, developers are forced to go back to email and SMS to contact users at all

## The Prisoner’s Dilemma
John Cassidy in his illuminating book *[How Markets Fail](https://us.macmillan.com/books/9781429990691/howmarketsfail)* explains that this pattern is in fact a version of the prisoner’s dilemma. The multiple actors in the market aren’t able to coordinate and they end up choosing options that are individually beneficial, but collectively negative.

The sub-prime crisis nearly crashed the global economy and we still live in its shadow. In the world of notifications: every OS release on our phones further limits how apps can notify us, is a similar crisis coming in the market for user attention?

## How we break free
A dire situation, surely, but we can do something about it: collaboration. The prisoner’s dilemma doesn’t work nearly as well if the prisoners can communicate and see each other’s choices. In the case of notifications, all that’s required is that we the creators of applications agree to some simple principles for trustworthy notifications.

This move is not without precedent. Multiple industries decided on voluntary pledges of quality and trustworthiness rather than deal with public ire, choosing self-regulation over government regulation. Perhaps you remember this seal from the childhood newsstand:

![crisis-1](//images.ctfassets.net/z7iqk1q8njt4/2nsPqQwBpHIueEHCVrtoQl/82d7f10962cbd1731f1ee55036cc23e0/crisis-1.png)

Next to Captain America’s adventures and even Grant Morrison’s Swamp Thing, the Comics Code Authority seal was stamped on the cover of comic books for over 40 years. And perhaps you saw another sign of voluntary self-regulation in an air-conditioned theater this weekend:

![crisis-2](//images.ctfassets.net/z7iqk1q8njt4/1W7YN13dcLNuTHnGnir9Vv/433631f477614ba9671a680587009def/crisis-2.png)

Neither of these ratings and advisory boards are without their detractors, and as Comic book fans aged and concerns about violent comics diminished, the comics code has disappeared. However, these do show that a lack of public trust can be addressed by an industry-wide standard.

## A pledge for better notifications
Folks, I don’t want to be corny, but I do want us to get better. Here we get to the crux: I want us to agree to do better. Here are the principles that can guide better notifications.

*One caveat here: this pledge is not about dark patterns or dishonesty. Tricking the user into spending money unintentionally should be covered by generalized ethics, this is about good design principles for developers who want to build trustworthy tools.*

### 1. Be timely
We often feel bombarded with notifications, so a requirement that they come faster can seem counter-intuitive. But it’s critical that you identify when and with what precision your users expect to be informed. A notification that your web service is down needs to come sooner than the first angry call from a user. And a notification about breaking news needs to come before you say something mean about Queen Elizabeth on Slack. 

![crisis-3](//images.ctfassets.net/z7iqk1q8njt4/CskUDdiZMdgRl1RvZpzhi/3bf58dc29d3f3195aebd59a53df193d6/crisis-3.png)
*When the Steam Deck inspired a purchasing frenzy, many users complained they got inaccurate notifications, like this classic epoch failure for a user in the UK*

Timeliness also means not notifying too quickly. Notifications about how many people liked a cat picture don’t need to arrive at 2:00 AM, they can wait til morning. 

The required accuracy of notifications will vary a lot depending on your use case. A scheduling tool like Calendly will need its notifications to arrive on the exact minute we need them to arrive at a meeting on time. A more fun social app probably only needs to send notifications accurately within 30 minutes.

![crisis-4](//images.ctfassets.net/z7iqk1q8njt4/3jiPBK4MyEafiuSly0RPta/7f567998e084a0a5966b1e8036873f0b/crisis-4.png)
*This failure by YouTube may reflect a shift in usage patterns: where previously new and interesting videos didn’t need up-to-the-minute notifications, now users get breaking news and important premieres on YouTube.*

### 2. Be targeted
We may not want our applications to know everything about us, but targeting is a critical part of good notifications. If I ordered Pizza Hut for lunch, I don’t want them notifying me of dinner specials. Look at this not-ideal experience for a user of Accuweather that warned him of thunderstorms…3,000 miles from his current location:

![crisis-5](//images.ctfassets.net/z7iqk1q8njt4/3EZ0BStlnMusDD464RsorU/43052cf882848ee5430b53cc13944d12/crisis-5.png)
*The cut-off text makes the situation worse: it’s easy to assume this is happening in your town!*

Some things we’d ideally target in our notifications:
* Geography
* Time Zone
* User’s access level within our service
* Where they are in the user journey

### 3. Be brief
In the example above from accuweather.com, a slightly wordy notification meant the user didn’t see the area affected by the alert. This is one example of a larger problem: a failure to be brief and to-the-point with notification messages.

Since notifications are often shortened when viewed on different devices, be sure to put the most important information first. Journalists would call this the ‘inverted pyramid’ but I prefer to think of it as a special case of little-endian transmission: the least important information should come last.

A special case of the requirement to be brief is digests: ask yourself if your notifications are more meaningful in a group or one-at-a-time. Notifications of individual ‘likes’ on a post is a great candidate for a digest, as is a long conversation thread.

Ideally since you’re following rule 2 and therefore know the user’s timezone, you can dynamically generate digests when notifications would be sent in the middle of the night for the user.

### 4. Offer (the right amount of) control
Finally there’s control. If I posted every bad example of user preferences for notifications this article would resemble 2000’s Flickr. But:

![crisis-6](//images.ctfassets.net/z7iqk1q8njt4/7k9Yb2Js0xw1tAAvczkx9T/c71c080f37ae7249d22ff251d830428e/crisis-6.jpg)
*A classic example is Starbucks’ which, for a time, would only tell you order status if you also accepted spam*

So we want to offer users real fine-grained controls. But it is possible to get too fine-grained

![crisis-7](//images.ctfassets.net/z7iqk1q8njt4/AtDdpPBn2oT7fJTbbZEZI/fe645350138a19d7e5f892d3dc098c07/crisis-7.png)
*If you zoom in, this is every notification setting for Google Maps*

The solution when you have too many settings is to offer some grouping, so that users can turn off whole categories.
What unifies these needs?
The common thread between all of these requirements is that they all require technical lift. Timeliness, targeting, brevity (with digests), and user preferences all require that we go above and beyond with our notifications service. A simple bulk send email kicked off by a cron job can’t deliver these features without some very sophisticated and un-maintainable regex. The solution then is to have a notifications service that can offer these features in a lightweight experience for our product team.

In the last article of this series, we’ll cover how you can build a great notification experience *without* using Courier.


You can use the tips in this post to apply to your own internal notification system, or you can check out Courier to handle it all for you.

Avoid a notification crisis like the 2008 crash! 

woman on red backdrop screaming in annoyance as she is inundated with too many notifications

sub-prime-crisis-header

There is a direct connection between all the unnecessary mobile notifications you get and the financial crisis of 2008: lack of accountability for bad behavior.

sub-prime-crisis-thumbnail

The Sub-prime Crisis of Notifications

Build a Serverless lie detector that uses AI for facial recognition (with Node.js, Azure Functions, Azure Face API, and Courier API)

Build a Serverless Lie Detector with Node.js, Azure Functions, Azure Face API

Build a Serverless Lie Detector that uses AI for Facial Recognition

denis-tatar-headshot

Denis Tatar


*Preference management is an integral part of a great notification infrastructure, which makes it a very important piece of the puzzle here at Courier. This also means that there was a lot of learning and experience-building opportunity for the intern on the project, Denis Tatar. Denis’ internship was only a few months long, but he was able to make an enormous impact as the product manager for Courier’s Preferences feature.* 

*We wanted to learn more about Denis’ experience, so we asked if he’d be willing to work on a writeup for us. Then what he came up with was so good, we thought it would be a good idea to share with all of you! This post will cover Denis’ workflow from planning to execution around the Preferences project as well as his experience working with the Courier team specifically. We’ll let Denis take it from here!*

## What was the problem?
The problem we experienced at Courier was that we’d offer Preferences (V3) to our customers, but the entire product feature’s strategy wasn’t fully fleshed out. I believe that V3 was a great stepping stone for V4, but fundamentally had flaws in certain parts of its strategy. Allowing only global opt-in/out is an example of this. Another problem was that V3 didn’t gain much traction, which I believe points back to the lack of a fully thought out strategy. In May, Preferences (V3) would only allow users to opt-in and out of their preferences of choice globally. V3 of Preferences only allowed our customers (and their customers) to opt-in/out of notifications, and customers globally could also decide if certain notifications were required or not. V3 helped give our customers the ability to start playing around with the idea of having preferences. However, globally opt/in out is a problem because it constrains end users’ notifications options. It was either all or nothing, no in-between. Similar in theory to the Pokemon saying, “Catch one, catch them all.” A problem with this, though, is inbox flooding. Global opt-in would allow for the concept of the end users’ inboxes becoming flooded with every product notification which is problematic because it can easily drive users away from your product. 

Global opt-in/out was quickly resolved by allowing users to select what content they wanted to be notified of and the channels they’d prefer. This overall trend in the market is used by thousands of companies (B2B and B2C products), especially in the technology space.

![Product Preferences Screenshot](//images.ctfassets.net/z7iqk1q8njt4/4wL7Y4vOcZxXWQHf40diKM/95442b858fa2c6def0f2d46add560a54/image_for_internship_blog_post.png)

Visibility became a serious issue with V3. End users never had the option to select what type of content and channel they wanted. Users would be asked if they were interested in receiving notifications in general. Not offering options is problematic as it constrains visibility on what you’ll receive through notifications. End users also don’t like surprises when it comes to product notifications. Having clarity is key because it enables end users to have control over their notifications.

With V4, we solved the visibility problem, which was the main “fail” from V3. Our customers and their end users now had the ability to control the content they received and the channels they would prefer.

V4 was a good way to strategically notify end users. 

## Plan
There were three phases we followed as a team when building Preferences. 

**1. Research**
In phase one, I spent a decent amount of time looking at what is currently available in the market in terms of preference centers. I would constantly ask myself the following two questions:

“How does [insert company name] manage notifications? What does their preference center look like?”

These questions were key. They helped me dive into necessary research which helped me pick up on many important market trends. Out of all the trends found though, there was one that stood out the most. 

**2. Trend**: Channel & content selection through a toggle/grid style layout for preference centers is a must have.

This trend became the backbone to our summer project. It was important to offer users preferences options. 

During this phase, I read many case studies. I was surprised to see how many existed on this topic. Each one helped enlighten me with solutions for the problem we were tackling. I learned through other people’s mistakes, absorbing the valuable lessons. 

Talking to customers was extremely helpful in this phase. I was able to hop on numerous calls with our customers and hear their perspectives on this problem. I would ask questions and show examples of what we had in mind for a solution. This helped tailor a POC. The better we understand our customers’ perspective, the easier it is to start designing something that they would use. 

**3. Designing a POC**
I really enjoyed this phase. Watching research become an actual POC was incredible, and so fun. We took all the feedback I had gathered, then created several iterations of designs.

Once we created a POC, it was essential to go back to our customers and ensure that it was something they envisioned for Preferences. Our customers were also lovely people to work with, always there to provide their much-needed feedback.

Often, I would have a decent amount of brainstorming sessions with Ian. We’d look at our research and what our customers had to say, and combine these sources into a POC. It was an insightful process to be a part of.

This phase lasted several weeks until we finally landed on a POC that satisfied all of the customers we had spoken to since May 2022.

**4. Building an MVP**
Once we had a POC and fully completed designs, we began building our product feature. This phase taught me two vital lessons…

*Being organized is extremely important.*

and...

*As a product manager, you need to stay one week ahead of your team.*

While working at Courier and delegating tasks, I noticed that the more organized you were, the easier it was to work with others. My organizational skills would impact how clearly our designers and engineers understood our goals and individually delegated tasks. The more organized we were, the faster and more efficient we worked. Outlining the tasks our team needed to complete, and vocalizing why these tasks were necessary helped a lot. It brought clarity to everyone, including myself. 

The second lesson here was given to me by our CEO,Troy. He taught me how important it was to think about the current and following week. Troy brought this up because, as a product manager, you want to keep your team informed on what projects and tasks are in the pipeline.. A product manager that isn’t in this mindset can quickly become a hindrance to their team. Taking on this mindset brought clarity and made me less stressed about our project. I would spend time planning each week,and estimating where the team should be at the end of each week (cycle). 

These two lessons helped when we were building an MVP. We progressed through each week as a team, with each week’s tasks outlined, along with the weekly goals we’d needed to achieve. Working with the team at Courier was amazing, everyone was  understanding and absolutely brilliant. What I loved the most was that everyone had an opinion. Engineers and designers would ask if specific tasks were priorities before building them, which allowed us to build the MVP and get it up and running quickly. These questions helped guide priorities and decision-making. 

## Execution: What I did exactly
Throughout this internship, every day was different. My week would involve speaking to customers, delegating tasks to our engineers and designers, and taking time to think ahead, two to three weeks ahead of the current week. I also worked closely with both engineers and designers, ensuring great synergy between both teams. 

There were four core responsibilities that I embodied throughout my product manager internship at Courier:

Being the internal expert on what the market (customers & prospects) want within my realm of focus.

Being the internal expert on what my product feature already provides (and thus the delta to the above core responsibility).
The ability to prioritize the path that gets Courier from our current state to our desired state.

The ability to educate the rest of the company on the current product, the product being built, and our ultimate product vision so that everyone can be on the same page without being experts. 
As the **glue** that ensures the team is working together on the right thing for the right reasons, their success is ultimately limited by my effectiveness in one and two. I cannot accurately educate teammates on what I don’t profoundly understand myself. 

Troy was a fantastic mentor throughout my entire time at Courier. He brought these four core responsibilities to my attention, which became an integral part of my internship. What resonated with me the most was being the glue between all teams. At first, I looked at this concept and was intimidated by it. But, I had a blast easing myself into becoming this glue-like figure between teams. It definitely wasn’t something easy to pull off, but I enjoyed the challenge. I managed to make a lot of great friends along the way too!

## What trade offs did I experience? 
There were many trade-offs throughout my entire internship. The main ones I experienced were related to the following concept “make it work -> make it good -> make it fast,” which I often heard throughout my internship. There were many times when small features that could make our UI/UX stand out would actually slow down the team. 

Trade-offs like these were necessary. They had me questioning whether we focus on the nitty gritty details, or do we put the feature aside and focus on making a product that functions  and gets the job done? The latter part of that question was often chosen as our strategy. It’s tough to make these calls because you know the team can develop an outstanding product build with phenomenal UI/UX components, but our build must accomplish what it’s meant to do in the first place. 

The main goal was to release our MVP, ensure we have customer feedback, improve any core features, and then focus on minor priorities that affect the UI/UX of this product. 

## What was it like working with the team?
I had a blast working with the Lifecycle team on Preferences. Everyone was so kind, and offered fantastic feedback. I’ve mentioned this numerous times around the office, and on calls with coworkers. Working at Courier didn’t feel like work; it felt like I was working on a side project with close friends. I genuinely think this is why I was able to produce the work I did at Courier, because of the environment. Courier is easy-going, extremely friendly, and results-driven.

Another thing I really loved about the team was that they always thought of me. If there were tasks that engineers or designers would do that was considered a ‘norm’ for them, they’d ask me if I’d like to give it a shot to see what it’s like. I have three examples of this. 

When designing a specific tool tip for a part of the Preferences project, Ian (Senior Designer) during one of our calls, asked if I wanted a shot at designing a tool tip. This involved working with Frames in Figma, a concept I never worked with. I really enjoyed creating that tool tip. It made me feel included.

Every week the team would have our team Lifecycle planning meetings. We’d speak about tickets, and write them up. It was early on in my internship when Suhas (Senior Engineer) asked me if I wanted to try writing up several tickets on Linear. I was aware that this was something most PMs would normally do, but I had a lot of respect for Suhas for bringing this up, and was willing to teach me how to properly create tickets in Linear. 
Once the team had something solidified for Preferences, I began to ask around internally to learn if there were any companies that would be interested in hearing about my project. Nathan (Account Executive), reached out to me to let me know about a customer interested in this product feature. Nathan encouraged me a TON when it came to communicating with this customer. I was able to step outside of my comfort zone because of Nathan’s encouragement. I’ve never gotten to speak to a customer before at any of my previous internship experiences, and I learned a lot about customers and the way they perceive Courier. 

Note that these are just three examples from the many opportunities like this throughout my internship. I do want to give a big shoutout to Ian, Suhas, and Nathan. I appreciate you guys giving me opportunities to learn and grow, it means the world to me. 

## How did I work with designers?
I enjoyed working with Ian (Senior Designer). We’d have impromptu meetings through Slack’s ‘Huddle’ feature, (which was internally renamed to **‘Huggle’** because of a typo I once made that stuck). These meetings were really great for brainstorming and product design. Sometimes, Ian and I would have calls later at night because it was easier to come up with more creative ideas.. We’d have one to two hour sessions, and we’d come up with some really awesome UI/UX for Preferences. This is something I’ll never forget. 

When working with Ian, I would try to make it as easy as possible. I would create a to-do list through Google docs or Slack, so both Ian and I would be aware of what needed to be completed every week. 

During our calls, Ian and I would also talk about a lot of different topics not always directly related to work, which was great. This really helped build our friendship, making it so much easier to collaborate and come up with a clean UI/UX for Preferences. I often do a decent amount of product design outside of work hours, and Ian would always give me phenomenal advice on product design and on Figma!

## How did I work with engineers?
I briefly touched on this, but when working with engineers, I would help create tickets, and organize what each week would look like. I helped our engineers whenever they were confused about anything related to Preferences, and would explain how I came up with specific names, why Ian and I would design certain parts of our product, and the goals behind these designs. Many of these answers came from my extensive research process with customers that were interested in Preferences. 

While working with engineers, I learned a lot on how to properly break down tickets (eipcs) within Linear. I thought I had a firm grasp before working at Courier, but I learned a lot more after working with the Lifecycle team. The key to breaking down tickets is to be able to think about every single detail alongside engineers. Being in a small group while doing this was super important, because each individual helped bring up a very important perspective on how to break down tickets. 

During my internship, Seth (Chief Technology Officer), Suhas (Senior Software Engineer), Christian (Software Engineer) encouraged me to speak to the Developer Experience team at Courier and show them our project. The main goal behind this was to test to see if the UI/UX of Preferences was intuitive, if the design made sense, and if the Developer Experience team understood the goal behind this product feature. I prepared a slide deck explaining our project in its entirety. This was a great experience because it helped me prepare on how to **sell Preferences to our customers**. Giving insightful presentations about products and **“selling” your product to customers is such an important and overlooked skill for product managers**. Speaking to folks internally helped me practice and refine this skill, as well.. 

## How did I solve the problem? 
Before V4 Preferences, customers weren’t given the option of choosing what content they’d like to hear about, and how they’d like to hear about it. With V4 Preferences, users now can voice their opinions on both of these matters. This new product feature makes it possible for customers to choose what they like, and want to hear about. Specifically through their channels preference.

Gone are the days of inbox cluttering and customers becoming aggravated with the amount of notifications they receive. Preferences minimizes the frustration that end users experience with their notifications. 

*Want to apply for a role at Courier? Check out our [careers page](https://www.courier.com/careers/). To check out what Denis helped build in action, request a demo [here](https://www.courier.com/request-demo/) and ask to see the Preferences feature.*


Ask your Courier rep to demonstrate the Preferences feature.

To check out Denis' project in action, request a demo! 

Female manager and male intern standing in front of a machine

PM internship with Courier

This post will cover Denis’ workflow from planning to execution around the Preferences project as well as his experience working with the Courier team. 

Female managers and male intern standing in front of a machine where intern is learning how to use it

PM Internship with Courier

 I Owned a Major Product Feature as a PM Intern

Recently I had a chance to talk to [DevOps
Minneapolis](https://devopsdays.org/events/2022-minneapolis/welcome/) about the [true nature of user experience](https://www.youtube.com/watch?v=C0nqIYxMPUI). The audience found this information to be particularly interesting, so I thought it would be helpful to share it with a wider audience. This post will be the first in a series of three posts that will discuss user experience beyond your app’s UI and how you can optimize it. 

So where is your user experience? More generally, where does your application happen? For those of us who work in SaaS, the answer is simple: the application occurs inside the application interface. Whether we’re selling business tools or teaching Spanish, the application happens when our users access the UI.

![image1](//images.ctfassets.net/z7iqk1q8njt4/7fjNtDXh4kd1X705WbeUMI/1c56d888e770e3c9cd1f5b5c88e8ac0d/image1.jpg)
*Your UX is inside your application… right?*

When we talk about our users having a good experience, that much-vaunted UX, the things we’re tweaking will be inside this application. We have several specialists who worry about user experience. Whether that’s UX thinking about existing users or data and product people making sure the experience for new users is frictionless.

![UX wireframes](//images.ctfassets.net/z7iqk1q8njt4/2rwQGF8vmim0Zm0H1j0Tmn/d0c5031862d85d08998fe012b7740054/image2.png)

I don’t mean to trivialize this process: it’s much more than tweaking colors and moving buttons by a pixel. Those tasked with UX often have to ask the most basic questions: what do our users want, and what’s the best way to give it to them? This matters because however cool our technology is behind the scenes, if the user doesn’t have a good experience with it, they’re unlikely to return.

This article argues that there’s a more important user experience than the one inside your app. In fact, your app has a whole interface that has more impact on your users, that touches them more deeply than your application interface.

## It’s your notifications
![iphone notifications](//images.ctfassets.net/z7iqk1q8njt4/9UViH6p0qPhaiKC69gflN/d87cc815b893a46664348d1876a63be4/image3.jpg)
*This is where your notifications really happen.*

Many of our favorite apps largely interact with us through notifications, the examples are everywhere. 
* Tools for observability and security most frequently have all our interaction starting with notifications. After all, we're probably not checking our APM tools until we know something is wrong. 
* For social media applications, the best moment we experience with them is seeing that X number of people loved our post. 
* And for communication and collaboration applications the notifications should have most of the information that people want you to see.

In fact, I’d argue that for many of our most valued tools and services, most of our interface, for good or ill, is through notifications. Notifications bring you into the application. They provide reassurance, warnings, anxiety, or annoying notifications about sales of pizza. Notifications are your application. 

I mention all this because I believe that your UX is in danger. Primarily, the experience of notifications has been ceded to teams outside of the product team. Instead of our product team controlling notifications, it’s the operations or marketing/growth teams that control most of the notifications we send.

Let me show you far we have strayed from g-d’s light:

## The tale of the signup campaign
The time after a user creates an account is critical for any SaaS tool. Even when users sign up and immediately start using the product, there will be features or extended use cases that we, the developers, want them to try.

Put yourself in the shoes of a product team that’s trying to improve the rate at which new sign ups become committed users. In (almost) all product teams, we’ll realize that we want to get in touch with users after they sign up to encourage them to keep going with our product.

The platform doubtlessly sends a signup confirmation, and we start by tweaking that. We get our new copy and links to the operations team, or platform dev, and they change the post-signup email. But soon, we want more. First off: we don’t really want to email users the instant they sign up, we’d like to wait at least a few hours, to let the platform feel a bit familiar first. Then we’d like to follow up after a few days, and a few days after that.

Even better, we, the product team, would like to customize these messages a bit, depending on their team size, what license they have, etc. 
The operations team, who implement all outbound notifications, is rightfully a bit frustrated by this. They’re used to solving bugs and feature requests for the platform, not tweaking an email. Scheduling? Audience customization? This sounds like a job for….

## The CRM, where for a time it was good
With all the need for custom targeting, a good first solution is to have a signup get sent as an event to a Customer Relationship Management (CRM) tool like Salesforce. From there, it’s easy to start a ‘signup campaign.’ Since the CRM should know things like the org size and license level of the user, the messages can be nicely customized.

And for a time, it was good. However, trouble starts when we go one step further with targeting and customization.

You see, our signup campaign encourages users to use certain features, like say Reports Export. We want to tell the users about the feature, demo it for them, walk them through the concept. “Please” our emails beg, “export your reports, with the Reports Export.”

This message will seem super weird if the user has already used Reports Export. So we, the product team, go to whomever runs the CRM and say ‘can we cancel this email if they’ve used Reports Export.’ Of course, the CRM doesn’t know that. So we end up back with platform engineering, asking them to send an event to the CRM when someone first uses Reports Export. 

The ‘quick and dirty’ solution of CRM wasn’t a durable solution to our problem.

### The problem is a ceding of territory
The inherent problem in the scenario above is a ceding of territory by the product team. If the product team wanted to move a button, or change the order of a toolbar, it wouldn’t make sense for the marketing team to say ‘no.’ But when we want to send a correctly targeted sign-up campaign, our reliance on our CRM means Marketing has to say ‘no’ to a better user experience.

Similarly, we wouldn’t let ops or platform engineering keep us from adding a helpful tooltip, but we are letting them keep us from sending a helpful email to the right users.

## What we can do to solve the problem
The problem here is a lack of tooling, either external or internal. Every new notification stream requires engineering time, and that means  technical limitations keep us from delivering the experience our users deserve.

Whether it’s by using Courier or an internal spike to create a messaging microservice, you want to develop a robust set of features that make it easy to send multiple notification types direct from your platform.


Sign up for Courier to learn about how we implement a notification system that improves user experience both within your app and outside of it.

Are you an engineering leader who needs to build a more robust UX?

birds build around a nest in a tree, but not inside it

ux-not-in-app-header

Your app has a whole other interface that has more impact on your users, that provides a deeper user experience than your application interface.

Your UX isn't in your app: the importance of notifications

ux-not-in-app-thumbnail

Building a Great UX Outside of your App

secret agent sitting in front of a computer for a hackathon with Courier

Courier hackathon

In this tutorial, we will be building a Node.js app that sends multi-channel notifications in morse code.

Sending Secret Messages with the Courier API and Node.js

Secret agent engineer sitting in front of a computer getting ready to join Courier's hackathon.

Welcome to the Courier Engineering Blog

Build your first notification in minutes

Build your first notification in minutes

Product

Developers

Resources

Company