My role in the project

Designer Lead responsible to all the deliverables. Research, UX and UI. Working with an agile team composed by PM, User Researcher, Technical Lead, Front end, Back end and Business developer.
Tools used: Pen and paper, Hotjar, Google analytics, User testing, Sketch, InVision.

The challenge

Provide an easy way to login on the learning platform for clients which doesn't provide corporate credentials, email or single sign-on for employees.

The problem

Very manual process of onboarding was constantly causing trouble on support and blocking sales.
New accounts were created or deleted every week using a spreadsheet file managed by Lobster developers.
80% of all our user base had no corporate credentials like Email or Username and Password. in 2018, 45% of all customer service tickets were related to login issues. 36h of development hours every week for handling spreadsheets.

The audience

I started picking up the most affected audience inside of the Login and joining-in flow. Managers and Learners needs to exchange information in order to have a fluid Onboarding.

The onboarding phase is a collaboration in between Learner and Managers Based on the problem I identified two main participants on the story. I used two of our personas to anchor to the user needs and avoid our desire to solve all the problems in the world.

Insights collected from the Interviews.

This process of talking to the users opened my eyes to many critical problems we had, but also gave a lot of motivation to seek for the opportunities.
Word of mouth. The most common way to exchange information in a hotel was during daily standups.
Bulletin board. They used to concentrate and track learning programs in a Bulletin board.
High turnover staff. Hotels doesn't provide corporate credentials because most of the staff are temporary.

Design Sprint

To concentrate efforts and reduce time to gather information we decided to assemble a new team specific to work on this project. We formed a team of 5, bringing other stakeholders along the way when was necessary. As a facilitator of the sessions I decided to follow a 4 days Design Sprint method proposed by AJ&Smart and Jake Knapp to explore a possible solution for this problem. This way we could create a testable artefact within a week.
KPI's and the Definition of Success was also generated in the beginning. Without this would be difficult to know where was the north Start. The definition of success and the Objectives was printed and attached to the wall. Provide a stable solution to access Lobster Ink platform for users without Email and no SSO (Single sign-on).

"HMW” and Experience mapping

In the first day we used the framework “How might we” to generate possible ideas to the existent problem. We also had a fun and rich session drawing the experience map.

KPI's

Number or new user accounts created. Number of support tickets opened related to login.

Project goals

Provide solution to onboard new users without email or SSO.

User goals

Join the learner group without using personal or company credentials.

Business outcome

Being able to acquire new clients which don't provide personal email to employees.

Exploring Solutions

This phase was important to decide which solution we should move forward.With representants of tech, business and design, we could explore in depth each idea.
The second session was a hands on activity. All the participants (including virtual) drew their hypothesis with pen and paper, and we voted using InVision Freehand. Many bumps was found along the way such as certain kind of integration our product didn't have by the time, or certain kind of resource we couldn't consider.
The ideation session was very important to reduce the scope of the solution. We decided to refine even more the problem statement and focus in a different way to provide access to users. At this point the solution was pivoted and we started to consider to provide a code for the users. This code could be generated by a manager and then shared with the learner.

Inviting learners using a code.

We decided to move towards the idea of generating a code and sharing with learners. They could input this code on the login and being redirected to their business unit.

The main user tasks

• The process starts when the manager setup a code for the learner group.

• The most challenging part was to help learners on the invitation awareness. It's all offline.

The Code input

The users could input a code provided by the managers and join the specific group. I add an FAQ modal to help user understanding the input code flow. Validations on the input field to avoid misusing the code.

Prototyping and testing

After voting on the most interesting wireframes we started to build some low fidelity wireframes. Most of the pages already had templates and the Sketch library provide a good amount of components to be used. The possible flow was created in few hours and test script was already created by the User researcher.
The testing phase was made using 10 participants, 5 managers and 5 staff. The solution was considerably simple but the scenario was a bit complex, the staff had to act as received a code from their manager. During this phase we identified many gaps of organisation communication. Hospitality staff usually receive instructions once in a day, the environment is usually chaotic, and they didn't know how to report a problem such as credentials lost.
Some iterations was made along the process, the main flow was validated, the results wasn't all positive but we believed the core functionality was well accepted by staff and managers. We had positive signs to move forward with the solution.

Preliminary results

