This is part of the 15-day UX Writing Challenge presented by Daily UX Writing.
Scenario: A user is creating an account. When they come to the step where they are asked to enter their name, they get an error message. A fraud detection software thinks their name is fake — but it’s wrong 5% of the time.
Challenge: Write an error message that prompts them to fix the error without shaming them for having a fake-sounding name.
Message: 45 characters max
Task & Goals
Suppose you’re signing up for an app and you’re asked a bit about yourself. You write down your name and press submit, but suddenly you get an error message saying your name is invalid. How does that make any sense? It’s your name. Who decided that your name, the one you’ve used all your life, is actually wrong?
For some of you that grew up writing papers on Microsoft Word, you might have experienced something similar to this. No, Microsoft Word, my name is not spelled incorrectly; you just can’t detect non-Anglicized names.
Note: I want to preface something and say that this design feature doesn’t make any sense to me. I understand that security is important. However, when it comes to creating an account, a name shouldn’t be the sole factor in fraud detection for some of the following reasons:
- multiple people can have the same name
- names are often detected for fraud after an account has been made
- names can be spelled differently despite having the same pronunciation
- because of the first reason, fraud detection should rely on more information than just a name
- marking non-Anglicized names as invalid is racist and demonstrates bias in the fraud detection algorithm
However, despite my quarrel with the design, this is our task. With that, our goal is write an error message that prompts the user to reenter their name without telling them that our fraud detection algorithm marked it as invalid.
Concepts & Ideas
Before we start our copy, let’s discuss how this feature might be implemented. I know as UX writers, we don’t need to understand computer algorithms. However, in this case, we should at least understand a bit about how it works to understand the context of how the user will experience its effects.
During my time as a software engineer, I wrote a lot of code that dealt with user authentication. These algorithms take inputs and quickly sort through our databases to see that for:
- users signing up: whether another account is already using their email or username
- users logging in: whether their email or username is in our database and spelled correctly
Since we know that our algorithm is wrong 5% of the time, that means that we’re playing a probability game. If a user enters their name, presses Next, and gets an error message, then according to our algorithm, they could technically reenter it in the exact same way and not get an error.*
*Note: If you’re curious about the odds of getting an error the second time, it’s .05 x .05 = 0.0025 which is 0.25% (because 5% = .05)*
**Note: If the user gets an error a second time (which is highly highly unlikely), then this creates a really bad user experience. But this assumes that our algorithm is indeed at fault and our user does have a valid name.
With all that said, here’s my copies:
Idea 1: Please enter your name again.*
Okay so this message seems pretty simple. Our algorithm has detected that the user’s name is potentially fake. So, we ask them to reenter their name because there’s only a 97.75% chance that our algorithm will not flag it as fake again.
Here’s what it would look like:
*Note: I chose the word “enter…again” instead of “reenter” because for non-native English speakers, seeing “reenter” may be confusing.
Idea 2: Please confirm you name.
This one is a bit more subtle because we’re not alerting the user that our algorithm flagged their name. We’re simply asking them to confirm their name; in the back, our algorithm will run a second time and likely allow the user to proceed.
Here’s how it could look:
*Note: Option B violates the challenge’s constraints, but it’s something I thought could be another viable approach.
If I had to choose between the two ideas, I’d opt for Idea 2 (Option A) because it’s more subtle. Maybe this is just a personal bias and ignorance of the algorithm, but users should not be flagged for fraud on the sole basis of their names when creating an account. Idea 2 allows for us to double check by asking the algorithm to confirm its results a second time.
Idea 1 with the red highlights seems problematic to me because it’s alerting the user that there’s an issue and doesn’t align with our message. But again, how can a user’s name be wrong if we have no record of them?
Conclusion
My issue with the fraud algorithm feature illustrates why it’s important that UX writers are part of the product development dialogue. When we have full context as to why certain features are being implemented and understand what is at stake along with the experience that we’re attempting to develop, we’ll have a better idea of how we can write our message to align with those goals.
This challenge allowed me to utilize my engineering experience along with my growing UX knowledge, which is refreshing and I enjoyed bringing a multidisciplinary approach to it.
How would you tackle this challenge? Let me know your thoughts in the comments. Again, I welcome any constructive feedback that you may have. Thanks for reading!
