Student Choice

A feature in which students can choose which learning materials to complete and teachers can grade all submissions.

Company: Schoology (acquired by Powerschool)
Role: Leading Product Designer, Leading User Researcher
Collaborators: Visual Designers, Product Manager, Delivery Team (Engineering)
Screenshots of the final student choice student experience UI design.
These are screenshots from the final student experience UI design.


In this feature, teachers create a menu of choice for students within a course. Students pick how to learn a subject or demonstrate learning using the choices their teacher provides. Teachers configure grading settings  and grade all student submissions efficiently and without overwhelm. 

This feature positions Schoology as the leading learning management system focused on personalized learning. It lays the groundwork for future personalized learning features such as Learning Pathways. The UI design is the foundation for Schoology’s elementary student UI design.

My role was to discover what that feature could be and design the MVP for this feature.


The steps below highlight key milestones, but they are a gross simplification. To get the real story complete with messiness, full thought process, and obstacles included, contact me for a portfolio presentation.

Student Experience

  1. Competitive analysis. I conducted competitive analysis on tools teachers typically use to offer students choices in the classroom: Google Classroom, Seesaw, Teachers Pay Teachers, and others. I wanted to design this feature to match existing mental models for how teachers offer learning choices to their students today, but with a more seamless backend that did setup heavy-lifting for them.
  2. Concept creation and wireframes. I collaborated closely with my Product Manager to wireframe the student MVP workflows that would be appropriate for users ages 5-18. I chose to prioritize the student flows because Schoology wanted to be known as the leading personalized learning LMS for Kindergarten through Grade 12. However, Schoology’s UI caters to adult and older student demographics. I knew that if we nailed the student UI here, backed by research, we could lay the foundation for Schoology’s future elementary-focused UI design.
  3. Research with teachers. I continuously researched with teachers to create the concept and iterate design. Why didn’t I research 100% with students when it came to designing the student experience? From a practical perspective, student participation in research activities is limited. Research must be done within the scope of their typical class and with teacher permission and supervision. I didn’t want to interrupt class time with multiple requests for research while we were still forming the concept. Additionally, while the primary user of a student choice activity is a student, the secondary user is a teacher. A student would only get to consume this feature if a teacher deemed it valuable enough to integrate into their classroom.
  4. Usability testing with students. I tested usability with students ages 6-17. This is where I focused most of my student research participation. I crafted both the designs and the research experience to cater to both “pre-reader” students as well as students with strong literacy skills.
  5. Visual design. The student UI designs I created set a new precedent for our product, since Schoology’s existing design patterns catered to adults and older students. I used existing components from our design system such as cards and expanding headers applied elementary-friendly design to them. For example, I asked engineers if our expanding headers could accommodate multimedia content including videos, images, and audio rather than just text. The answer was Yes, so I used that component in the Student Choice student experience and also set a precedent for how this component could be used for a future elementary experience UI. While I created, I workshopped visual design with other members of the design to ensure we were on-brand and fully polished for integration into our design system. 
  6. Engineering handoff. I created the design assets for this project using Sketch and Invision. This was before Sketch released their Inspect feature, so I redlined specs across form-factors, which was simple, since I followed responsive design principles throughout this project. Later, once our team adopted Figma, I transitioned these assets to Figma. To handoff to engineering, my product manager and I led a kickoff with the delivery team in which we presented the design assets, answered questions, and helped break the work into stories. (I consulted our lead engineer throughout the design process, but I have found it minimally disruptive to the core team’s current sprint to save sharing the design work in detail until kickoff.)

Iteration Snapshots

A rough workflow diagram showing the initial student experience concept.
A workflow diagram showing how a student choice activity follows a hub-and-spoke model.
A work-in-progress image of two different layouts displaying choices in the activity: a card view and a list view.
A work-in-progress image of a modal that would give teachers insight into why students made their choices in the activity.
A work-in-progress image of making the student choice feature's student experience elementary-friendly.

Teacher Experience

While interviewing teachers about their needs for a student experience, I also asked about how they would expect to grade a student choice activity. This gave me user research data to design a setup and grading experience for teachers.

  1. User research. I conducted user research to understand how teachers expected to be able to grade a student choice activity. Key research questions addressed included: did teachers want to assign a graded score to this type of activity? How did they expect it to work — each material gets its own individual grade, the whole assignment gets one summative grade, etc. How did teachers want due dates to work, if integrated into this type of activity at all? And many more. Methods used to answer these questions included surveys and interviews. 
  2. Engineering. I learned from engineers how the backend of grading in Schoology works today (ungraded and graded materials). Together with my product manager and lead engineers, we reconciled users’ desires with our product architecture. 
  3. Grading scheme. I collaborated with Product Management and Engineering to create a grading scheme for student choice activities that realistically matches what’s supported in our product architecture. 
  4. Concept and workflow. I designed a grading workflow that presents the grading scheme necessitated by our complex backend. I leveraged pre-established design patterns from a previously built feature, Grade by Question, and that project’s research. In the initial concept, teachers could grade submissions by student (e.g. grade all of Abby Apple’s submissions) or by material (e.g. grade all the “make a video” submissions). In the end, due to technical constraints, only Grade by Student made it into our MVP. I also leveraged Schoology’s legacy UI and design patterns due to technical constraints.  
  5. Usability testing. I tested this workflow for usability with teachers before handing off to engineering. 
  6. Engineering handoff. This step was nearly identical to my handoff with the Student Experience.
A flow map of the teacher grading experience.
A snapshot of a key screen in the teacher grading experience. Teachers grade each student's submission and then manually assign a total student choice activity score.
A screenshot of the grade by material teacher experience concept.


When I left Schoology, this feature was on Schoology’s roadmap. Our delivery team was doing backend work to make the release of this feature possible. The research, UX, and visual design laid the foundation for creating an elementary experience in Schoology, which is a key strategic initiative that was on Schoology’s near-time roadmap and was being built.