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 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 feels small and challenging to read compared to sites designed in the mid-2010s. The main content area was narrow enough on screen that increasing the font size would result in very few words per line of text, potentially hurting readability even further. The site’s rigid sidebars took up space that we would have liked to use for adding elements of visual interest to page content. The right sidebar consistently featured a listing of links to other popular services available on the site. On many pages, the listing of links was followed immediately by the page’s primary call to action: A link to download a file. Putting the call to action immediately after a listing of links unrelated to the page discouraged our users’ eyes from scanning the page deeply enough to find the call to action.
A confusing information architecture. The website’s navigation structure was built on an acyclic graph, designed to make individual pages available through multiple navigation vectors. 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 isn’t interested in knowing 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.
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. I don’t always jump straight into Photoshop to make a high fidelity comp. 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. I used some additional tools to automate SASS builds. Our team used a mix of macOS, Ubuntu Linux, and Windows computers, so open-source cross-platform tools were a better fit than platform exclusive tools. The Node.js ecosystem provides front-end development automation tools, like Gulp, that are free, and cross-platform, so it made sense to use them for automating SASS builds. Additionally, I collaborated with the lead PHP developer on PHP templating to implement designs, including logic for loops, and logic that provides an alternate rendering for empty states.
Partnership builder, not gatekeeper. 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, but I found this problematic. There had been rules enforced upon the website’s contributors based on broad generalizations that didn’t apply equally to everyone’s role. For example, there had been a rule not to treat one department differently from another. However, each department is different from the others, each with different missions – and in some cases, drastically different revenue models. Ignoring these differences resulted in missed opportunities to deliver the best online experience to our community, and nurtured dysfunction between my department and others. Treating colleagues as website partners, not as inferiors to be enforced, yielded better results for everyone, from the public, to colleagues in City Hall, and the ITS Department.
Responsive web design from day one. Research from many sources showed a trend that more end users browse sites from mobile devices than ten years ago. Our analytics showed that the link to take visitors from the mobile site back to the desktop site was one of the most popular links on the site. The team agreed strongly that we preferred pursuing Responsive Web Design to streamline the user experience on our end users’ many varying devices.
Information architecture that puts users first. Instead of a site where each City department has their own section, I advocated for building a listing of City services sorted by the kinds of needs experienced by our neighbors outside of City Hall.
Design for search engine users. Our Google Analytics data showed that, although our homepage was our most frequently visited page, it was almost never the most frequent referer for our other pages’ traffic. They often started at Google, searched for a term, and landed at a page deep within the site. The new site should anticipate this. If the deep page the visitor lands on isn’t exactly the right one, they can find their way back into the site’s navigation by using breadcrumbs above the page title. Pages deep within the site will often be the first impression users have of our site, so I designed more of those pages to feel like landing pages.
Design for federated search. Because the IT Department has in-house developers, we had the capacity to build a customized search service that can return deeper results than can be discovered by web crawlers. Additionally, a federated search narrows down results to only official City resources. Although many users search Google first, a customized search provides another helpful entry point for the public.
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.
I was most impressed by GOV.UK, for the way it broke its information architecture down by needs and problems.
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.
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.
Before getting started on the design, I wrote some design principles to help guide the process. Because so many people would contribute to this website, it was important to me to be transparent about what was considered “good”, what was considered “not good”, and how these choices would impact those in our community visiting our site.
- 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 informal or 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.
Design persona. In addition to design principles, I asked myself questions about the personality of the website, itself, inspired by Aarron Walter. I imagined a mashup of a government records clerk, and a record store clerk: They know the contents of their shelves, like it’s the back of their hand. Not only do they know where to find things quickly, these clerks know the real impact the contents of their shelves have on their visitors.
Design language. For header type, I chose Lato, because its personality maintained a balance of feeling modern, formal, and approachable. For body type, I chose PT Sans, for its simpler glyph forms, and overall approachable feel. For the palette, two blues were chosen: one to represent the blue color already prominent on familiar City branding, and a second shade to represent a lighter accent color. Five shades of each of those two colors were then chosen to represent varying shades of light and dark. Beyond that, complimentary shades of green, red, and orange were chosen, for accents, calls to action, warnings, and so on.
Publish early, collect feedback, iterate. We had seen other government teams publish their next generation websites as public alphas, so they could build transparently and collect feedback as they progress. This mirrored findings from prominent design teams in the startup world: It’s less risky to find failures early on in the project, rather than later on.
Adapting the design process to specific challenges
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.
Refining text styles for several dozen text fields in an app like Photoshop is tedious and time-consuming. For this kind of use case, I can leverage the cascade in HTML and CSS to make high fidelity design decisions in-browser, in a lot less time.
Collaborating with other departments on a portal project. When 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 turned to the department’s Community Relations Manager to offer input as a subject matter expert on how to structure links. I created some mostly-empty wireframes in Google Slides, to open a dialog about what the overall layout might look like, and how to prioritize screen real estate for certain links. 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 for me to better understand the stakeholder’s priorities, so we can move forward from there.
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.
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.
Prints of these comps were presented in review meetings, so that annotations could be added by the rest of the team, and stakeholders.
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.
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.
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 structure. 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 feature a Page Overview, designed to give users a quick idea of whether or not they’ve at least landed at the right page. This includes a Page Summary in large text, Contact Information for the government office that offers the service described by the page (where applicable), and a Table of Contents designed to help users scan the page faster, providing links to specific sections further down the page. This nomenclature was brought up during design pitches at team meetings, and documented by the naming conventions of the site’s CSS classes, so anyone working with the code or a web inspector could easily name each portion of the design.
Iterating the design, based on internal and external feedback.
First iteration. Early on in the project, I gave only marginal attention to the homepage. Features and functionality on the homepage need to link to deeper sections of the site. It made sense to prioritize designing and developing those features first, and adding widgets referring to these features to the homepage second. The design that I originally pitched attempted to borrow some inspiration from Hawaii’s homepage, while setting the stage for a navigation tree more similar to GOV.UK.
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 had hoped to make the image feel almost (but not exactly) 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 high political capital to increase the amount of shortcut icons, and top tier navigation links. Predictably, everyone wanted a piece of the pie. Despite several assurances from the team that this was only a first iteration, and not a final product, many stakeholders demanded their piece of the pie right away. 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 so many links. These were expressed to me not as requests, but as new requirements. 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.
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 feedback I received by word of mouth was that twelve shortcut icons was way too many. This helped validate my argument that we needed to reduce the screen real estate allocated to these icons.
We started to receive public feedback, collected by Google Forms. A number of comments retrieved through this form revealed a new problem: Many users thought the collection of shortcuts underneath the search bar was meant to be the site’s primary navigation, not the secondary means of navigation that was intended. It seemed as though the search bar drew attention immediately (as intended), but most visitors didn’t scan above that first point of entry. From these comments, I concluded that the bookmarks were so visually dominant, that users scanning the homepage completely missed the main navigation bar at the top of the screen. Having this public feedback available proved crucial for me more effectively pitch the next iteration.
Second iteration. By this point, the team had shipped new design and functionality for News Releases and a City Events Calendar. I had some more time to design more imagery to cheer on Bloomington, as a community. Several stakeholders felt that breaking down the information architecture by user verticals was just too difficult. At this point, we made a decision to make the homepage more like GOV.UK, with a directory of services. Considering that many of our site’s visitors didn’t even see the main navigation bar, anyway, we eliminated that navigation bar, and put the main navigation under the search bar, where we knew our visitors were looking.
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. My goal with this calendar design was to cut down on visually repetitive design elements, and use the space reclaimed by eliminating repetition to add some style and personality to the calendar data.
Fool-proofing old News Releases. I frequently received requests to eliminate old News Releases from the City’s previous website. Members of the public often called someone at City Hall on the phone with questions about events from years ago, thinking that the event was coming up soon. This happened because, despite the year being listed on the News Release’s dateline, the person still read the News Release and thought it was a fresh announcement, rather than a years-old one. However, as a public agency, the City Government shouldn’t un-publish old documents that represent public history. To help alleviate this confusion, I created two versions of the page header for News Releases: One for recent releases, and one for older releases. I applied a sepia filter to the header for older releases, to help visually reinforce the message: This is old news, not new news.
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 needed content and organizing it in a way that focused on helping website visitors solve their problems.
Early on in production, 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? And how do we help them finish it?” I thought this would make it easier to identify content that shouldn’t be published on the site, and promote focus and quality for the content that we do publish. However, my pitch was not well-received.
After we launched the public alpha of this site, I learned about user journeys at a conference session. In hindsight, I think I should have researched examples of user journeys, and shared that these deliverables are used by the teams that produce the work we most admire. More recently, I read some thought-provoking insight UX Strategist Jaime Levy shared in her book, UX Strategy. In her experience, user journeys are often convoluted and only helpful to individuals who attend long, contentious meetings—but that similar, simpler deliverables provide value for shaping a product or digital service, while being less time-consuming to produce.
Although I didn’t get an opportunity to explore these ideas 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 your project. Your end users are more likely to notice mistakes than either internal stakeholders or designers, and this can be a tremendous benefit, but it will only help you if you listen.
This project is an ongoing work in progress
Unfortunately, I had to leave my role with the City of Bloomington before this website—and its many sub-projects—had a chance to finish. I ended my employment on good terms, and I’m eager to see work on this site carry on under my successor.
Because the site is a public alpha, and the team believes government work should be done in the open, the team often publishes rough drafts of updates to the public site. I noticed the team started working on a third iteration of the information architecture in December 2016—as of this writing, it appears the IA is unfinished, or a homepage redesign may still be pending.
This case study is meant to serve as a document of my contributions to this project, and its condition at the time I left the team.