UX refactoring on subscribe form
We start to publish articles, related not only to business models but to UX also. Let’s start with refactoring UX on a well known subscribe form.
Most of you, of course, face to the problem, when a business problem must be solved in the existing system, but you can’t break anything or redesign from scratch. In the vast majority of cases, all attempts (especially in large companies) are smashing at stages of coordination, development, security and other related systems and departments.
So, we’ll call “UX refactoring” the process, when you change only your part in an interface. Isolated. Don’t touch backend or even API of the main system.
Refactoring and redesign — not the same things. Not mix it.
So, let’s back to subscribe form. It was a rainy autumn evening. We have taken standard form of two elements (input field and a button) and drawn what transitions could be between screens.
We get six screens, two of them are the result of the user error (defects):
- In the beginning, when the user tries to subscribe with an empty email field;
- When the user already has been subscribed and want to unsubscribe, he clicked not on the button “Unsubscribe”, but on the input field.
We have set the goal to leave the same elements, with the same functionality, and change nothing, except the site (layout, maximum). By applying “signs and properties” conception, we wanted to change functional, to vanish this two defects.
Once again, please note that this is not a redesign of the subscription form. This is refactoring, maximally isolated changes, concerning only on UX.
Here you can see the whole prototype in Figma:
Six screens transform to four. Plus, there are some very interesting effects.
But, step by step. Below is an analysis of the screens, with comments on the image and in the text.
I. The start screen is left unchanged. We consider that it must be left as is, users got used to it.
II. The email entry screen has totally changed.
The “Subscribe” button, instead of becoming inactive (disable), becomes part of the input field. Just text that can’t be clicked.
Diving into the inside the input field, we found another great way to prompt the user: just behind the cursor, we put the symbol that is expected at the moment for successful validation. In the picture, you see the “@”, and after its input should be at least one character (number or letter), then you can display the point.
III. The screen with the entered email is pretty standard. When the validation is passed (its analysis we left outside the example), the “Subscribe” button again becomes a button. Plus changing the text above the input field, prompting action
IV. The opposite effect was shown further — the input field became part of the “Unsubscribe” button, after the fact of subscription.
The user can click at any place of this big button: on the email, or on the button “Unsubscribe”. The user will be taken to the previous screen. The only difference is that the focus will be on the button. If desired, you can subscribe again to the same address, and enter a new one. If you click on the input field, you get to the second screen.
The result of the refactoring:
There was removed the possibility itself to get into an error state. The system itself “holds” the user’s path, leading it in the right direction.
In conclusion, wanting to say: Yes, it was possible to make it even more interesting and better. But it will be a redesign of the form and there the result will be radically different. And, perhaps, require changes in related systems.
Second moment. The example does not cover validation, micro-interactions, related texts, and the rest of the business process. So there is also quite a vast field for improvements.
And how do you cut off a user’s dead-end paths and keep it on the main road?
Special thanks to Wova Roodnyy for ideas, consultations and the elaboration of the logical model
