Developer notifications

Dell’s Developer Experience team was preparing to launch a public API marketplace called the Developer Portal and needed at least 50 notifications for it, which was more than I’d ever written for one project at that point.

I had to figure out how to keep all of the messages and their components organized and how to communicate the same things to both known experts (Dell employees) and an unknown, external audience.

After reviewing the provided user journey maps, I determined how many emails, message bars, and modals I’d need to write. I decided to use an Excel sheet to keep the separate components of a message (like a CTA from an email or the header of a modal) connected but distinct.

Another challenge was the actual writing because these messages would be shown to both an internal audience (Dell employees) and external customers. I turned to research conducted by the Nielsen Norman Group on plain language that shows everyone, including experts, prefer plain language, and that it’s especially crucial for online reading where users mostly skim.

An example of this is the scenario where a user changes an API’s status in the portal to “disabled” and the API becomes “EOL.” Dell developers would understand this means “end of life” and the connotations of that initialism, but external customers likely wouldn’t. So, in the notification, I explained that disabled APIs will be accessible only to subscribed users for 30 days before it becomes inaccessible.

In the end, I wrote 35 emails, 22 notifications, and 10 modals for the Developer Portal—a total of 67 deliverables. This project was a lesson in keeping my work organized and connected to the design, as well as balancing necessary technical jargon with plain language for a diverse audience.