I worked as a contract UX Designer at BetterLesson, an edtech company that provides resources and personalized support to educators for professional development. One of my projects include the update of teachers and coaches' storytelling experience on the company's platform, the BetterLesson Lab.

Product Strategy: Ben Leddy, Annalisa Oswald, Yoon Kim
User Flows: Yoon Kim
Illustrations: Annalisa Oswald​​​​​​​
Wireframes: Yoon Kim, Annalisa Oswald
Prototypes: Yoon Kim
Usability Testing: Ben Leddy, Yoon Kim
The BetterLesson Lab provides an abundance of pedagogical content aimed to support educators' growth, largely consisting of strategies for teachers to implement in the classroom to achieve specific goals. These strategies are categorized and fall under BetterLesson's learning domains, which serve two purposes: a) They reflect the company's pedagogical values and b) they determine the pricing structure of the company's partnership with school districts.​​​​​​​

Overview of BetterLesson's Learning Domains

When a school district partners with BetterLesson, they choose usually two or three learning domains and their teachers gain access to content under these domains. In addition to browsing content, the teachers work with BetterLesson's coaches, all with extensive (10+ years of experience) backgrounds in teaching. Teachers and coaches connect virtually on a regular basis, and in the process coaches foster teachers' growth by helping them identify goals and pointing them to strategies that can help achieve these goals. 
The two parties are able to document their year-long work in BetterLesson Lab's "Story." This is a valuable experience for teachers as they will have a portfolio at the end of the year demonstrating their growth that can benefit in their career advancement. It is also an effective way for district administrators to see and decide their return on investment. 
In the current experience, teachers are hardwired to using learning domains as a framework of their documentation. This means they are able to document work within the domains their district purchased from BetterLesson, but the documentation has to be kept separately. 
From research of our current users, we learned that teachers found it restrictive to having to use our learning domains as a set framework for documenting their work with coaches.
Furthermore, BetterLesson was forming partnerships with districts that introduced new user groups consisting of coaches employed by districts and their own sets of teachers they supported. Like our current users, these district coaches and teachers wanted access to our content, but did not want to use the learning domains to frame the documentation of teachers' growth. 
To cater to our current and incoming users' wants, we knew we had to add flexibility to the current storytelling experience. At the same time, the learning domains reflected BetterLesson’s values and beliefs in education, and internal stakeholders were concerned that the domains would lose their purpose in the platform. Stakeholders also articulated the importance of the storytelling experience continuing to reflect BetterLesson’s TML (Try, Measure, Learn) methodology where coaches and teachers tried a strategy, measured its effectiveness, and learned from the outcome.​​​​​​​
After identifying internal stakeholders' concerns and current and incoming user groups' wants and painpoints, we took a close look at the current user's profile section as we thought its key features could be merged with user's story.  
Teachers being coached by BetterLesson coaches currently have a profile section in their experience where they record their vision for students and are able to see their story (also called portfolio) as either "Highlights" or "Timeline." 

Teacher profile showing metadata and teacher's year-long vision

Highlights view of story in "Profile"
Highlights view of story in "Profile"
Timeline view of story in "Profile"
Timeline view of story in "Profile"
With the current configuration of the storytelling experience, it made sense for users to write and view their year-long vision in their profile as well as having multiple views of their stories.

The profile also served as a way for users to have an overview of their multiple stories in a single page as they were currently hardwired to use learning domains as a framework for their storytelling. 
If we created an experience where users could a) not use learning domains at all or b) access multiple learning domains in one story, users would not need to access their profile section to have an overarching view of their multiple stories. We thought we could unify user's profile and storytelling, and this unified experience would serve the aforementioned four user groups: BetterLesson coaches, teachers being coached by BL coaches, district coaches, and district teachers. 
We decided to take the unified experience of user profile and storytelling in two directions. 
We were able to test the two prototypes to focus groups consisting of our teacher users from across the country. While feedback was mostly positive, we concluded the testing sessions with two major takeaways that would guide our next steps.

1. Filtering artifacts. Recall mechanism.
Being able to work on multiple learning domains would mean adding more artifacts in a single story. Users articulated the need for quickly locating specific artifacts instead of scrolling through what would be their long timeline. Providing filters, perhaps by utilizing the tags we introduced in both prototypes, would enable users to do this.
2. Change can be difficult. Importance of familiarity. 
While users appreciated being able to work on growth areas from multiple learning domains in a single story page, they pointed out that they had already gotten used to the current experience and found themselves looking for cues from it in the new prototypes.
This specifically applied to the first prototype where multiple visions could be added. From the current experience, they had conceived that writing a vision meant sharing their long-term approach and goals in teaching, and being able to add only one made this experience all the more considered and precious. Adding multiple visions would undermine this experience, and users wanted the constraint of adding just a single vision.
The same principle applied to the second prototype where we changed the name of growth areas to goals. Our rationale was that incoming users would find the concept of goals more intuitive, but we failed to consider current users' familiarity of working with growth areas. Keeping this name consistent from the current experience was important to our current users.
Back to Top