Redesigning the stomt sign up
Acquiring new users can be tough. It involves targeted marketing, offering the right service/product at the right time and requires a seamless checkout/sign up process. If you have got users as far as the sign up, you have done a good job! Now, on the last meters, you should not screw it. 😏
In the past days, I worked on the sign up process of stomt. Stomt is an innovative feedback platform which allows anyone to express wishes, discuss them and support movements. Fortunately, our iOS developer already worked hard to improve the sign up process and provided a video which largely inspired the redesign for the web-based overhaul. Shout out to @H3xept!
The legacy sign up
The old registration allowed to sign up with an email address or with an account from a social network. In the latter case, the user would be redirected to the particular service. In case of the email registration, the process asked the user for a full name, a unique username, email address and a password.
Here is a short record of the old sign up to get a better impression.
Pro’s
- Feedback: Every form field error can be identified.
- Alternatives: You can sign up via Facebook, Reddit and Twitter.
- Engagement: The form incorporates engaging language.
- Simplicity: The form eliminates as many fields as possible (sure, we could discuss about “Full name”)
Con’s
- Accessibility: The intention of the tooltips is to help and provide feedback. Unfortunately, tooltips mask the previous input field. Even worse, the user can not navigate to the previous input field with the pointer.
- Too much information: The tooltips contain too many messages.
- Focus: Sign up via third-party accounts is displayed even if the user decided to sign up with email address (okay, opacity reduces the attention already)
- Surprises: The submit button appears just if the form was filled out correctly. This surprises and might confuse some users.
The new Sign up 🙌
Clearly, there was room for improvement. We started with splitting the sign up. In a first step, the user should decide whether an existing account should be connected or a new one should be created. This allowed us to get rid of the right sidebar and focus fully on the form interaction.
We removed all tooltips and moved the feedback messages below the input fields. At all times, an input shows at most one feedback message. This simplified the layout and prevents the user from being overwhelmed. The feedback messages are of different type; from engaging snippets to (a)sync validation errors over to success messages.
Inspired by the floating label pattern, we developed our own mixin to re-use it across the form. We spent a good amount of time to work on smooth animations for the feedback messages and the floating label.
Finally, we decided to show the inactive submit button right away. But we kept the neat message next to the submit button as well as the slight animation because it fits perfectly in our concept of this interactive and engaging sign up process.
Here is a short record of the brand-new sign up. Give it a try!😀
What about mobile?
The old sign up for mobile shared almost anything with the one for desktop. In fact, the sign up was the same. The only difference were the layout to better fit on smaller screens in portrait mode.
However, all of the aforementioned problems also applied here. In addition, much screen space was wasted and forced the user to scroll. On some devices, revealing the digital keyboard caused weird scrolling back and forth. This was motivation enough to question the overall process.
Again, a short record of the old sign up to get a better idea.
Inspired by the iOS prototype, the team decided to split the mobile sign up even more. Every input field got an individual page. Navigation between pages received smooth sliding animations.
At the bottom of the screen, arrow buttons were added to allow seamless navigation between pages. Event handler for the Enter key were added which allow to jump to the next page without leaving fingers from the keyboard.
Animations of the feedback messages were tweaked by making them fly in from the left. As a polish, positions and margins were fine-tuned to prevent “jumping” and other unpleasant UI behaviour.
And here it is: the brand-new sign up for mobile. Give it a try!
Responsive vs. KISS
To make the sliding views compatible with the browser navigation (back & forward), we added dedicated states. At this point, the implementations of the desktop and mobile sign in started to diverge. Many conditionals had to be added to share the controller and template.
We decided to build separate components and keep it as simple as possible while sacrificing DRY (Don’t Repeat Yourself) to some extend. However, as part of the redesign, we refactored everything into small modular components to avoid as much redundancy as possible. Without responsive breakpoints, we managed to extend our routing module to serve the suitable (desktop vs mobile) component depending on the screen size.
The separate components could come in handy as the project starts to utilize lazy loading. This could reduce bandwidth especially for users from mobile devices because the desktop sign up component must never be retrieved from the server.
What are your thoughts on this? Would you always go the responsive way? Please let us know! 🙂 We possible publish a dedicated article on this topic in the future.
🔀 Cross posted on the stomt blog
Sebastian offers IT coaching and consulting at synsugar. He’s passionate about web technologies and likes to contribute to open source. Connect with him via @s_henneberg or @synsugarIT.
