As a technical writer, I sometimes do UX writing for the products I work on. I decided to look into UX writing as another service I could offer, so took the daily UX challenge at https://www.dailyuxwriting.com.
Here's the day 15 (of 15) challenge.
Scenario
Day 15 - write a registration experience for a product for people who are shopping for cars online.
The service helps registered users find the lowest price by contacting and comparing prices from three competing local dealerships.
Challenge
You can write as many screens as you feel is necessary to provide a compelling experience, but you must collect (in any order) all of the following information from users:
Home address or valid mailing address
Phone number
Valid email address (be sure to include a verification step)
Full name
Be sure to include unique error messages for incorrect entries for each screen.
Character constraints per screen (both challenges):
Headline: 45 characters
Body: 100 characters
Button: 25 characters
My answer
There's quite a few user journeys to cover here, so I'll break them down into separate sections.
User doesn't want to create an account
Some users might not want to create an account. People can be reluctant to provide their details to apps they haven't used before.
Comment (sign up screen):
For this one, the character count is tight. I wanted to emphasise the main benefit of the service - finding cars at good prices locally - and also reassure the user that they aren't going to be swamped with marketing.
Comment (no sign up screen):
For this screen, I went with something quite simple. I also wanted to give the user an easy way to go back while also encouraging them to change their mind. I also added a contact support button, in case there's something wrong and the "sign me up" option on the first screen takes them to this one by mistake. It also might encourage the user to contact support if they want to use the service but have specific reservations about making an account. If these reservations came up repeatedly in support tickets or calls, the app could link to a help screen that puts the customer at ease.
Getting user’s name
Originally, I considered adding all the user details to a single screen but it looked a little cramped. The limited space also made it tricky to display errors without overlaying notifications, something I didn't want to use.
So for the name details I went with this:
Comment (name details screen):
For asking the user's name, I went for First name and Last name as I've heard "surname" can confuse people. I normally avoid using "please" in UX text, but "tell us your name" felt too much like a police interrogation, so I added the "please" for a softer, more polite tone.
Comment (name error screen):
I know there can be problems with using first name and last names as some cultures use different formats. That must be frustrating for those users. So I've tried to make it clear the error is the app's fault and not theirs. There are options to try again in case it was a simple error and also to contact support in case the form isn't coded for their name. For example, if their name contains characters that are not supported.
Getting user’s address
Nice and simple for asking for the user's address.
Comment:
For getting the address details, I kept it simple: a field for each part of the address. I also wanted to emphasise that the address is needed for the search. My intention with this is that if a user wants to find a car local to an address that is not their home address, they can enter a different address for the search. With the error page, I wanted to make it clear that the app can't recognise the address, so removing some of the blame from the user. I also think it is important to include a "contact support" button in case the user is entering a valid address format that the developers have not accounted for in the code.
Getting user’s phone number
Next up, a screen that asks for the user's number and also an error screen in case the number isn't recognised.
Comment:
With these screens, I've kept the headlines simple, so it is obvious to the user what is needed. The text on the screen that asks for the number explains why it is needed. The text on the error page puts the emphasis on the app not recognising the number that's been provided. Again, I've included a contact support button in case the number is correct and the app is at fault. I've specifically asked for a mobile phone number because I've said the number may be needed if the company want to contact the user offline. By adding "if needed", I'm trying to assure the user that it is only used if there is a problem, not for marketing etc. If the character count had been higher, I may have explained that more clearly.
Getting user’s email address and verifying it
The final bit of information to retrieve is the user's email address. The task also states that I need to have an error screen and an email verification process.
Comment:
With the screen that asks the user to enter their email address, I've kept it simple but also wanted to reassure the user that their email won't be used for marketing spam. On the error screen, I've followed the same pattern as before, putting the blame on the app rather than the user and giving the user an option to contact support.
The verification screen is a simple message that tells the user to click the link in the email that is sent to them. I've included an option to contact support in case the email doesn't arrive. I'd imagine a help center page could explain to look in spam folders etc. It would be nice to include that information in the app itself, but the character count is tight. Maybe I could have added an extra screen in case the email doesn't arrive.
Registration a success
When the user clicks the link in their email, they will be shown a registration success screen. They will be logged in automatically and can start their search.
Comment:
For this one, I've repeated the word "now" for emphasis and to encourage the user to search now, rather than quit the app and forget all about it.
General error screen
I figured the app would need a generic error screen in case anything goes wrong.
Comment:
I've used "blowout" to tie in with the car theme, and again, have made it clear the error is with the app, not the user's actions. The call-to-action buttons are to try again or to contact support. Trying again can be frustrating if the user has already tried a couple of times, so having the option to contact support directly might help to stop them quitting and looking elsewhere.
Deleting an account
As the app has taken the user's personal details, it needs to have a screen for removing them. I was undecided about where to put this as it isn't really part of the sign-up process. So I guess it would be better if it was available from the menu.
Comment:
Here, I've let the user know the consequences of removing their account. If they really have no intention of using the site, then it makes sense for all parties that their information is removed. But if they think they might come back later, leaving their account in place will save them the hassle of starting a new sign-up.
Looking for a UX writer?
Do you need a UX writer for your project? I'd love to hear from you. I've worked in software teams for most of my career as a technical writer and have helped improve UX content as part of my role. I'm also trained as a content designer and have worked as a copywriter too. So you can hire me for long copy, short copy, microcopy, whatever you need.
I'm always interested in new content writing opportunities. Remote working preferred.
