Craig Wright is an experienced technical writer based in Chesterfield, UK. He hates writing about himself in the third person, so I shall stop now.
Always interested in new content writing opportunities. Remote working preferred.
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.
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.
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:
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
There's quite a few user journeys to cover here, so I'll break them down into separate sections.
Some users might not want to create an account. People can be reluctant to provide their details to apps they haven't used before.
Text (Sign up screen)
Headline:
Sign up to Car Hunter
Body:
To find the best car prices in your area, we need your details. Your info is only used for searches.
Buttons:
Sign me up
No thanks
Comment:
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.
Text (No sign up screen)
Headline:
We're sorry to see you go
Body:
If you change your mind, you’re welcome to come back and use Car Hunter to find great car deals.
Comment:
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.
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:
Text (Name details screen)
Headline:
Tell us about you
Body:
Please tell us your name.
First name (field)
Last name (field)
Button:
Next
Comment:
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.
Text (Name error screen)
Headline:
Tell us about you
Body:
Are your name details correct? Our app thinks you have entered an incorrect name.
First name (field)
Last name (field)
Buttons:
Try again
Contact support
Comment:
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.
Nice and simple for asking for the user's address.
Text (Address screen)
Headline:
Your address
Body:
We need your address to find car deals in your area.
House number (field)
Street (field)
City/Town (field)
Post code(field)
Buttons:
Next
Text (Address error screen)
Headline:
Incorrect address
Body:
We don't recognise your address. Please complete all of the fields.
House number (field)
Street (field)
City/Town (field)
Post code(field)
Buttons:
Next
Contact support
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.
Next up, a screen that asks for the user's number and also an error screen in case the number isn't recognised.
Text (Phone number screen)
Headline:
Phone number
Body:
Provide your phone number so that we can contact you offline if needed.
Mobile phone number (field)
Buttons:
Next
Text (Phone number error screen)
Headline:
Wrong number?
Body:
Is the number correct? Our app thinks you have entered an incorrect number.
Mobile phone number (field)
Buttons:
Next
Contact support
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.
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.
Text (Email screen)
Headline:
Email address
Body:
We need your email address for your Car Hunter login. Don't worry, we won’t send you marketing.
Email (field)
Buttons:
Next
Text (Email error screen)
Headline:
Wrong email?
Body:
We can’t recognise your email. Check that it’s correct or use a different address.
Email (field)
Buttons:
Next
Contact support
Text (Verification screen)
Headline:
Confirm your email
Body:
We’ve sent you an email. Click the link in the email to complete your registration.
Buttons:
Contact support
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.
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.
Text (Sign up success screen)
Headline:
All done! Now find a car
Body:
You've completed our sign-up process. You can start your car search now!
Buttons:
Find a car near you
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.
I figured the app would need a generic error screen in case anything goes wrong.
Text (General error screen - 404)
Headline:
Oh no, a blowout
Body:
Something's gone wrong with our app. Please try again or contact support for help.
Buttons:
Try again
Contact support
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.
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.
Text (Delete account screen)
Headline:
Are you sure you want to leave Car Hunter?
Body:
If we remove your details, you will need to create a new account for future searches.
Buttons:
Yes, remove my account
No, keep my account
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.
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.
Craig Wright is an experienced technical writer based in Chesterfield, UK. He hates writing about himself in the third person, so I shall stop now.
Always interested in new content writing opportunities. Remote working preferred.
Registered Number: 08029184
Straygoat logo design by Bristol graphic designer, Nik Jones.
© Straygoat Writing Services Ltd.