Everyone has more data than they know what to do with. And many people start with the end in mind and say, “I need dashboards.” Even the U.S. Department of Education has gotten into the game, saying “Districts, and others should design, develop, and implement learning dashboards…to improve achievement and instructional practices.”
Um, thanks for that, but how exactly? The solution that many have come up with in education is to piece together a data warehouse by pulling data from each of the systems teachers use and pushing it into one master database. Then they buy business intelligence software to create reports using that database. There are so many challenges to this approach, but they’re not always obvious if you haven’t gone down this path before:
- Cost: Each pipe costs money to create and to maintain. Plus you have the cost of maintaining the data warehouse itself. Are you experts in data modeling and SQL? Probably not.
- Complexity: How many systems do you want teachers to have to toggle between just to execute their daily tasks? Adding a data warehouse only adds one more.
- Data integrity: So you’ve created your reports and you show one to a teacher. The first thing they’re likely to say is, “Huh, this doesn’t look right. This doesn’t make sense to me.” What they’re really saying is, “How do I verify this for myself so I can have confidence that I should rely on this system to make decisions?” Since the report is in a different system than where the data was originally entered, you’re not going to have an easy answer and teachers can lose trust quickly.
- Creating reports becomes a bottleneck: How long does it take between when a teacher has a question (that should be answered using data) and when the teacher gets a report? In reality, the educator often doesn’t ever get the report. because most districts only really have reports created for the top five most important questions that official knew were going to be important at the beginning of the year. What you want is teachers and leaders having the ability to interrogate the data themselves, but in reality they often end up having to send a request to a technical resource and hope that their request makes it to the top of the pile.
- Teachers don’t have a report viewing period: And by the way, where does pulling up the reporting platform fit into a teacher’s day? Trying to get this point across to someone the other day I used the analogy of email. “Let’s say I’m building you some analytics for your email. You have two options: 1) I build the insights directly into Outlook so when you’re writing an email you see them, or 2) I put up a brand new website that has your reports on it. Which one are you more likely to use?” The lightbulb went off and he said, “Oh! I’d never pull up the website–you’d have to build it into my email if I’m ever going to use it!”
- Delayed Data: Data is usually pushed to a data warehouse nightly, meaning that anything I do today definitely won’t be in the report. So are teachers going to pull up a report and say “Oh, this isn’t useful because it must be missing my most recent assessment”?
One of the fundamental principles of user experience design is that context matters. It’s critical to think about how teachers do their work and how they make decisions before you decide that a data warehouse is going to solve your problems.