For Teachers... and Readers.
Keeping up with student reading progress.
Literator helps K-6 teachers track literacy. The design challenge was to see what teachers needed to improve the functionality of scheduling, student-teacher meeting documentation, and time management.
The development team proposed that we design a scheduling option for teachers to manage teacher-student meetings.
We undertook a two and a half week design sprint to understand the app, understand it's users, and suggest additions and changes.
I redesigned my team's solution working within UI guidelines for iOS. This was an exercise for myself to further refine the work from a UX perspective. This design has elements that we had slated for our next design sprint. It turned into a complete redesign. It was great to work within a design system. The run through above is all my own work.
Some notes on the process. The Literator orange color was the foundation of brand in the redesign. It was strong enough to be seen as the app's color and easy to utilize within the iOS 11 design system. It was a fantastic way to break down the user flow. I could match the components within the design system to user needs and goals and keep consistency throughout the app. I could see how agile this would be for any design team.
Problems and Goals
If we could help teachers keep track of which student was at what level we would be on target. Less paperwork, record keeping done in real time, and getting a handle a particular student's reading progress at moment's notice would make the app indispensable.
The goal— help kids to read.
The business goal— if a school is using Common Core Standards they need Literator.
Create forms to find teachers appropriate to our study.
Identify participants for interviews or observation in class.
Compile relevant questions.
What makes reading happen, who are the teachers, who are the students?
What are the realities of standardized testing?
What assistance do teachers need?— in the classroom, with testing, with record keeping, with scheduling.
How often do teachers notify parents? How do they do it?
Compare what teachers said they did in class (attitudinal research) with what they actually did in class (behavioral research).
Conduct numerous interviews.
Observed teacher-pupil interaction in the classroom.
Synthesize data with various methodologies.
As part of the design brief, The Literator development team had suggested that we design a scheduling function within the app. This would enable teachers to keep a calendar and schedule their one-on-one meetings with students.
Attitudinal - We got a feel for what teachers were thinking through eight in-depth interviews. There was a skepticism towards the testing. It was partly due to the complexity of the standards. Regardless of this skepticism, it was teacher passion and dedication that set the tone for this phase of our research. They wanted their students to succeed, and were willing to try new approaches.
Behavioral - In practice, Literator added to teacher cognitive load. We observed a teacher-student confer and there was cognitive dissonance in trying to connect with the student while tracking progress. Our takeaway was that fewer choices and simple, big content would be most effective.
Competitive analysis - Literator had the great competitive advantage of being the only app specifically addressing the BAS system. So we looked at what teachers were using other than Literator, primarily Google Docs and Sheets and pen and paper. The benefits of pen and paper are their flexibility and familiarity. Google docs is similar in it’s adaptability to a wide range of needs, and it can be collaborative and very easy to share and keep track of.
We looked at indirect competitors to get an idea of what other successful companies were doing to get teachers to adopt their platforms. We found that ease of adaptability to different teaching methods and ease of learning were key to apps like Edmodo and Teacher Aide Pro.
Synthesizing Our Data
We used affinity mapping as a tool in our process. It helped to show the complexity of the research. There were many factors that vary from school to school and district to district, notably class size and time available per student. It was clear that there could be larger and longer studies on this topic. It was also clear that time was the biggest component of our design equation. The developers showed this in asking for a scheduling function and the research bore this out in our classroom observation.
The teachers needed a better handle on how to fit their student-teacher 1-on-1’s into their days. If we folded a scheduling function into the app it would seem to enable teachers to see more students. But the teachers we interviewed didn’t necessarily see themselves sitting down to fill out a schedule or even set the next appointment. It was clear they wanted flexibility and the option to see who needed it the most or who hasn’t been seen in the longest time. This was backed up by our behavioral research where we saw how brief student teacher meetings were.
Some key takeaways from our observations:
Teachers need to track their time.
Teachers take notes on reading ability and behavior, and It's easy to lose hand written notes amidst all the paperwork that teachers typically handle.
There is a reliance on grouping students in the classroom with different sort methods. Sometimes it is to distribute knowledge between kids at different levels and other times to push learning forward among kids at the same level.
It was clear that a major part of the solution was to sort student lists in various ways.
My team came up with various paper prototypes. We collaborated on how to approach altering the app. We came up with a screen flow that we could test with users. We found that:
Many sorting options accessed through different parts of the UI result in confusion and off-putting complexity.
Text was frequently too small to read during one-on-one confers with students.
The existing design of the app was unclear about how to rate a student's answer.
Access to functions like notes should be obvious and centralized.
Here’s What We Learned
We took a risk and started developing towards multiple sorting options of student lists instead of adding the requested scheduling function. We came to this late in our design process. Aspects of our team’s design were a surprising challenge to the client. In hindsight, my team would have had more communication with the developer. However, in a post-presentation meeting the client revealed they had also planned to add new sort options. The scheduling feature was something they wanted to my team test and see what we would come up with. In contrast, we understood their initial brief as a design project not a proof of concept.
Ultimately, we were able to corroborate our findings about the importance of sorting options with the client's thoughts and research. The request for a scheduling function was an everything-but-the-kitchen-sink idea. The pressure to solve problems through adding more functions is hard to resist, but we strongly felt adding the scheduling option would do nothing but make for a plethora of choice that would add to overall complexity. Our research showed that the simpler the design was, the better. Student meetings were better served by improved access to student data, and my team designed towards that goal.
Testing and research illuminate the path to good design.