The average user is largely indifferent to the shopping app they use to make their purchases. Whether they use Amazon or Flipkart, their goal is to get the product at the cheapest price and they’d probably switch at a moment’s notice. Quizizz’s users are different. Teachers love the product and go to great lengths to continue to use it.
There are a LOT of teachers out of there. Teaching is a core profession. You’re not designing for some obscure power user like you would be developer tool. The person you’re designing for is very well known and relatable.
Quizizz is still a startup. You will have full freedom to go ahead and dip your toes everywhere. Need access to some data and know how to run SQL queries? Go right ahead.
Imagine working at a Fintech company where you always have to be on top of RBI regulations. That flow you designed last month, well gotta add X, Y, and Z to it to comply with new government regulations. Constraints in design are great but those are self-imposed constraints or constraints that come due to technology. Arbitrary constraints that policymakers come up with are not as much fun to comply with as a designer.
Design works best when there is minimal distance to the user. If you’re working in Enterprise Design at some company, there are multiple barriers between you and the people that you would be eventually designing for. You’d have to jump through a lot of hoops to get a single user interview and all this friction is counter productive to your work. At Quizizz, users are Teachers and they’re not hard to get a hold of.
Teachers spend way too much time on work other than teaching. Like planning lessons, taking attendance, preparing tests, grading them, 100s of admin tasks, and more. Most teachers are overworked and underpaid. We want to free up their time so that they can focus on more meaningful activities like spending time with students who need extra love and care.
For students, the problem we’re trying to solve is simple. Most students don’t really engage with or enjoy their classroom activities. You have a test on Monday? Your weekend is ruined. You sit through classes not because you want to but because it’s forced on you. We just try to make students want lessons, practice, and assessments.
We started out with just doing one thing really well. Assessments. Teaching is like stand-up comedy. The same way comedians hone their material by getting feedback from their audience, teachers need to get feedback from their students. Comedians can figure out what’s working and what’s not working with how much the audience is laughing and on what. Teachers need to know this too but there’s no fast and reliable way to do it. This is what Quizizz provides.
For students we turned these assessments from stress chambers to something a lot more easy-going, and fun. From something they want to avoid at all costs, to something they look forward to. We turn assessments into a multiplayer game—a classroom experience.
Currently, we’re retiring from just being an assessment(tests and exams) platform. We are becoming a complete learning platform. We want to apply the lessons we learned while building our assessments product to all the other activities teachers do during classes.
Disclaimer that this is copy pasted from a doc addressed to the team internally. So if the tone doesn’t match it’s due to this. And in the spirit of full transparency, we are still in the process of realising these, and practicing it fully. So this is a more accurate view of what values we are chasing.
The only way we can keep improving as individuals, and as a team is through feedback. Recognise that being receptive to feedback is the single biggest growth multiplier. In a team setting, doing this builds trust within the team. And trust is the foundation of teams that make a meaningful impact. Practice it on a daily basis, with all the people you work with.
When giving feedback, our aim is to assist, and to make sure the feedback is actionable. Giving direct feedback isn’t a pass for us to be jerks.
For eg. if I find a meeting unproductive, and the feedback I give is “this meeting didn’t need me, and it was a waste of my time”—this is jerk feedback. Instead better feedback looks like “if you share the agenda in advance, then I can decide if I can be useful in this discussion or not in advance”
When receiving feedback, make sure you appreciate the person giving you the feedback. Then either accept or discard the feedback using your own judgment.
When we start working on a project, we focus a lot of our energy on figuring out why we’re doing this project, and what is the desired outcome. It’s our job to have clarity on both of these questions. Only then we start doing what we do i.e. design.
After having a clear understanding of what a successful outcome is, we leave no stone unturned in order to meet the outcome. And we tie the design decisions to this successful outcome. More often than not, the chances of success after shipping the first iteration will be low. Learn from what went wrong, and go back at it again.
Getting stuck is fine. Not asking for help to get unstuck is not fine.
Finding that crucial insight that will help me build the feature I am working on is fine. Waiting for someone else to find that insight for me is not fine.
Calling out blockers that are not being resolved is fine. Being aware of the blockers and shrugging from calling it out is not fine.
Recognising that the situation will never be perfect, but we will still have to act is important. Inaction is not an option.
We take ownership. We recognise that what we do on our design software isn’t the design, it’s what gets used by a user. We ship. If there’s an engineering constraint, then we ask ourselves how can we work around that without diluting the user experience to get users to value ASAP.
The only edge an org of our size over the Googles and Microsofts of the world is that we are nimble, we can change our direction, we can move fast. And recognising this being a part of the Quizizz design team is important. We also take pride in never being the dependency. We set a planned deadline, and we meet that deadline.
We move fast but that doesn’t mean we trade off on quality of software we ship. iPod was a breakthrough in technology back in 2001. It exuded quality like nothing else did. It went from idea to people’s hands in a span of 290 days.
If we’re using speed as an excuse of quality what we’re really doing is saying that good design has to be slow, when there’s evidence that suggests otherwise.
We don’t reward people who have moments of brilliance. We reward people who consistently deliver impact. Consistency over perfection.
But why? Because when you are consistent, you signal your team members that this is the least you can expect from me. That makes it easier for the team to figure out what they can really achieve with you, and how they can hold you accountable.
Short answer - it depends.
Long answer - in some areas we are completely design-driven. In some places we are data-driven. Depends on what you’re trying to achieve with your team.
For eg. in growth and revenue teams you need to be data-driven to find opportunities that can be potentially high impact. You can figure out where people are dropping off in the funnel or if they’re churning too much. In these teams the best path to diagnose problems is definitely data-driven.
On the other hand, student engagement team is design-driven. Because when you’re trying to solve for student motivation and learning you need to have a strong point of view on what a good outcome looks like. Eg. Students should retain as they can during an assessment. How do we make that possible through design?