IXL Learning's mission is to create and support the best educational technology possible. IXL features an adaptive online curriculum, covering math, language arts, science, social studies, and Spanish. Students master concepts through targeted micro-skills in which they typically answer between 20 and 30 questions. As of 2017, it's used by 1 in 9 students in the US and by schools in 95 of the 100 top districts.
When I joined the company, IXL covered math and language arts and was in the process of developing content for science and social studies. As the sole product designer dedicated to enhancing IXL's content, my role was to create engaging new ways for students to interact with questions on IXL, in place of standard multiple choice and fill-in questions. As our product continued to grow, I was also responsible for maintaining a unified student user experience.
For instance, one feature I worked on was deployed in skills that teach students how to count. Previously, students were asked to count to a particular number by typing one letter a specific number of times (e.g., "Type 5 'D's using the keyboard."). In its place, I designed a way for students to learn how to count by dragging and dropping stickers onto a background.
Over the course of a year and a half, I led the creation of 30+ new question features for the site. My objective was to create a more delightful, engaging, and intuitive experience for students. For each question feature, I also aimed to reduce students' cognitive load, enabling them to focus more on the education material rather than the technology behind it.
While I led the design for each feature, their creation was a team effort. I worked closely with curriculum designers (i.e., subject area experts), visual designers, software engineers, and QA analysts to ensure we created the best possible experience for students.
Below, you can view a selection of the features that I designed:
If you're interested in testing any of the features shown above firsthand, you can follow the links below to check them out live on IXL:
When curriculum designers developed new skills, they would request a new feature from me if they thought the skill could be improved through a new interaction type or visual interface. I regularly received requests from curriculum designers working across all of IXL's subjects and grade levels.
Upon receiving a request, I would review it and assess its feasibility. Oftentimes, I would collaborate with the curriculum designer who sent the request to explore different high-level design directions. If we agreed that a new interaction or UI would make the questions more engaging and impactful for students, I'd then work with the curriculum subject managers to prioritize the request and add it to my backlog.
When beginning to design a new feature, I would often start by meeting with the curriculum designer to understand the educational aims of the feature. I'd then sketch out high-level ideas for the feature and storyboard user flows. After narrowing in on a design direction, I'd then collaborate with the curriculum designer to refine the idea until we had a solid understanding of how we wanted the feature to work. At this point, I'd often also discuss the idea with the front-end engineering team to understand any potential technical challenges.
After deciding on a design direction, I would move to higher fidelity deliverables, collaborating with the curriculum designer to further refine and polish the design. As necessary, I'd code prototypes for the interaction and work with a UI Designer to create polished mockups. Once the design was completed, I would write a feature specifications document, which outlined how the feature should look and work for the engineering and QA teams.
After handing off the work to the engineering team, I'd meet regularly with the engineers to help overcome any technical challenges and ensure the design was implemented according to spec. Then, after receiving the coded feature back from engineering, I would work with QA to create a test plan and test the feature. Once the component was certified for release, I would hand it over to the curriculum design team for use in skills!
In the section below, I walk through my design process in detail for one question feature.
Sample Feature: IXL's Card Patterns
The Card Patterns project kicked off when a math curriculum designer proposed we explore interactive methods for students in grades Kindergarten through Second to learn how to identify and create patterns. She suggested considering a card design where students could place cards into a predefined row, similar to what they might do in a classroom.
Upon receiving this request, I reviewed the component's core requirements and its use cases in order to determine the full scope of the project. Ultimately, our goal was to help 5- to 7-year-olds learn about patterns in a delightful and engaging way. We wanted students' interactions with the questions to be fun and intuitive, while maintaining their focus on the material being learned – the patterns.
Based on this information, I organized the component into more granular building blocks (see the diagram above). Doing so allowed me to assess approximately how many new component modules would be required. It also provided a helpful model of the component that later facilitated design work occurring simultaneously on multiple parts of the project.
With an understanding of the user goals and component requirements, I turned my attention to the component's design.
To start, I researched how students in Kindergarten interact with physical cards and textbook exercises when learning about patterns. I then utilized several divergent thinking techniques, including brainstorming and bubble mapping, to generate a few potential design directions for the project.
After evaluating the designs against the user goals, I went with a design that was fairly similar to the rough design outlined in the original proposal. In consultation with the math curriculum design team, I decided that a card design where students drag and drop cards from stacks into answer slots would be most intuitive for 5- to 7-year-olds.
As I converged on a design direction, I began to sketch out how the design might look and explored how to best support the design on both desktop and tablet interfaces. In this case, since students would typically fill in the pattern from left to right, I decided to introduce a new interaction to enhance usability: in addition to dragging cards, students could have the top card from a card stack appear in the leftmost empty slot in the pattern by simply clicking on the stack.
After creating storyboards and rough wireframes, I met with members of the front-end and mobile engineering teams to gather design input and determine performance/usability tradeoffs. Having recently adopted a new framework, the engineering teams were worried that including complex animations might significantly increase development time. Consequently, we decided to use simple animations and to address the risk of animations being challenging to implement early in the implementation phase.
Next, I collaborated with a visual designer to create high fidelity mockups of the component and its layout. As the design progressed, I also created simple animation prototypes in JSFiddle that we were able to fine tune and hand off to engineering.
One interesting design challenge that we faced was creating static and interactive cards. Since both types of cards would be shown in the same pattern row, it was important that students would be able to distinguish which cards they could interact with; however, it was also important that students did not interpret a card's color or style as a part of the pattern.
In order for the cards to look like cards, they needed to always have drop shadow, even when static. At first, the visual designer and I explored whether varying levels of shadow might be enough to differentiate the cards, but in testing with curriculum designers, we found that the difference was too subtle. Therefore, in addition to varying the amount of shadow, we also ended up making static cards a darker gray.
With the initial design finalized, I wrote a specifications document detailing all of the component's requirements for the engineering team. After validating the design solution and specifications with the curriculum design team, I met with the project's software engineer to kick off the project's implementation phase.
Over the course of the next month, I worked closely with the project's software engineer on the design's implementation. We were able to successfully implement most of the animations, and the engineer began developing the component per its specifications document.
While the engineer focused on developing the component, I turned my attention to some of the more challenging animations, which are displayed when students incorrectly answer a question. We wanted to be able to show a pattern animating in order to help students better understand how patterns work.
The first design successfully conveyed how a pattern works, but the animation of cards moving from one period to the next looked awkward and felt slow. In the second and final version, I had cards appear in place and added blue bars above and below the cards to better focus the student's attention. In this way, I preserved the original concept while improving the animation's look and feel.
I then handed the animation off to the engineering team and began testing the component. After thoroughly testing the component and working with engineering to address bugs, I handed off the component to the math curriculum design team to begin incorporating into questions about patterns.