The City of Bloomington, Indiana

Imagining how web-based technologies can help a small community better connect with its local government.

Feb 2015–Jun 2016

Background

Municipal governments offer a variety of essential services to the public. Unfortunately, government offices have the same business hours most businesses do, and fewer residents are free during the day to place a phone call, or physically go to City Hall to conduct their business with the city. Many cities around the US have found more residents have time and attention to focus on government business after hours, on the Internet. A municipal website is often the first contact constituents make when they need help solving a problem, and it is important that the government’s website serves as a Digital Front Door for the community.

Challenges to be addressed

A restrictive website design. The City’s previous website featured an outdated three-column design, making the site feel busy, cluttered, and confusing to use. The main body copy was set in a font size that felt normal in the mid-2000s, but felt small and challenging to read compared to sites designed in the mid-2010s. The site’s sidebars took up real estate that prevented us from adding visual interest to page content.

Visual hierarchy problems. The right sidebar consistently featured a site-wide listing of links to other popular services available on the site. This made it easy to assume the right sidebar contained only content that concerned the site as a whole, not the page. However, on many pages, the second element in the right sidebar was the page’s primary call to action: A link to download a file. This confusing visual hierarchy led to several UX problems, including:

  • Visitors not finding links to important document downloads.
  • Site contributors independently looking for workarounds to the site’s confusing design. Different contributors came up with different workarounds, resulting in confusing inconsistencies across the site.

An internal page from the old City of Bloomington Website

A confusing information architecture. The website’s navigation structure was designed to make individual pages available through multiple navigation paths. This was intended to make it easier to find information, but proved problematic. Both end users and website maintainers felt confused about “the right way” to categorize or navigate to a particular page.

Of the multiple navigation structures implemented, the one that received the most maintenance over time was a structure based on City Hall’s org chart: Content authors in each department easily understood that “our stuff goes into our department’s section of the website.” However, after reviewing other cities’ research, and conducting our own conversations with our neighbors, we found the general public doesn’t know City Hall’s org chart, and organizing a website structure around that chart created a barrier to entry for the public.

Mobile website users. Although a mobile version of the site was built, it was implemented with a different codebase, and content was served from a separate repository. The mobile site featured significantly less information than the desktop site, and information was often out of sync with the main website.

Dysfunction among website contributors. Bloomington’s website isn’t the work of one person, or one department. It’s the work of several individuals, spread throughout every department of the City. I was the go-to contact for colleagues from other departments on matters related to the City website.

My predecessor reportedly treated the job as a gatekeeper role. There had been rules enforced upon all contributors based on broad generalizations that ignored differences in roles, and differences in department revenue models. To work around policies that failed to address basic needs, website contributors with limited technical ability and system permissions sometimes found ways to “sneak in” what they needed.

My role

Part of a small, experienced, multi-disciplinary team. The core team included four individuals: myself, the PHP developer, our team manager, and our department director. Everyone on the team had over 10 years of experience with creating websites, and we each participated in drawing sketches on whiteboards, ideating and iterating design ideas, and submitting suggestions for information architecture.

Sketches, wireframes, and mockups. I chose different design tools, depending on the specific challenge I needed to address on a given day. Some challenges were better addressed with paper sketches, while other challenges were better addressed with wireframes. Sometimes, high-fidelity comps were created in Photoshop, and other times, the high-fidelity deliverable was made with HTML and CSS. In each instance, I picked the tool that moved the process forward to the next stage as quickly as possible.

Code. I worked as the lead HTML and CSS developer on the team, with some support from the team’s lead PHP developer.

Partnership builder, not gatekeeper. I advocated for treating website contributors as partners, not as inferiors to be enforced. When website contributors made requests to post material to the site that I didn’t understand, I met with them to understand what problem they needed to solve for the public, and developed a strategy for how best to solve that problem, with available resources.

Design Goals and Brand Principles

Responsive web design from day one. The team agreed strongly that we preferred pursuing Responsive Web Design to streamline the user experience on our end users’ many varying devices.

Organize content by problems and needs, not by City Department. A lot of people who need government services are not experts in how the government runs. Our design shouldn’t require them to know our org chart, just to find a service they need.

Design for search engine users. Our Google Analytics data showed that most of our visitors were referred by Google to pages deep within the site. The new site should anticipate that most visitors will skip the homepage.

Approachable and calm. Many who find themselves in sudden need of a particular government service are already panicked. Navigating our website shouldn’t fill them with dread that they are helpless to find the right page.

Balance friendliness with trustworthiness. As a government of a small city, all of our constituents should be welcomed as if they are our neighbors. They often visit City Hall on our front lawn, and our work sometimes places us on theirs. However, the overall tone of the site should not be so casual that official government services appear to be unreliable.

Emphasis on getting things done. The purpose of a Digital Front Door is to empower the public to conduct their business with local government. If a web page that gets proposed for the website doesn’t help the public to get something done, we need to carefully consider that page’s value proposition.

