ProxiedMail: Redesigning Email Alias Management to Reduce Friction

1. The single-click workflow

To solve the time-to-task issue, I introduced a primary action area above the fold.
• A prominent “Create a proxy email” button allows users to generate an alias immediately.
• The alias appears in a ready-to-copy field, eliminating the need to navigate to a different area of the app, for a simple task.

2. Recent Activity

Instead of a wall of text, the new dashboard uses activity blocks to provide helpful context:
• By displaying Recently Created, Forwarded, and Blocked aliases, users get an immediate snapshot of their privacy status.
• Including a “Copy” button directly on the activity feed helps users grab a recently used alias in an instant.
• The Favorites block ensures that high-priority aliases (like those used for banking or primary socials) are never more than a glance away.

3. Data Visualization

The Usage Summary section provides a sense of value. By quantifying Total Aliases, Custom Domains, and Blocked Emails, the UI reinforces the app’s core benefit: saving the user from spam and protecting their identity.

4. Feature Discovery

Rather than cluttering the top of the page with instructions, I moved advanced features like Rules and Integrations to a dedicated section. This ensures the UI stays clean for beginners while offering a clear path to power user for advanced settings and workflows.

1. Reducing decision fatigue

Previously, users had to manually generate a proxy username, requiring at least one additional click:

In the redesigned experience, a randomly generated username is pre-filled by default for users who do not require a custom option. This eliminates the need for a separate ‘Generate’ button-click, saving a step in the workflow:

In the earlier design, the same input field displayed a blinking cursor next to the ‘Generate’ chip, which created a confusing interaction pattern.

UX Decision: Pre-generating a unique username provides a zero-click path to creation, while still offering a clear, intentional option for users who want to create a custom username.

2. Streamlining the Domain Selection Workflow

In the original design, managing default domains felt like a separate and disconnected task. The redesign integrates this directly into the domain dropdown. Users can instantly select a domain and make it default for future use-case, without leaving the page and breaking their workflow.

System-generated domains and custom domains are also now visually distinct, making it easier for users to quickly scan and select the right option.

Furthermore, the redesign includes a checkmark against the current ‘in-use’ domain so that the user is visually aware of the remainder of the domains they can choose from.

UX decision: Combining system and custom domains – and allowing users to set a default – eliminates repetitive selections and keeps users focused on the primary task without leaving the flow.

3. Improving visual inconsistencies

The CTA button now matches the input field’s design language, sharing the same height, padding, and border radius. This overall creates a more cohesive and structured layout.

I decided to remove the ‘Reverse Lookup’ button from the form and relocate it to the individual proxy email card. This keeps the form clean and reduces visual noise, while ensuring the primary CTA deservedly receives full attention.

UX decision: Visual consistency reduces cognitive friction by making related elements feel part of a single, unified action. Removing secondary actions from the form helps establish hierarchy and directs user focus toward the primary task – creating a proxy email.

4. Live preview and final alias

One of the most effective additions is the live email preview (“Your proxy email will be:…”) located directly under the username field. This helps users to preview a proxy email before generating it.

Additionally, giving users the ability to copy the proxy email immediately after it is generated removes the need to scroll down the page to find it in a table. This saves time and reduces friction, especially for users creating multiple proxy emails in quick succession.

UX Decision: Live preview provides immediate feedback. Users don’t have to mentally concatenate the username and domain; they see exactly what they will be copy-pasting into a third-party site.

Allowing users to copy the proxy emails once generated, keeps the action close to the point of creation and supports faster workflows.

5. Optional metadata

The addition of Notes and Tags (hidden behind an optional dropdown) is a valuable addition for users to stay organized. This solves the forgotten alias problem – where users look at a list of 50 emails a year later and can’t remember which one was for their bank versus a random newsletter.

UX Decision: Keeping metadata optional preserves a clean interface while still supporting advanced organization needs.

1) Robust table headers

The original table offered almost no way to find a specific alias in a large list. I wanted to ensure that a user has sufficient search, filter and sorting options to easily find the alias they are looking for.

The redesign introduces a multi-layered filtering system:
a) Quick toggles: The All / Active / Inactive segment allows for instant broad filtering.
b) Granular control: By adding specific filters for proxy username (especially if they are searching for custom usernames), domain, forwarding email, and date range – the app is scalable for power users who might have hundreds of aliases.
c) Search context: The search bar explicitly tells the user what they can search for (aliases, domains, notes, tags), which reduces guesswork.

2) Restoring visual hierarchy

a) The card model: By putting each alias in a distinct white card against a soft grey background, I’ve made it immediately clear where one alias’s data ends and the next begins.

Furthermore, each card has its own column heading, making scanning the data easier than retaining it in memory.

b) Status clarity: Replacing a simple toggle with a clear Active/Inactive badge makes the state of the email scannable at a glance. I believe it also makes more sense to label it as ‘Active’ instead of ‘Enabled’ as a user may get confused as to what specific feature of the card has been enabled.

