Daily UX writing challenge. Day #15

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.
‍

‍

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.

‍

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:

‍

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.

‍

Getting user's address

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.

‍

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.

‍

‍

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.

‍

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.

‍

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.

‍

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.

‍

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.

‍

‍

General error screen

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.

‍

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.

‍

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.

‍

‍

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.

‍