Publish early, collect feedback, iterate. This site had a lot of content, with information covering many domains. There was no way someone in the IT Department could correctly grasp how to organize it all. My plan was to start small with a sample of ten services from each department, chosen with the help of administrators and website contributors. We would then test the site, and make course corrections with the next iteration.

Design Research

We examined dozens of other governments’ sites, commercial business sites, and university sites to get a picture of what other work exists in the market, and what design patterns seem to best solve the challenges of sorting and categorizing large amounts of information. The team favored the State of Hawaii’s award-winning site, for its attractive homepage and information architecture that caters to specific audiences: Government, Residents, Businesses, and Visitors. The City government offers a wide variety of services. We thought that residents looking for services geared toward them might get overwhelmed if they are forced to browse through services geared toward businesses, and so on.

Screenshot of the Hawaii state government homepage

I was most impressed by GOV.UK, for the way it broke its information architecture down by needs and problems.

Screenshot of the GOV.UK homepage.

This site’s information architecture provided a consistent, and easy to understand schema: Two tiers of categories, with all service landing pages residing at the third tier. Simple animated transitions made it easy to understand where a user was before they clicked, and where they ended up after the click. All three tiers of navigation were visible at all times, on desktop devices. This consistent schema reduced the cognitive load of exploring the services index topic-by-topic.

Screenshot of the GOV.UK navigation.

The personality of the site seemed dry–which I think is a great fit for a national government. However, due to the small, almost intimate size of Bloomington, everyone on the team agreed we wanted our design to convey a more lively personality. We initially decided we wanted our information architecture to mash up of what we liked best about Hawaii’s site what we liked best about GOV.UK.

Adapting the design process to specific challenges

This website was more than just one project: It was comprised of several sub-projects. Different projects for this site presented different constraints. Before getting started, I thought about what specific problem needs to be addressed at this particular stage of solving this particular problem, and followed a design process that resulted in deliverables and finished layouts as quickly as possible.

Data-heavy design. For example, a screen listing an index of documents and metadata for public meetings involves laying out several dozen text fields. To make a quick pitch about the overall layout, I sketched out a rough idea of what the design would look like on paper.

A sketch of the City Calendar

Refining text styles for several dozen text fields in an app like Photoshop is tedious and time-consuming. I hadn’t discovered Sketch yet. In this case, I leveraged the cascade in HTML and CSS to make high fidelity design decisions in-browser.

A screenshot of the City Calendar

Collaborating with other departments on a portal project. We set out to create a new marketing-focused page to help introduce the public to the Parks and Recreation Department’s many offerings. I created some mostly-empty wireframes in Google Slides, to open a dialog with the department’s Community Relations Manager about what how to prioritize visual hierarchy. Wireframes were a new concept for this stakeholder, so I was very careful to explain that this was not representative of what the final design would look like. This was more of a discussion tool to help better communicate the stakeholder’s priorities.

Empty Parks and Recreation Portal wireframe

The discussion with the stakeholder was constructive, and we were able to go through the wireframe, step-by-step, and start prioritizing links and content for this new portal.

Populated Parks and Recreation Portal wireframe

With prioritization and hierarchy discussed, the next problem I worked on was how the look of the screen makes us feel. For this, I created high fidelity comps in Photoshop. Once we started to see high-fidelity comps, we had some more ideas about how to improve the page structure, but this did not stop us from iterating quickly.

Mockup of the Parks and Recreation portal

Prints of these comps were presented in review meetings, so that annotations could be added by the rest of the team, and stakeholders.

Annotated mockups for a Parks and Recreation facility page

First iteration of the information architecture and homepage

Following what the team liked about Hawaii’s site, we set a navigation bar with our vertical audiences in the first tier navigation bar, at the top of the site.

First iteration of homepage

The second tier of navigation was a set of categories related to each vertical, listed in the left column of a site index. The third tier of navigation was the list of landing pages, on the right hand side of the site index. I initially wrote short descriptions for every section. Keeping with the design principles of approachable and calm, and balancing friendliness with trustworthiness, I wanted the word choices to strike a balance between common language and office vernacular. Some vernacular was important for sounding official, but it needed to be explained, so that visitors could learn about the inner workings of their government while the browsed through this navigation.

First iteration of site navigation

For services that couldn’t fit on just one page, we provided an optional fourth tier of navigation, just beneath the landing page title, but only on landing pages about topics and services that couldn’t be contained to just one page. Grouping pages at this level of the navigation made these pages feel like several unified mini-sites, even though they were served through the same Drupal instance. Many departments at City Hall don’t have access to photography, or photographers, so the design provided a default photography option: Images of City Hall itself.

Page Header without sub-navigation.

Page Header with sub-navigation, and default City Hall photography.

Balancing a friendly introduction with a formal follow-through. An important goal of this project was to help make government more approachable to all, without restricting the site from presenting legitimately complex subject matter. To help with this, most pages start with a short Page Summary in large text, Contact Information for the government office that offers the service (where applicable), and a clickable Table of Contents designed to help visitors scan the page faster.

Example of a page using the design language

