Courier Redesign / Rebuild

Improved performance by 90%+, designed and installed a Design System,

and set foundations for future vision.

Courier Redesign / Rebuild

Improved performance by 90%+, designed and installed a Design System, and set foundations for future vision.

What is Courier?

Courier is a platform designed to help businesses manage and deliver notifications across multiple channels—like email, SMS, push, and chat—all from one unified place. Customers can create customized message templates, control routing logic, and analyze engagement through powerful insights.

Why a massive redesign / rebuild?

I am the Co-founder, but after 2 years I decided to move toward bigger companies. The CEO told me that after I had left, they hadn’t maintained a clear vision or structured design approach. All feature requests came from Sales, aiming to attract customers—but it didn't work. The app had become slow and inconsistent, with Customer Support flooded by complaints about performance and bugs. I decided to come back to help.

"Courier was losing customers because of performance, outdated designs, and bugs."

Together, the CEO and I agreed that Courier needed a full redesign and rebuild to survive. This was not a light decision, and we looked at other options first. A cost analysis told us it would take less time to redesign and rebuild then fix what we had. This would mean all teams stepping up, aligning the roadmap, and forming a dedicated team I would manage to drive this effort.

Before

After

Redesign

Getting started

Before designing I needed to get the company aligned, create a team, and do research.

Project managment

I began by cleaning out Linear, which had accumulated around 1,500 issues, most of them outdated or irrelevant. I reduced this to fewer than 400 active issues, cutting dead projects—over 40 in total—including those tied to people no longer at the company. I gave the team a week to tag any active projects with notes; anything without a note by the end of the week was deleted. This streamlined the backlog to just four or five main initiatives, each containing relevant projects, making it easier for the team to focus.

I also held an all-hands meeting to introduce the initiative, align the company, and share how we’d need their input and collaboration. This was a important in building a sense of shared purpose across the company, especially since, at the time, the company hadn’t yet established common goals.

Team composition

While all teams would play a role and collaborate with us, we still needed a dedicated team to work on this full-time.

Product Designer

UI, UX, PM

Maryam

Product Designer

Troy

CEO

Consultant

Brandon

Engineer

Frontend

Riley

Engineer

Frontend

Redesign

Keeping track of progress

A simple clasification and language for the whole company

ReStyle

Apply tokens to all elements. Swap hardcoded elements with ones in the Design System.

Automations 2.0 was a module we could only ReStyle with tokens until we could ReBuild.

Tedius, but not costly.

Apply tokens, replace components

Re

Style

ReStyle

Apply tokens to all elements. Swap hardcoded elements with ones in the Design System.

Automations 2.0 was a module we could only ReStyle with tokens until we could ReBuild.

Tedius, but not costly.

Apply tokens, replace components

Re

Style

ReStructure

For screens requiring layout changes, we enhanced usability without a full overhaul. All ReStructures had a ReStyle applied to them as well.

'Settings' had a huge ReStructure.

Costly in time, but not in difficulty.

Same as ReStyle, but we have to move things around

Re

Structure

ReStructure

For screens requiring layout changes, we enhanced usability without a full overhaul. All ReStructures had a ReStyle applied to them as well.

'Settings' had a huge ReStructure.

Costly in time, but not in difficulty.

Same as ReStyle, but we have to move things around

Re

Structure

ReBuild

Completely outdated sections needing full redesigns.

ReStyling was applied until these projects could be scheduled and resourced approprietly.

Costly in time and resources. Saves time in the future.

Blow it up and start again from scratch

Re

Build

ReBuild

Completely outdated sections needing full redesigns.

ReStyling was applied until these projects could be scheduled and resourced approprietly.

Costly in time and resources. Saves time in the future.

Blow it up and start again from scratch

Re

Build

The 3 card system

Such a huge project would touch all screens, so I created a simple tagging system. Each screen got a specific tag assigned: ReStyle, ReStructure, ReBuild. Each card represented the scope of the screen. While one day all screens in the app will need a full rebuild, this approach buys time without looking inconsistent to users. It also helped to have a language that we could all understand.

While one day all screens in the app will need a full rebuild, this approach buys time without looking inconsistent to users. It also helped to have a language that we could all understand.

How did I decide what tag to use?

I applied the cards depending on scope, resourcing, and our roadmap. If I knew we would rebuild a screen later, I would assign it a ReStyle. If we needed to organized and groups items together I would assigned a Re-Structure. Re-Builds were discuss withe CEO and CTO to ensure it was coming in the next year. I followed the 80/20 for most of the decisions.

It was painful to sometimes have to do a ReStyle when I wanted a ReStructure or ReBuild. But discipline and restraint mattered above else.

I applied the cards depending on scope, resourcing, and our roadmap. If I knew we would rebuild a screen later, I would assign it a ReStyle.

If we needed to organized and groups items together I would assigned a Re-Structure. Re-Builds were discuss withe CEO and CTO to ensure it was coming in the next year. I followed the 80/20 for most of the decisions.

