I’ve lived in Toronto for over five years now, but up until recently, I wouldn’t be able to tell you anything about how municipal services in the city are provided, how budgets are decided or even how much the city spends in a year. (Spoiler alert: It’s $10.8 billion, as the open data site I worked on with the skills I built at HackerYou helps you discover in a hassle-free way.)
I found that newspaper coverage was often too specific to a certain topic (e.g. emergency services funding) and lacked the big-picture context that made the numbers more understandable and relevant to a layperson like myself. The City of Toronto’s official website had more comprehensive data, but only in the form of lengthy PDF financial statements chock-full of dense terminology.
Looking at them, I felt like Michael Scott in The Office, asking his accountants to explain budgets and surpluses as if he were an eight year-old, and subsequently, as if he were a five year-old. As someone who prides myself on being an informed member of society, I did not like that feeling.
I loved the design and approach of data-centric websites like the MIT/Deloitte project dataUSA.io and the Steve Ballmer-backed usafacts.org. I thought it was more than a little odd that a major economic centre like Toronto did not offer anything even remotely comparable.
Enter Budgetpedia: data viz for municipal finance
Right around the time I finished my courses, HackerYou happened to be hosting project pitches for CivicTechTO, where I learned about an early-stage open data project called Budgetpedia. The project visualized Toronto’s finances in the form of charts and graphs (right up my alley!) and focused on educating residents and encouraging their participation in the budget-setting process. They were looking for volunteers to help them conduct a UX review of their website. I couldn’t have raised my hand fast enough.
Lessons from the UX Review Process
During the UX review process, we had a variety of different users and stakeholders sit down with us to use the site and explain exactly how a site like Budgetpedia could be useful for average Torontonians. While many of our users were impressed by the amount of data that we’d been able to collect and visualize, the sheer volume of it was definitely overwhelming. It was clear from their feedback that our charts needed to include things that made them easier to understand, like a line explaining the difference between two types of budgets, or the ability to drill down into specific categories.
Our task was clear. Based on the feedback, we came up with a few ideas to pursue for upcoming iterations of the website:
- Audience engagement: implementing the concept of “data stories” to help users actually make sense of the numbers.
- Rapid content development: Building a flexible and familiar CMS back-end that would make it easy for for non-technical project members and guests to contribute their own data stories
- Building partnerships: Access to reliable, granular data continues to be a major challenge. To get the data people are interested in, Budgetpedia has to continue building rapport with councillors, city officials and organizations to obtain those numbers.
- Democratizing Data: A key priority for us is to easily share data with other organizations that can leverage our efforts. Building an API that media and other organizations can plug into to develop their own visualizations is one way of accomplishing this.
We implemented our user feedback into this revised version of Budgetpedia. It’s a proof-of-concept site that we intend to use to obtain more feedback from our community partners, and to show city officials and media groups what the platform can do.
To help demystify the budget for non-policy people (eg. most Torontonians), I also put together an interactive backgrounder to explain how budgets and deficits are defined, what they’ve looked like in recent years, and what they actually mean for city residents in their real lives. To do this, I took a deep dive into the city’s statements to extract the nitty-gritty financial data we needed to create useful data stories. A well-designed Data Story should be thrifty on text, and let the charts do the talking. I wanted to take that a step further by letting the user actually control the chart themselves.
Let’s take the example of city revenues. Rather than simply displaying the data in a static table, I wanted to put it into an interactive chart format that allows viewers to see individual items (eg. Property Taxes) in isolation. This way, they can compare it directly to other items like User Charges (eg. TTC Fees, Waste Management) which makes the data more useful and relevant. They can also click the hamburger menu icons to download the chart as a static image file for reference.
During this process, it became clear that reading financial statements can be like reading a physical broadsheet newspaper – not super user-friendly. You might come across a headline number on Page 3, but to understand what numbers make up that number, you’ll need to go to Page 46 to see the relevant notes and caveats. A good data story should eliminate that annoyance by putting all the relevant data into a single, easy to use chart. That’s where drilldowns come in handy, especially for explaining where the money goes once a surplus has been recorded.
Applying What I Learned at HackerYou to Budgetpedia
By far the most important thing about my HackerYou education was how relevant and directly applicable what I learned was. Trying to understand loops in Harvard’s famous CS50x online course felt like trying to crack Cold Fusion, but under under my HackerYou instructor team’s tutelage, the process felt completely natural.
At HackerYou, I got to work with three professional developers in every single class whose job it was to support my learning. I can’t tell you how much it helped me to have them tell me how their own learning curves were not dissimilar to my own. Real software, even when it’s built by superstar developers with millions of users is not free of mistakes, and hearing about the challenges and experiences of my mentors and instructors was such an important part of the HackerYou experience. As the CEO of LinkedIn, Reid Hoffman, once said, “If you’re not embarrassed by the first version of your product, you’ve launched too late.”
In my dual role as a Project Manager and Web Developer, my key tasks are to set priorities and find the most efficient ways of doing things. Some of these are technical in nature, such as making decisions on which technology and tools to use. In all of these decisions, I benefited immensely from my time at HackerYou – what I learned through the course and in my discussions with instructors and mentors gave me the toolkit I need to evaluate solutions based on the needs and constraints of the projects I’m working on.
We’ve received good feedback on the Budgetpedia site so far, and I’m excited to continue working on it for months or even years to come. Web applications are iterative by nature; there’s always something that can be improved, or doesn’t quite work as intended. Our goal is to engage with stakeholders and continue to iterate the site to better serve the needs of the public.