Iterating the homepage, based on internal and external feedback.

First iteration. The design that I originally pitched attempted to borrow some inspiration from Hawaii’s homepage, while setting the stage for a navigation tree similar to GOV.UK.

First iteration of homepage

The main navigation was at the top, and the four icons beneath the search bar were meant as a collection of shortcuts to popular services. I felt the photography on the Hawaii homepage was distracting, and posed a challenge to readability, so I made the image monotone, and lowered the contrast, to make it more subtle. I wanted the image feel like a reflection in a glass door, as a reference to the glass doors at the front of City Hall.

Once we started collecting internal feedback, we received significant pressure from stakeholders with considerable political capital to increase the amount of shortcut icons, and top tier navigation links. The collection of shortcuts grew from 4 to 16, and the space to view the background photo behind the search bar was eliminated, as an attempt to accommodate shortcuts. I knew these requests were bad, but I also knew we were shipping a first iteration, and we would start collecting external feedback. I talked our department director down from 16 shortcuts to 12.

Second iteration of homepage

When we launched with this homepage, internal feedback was that the new site is an improvement over the old site—especially the Responsive Web Design—but still had a lot of room for improvement. Some vocal stakeholders worried the design didn’t celebrate the vibrance of the community. There were concerns that the strict three-tiered navigation structure of GOV.UK couldn’t be made to fit our city’s services.

Some external feedback I received by word of mouth was that the amount of scrolling required to see all twelve shortcuts was overwhelming.

Feedback revealed that users didn’t look at the top right corner. We also collected public feedback, using Google Forms. A number of comments revealed a new problem: Many users thought the shortcuts underneath the search bar were the site’s primary navigation.

Incorporating feedback for a major pivot. Several stakeholders felt that breaking down the information architecture by user verticals was just too difficult. The team made a decision to make the homepage more like GOV.UK, with a directory of services. We eliminated the top navigation bar that many users didn’t notice, and put the main navigation under the search bar, where we knew our visitors were looking.

Third iteration of homepage

Other layouts created for this site

City events calendar. With several departments, public boards, and commissions, the City of Bloomington hosts a lot of events, ranging from public meetings, to educational outreach programs, and even public entertainment. We needed a calendar design that made it easy to see what events are scheduled for upcoming dates. Most of the time, there were multiple events in one day. The data density was much higher than, for example, a list of upcoming meetings for one public board. This calendar was designed cut down on visually repetitive design elements, and use the reclaimed space to add some style and personality to the calendar data.

City Calendar

Fool-proofing old News Releases. I frequently received requests to eliminate old News Releases from the City’s previous website. However, as a public agency, the City Government shouldn’t un-publish old documents that represent public history. Members of the public often confused old news releases for announcements of upcoming events, resulting unwanted phone calls. To help alleviate this confusion, I created two versions of the page header for News Releases.

Header for the City Newsroom

Header for the news releases older than two months

Why this project failed

We didn’t break the site down into small, manageable releases. In the beginning, I pitched our managers on the principles of Lean Startup. When I suggested we implement pages for ten services from each department, testing the site, and iterating from there, managers responded that this was too much work. Instead of completing the project with several small steps, they insisted we finish the project in a few big steps.

Nobody owned Information Architecture, and nobody agreed about it. The managers hoped to finish the project quickly by writing a content migration script that could copy content from the old site to the new site. Unfortunately, because there were several rounds of disagreement about what content should go where, the variables needed for the content migration script didn’t materialize.

The project was repeatedly put on hold. Fixing this website was not a political priority. There were frequently other crises demanding immediate attention. Constantly shelving this project led to communication black-outs with content contributors, preventing them from posting their content the new site. I attempted to alleviate these problems by suggesting we dedicate at least one day a week to this site, but I was told that this was a luxury we simply couldn’t afford.

What I learned, what I’d do differently

User journeys, user flows, process diagrams. At the beginning of the project, I recommended we follow a design similar to GOV.UK. However, as I read blog posts about their processes, I learned it was more than just a design decision: There was an entire workflow that went into creating the site’s content and organizing it in a way that focused on helping website visitors solve their problems.

To try to get the team to think more about the UX aspect of this project, I suggested that we ask three questions about each page we want to add to the new site:

  • Whom does this page help?
  • With what does it help them?
  • How do we help them finish it?

Although I didn’t get an opportunity to explore this idea with this project, I think deliverables like this are a helpful tool to clarify for the production team where the goal post is set. I’m very interested in working with something to address this in future projects.

Follow the data. Working as a designer on a project big enough means engaging with stakeholders. They must feel as though their concerns have been heard, but their interests are often at odds with those of users. Collecting data, whether qualitative or quantitative, helps give voice to users. A designer can’t simply insist they know users better than stakeholders do—we need to back our assertions with data. It isn’t enough to point to data gathered by other teams, collected from their users—that data isn’t specific to our project. Our end users are more likely to notice mistakes than either internal stakeholders or designers, and this can be a tremendous benefit, but only if we listen.

The City of Bloomington, Indiana