It was painful to sometimes have to do a ReStyle when I wanted a ReStructure or ReBuild. But discipline and restraint mattered above else.

We could view our progress through a feature-flagged dark mode

All components in the new DS (Design System) would use tokens and would support light and dark mode. An internal feature flag allowed us to see what UI elements were hardcoded, and which ones used the new DS.

Research

For three weeks I did my research to identify our problems. I cried a lot during this period.

Courier’s automations offered a visual builder for managing notifications. As usage grew, users began to hit a node limit. A quick investigation found users were using multiple conditional ‘if’ nodes to handle logic.

To solve this, I wanted to introduce a 'switch' node. Unfortunately, our flows had a top-down flow, and this particular node requires a left-to-right flow.

Customer feedback, our expertise, and data analysis helped make the decision to redesign Automations. I also saw this as a great opportunity to improve performance, expand on enterprise features, and add a new ‘get profile’ node. To me, a redesign should not only enhance UX but also add meaningful business value.

•

Customer support: Spent time with them to give me their top problems.

•

Personal: Looked at the industry, standard practices, old references of concepts I had done.

•

Data analyst: Spend time with our DA and created a plan to start queuing metrics we found useful. Identified power users for reference.

•

Investor conversations: Pat Malatack, former VP of Product of Twilio gave a ton of feedback of what was broken.

•

Team conversations: Spoke to every team to get a feel of what was not working for them.

•

Dogfooding: Went though onboarding and set up my environment and used the product.

Shocking research findings 🤦

Ok so… there were a lot.

No design system

Living on V.9 of Next.JS

App took 12 sec to load… felt hung

No project management tool

No metrics… not even in billing

Settings was a dumping ground

Automations was dark mode only

Unstructured grouping of assets

Buttons were handling logic

Hardcoded elements everwhere

All engineers working in silos

UI dev time moved at a glacier pace

Bugs galore

Main menu was not a global element

and more…

Now that everything was setup, it was time for me to get my hands into actual design.

Some screenshots showing massive inconsistency

The app was only available in light mode, by automations used a different style and was only available in dark mode. The reasoning was this was the way to introduce a dark mode into an app. Applying token to Automations went up the list of priority to at least make it feel part of the app.

Introducing

Heron Design System

I designed a minimal DS that would fit our needs, and follow rules and guidelines.

Creating the design system in Figma

With the audit complete, I designed and built a custom design system in Figma, tailored specifically to Courier’s needs and ensuring that every component had a purpose, avoiding unnecessary bloat. We did not use an existing DS as they come prepackaged with too many elements. We were trying to consolidate as much as possible.

I did all the UI elements and worked with engineering to install Token Studio flow. This system established:

•

Token-based consistency: Managed core elements like color, spacing, font, and layout. Pretty standard.

•

Color and spacing tokens: I defined tokens for primary colors, background hues, text, and panel colors. Each color was referenced in both light and dark modes, where light mode referenced one palette, and dark mode referenced another—easily toggling between modes and allowing quick future customization.

•

Adaptive sizing: Set up a universal sizing structure (x-small, small, medium, large) with specific pixel values to create consistent padding, margin, and element spacing across the app.

•

Token Studio for direct updates: By integrating Token Studio in Figma, I enabled design-to-development collaboration without bottlenecks. This setup allowed me to push token changes directly to GitHub, where engineers could approve them, facilitating real-time design updates that saved critical time and resources.

I created standard foundational elements. Yup, I did all from scratch.

All elements were mapped to our token and design system in Storybook

Rollout

While I prefer milestone releases, this was too big to keep a separate code base. Literally rolled out day-by-day whenever anything was ready. Styling elements in the DS were still matching the old design (color and sizing) until we had enough done. Switching the style over to the new one when we were ready took a matter of minutes.

Some before / after shots

A small sample of the changes I did (some currently in flight). All designs shown were done by me.

Before

After

Asset Manager, formerly Template/Notifications

Automations 3.0

Redesign

The results

We could see the effects and changes on a monthly basis.

Feedback

I took feedback as we released. But we were impressed to see that no customers complained. If anything, we got constant reminders that they were happy about the changes. The most common feedback was wanting to more developer friendly flows. This was an initiative I wanted to do after called Courier EF.

Results

The main praise we got was on performance. Every week we would get asked what we were doing to make the app faster. The reality is that by eliminating redundant components and optimizing DOM load, load times dropped from 9–10 seconds to under a second. A gain of 89.5%!! in loading times throughout the app (some sections need to ReBuilt to improve their performance).

-89% Load times

Huge gains

Twilio signed

Their confidence was earned

Cut Dev time in half

Engineers didn't not have to worry about styling

Minimal design handoff

All designs were attached to the DS and tokens.

Increased uptime

4 days improvement in yearly uptime

-80% CS

UI related customer support down

Winning 90% against our main competitor

Up from 60%