Tori Breitling

UX/Product Designer

The "guide" page type

Designing an approachable, modular model for complex city processes.

Context

This challenge takes place within a larger project, which is the rebuilding of the City of Austin's website. Not only is the content getting re-written department by department, but we are also building a custom CMS to support the maintaining of the website going forward. The team looks to me to establish the content model, including page types, requirements, and the interaction design of the backend UI (based on the open-source Wagtail), as well as direct the visual designer on the corresponding public-facing site.

The City of Austin offers residents hundreds upon hundreds of services — everything from building permits to supplemental food assistance. Since people are increasingly reliant on mobile devices to accomplish their day-to-day tasks, the ability to access these services online has become imperative.

Challenge

There are a number of somewhat linear, complicated processes within the city that residents must learn in order to get something done at the city. Some examples are:

Getting a mobile food truck permit
Organizing and getting approved for a community garden
Getting a permit for residential development

What's worse: the harder the process, the more inequitable it is.

The question was, then: how do we organize these processes into something that residents can more easily navigate? How do we make them more equitable?

Team

I'm part of a cross-disciplinary team. The team consists of:
• 3-5 content strategists
• UX designer (myself)
• Visual designer
• 3-5 developers

The design of the guide is an example of how we as a team are assessing the content on the current website and transforming it into a modern content delivery system that is mobile friendly, equitable, and accessible.

Understanding the problem

Here a content strategist and I are dissecting existing content and trying to put it into sensible buckets.

Content and worse-case scenarios

I spent quite a bit of time reviewing the content with the content team. We chose food truck permitting as our test case. Even though much of the content could be rewritten and streamlined, there wasn't much to be done in the way of actually simplifying the process, which required permits, inspections, food-handling certifications, restroom agreements, operational itineraries, and other requirements based on food truck type and/or location of operation.

Many of these processes are so complicated that the residents are nearly unable to navigate them without help. There are rules to be followed and documents to be filled out, yet these documents may be from multiple departments within the city, and the requirements for them vary depending on a number of factors. In actuality, sometimes even the city departments don't fully understand what the requirements are. As one mobile food vendor said: it depends on who you talk to. You'd get a different story every time.

In some cases, like residential permitting, cottage industries have sprung up around them as they are so impenetrable as to be next to impossible without expert help. Mobile food truck vendors started their own google group as a way to get help from others who have gone before them.

I got SO much disinformation when I was starting this... and I learned more correct information from the people who'd been through it.

Tina R, owner of a coffee trailer

User Interviews

It became clear from talking to food truck vendors that the problems were numerous:

The departments themselves were vague on many details; for instance, the truck inspection process was fraught with inconsistencies, and the outcome largely depended on the employee that conducted the inspection .

Getting the most accurate information was largely dependent on physically going to the governing office, in a part of Austin poorly served by public transportation, which in itself created inequity.

The information that was online was hard to find, and hard to understand. Much of it was embedded in forms or PDFs.

Iterating to a solution

Desk research: How this problem being solved elsewhere?

Our team often looks to other city and state digital design teams for inspiration and learning. We most often look to mass.gov and gov.uk. While gov.uk had a very interesting tool which guides users through a defined goal, the processes we were working with weren't defined enough. Mass.gov uses table of contents for some of their extremely long pages, but this model didn't support our content. Additionally, and perhaps most importantly, I had to work within existing limitations. Most notably there's no single sign-on available, so no ability to utilize online forms or save incomplete work.

I started to think about other models that supported big volumes of content in a structured way. As a frequent user of online learning websites, I looked to course ware for inspiration.

Sketches

I starting with experimenting with frameworks that I thought might support the volume of content for these city processes.

One of big hurdles to overcome was providing residents a way to access content in a sensible way. Currently, the content was spread across a number of very long pages, and not in any particular order, making it very hard for residents to understand the scope of documents related to their task, or the order in which they should be viewed.
While these processes were too undefined to use any structure like steps, I realized they could be loosely grouped into linear buckets.
Additionally, I wanted to reduce the amount of friction and visual noise on the page - how could I just show the relevant content to residents so they can focus on the task at hand?

The content strategy team was already in the process of re-writing this content to new standards (service-oriented language, 5th grade reading level, plain language, no acronyms, etc). As part of that work, content is broken down into shorter pages that describe a single service or offer information on a single subject.

