In response to the open government initiative, Designation challenged my team of three to design a responsive microsite for the city of Chicago. The goal was to streamline residents’ experiences accessing critical information or communicating with their elected representatives. Government websites must contain comprehensive material and services across extensive topics. This experience can be overwhelming and difficult to navigate.
With such a broad scope for the project, we decided to narrow our focus through user interviews. What mattered most to residents of Chicago? Designation provided four potential areas of concentration:
We conducted eight interviews with residents roughly matching the demographics of Chicago in age, gender, and race. Conducting a few guerilla interviews led to inspiring interactions with users that we would have otherwise never come across. We asked both focused questions that concentrated on the current city website and government services, as well as exploratory questions about civic issues and any communications with elected officials. We chose questions in these areas because of our initial assumptions. We hypothesized that:
After synthesizing takeaways from our first affinity diagram, an overarching theme emerged. Users needed to stay updated on the “status” of issues that affected them, those associated with their specific neighborhood.
“I want information on what the city is trying to get done. I would love to see them bring focus to something I wasn’t aware of.” - Charisma
“I want to put in my zip code or address to get information about my neighborhood on one platform.” - Carol
At this point, status included such things as taxes, crime, infrastructure, events, permits, and transportation. But which type of status was most important to our users and why? We reorganized our insights to find out. We determined what mattered most to our users was the status of taxes and spending, or city budget information. Users didn’t trust the city. They reiterated increasing taxes, widespread corruption, and a desire for more transparency.
“I need more transparency with property taxes. I want to know where my money is going. More information is better.” - Wayne
“We live in Crook County. They’re like a bad boyfriend: they tell you what you want to hear and they’ll do whatever they want.” - Claire
Our users’ main concerns didn’t align with our assumptions. But our questions about civic issues brought out residents’ emotional relationship with the city. We then consolidated our interviews into three personas. This helped to keep the team on the same page while making decisions for our users. I created our primary persona, Lucas, who allowed us to focus on the users’ most prominent needs.
After determining that users wanted to know where their money was going, we dug a little deeper. According to a U.S. PIRG report, Chicago is a model for how cities should make spending data accessible to the public. This was great news! But Chicagoans were in the dark. We set out to research the avenues currently available to users and we found a ton of information:
We were drowning in data. There were pages upon pages of disconnected, dense information in pdfs, data sets, and charts. All used complex financial concepts and terminology. One of our interviewees, a super-user of the city of Chicago website, summed up this same struggle facing members of his neighborhood community group:
From this massive data pile and its resulting disconnect from users, we discovered an opportunity:
According to independent third-party agencies, like the U.S. PIRG, Chicago is doing an excellent job of publishing raw budget data. However, residents must invest a lot of time and effort to organize and understand the various documents and how they relate to one another. How might we present city budget information in a way that is quick and easy for residents to find?
But was it valuable enough to make our primary target providing access to this information?
“Transparency is important for good fiscal management and checking against corruption, so citizens can feel confident in how their governments spend tax dollars.” - U.S. PIRG senior analyst, co-author of the above report
Once we defined our problem, we explored examples within the landscape of budget data representation. We researched financial data tracking websites and apps across several disciplines. The precedents from state and city governments proved to be the most impactful.
We kept these takeaways in mind heading into iterative prototyping and testing:
We noticed that our government budget data examples were not mobile friendly. Since our task was to design a responsive website, we chose to begin prototyping in mobile first. This compelled us to tackle spacing concerns with the quantity of our content. We ideated and generated six roughly sketched, high-level concepts. We experimented with:
Users wanted to find out more about their neighborhood’s budget and how it compared to other neighborhoods.
High-level topics with personal interest, like safety, infrastructure, or education, appealed to users.
Users preferred seeing an overview of the city, like a map, chart, or stat, to give them immediate context. They then wanted progressive disclosure of more specific information.
We developed three paper prototypes to test the data’s portrayal by neighborhood, organization into topics, and level of granularity within a flow. While the progression of information was similar between prototypes, navigation and data representation varied.
This prototype broke down the city’s annual budget using a series of pie charts. It listed each pie chart section percentage for topics, departments, and programs. Users found it difficult to navigate since there were no breadcrumbs to follow their path.
This prototype first gave the city’s annual budget and required a neighborhood zip code to access all other information. As a restricted flow, users found it easy to navigate. It divided the neighborhood’s annual budget by topics, departments, and programs using both pie and bar charts. On the program’s page, users responded to the number of work orders completed, which was tangible to them.
My prototype gave users the option of two parallel flows from any point. Tabs allowed users to switch between the city as a whole or a neighborhood by zip code. Although users had more freedom, they found it wasn’t as intuitive. I split the annual budget into sections most aligned to the data portal source using both pie and bar charts. Users responded to the bottom navigation breadcrumbs, which supported jumping between levels of granularity.
Paper prototype testing revealed complications with our insights from concept testing:
Users loved seeing how the city allocated money by neighborhood. For rapid prototyping, we used mock data by taking the city-wide numbers and dividing by the number of neighborhoods. But does any of the budget data exist for specific neighborhoods?
One task we tested was to find a data point from a specific program, Graffiti Blasters, which the city categorized under safety. But users associated graffiti removal with topics such as infrastructure or community services and became lost. The contents of high-level topics weren’t clear since each user had a different mental model.
Users felt the information was too granular and had no context as to what the numbers meant. The layers of detail down to specific program expenditures weren’t relatable and users felt disconnected. More granularity in dollars doesn’t equate to user engagement.
We needed to dig even deeper into the data. Seeing the budget broken down by neighborhood appealed to users. But the city doesn't divide the budget per neighborhood. It allocates money at a city level for departments, sub-departments, and programs. We first needed to determine roughly what information was currently accessible to us. From there, we could estimate to what extent the solution could query information if we had access to all the city’s data.
The city organized the data in a way that didn’t match users’ mental models and was in a format that didn’t matter to them. We struggled with how to present such complicated information in a simple way without losing accuracy. Misleading users would contradict the goal of transparency. To work through these issues, we took two approaches to our first Axure prototype: simplify and quantify.
Users started with a centralized search bar. Taking keywords from their input, it bypassed topics and directed them to the appropriate department. They no longer need to know where things lived. The text was more conversational. Users could jump between revenue and expenditures, but would return to the search bar to find a different department. We listed revenue streams for the whole city, as there was no way to break it down by neighborhood. More detailed descriptions for these sources existed if the user wanted to view them. City and neighborhood expenditures were only shown if they were quantifiable or tangible. The city may not appropriate money by neighborhood, but the number of resources, services, or employees resulting from the city’s budget could correlate to locations.
Users still responded to their neighborhood, wanting a greater emphasis on comparisons. Quantifiable data was the key to remaining true to budget allocations by neighborhood.
Users appreciated that it was straightforward. But now it lacked immediate city context and the search bar was the only point of access. Quantifiable data showed users numbers that made sense.
We finally presented the data in a way that made users care because they understood how the budget related to them. Users expressed interest in taking future steps. They felt it could be a positive tool for the city to show the budget’s impact.
“I want to know when the budget vote comes up, when the meetings take place, and who’s in charge. If something isn’t well funded, how can I make my voice heard?” - Florence
“To justify taxpayer spending, it’s important to show where your tax dollars are going and how many people are benefiting from this resource.” - Osway
We were on to something, but we needed to flesh it out further. Armed with a stack of paper, sharpies, coffee, and snacks, we redesigned the website. We started with the heart of the concept, quantifiable data, and worked backward. Due to the volume and variety of information, we defined a card system to aid in comprehension and development. Cards were consistent for the neighborhood level, city level, expenditures, and revenue.
From our sketching session, we built our final prototype in Axure. The entry point to the data was now the neighborhood, which led to an overview of each department’s quantifiable expenditures. From each department card, users could switch to the sources of revenue for that department city-wide. Additionally, department cards allowed the user to jump to specific side-by-side comparisons. Comparisons were for that department’s expenditure data for both the city as a whole and custom neighborhoods. These comparisons could be powerful when there was a mismatch between resources and need.
We played up this comparison feature on the home page, which clarified the value proposition of the website. This led to the name Simple Slice during our sketching session filled with pie charts. We discussed the neighborhood part of the city budget as users’ “slice of the pie.” After struggling with how to represent the neighborhood, we found a format that provided transparency. The quantifiable data allowed us to define each neighborhood’s slice with accuracy and simplicity. Advocating for their community, or their slice, was a reason for users to get involved. Resources were accessible for users to stay updated including reaching out through social media, contacting OBM, or attending budget meetings.
We tested our final design against the current city of Chicago website with three tasks of varying degrees of granularity. For the first two tasks on the city’s website, all the testers either timed out or gave up before timing out. Users completed all three tasks faster on our website. We reduced the time spent:
We streamlined access to tangible city budget data while providing context specific to each user. Links to the city’s data portal and AFA gave users the option to dig deeper into the numbers.
If we had more time, I would have liked to research and ideate data visualization techniques to explore interactive alternatives to listed icons and statistics. I learned to lead my teammates through a rotating facilitator role to keep the project on track within a short time frame. The crucial addition to my design process was identifying and testing assumptions. It was important to iterate our research to validate or invalidate assumptions and build on the results. When users wanted to see data organized into topics, we only found out through testing that it didn’t work in execution. I used this skill many times over in my subsequent projects with real clients, Ven.u and eRetirements.