Due to various NDAs, I am not permitted to share actual designs and real-world improvements I’ve made at the companies I’ve worked at.

Instead, I’ve done my best to take my work and translate into this portfolio using low-fidelity hypotheticals that mimic the design thinking and attention to UX that is a core part of my mindset.

The spirit of my work is here, but certain details have been adjusted to protect security and intellectual property. Please excuse any vagueness in my explanations as I attempt to balance propriety while showcasing my abilities.

Internal CMS

This tool was built with minimal time in a utilitarian fashion. As new features were added, its design ballooned as options were tacked on without a thoughtful discussion. The end result was an overwhelming experience that made it hard for the team to do their job.

One of my main immediate priorities was identifying the necessary components and stripping out anything that wasn’t helpful. Working with stakeholders, we realized that about half of the information on the screen could be removed. By reducing the amount of information presented, we could ensure that the important bits were not missed in a sea of data.

the original version

For instance, the login history showed a column for zip code that no one ever used in daily routine. There were about 8 different indicators that an account was a different tier that could be condensed into a single “Level” marker.

my proposal

Sweeping away the unnecessary information dramatically improved readability, but that wasn’t enough. We needed to rethink the way the tool actually worked, and in order to do that, I went through each account maintenance process and broke it down.

From a high level, there were a few of ways I evaluated each process:

  1. Time it takes to complete – This was deceptive because skilled agents were able to complete intensive processes very quickly. A beginner would take much longer to recall each step and reference the correct information due to the various separate pages. In high-turnover roles, it’s important that onboarding new associates is as frictionless as possible.
  2. Number of clicks required – This was more revealing, and frankly one of my favorite ways to evaluate any UX flow. Many of the processes the team worked on required upwards of 20 clicks when it was technologically possible to reduce that number to 5.
  3. Cognitive load of process – This was another aspect that was tougher to reveal given the seniority of the associates on the team, but as a newcomer, I was able to better evaluate from a trainee’s perspective how we could boil everything down.

From there, I proposed a one-page, process-driven design that combined the multiple elements of certain procedures. Condensing the separate pages into one would cut down the friction and enable associates to view all of the relevant data at once.

In the first phase of this roll-out, we focused our attention on the login page, dramatically simplifying the information presented, and translating some of the more technical aspects for basic understanding. For instance, User Agent was converted into Device information which tells a similar story for associates looking for a high-level view of the account.

The response to this was gratifying. We made it an optional toggle and found that most associates chose to opt-in, enjoying a simplified interface. Interestingly enough, we found that more advanced specialists would leave the simplified version as the default while occasionally toggling the User Agent setting for greater detail. However, no one who toggled “zip code” off ever turned it back on.

2FA Reset Flow

There’s a security measure called 2-factor authentication where users login with both a password and a 6-digit code generated by a separate device (usually a phone). It’s a great way to protect your more sensitive accounts, but the additional layer of security comes with a pitfall – the loss or decommissioning of your device. While users are always encouraged to backup the 16-character key that can restore 2FA access, it is a common occurrence for most CX teams to field many inquiries from folks who cannot locate this information.

Working with Risk, CX, and Security, I was able to propose a new approach. But first, it was critical to understand why the current process was in place, and to map out that flow. Below is one flow in list form, but we mapped out 6 additional flows and 6 subsequent solutions:

  1. Customer visits login page after 6 months of inactivity. They’re prompted for the code but have gotten a new phone.
  2. Since there’s no other option, the customer decides to contact support using that button hidden in the footer.
  3. Once the customer fills out the form, an agent manually sends a verification key and a list of account questions.
  4. The customer replies with the required answers, and is either prompted with additional questions or waved on to the next step.
  5. An agent manually locks down the account and opens up an upload portal so that the customer can upload a verification image.
  6. The customer uploads the image and replies back so that the agent knows to check the account.
  7. Agent completes a series of security checks and then allows the customer back into their account.

What an absolute nightmare for all parties involved.

The team had a list of proposals but they were “quick fixes” that would not help the underlying issue: this process needed to be almost entirely self-service.

Regardless, we compiled both a list of quick fixes (sending the code automatically, asking the necessary questions at once, updating the form to get more information ahead of time, adding example images to the content, etc.) and the dream process:

  1. Customer visits login page after 6 months of inactivity. They’re prompted for the code but have gotten a new phone.
  2. Underneath the code field is the option “I don’t have this” which the customer clicks. 
  3. A confirmation link is automatically emailed to the customer, who clicks it, enters their login credentials, and is prompted to upload a verification photo. 
  4. A queue of uploads is reviewed by a security specialist. Any strange uploads receive follow up questions, but the majority of cases are approved within 12 hours. 

This process proposal retained much of the security from the original process while dramatically reducing friction and increasing resolve time 8x. It did however increase our risk tolerance by reducing the mandate for account questions for all queries. Additionally, as a result of the increased resolve time, there was a higher risk that we’d let an attacker in before the true account owner would be able to alert us.

To mitigate these concerns, we began an initial phase with the questioning component reduced based on a sophisticated risk analysis. We also revamped the content to clarify the asks, and ensure that examples were provided at every step.

As a result of our initial efforts, resolve times were cut in half and our insult rate dropped. Encouraged by these findings, additional phases will be implemented.

Rate Limiting

Sometimes, little issues slip by the wayside when folks try to rebuild everything. In one case, I identified a pattern with a small portion of customer complaints that seemed like the issue could be eliminated with a few tweaks. Here’s what customers were seeing:

a truly inscrutable error

As you can imagine, this was not a good experience. It was confusing, scary, and did not provide enough information. Customers would write in on a daily basis to wonder if they had done something wrong.

And the team would send a blanket statement in return. The response basically said “stop clicking the login button multiple times” but it was also written by someone with more technical background than our users.

My approach to this was three fold:

  1. Inform the engineering and security teams of this issue.
  2. Assist them in identifying the cause (clicking multiple times), and work with them to adjust the rate-limiting logic accordingly.
  3. Completely update the error page.

While updating the system logic dramatically reduced these occurrences to start, the true bullet was the page itself. This prompted some discussion between the various stakeholders as well as we wondered if we could avoid using the terms “banned” and “error”. Whenever possible, I try to use language that doesn’t instill fear into the users.

Not only does this provide context in easy-to-understand English, but it provides actionable information (return in 30 minutes and don’t click so much) so that the customer doesn’t encounter the same error.

In the world of technology it’s easy to get caught up in the jargon and forget that most of your users will probably have a limited understanding of your terminology. Whenever possible, use basic language to ensure a universal message.


It’s easy to say “keep it simple” and much harder to do so. In the words of Blaise Pascal, If I’d had more time, I’d have written a shorter letter.

Boiling down the noise into what’s essential is so hard, and demands a deep understanding of the product and the customer base. Immersion in the tools and systems is very helpful in bolstering your knowledge, but you still need to talk to your customers.

Even more important is to watch your customers, and how they work. In the world of UX interviews, folks might just be telling you what they think you want to hear, or simply not truly understand what they need. What they say is one thing, but what they do is king.

Watch how people use your product, and don’t interrupt. You’ll learn so much.