c) Enhancement: Added a ‘favourite’ feature that enables users to favourite a certain alias, that they can filter quickly later. The most recent favourites also show up on the dashboard itself for quick access.

d) Removed the awkwardly positioned ‘More’ action link. The card now expands when clicked anywhere and the down-caret provides the affordance required. Image attached

3) Prioritizing the email hierarchy

Since the proxy email is the primary data users create and interact with, it would be more effective to surface it first. Placing the proxy email first recognizes the user’s intent. They are looking for the “disguise” they created, not the destination address they already know.

4) Removing UI elements

I removed the ‘Protection Enabled’ badge completely as it didn’t offer any real value, and was simply distracting to look at. The users have already signed-up for the app trusting its in-built privacy and protection of their identities.

The ‘Description’ is now redesigned to be Custom Note. A user can add a note while creating a proxy email, or once the email is generated (by expanding the card and adding it therein – more of than later below)

5) Progressive Disclosure

The original UI was cluttered with links (such as ‘More’) and awkwardly placed delete icons. The redesign uses progressive disclosure for:

a) Primary actions only: The most frequent actions (such as copy, favourite) visible.

b) Secondary actions: Such as logs, export, and feedback are tucked away in the kebab menu.

c) Destructive action: The delete button is now placed inside the card. This prevents accidental deletions and keeps the interface clean.

Design iteration 1:

The first step was moving away from the system-first to a user-first design. To drive home this point, I made a few but important changes to the copy of the column headings and the field itself.

A) The old design has ‘Real Email’ as the heading of the real email address. In the redesign, I changed it to ‘Forwarding to’ for 3 reasons:

a1) It describes the behaviour: Users don’t think a certain proxy email is linked to a certain real email. In fact, they think: Where do these emails go?

‘Forwarding to’ answers that user’s question in the head.

a2) It befits the proxy email mental model better: A proxy email is basically an inbox rule with an alias. ‘Forwarding to’ reinforces that the proxy is just a transitional pipe connecting third-party sites to your real email.

a3) The field now supports changing of the forwarding email too.

This means that once the proxy email is generated, users are not locked in to the same email address. They can easily route any forthcoming emails to a new forwarding address.

B) I also changed the copy ‘Received emails’ to ‘Emails forwarded’ – again, because ‘Received emails’ feels lazy and passive. Users may think “Good, 3 emails received but has the app forwarded to my real email address?”

‘Emails forwarded’ signifies the system has already done its intended work. It received emails from another website, and has already forwarded them to your real email address. That is what reassures the user.

Design Iteration 2:

Initially I had a toggle button to denote the status of the proxy email. An active proxy email had the toggle ‘on’, and users may click on it to shut it off (essentially deactivating the proxy email)

However, this felt risky as a user may unintentionally click on the toggle without realizing, thereby disabling it; and wonder why they aren’t receiving emails in their inbox.

To address this, I redesigned the status of the proxy as a label chip that a user intentionally controls by expanding the card first and then deactivating the toggle inside. Supporting helper text beneath the toggle ensures users clearly understand the action they are taking, eliminating unexpected surprises.

Design iteration 3:

Recall how users had the option to add meta-data like a note or tags, while they were creating an alias (you can view that here)?

But what if they created an alias in a hurry, and now want to update it with a memorable note? I wanted to provide them a place to do so in the generated card. This is the first of its design iteration – a Custom Note label placed below the proxy email:

However, this design doesn’t help much. It only says that a note exists (indicated with a green dot) but doesn’t reveal what the note says. To view the note itself, the user has to expand the card fully simply to read what it says.

I therefore decided to add a little truncated text right below the proxy email.

This helps a lot, but the custom note label looks redundant. The user can already see that a custom note is added (as he is reading the truncated text). I therefore decided to remove the custom note label entirely and let the truncated text do the heavy lifting.

For proxy emails that don’t have a customized note, the text simply reads ‘Add a custom note’ – providing users a visual cue that the proxy email doesn’t have any note attached and they can add a note to the card if they want to. This is how it looks by default:

Tags:

For the tags, I realized that adding a tag label under the note label (when the card is at rest (i.e. not expanded) creates a visual imbalance.

I therefore decided to not include any indication of adding a tag, because most users add a note as that is the natural way of remembering things. Once the card is expanded, they can add tags which will still show up on the card at rest.

In the expanded version of the card, the user can add both custom note and tags, which will automatically populate the card at rest – so they can view the truncated note (that provides cues as to what the proxy email is about) and the tags too.

Design iteration 4:

The old design has a ‘Created at’ date placed at the bottom of the card.

This is definitely an important piece of information for the user, as it helps them recollect a proxy email when searching for it later. However, is that the only information that is helpful? I think there are some more stats that are equally helpful to make proxy emails useful.

I gathered a list of relevant meta-data such as:

Last email received
Category
Most recent sender
Total emails blocked
Domain reputation score
Email created on
Top sending domains
Spam flagged
First email received
Last updated
Average emails per week
Last block event
Time since last activity
Last disabled
Total emails blocked

Of these, I narrowed down to the most relevant ones:

a) Email created on:
Useful for tracking how long an alias has existed. Also helps identify legacy aliases that might no longer be needed.

