CuriaSport Login & Registration
Role: User Experience, User Interface Design and Front-end
Tools: Ruby on Rails, Inkscape, paper prototypes
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.
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.
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.
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.
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.
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.