So I'm designing an Education Management System and I'm wondering if I should be creating the Use Cases or the Class Diagrams first?
You should be first defining how the tool you are creating is going to look, feel, and be used by your users/customers. That is what dictates how your software will be architected.
People use your software, not computers, so design how people will interact with it first. If you design around how software components should fit together, your user interface will be made for robots, not human beings.
Actually, Jim Coplien advises not to dive into the Use Case diagrams too soon, but rather to first find out the simplest mental model for the domain.
Focus on the essence of the system form (what the system is) without being unduly influenced by the functionality that the system provides (what the system does).
For if your system thinks about the domain in different terms and concepts than its users, they'll have trouble understanding each other. And if your domain model is solid, it will be easier to implement changing requirements on top of it.
So I think the answer is: That depends on what you're planning to put in those Use Case and Class diagrams.
I'd start thinking about classes for the domain model. Talk with people who currently are working in this domain, find out in which terms they think and talk about education. Once you understand the domain, think about the Use Cases. Then as you start implementing technical stuff, think about the classes and objects that you'll use to implement this.
Don't be shy to produce code rather than diagrams all along. A picture is nice, but compiling and running code is a lot more concrete. So classes that model your domain are a good first and reusable artefact, even better than a class diagram.