I settled on a design which uses a left rail navigation with section headers to divide this re-written content into rough phases I cleverly name: Before the Thing, Doing the Thing, and After the Thing. In this way, I hoped to provide residents a quick overview of the content. Even if they were confused about what specific thing they might need to do next, they could probably assess which of these buckets most applied to them and start there.

In order to reduce visual friction, I wanted to remove "wrapper" noise, and present the content in a cohesive manner. The navigation on the left links to the primary content on the right. Additionally, the guide would aggregate documents and contacts into a single location.

Sketch of how content is pulled from pages and re-used in the guide

A modular, flexible framework

In my view, a huge benefit to this model is how guides are created. The guide is essentially a feed of pages, using the titles as navigation. This was a huge win for us, because it's a relatively easy technical lift for our small dev team, yet provides a flexible way to handle the many very complex processes across the city. It also inherently handles content governance - a single page may be used in guides across departments, while one department remains responsible for managing it as the "source of truth".

Note: I did need to work with the Content Strategy team to re-write the style guide for page titles. What I discovered was that since the page titles served a dual purpose as navigation for the guide and as page titles, they needed to be even more descriptive of the content to support scanning in the guide, as residents would not necessarily have the immediate benefit of scanning page content in the guide view.

Early prototype

Wireframes & prototypes

Because navigation was so essential to this design, I used Axure to create a prototype of the food truck content to use for testing. In it I included some features we could use to explore with participants, like starring of content, printing, and aggregating contacts and documents together for easy access.

Video of prototype used in testing

Prototype: This version shows collapsible navigation, due to the limitations of the prototyping tool. The final version exposes the navigation.

User Testing

User researcher Kristin Taylor and I created a test plan based on the prototype. Along with a content strategist, she tested with 5 residents who were already familiar somewhat with the food truck permitting process.

What we were curious about:

Did residents understand the structure? Were they able to navigate easily?
Did the starring system seem useful to them? Did they notice it and if so, were they curious about it?
What did they say about how to use the content? Did they want to print or not?
Were they able to find specific info within the content as directed? (there were several tasks of this nature.)
Did they want to search the content? Did they look for search on the page or did they try the browser search?

Updates we made based on user testing:

Users didn't notice the stars and how they worked wasn't immediately apparent. They stated they would print the whole thing. We took them out.
From a content standpoint, we needed to split up this content into two guides, as permitting your food truck was a completely different goal than keeping it permitted. We shared this finding with the content team, so they could include it in the style guide.
If vendors were going to print, they'd simply print the whole thing. While the interactive check boxes weren't interesting to users, the idea of a checklist was.
Participants were put off by the immediate wall of text, and wanted a softer approach to start with. I initially had an intro section, so we put that back in with an image, along with a description to help orient the user.
Content and documents - Having one place for documents was appreciated. However, users didn't notice the link to documents and contents per page, so I removed that, and put them in their own category in the left nav. Users also told us that it was confusing to have the documents listed more than once. We went through several ideas of how to present them, and in the end settled on a simple list for MVP.
We also realized that in general there was only one contact for most of these processes within the city, so we made a rule that we would show only the primary contact for any given process. This would make it easier for residents to know who to call, and lessen the chance of misinformation along the way.
Test participants wanted a way to access the most used documents - in this case, the checklist and the permit forms. We added links to those at the top off the guide. We wanted to make these more visible by making them buttons, but because we don't have a button component for authors on the back end yet, we pushed it to post MVP.

Scrollable comp, final visual design (content incomplete, however)

Visual design

Chase Chenevert, our visual designer, was largely responsible for the visual style for the guide, based on the styles he has implemented for the alpha.austin.gov website.

The guide is nearly code complete, and we're working with developers to make sure that the navigation, sticky header, and mobile implementation works as expected.

Looking ahead

"I need that."

Director of Minority and Small Business, pointing to the guide demo during a sprint review.

MVP status

Currently the guide is in development, and will likely be utilized by a number of departments and live by September 2019.

The team struggled with this problem for many months before settling on this solution, so I'm very excited to see this guide template utilized across the city. It offers a robust, technologically appropriate solution that leverages all the hard work the content team is doing, and has the added benefit of content governance that will work in the city's distributed content system. Win win!