We have a team of 42 people at Albert. The Schools and Engineering teams are each 14 people, there is a Content team of eight (four on ELA/ Humanities, four on STEM), a Product team of four, which includes our in-house designer, our CEO Luke, and our office manager, Molly. We all sit in one big room in an office above a Thai restaurant in the River North neighborhood of Chicago.

Because we’re still quite small, it’s fairly easy to pass information from one team to another, and this is particularly helpful when it comes to sharing user feedback.  Over the years, we’ve had different systems for how we collect and track user feedback but one thing hasn’t changed: user feedback drives the evolution of our product. It’s important for us to hear when things aren’t going well because we know the stakes in education are so high. If we have a bug, a confusing interface, bad content, or are in any way not meeting a teacher’s desired outcome, it negatively impacts teachers ability to teach.

However, listening to feedback is not enough. We have to act on it too. Below outlines how we think about user feedback at Albert and the changes we’ve made to our site because of it.

A few features that were directly influenced by user feedback:

• Template sharing
  • Teachers voiced that they were doing double work because multiple teachers teaching the same subject were creating the same assignments on Albert.   We’ve solved that problem by creating a template sharing feature, which allow teachers to share assignments with one another via a link.
• Google Classroom Integration
  • So many schools are already using Google for Education to power their classrooms. We heard from folks that a Google Classroom integration would make it easier for them to get started on Albert, so that’s just what we did.
• Practice exams
  • We strive to create content that prepares students for rigorous end-of-the-year tests, and without full-length practice exams, we couldn’t make that claim. We created full-length, timed practice exams so that teachers can give students simulated practice before the real deal.
• Removal of “credits”
  • We started Albert with a credit system which required teachers to pay for “credits” to earn access to more content. Teachers did not like the pay-as-you-go model, so we ditched it, even though much of Albert’s code was based on credits as an internal currency.
• Resetting assignments
  • Teachers wanted a way to reset assignments when students accidentally submitted without finishing. This feature turned out to be a pretty easy fix that didn’t require a lot of engineering time. Sometimes really small changes can make a big impact on teachers’ daily lives.

We ❤️ teachers.

Anyone using Albert should feel empowered to submit feedback but we more heavily prioritize feedback from teachers. We do look over feedback from students (and it’s particularly helpful when they find errors or typos), but we typically don’t implement major changes because of student complaints. Member of our Schools team have strong relationships with teachers and always pass issues back to our Product team. We also proactively seek teacher feedback through annual roadmapping surveys (surveys that ask teachers for feedback on several different features we’re thinking about implementing).

Sometimes we flag teachers who have given us particularly helpful feedback in the past. If you provide good feedback (rich, detailed, give reasons why), the Product team might want to hear more from you. You might be invited to try out a beta version of a new feature, be a part of a feature request community, participate in user testing, or simply have an informal phone call with someone on Product to tell them your thoughts.

We think about our user feedback in two buckets: bugs and feature requests.

Bugs

Bugs are issues on the site: a button that takes you to the wrong place, a page that has a slow load time, etc. When we learn about a bug, we start by simply trying to replicate the issue. The more information a user gives us, the easier that is. We’ll typically ask users to answer the following questions. If you have this information ready to go before you report the bug, we can resolve your issue more quickly!

• What were you doing when you encountered the bug?
• How did you expect the feature to perform?
• How did the feature actually perform?
• Has the feature traditionally worked the way you expected? Or was this the first time you’ve used this feature?
• If a problem is affecting your students and not you, be sure to include the emails or usernames of those students.
• If possible, include screenshots of the issue.
• If possible, try to replicate the issue with your console open and take a screenshot of whatever you see.

Feature Requests

Feature requests are suggestions from administrators or teachers on how Albert could be improved. When our team reads feature requests, what we really want to know is, “What core need does the feature fulfill for the user? Two users might request two different features, but they both have the same core need. The more we can understand why you want this feature, the easier it is for us to develop solutions that meet your needs. Some questions we ask users when they submit a feature request:

• How do you use Albert in your classroom?
• What problem would this feature solve for you?
• What is currently insufficient about the app?
• How would the feature you’re requesting meet your needs?
• How would the feature you’re requesting change the way you use the app?
• How important is this feature to you?
• Do any other apps you use provide this feature? If so, which ones

We care a lot about what our teachers have to say, and we’re always thinking of ways we can incorporate feedback into our product, so keep it coming!