b) Last updated:
To understand if any settings related to the alias were last changed (e.g. forwarding address, status, notes). It helps to audit the alias, and to check if something was altered recently (e.g. in case of compromise).

c) Last email received:
Timestamp of the most recent email received on that alias. Useful for cleanup – e.g. no emails for 6+ months, therefore qualifies for deletion. Also, helpful in spotting aliases that may have become targets for spam.

d) Total emails blocked:
The total number of emails that have been blocked for this alias (due to manual blocks, rules etc.) It helps quantify how much unwanted mail an alias has attracted. Also, useful for identifying aliases that are being abused or overexposed.

e) Spam flagged:
The number of emails received by this alias that were flagged as spam (either automatically by the system or manually by the user). It helps distinguish between legitimate usage and spam-heavy aliases.
Also, helps indicate whether an alias has leaked or been shared beyond its intended purpose (such as 3rd party sites selling user data).

f) Last disabled:
Helps answer the question: why am I not receiving emails from the sender? Also helps in identifying aliases that have been disabled too long ago and require permanent deletion from the system.

After updating the text to be shorter, I had the final meta-data I wanted for each proxy:

Created on
Last updated
Last email received
Emails blocked
Spam flagged
Last disabled

By showing these data points, I provide users with a tangible proof of the app’s value – and that is to protect their inbox.

Design iteration 5:

The split-box design for ‘Store Password’ and ‘Used On’ is not great design. Not only having two separate boxes unnecessary, but they also occupy wasteful space while being visually loud without a good reason.

This is the old design:

I decided to combine both of them in a more manageable tabular format.

This works well because it sets the right mental model. Instead of just ‘Used on’, the text now reads ‘Alias used on’ thereby setting the correct context and removing any ambiguity. It puts the focus on the alias – which is the primary objective of the tool.

The tabular format is better (instead of the split-card design) because the data is now grouped and contextualized – where’s the alias used on (i.e. which website) and if there’s any password generated and stored (in the password column). The table makes an obvious relationship between website and stored password. This makes scanning easy and scales naturally.

The password is now demoted-secondary visually, which is good. It doesn’t look like a password-manager anymore, it isn’t screaming for attention and the small action icons are contextual, give control over to the user, without getting in the way.

To reduce confusion, I renamed the column heading from ‘Password’ to ‘Website account password’, clarifying that the stored password belongs to the external website rather than the ProxiedMail app itself.

Design iteration 6:

In this iteration, I turn my attention to the action buttons at the bottom of the expanded card. For reference, the current state is shown below:

a) As a redesign, I ensured clear separation between action and state. Actions are now on the left, state is on the right.

Here are the action buttons:

Create reverse proxy
Create AI agent
Delete proxy email

The state is the ‘Proxy status’ toggle, to show whether the proxy is in the Active or Inactive state.

b) The meta-data is no longer polluting the action space. The ‘Created at’ meta-data is now part of the row that sits above, with other related meta-data.

Users instantly know what is informational vs interactive. Scanning is faster, and the UI feels calmer and more intentional.

c) The ‘Send/Contacts’ button from the previous design has been relabelled as ‘Create reverse proxy’ to accurately reflect its function.

Creating a reverse proxy generates an additional proxy email linked to the primary proxy. This reverse proxy can be used to initiate email conversations directly from a personal email client (such as Gmail), and ensures that the user’s real email address remains hidden while only the reverse proxy address is visible to recipients.

Because this action represents both the core use case and a natural progression of the proxy email workflow, it is emphasized as the primary CTA within the expanded card.

The ‘AI/Bot’ button has been renamed to ‘Create AI agent’ to more accurately reflect its purpose:

Selecting this action creates an AI agent that responds to emails routed through the proxy, on the user’s behalf. The button is styled with lower visual emphasis, indicating its availability without competing with the primary call to action.

Both actions are clearly labelled and supported by a “What’s this?” tooltip, providing additional context for users who want to understand their functionality in more detail.

Non-technical users won’t panic, while advanced users can still find these power features easily.

d) The “Delete proxy email” button is clearly separated and properly styled destructive. It uses a distinct red icon, helping prevent accidental data loss.

It isn’t visually competing with the main CTA, and readily available for users who want to delete a proxy email.

The footer finally has a clear hierarchy visually and semantically.

Primary action: Create reverse proxy (blue, far left)
Secondary actions: AI agent, Delete
Global state: Status toggle (far right)

This redesign is meaningfully better UX.

It is cleaner, calmer, more scalable, more respectful of user intent, more aligned with modern product patterns.

Most importantly, it no longer feels like everything’s dumped into one footer, but rather feels like a well-structured control panel for a single proxy email.