After coding and shipping the feature, our team started to measure the results. In the very first weeks of release we had no substantial numbers of traffic, but after the release notes had sent to our main customer though mailing we started to collect interesting results. They were not good. The Bounce rate was very high, and the Conversion rate was considerably low. Users was landing on the page and immediately due lack of instructions.
Some major bugs weren't considered during the Quality Assurance phase. Mobile users was having a lot of trouble to join the platform because of problems on the input field. Problems with API's and identity server was causing long time to load. Hundreds of non speaking english users from Southeast Asia couldn't understand the flow and ended up in an infinite loop.
Users often mentioned about the complexity of the code, but once we only had static prototypes we couldn't feel how would difficult this interaction.

Some findings

The qual. and quant. analysis of the issues brought some interesting findings to our team.
Internationalisation issues: A big number of users were in Southeast Asia and didn't speak english. The manager were responsible to translate to learners.
Sharing the code: Users were taking picture of the code and then sharing the picture with their colleagues using messaging app.

Reiteration

With numbers in hand we started to redesign some flows in order to fulfil the gaps we hadn't consider in the first version. Some CTA's was reviewed to facilitate the translation, and a some illustrations was created to give a better hand to users during the input coding step. In order to reduce typos we studied best practices on alphanumeric coding generator, it helped us to reduce the amount of characters accepted by the input field.

During the user interview phase some interesting about the onboarding phase was collected. Managers was writing the code in the whiteboard, os voice it loudly during morning standup meetings. The staff was taking pictures of the code or writing down in small pieces of papers to them input in the system afterwards. We saw an opportunity to help creating a printed version of the code, managers could then give the printed instructions to the staff.

Improvements

Based on the findings on the research, I decided to make some changes in order to release a better second version.

• Remove signup button

• Solve technical issues and improved the code field

• Add illustrations to improve the understanding

Smart code

The code became even more simple and use to copy and paste. Based on the findings, I decided to add a new functionality to copy and paste the code directly from the input field.

• Managers generate a unique code per business units.

• The code can be printed, shared by email, message, or copied.

• Managers can control access of new learners by generating a new code.

Easy signup

Based on the findings from the first iteration, I decided also to generate the possibility to print the code. With this, the learners can simply copy the code from the bulletin board and paste on the phone, or even share the picture with their colleagues.

• Learners receive the simple 6 digit code by message, in the daily standup, internal communication system or check on the bulletin board.

• Input the code received in the mobile or web version.

Fast onboarding

I also found an opportunity to revamp the first interaction of the Learner with the platform. The onboarding screen was redesign to be more informative. This gave a boost on the joining process.

• Learners join the platform using the simple code, and choose their job tags.

• The learner is automatically redirected to the learning group.

• It saves time because the learner don't need to choose the group.

A new hypothesis

After the first week of release our marketing team sent the release notes for major clients. After few weeks with more traffic on the platform we could see some improvements.

• Bounce rate considerably lower

• Less dropoff  > more conversion on the onboarding.

Measuring the impact

Four months after the delivery we gathered some numbers.

4 new clients

Major deals on the pipeline was closed, some reasons was directly related with the new ability of inviting staff.

Less support tickets

The support tickets related to login decreased considerably considering the amount of new accounts created.

+300K USERS

New deals and existing clients dumped a good amount of user using invitation code.

Learnings

There was many lessons learned along this project. Firstly is that Design Sprints is not a silver bullet. Deal with complex problems requires a capable team focused in an collaborative process with useful and accurate information in hand. Prepare a fertile environment to generate ideas often takes more time than a week.

Sometimes applying a User Centred approach requires resilience and a some patience. After the first iteration the team was already celebrating success and planning some upcoming feature to be build. Only after some some fight with the Product Owner we could bring evidences to the table and push the team to work on technical improvements. Without those number I assume would be impossible to see any success.

After three months of the new solution released we could see positive results. Sales team was happy with the new automatised way to provision users, managers now could invite the staff by themselves without allocating developers to help during the rollout process. 4 major deals on the pipeline was closed, some reasons was directly related with the new ability of inviting staff. Customer support saw a considerable reduction on support tickets and complaints related to login. The customer support had more time available which used to create a webinar explaining how to better use the new Invitation by Code Functionality.