CuriaSport Login & Registration

Role: User Experience, User Interface Design and Front-end
Tools: Ruby on Rails, Inkscape, paper prototypes

Problem

Curia Sport Center booking site (sports centers, soccer fields) used to have one daily support call from users complaining about password reset “I can’t change the password, could you change the password for me?”.

It seems that users were not able to recover their password because it was not so clear to them what to do next or if they had requested password recovery at all. Users didn’t know they needed to check their email, although the message was visible on the interface.

Password recovery interface before re-design. Note that the label reads “Begin session” in Spanish instead of “Recover your password”

This is what the users saw after they tried to recover their password.

Above are some screenshots of the old user interface, miss-label input that reads “Begin Session” instead of “Recover your password”. After the first interaction, there is a new message with instructions, but in the same color, users dismiss this information (everything looks the same). We later saw that users were trying to do this same step over and over, they thought it was not working, but they only needed to check their email.

We evaluated the whole user flow and it was plagued by pain points, we also discovered another priority, the registration form. The registration form was too long and users were not able to select their “location” (because it was not listed in the drop-down menu), some users complained that they were not able to register at all using their cellphones as well. It was really something, users couldn’t even create their accounts; they were unable to use the application.

Challenges

Convincing my team to work first on the user experience and paper prototypes for this recovery password before moving on to other backlog items was really difficult. They were worried about doing all these design-related extra steps: user flow, personas, and paper prototypes. Nevertheless, they were really happy to collaborate once they saw all the blockers users experienced during the recovery password process and registration. They even provided ideas and were really involved in the solution.

User flow showing real pain points for the users or death ends (apologies for the low-quality photo).

Sample “Persona” – User that logs using his cellphone

Metrics

During the sprint planning meeting, we chose the goal to help the user have a good registration and recovery password experience. Because we were also fixing the registration form, we wanted to check:
1. Number of registered users.
2. Time that the users spent during the registration process.

Metrics are the key here, we checked the strategic plan for the product before with the Marketing Director. They wanted to measure the number of transactions, and that was related to user registrations as well (users can’t perform transactions if they can’t register). The marketing team didn’t have this information and was looking forward to finally having that information to make decisions.

The final result

We implemented the team’s ideas, the Sprint planning meeting was a working section, we also decided the amount of time needed to each item in the Sprint backlog using Planning poker.

Paper prototypes and user flow with the proposed solution (apologies for the low quality photo).

Sample sketch for the illustration message of “Success”

After solving the main pain points for the users, the support team stopped receiving calls to manually reset their passwords. We also improved login and registration time and experience with this new user interface — it was faster and intuitive.

New login screen, sport center booking website

Sport Center booking site, new “restore password” user interface

Registration form, the user was able to use social media accounts or email registration

Registration form after re-design looks more clean and we were able to remove some optional fields

What we learned

Usually support requests show really significant issues that require our attention.
It was wonderful to see the whole team involved, creating ideas. Having a single goal to focus on really helped.
We didn’t gather the number of transactions or registered users available before starting these modifications. This means that although we know that the design seems to work because the support team didn’t receive more recovery password tickets, it might be because users were not using the application at all. If you don’t have evidence of what your design achieves, it’s meaningless, and not visible to the stakeholders and management.
We did include a task into the sprint backlog to get these metrics beforehand, but this particular item required extra programming and the CEO included other items with high priority into the sprint backlog (we didn’t know any better and the team agreed on that). So this task was never performed because we ran out of time.