Fluent City is an online language learning start-up specialized in the conversational teaching method. In May 2020, Fluent City successfully launched a new subscription-based online learning product along with a custom learning management software (LMS). At present, approximately 50-100 lessons are scheduled, managed, and conducted online. 

The primary aim of the LMS was to provide a one-stop shop for Fluent City teachers. Specifically, the lesson summary feature allowed teachers to use the software platform to log lesson information, fill out a summary of what happened in class, and send it to students. Centralizing lesson information within the platform is beneficial not only for teachers but also for the business: it would create a repository for custom lesson content and lesson plans, thus reducing the cost of curriculum development. 

The challenge

However, only 1% of teachers used the lesson summary feature and Fluent City’s content and curriculum development became stagnant. 

It came as little surprise then that in August 2020, new user acquisition plateaued and the churn rate hit 33%. Customer feedback revealed that students felt the business fell short in fulfilling the promise to offer hyper-relevant and personalized lesson plans and content. 

To increase retention, the team formulated this question: How might we encourage teachers to use the lesson summary feature more?

Project goals

• To increase the adoption rate of the lesson summary feature

• To discover materials, curriculum, and content covered in lessons 

• No rebranding nor major styling changes

My role

UX research, UX/UI design

timeline

2 weeks (40 hours)

Primary research

Primary research for the project was conducted through a total of 15 user interviews with current Fluent City teachers. Questions focused on how teachers viewed their role, what prevented them from achieving their teaching goals, and how they currently solved their needs.

Key research findings:

Diving further into pain point #3 revealed that there was an issue with discoverability: 4 out of 8 teachers did not know where to find the lesson summary feature

Define + ideate

Using the insight and need statements that were revealed during research, the team formulated problem statements. This helped to narrow down the problem space: rather than trying to solve everything, we formulated problem statements to identify key issues in the current design that prevented teachers from using the lesson summary feature. The problem statements were converted into how might we statements to pave the way for ideation.

GROUP BRAINSTORMING

Using the HMW statements as starting points, I conducted an online group brainstorm using the rapid ideation technique to generate possible solutions. Time constraints made this brainstorming method the best choice; there were members from different teams and leadership levels present and we wanted everyone’s equal input as fast as possible. 

The following features were chosen as high priority due to their low-to-mid effort to implement and the high impact it would create.

• Conditional button to appear on lesson card when recap isn’t filled 

• Reconfigure internal system so information is organized by student, not lesson

• Direct access to the lesson summary page from the online calendar  

• Change button copy on the lesson summary page

• Add a warning text below the button

• Attachment feature

*this was later downgraded to P2 due to the effort required to implement 

03 - Final Designs

A two-week timeline meant that we had to move from research and ideation straight to implementation (more on this in the Conclusion section). Here are the major changes implemented:

04 - Conclusion

The designs were not heavy tech lifts and as we were pressed for time, we decided to move directly from design to hand-off.

Since we did not run usability tests, I worked with the Product team to monitor the following success metrics: 

• Usage of the lesson summary feature: the number of teachers that fill out the lesson summary.

  • Benchmark: only 1% of teachers used it before design changes were implemented

  • Success metric: increase usage to 10% in two weeks after launch  

    • Result: 17% of teachers used the lesson summary feature

    • Conclusion: success. The designs encouraged teachers to use the lesson summary feature more.

• Satisfaction rate: survey sent to teachers to gather feedback and satisfaction with the new design  

  • Benchmark: NA

  • Success metric: over 80% of teachers reply that new design is easier to use 

    • Result: 85% of teachers reported that new design is easier to use

    • Conclusion: success. The designs made the platform easier for teachers to use.

Reflections

Working within a tight timeline pushed us to skip a lot of steps, such as testing and creating user personas, however, a few of the team members had worked as Fluent City teachers and this helped to create empathy for the actual user (teachers). This project was a great learning experience for the following reasons:

1. Communication is crucial
   There was a misunderstanding among the team members regarding the exact scope of the “attach files” feature. Specifically, we failed to consider that attached files must be uploaded to and stored in our system. Due to storage scarcity and the effort required to store the files, we had to downgrade the “attach files” feature to priority 2.

2. Importance of consistency in design within the platform
   Fluent City does not have a design library and our style guides do not specify how and when to use specific colors and date/time formats. As such, the platform lacks consistency in color use and input formats which may cause confusion and disrupt learnability. Fluent City must create a design system so the team’s workflow can be streamlined and the user experience is more consistent.

3. Learning about real-life constraints
   In an ideal world, I would have liked to conduct usability tests with teachers in order to gather feedback. This was a point of debate among team members; the usability test, analysis, and revisions would have taken at least two days thus we risked missing the deadline. In the end, we prioritized our timeline and relied on staff members’ institutional knowledge for feedback. This experience taught me that the design process is not always linear nor completes its full cycle.

See more projects