Screenshot from the live City of Boston site (as of March 2022), with the ‘accordion’ design that my team and I proposed
This was a 3 week volunteer project and the City of Boston kindly gave me permission to write it up in full here. The project was also written up as a blog post on the City’s website, which you can read here if you want to learn more.
Screenshot from the live City of Boston site (as of March 2022), with the ‘accordion’ design that my team and I proposed
I worked with a team of fellow volunteer UX designers to improve the usability of the City of Boston’s website. We were given free reign to select an area of focus, and through research zeroed in on the site’s ‘how-to pages’.
Given the site had to be usable for a very broad population, we placed a great deal of focus on user research and usability testing. Through this approach, we were able to confidently propose a new accordion-based design that made the pages more ‘scannable’ and is still live on the City’s website to this day!
My Role: I worked alongside 3 other designers and the City of Boston team as project manager and contributed directly to user research, information architecture and usability testing.
As a team we were very excited as soon as we got the go-ahead to work with City of Boston. We were already aware of their site and impressed with the work the Digital team had done to improve its user experience. They had recently redesigned the website with the help of design agency IDEO. As part of the redesign, which was launched in July 2016, the site was given a new look and structure that was refreshingly attractive and usable for a government website.
Nonetheless, at the project kickoff, it became clear that there were still aspects of the site that the public had suggested weren’t entirely intuitive and/or consistent. The Digital team had also already commissioned a significant amount of user research that had highlighted some opportunities to further improve the navigation, information architecture and usability of the site.
We were given a list of possible areas of focus for our project by the City Team, and freedom to choose the area where we felt we could add the most value. However, we wanted to get a feel for the site’s user experience and use cases before narrowing our scope.
We headed out to City Hall to start talking to its employees and visiting citizens, having set ourselves the objective of identifying key pain points and opportunities for improvement associated with boston.gov. I conducted guerilla user interviews with frontline customer service advisors at various service kiosks as well as a couple of residents. I even tried to talk to Leonardo DeCaprio at the wax museum immediately outside City Hall but he wasn't very talkative!
It became clear that users were not identifying or understanding certain processes and calling in to City Hall rather than being able to complete their tasks online.
This raised the question of whether the correct guidance was actually online at all, or whether it was just being missed for whatever reason. My teammate and fellow researcher Amanda and I also heard anecdotally that there were only a few select tasks that most people visiting City Hall are there to complete - paying for a parking ticket, excise tax and property tax.
The Digital team had flagged the ‘how-to’ pages on the site as a potential area for improvement, based on some testing they had done with the general public. These pages are step-by-step walkthroughs of how to complete certain tasks on boston.gov. The vision had been for constituents to use them to get a deep, thorough understanding of a process, task or application along with all necessary forms or deadlines needed to complete the steps.
However, the Digital team had some concerns over whether people were able to find the information they were looking for on these pages, in particular the ‘tabs’ that sat at the top of the page that were supposed to indicate the different, distinct ways to complete a process.
These notes from the Digital team, combined with our early research findings, started to point us towards the how-to pages as a sensible area of focus. If constituents were missing important details related to key tasks, as we had heard, then improving the accessibility of that information on the how-to pages could be an effective means of improving this.
With our area of focus set, we refined our research objectives around the 'how-to' pages. These objectives included:
1) Understand more about users’ mental model of how-to pages. What did users expect to be able to do on a how-to page and how did they understand them in relation to other pages on boston.gov
2) Assess the usability of the ‘how to pay a parking ticket’ how-to page, particularly in relation to the use of tabs for in-page navigation.
The City’s existing Google Analytics research had shown that the ‘how to pay a parking ticket’ page was the second most visited page on the site after the homepage. This suggested it was a good area of focus for our research.
We decided to focus our early research on testing the existing site rather than conducting further user interviews, given the City had already commissioned a large amount of user research that had given us some clear assumptions that we needed to validate.
We created 2 primary tasks asking users to pay for a parking ticket online and by-mail, based on scenarios that challenged them to identify the tabs and other important pieces of information on the page, such as permitted payment methods and information about penalty fees.
I personally conducted 2 formal, recorded usability tests, with 9 completed in total as a team.
Our tests of the existing site sought to identify if users were missing important information and if so, why
The key findings from our testing were:
“If you only see the forest, you probably miss the trees. That’s what’s happening to me right now, like I miss the details basically.”
- Jennifer (a user, said after test of existing site)
One clear trend emerged: users were exhibiting pronounced scanning behavior. The large headers on the how-to pages were drawing the user's eye, causing them to move straight past the tabs at the top of the page and not even notice the important payment information contained to the right.
We also hypothesized 'banner blindness' was contributing to this - i.e. users were subconsciously looking past anything inside the blue box at the top. This blue box was displayed in the same way adverts or big decorative photos are placed on other sites - which users would be used to visually skipping over.
This led us to our problem statement:
“People need a way to digest important details quickly when completing everyday tasks on boston.gov. They miss some things entirely, or don’t feel confident in others, and fall back on inefficient and often incorrect analog methods.”
- Our problem statement
With our problem statement established, we set out to answer the question “how might we make the how-to pages more scannable?”.
We knew that visual hierarchy of information on the how-to pages would be an important factor. To help identify what this hierarchy should be, I conducted some participatory design, giving users equal sized post-it notes representing different components of a typical how-to page and asked them to arrange them in a way that felt useful for them.
We also played around with ideas for the layout ourselves by printing them and cutting them into their constituent parts.
There were two ideas that emerged from this process that we liked. Firstly, as soon as we took the tabs out of the header they immediately became more noticeable. Secondly, we liked the idea of pointing users towards important information through revealing it gradually and at the point of need (progressive disclosure). This was as opposed to overwhelming them with all the information at once.
This idea led us to accordions - something we had seen done well in our comparative analysis of the state website mass.gov (see below screenshot). By revealing information at the point of need and not all at once, we thought users would be more likely to process important information.
Our best practice research validated that accordions were a worthy consideration.
“By hiding most of the content, users can spend their time more efficiently focused on the few topics that matter.”
- Nielson-Norman Group
Nonetheless, we wanted to explore the idea with users and so tested it against our best alternative in some paper prototype A/B testing. We asked 13 people in-house to compare an accordions design with one where the tabs were simply brought out of the header but positioned as buttons at the top of the page.
The people we spoke to were overwhelmingly in favour of accordions. The accordions provided them with the right amount of information at the point of relevance so it didn’t feel overwhelming, whereas the ‘buttons’ design still had too much information visible at once and was overwhelming to users.
At this stage, we felt confident enough to proceed with a solution statement based around accordions and turned this idea into wireframes and a clickable prototype.
“Turning tabs into accordions will improve the scannability of how-to pages through progressive disclosure. This will mean users can feel more confident they haven’t missed any crucial details.”
- Our solution statement
Our final proposal for the re-design in wireframe form, with annotations to explain our design decisions
Considering boston.gov needs to serve everyone, we knew it would be important to test our designs with a variety of users.
In the end we tested our accordions design and a number of related tweaks with 29 users, bringing the overall number of users we spoke to over the course of the project to 56 (including 15 tests of the original site and 12 paper prototype tests).
We tested in a variety of locations, to ensure we were testing with a representative sample of boston.gov’s users. We also tested with a range of ages for similar reasons.
Our testing focussed on two areas:
1) Can people use accordions?
2) Are people able to find relevant information for a given task?
We also tested the how-to pay a parking ticket page exclusively to give our testing focus but constantly looked for ways to apply our learnings to other how-to pages.
Our new design tested overwhelmingly positively. We found users were able to complete our tasks more easily than we had witnessed with the tab design. Virtually every user was able to use accordions with no problem at all.
That said, we also learned that any information that users needed to decide which accordion to click on needed to be placed outside the accordions, as otherwise it might not be found.
You can scroll through the PDF below to see an annotated walkthrough of our final re-design proposal and an explanation of the changes we made to the existing site through testing.
Overall the response to our work was very positive. We were invited to present our work at City Hall and to write a blog and medium post for the Digital team. Through ‘getting out of the building’ we managed to identify a real user need and were focussed enough in our scope to conduct rigorous user testing which got us to a great result.
We were fortunate enough to be asked by the City to continue working with them on a volunteering basis.
Our proposal was ultimately implemented on the City of Boston website across all their how-to pages, and the design is still live on the site today!
I consider myself very fortunate to have worked on this project with my teammates. The Digital team at the City of Boston are leaders in their space and were very generous in the support and level of freedom they gave us to target the areas where we felt we could make a difference. I’m also personally really interested the possibilities for creating a fairer society through simplifying and improving access to government processes and services, having long followed the work of the United States Digital Service and their equivalent in the UK - the Government Digital Service.
1) Prioritisation - we decided to just focus on one problem over the 3 weeks - the how-to pages - and this paid dividends as we were able to test with a large number and variety of users (56 people of a variety of ages), which was important given the enormously diverse user-base of the site.
2) Defining our problem statement and target user - in the early stages we debated whether our user base was too broad and our data too limited to define a problem statement and target user before entering the ideation phase. Focusing on identifying a certain behaviour (scanning, in this case) was a helpful means of giving direction to our idea-generation and the design/testing, without artificially confining ourselves to a particular demographic.
1) Be more comfortable with ambiguity during the ideation phase. I wanted our problem statement and user to be clearly defined before going into the ideation phase of this project. While I feel like this helped give us direction at key points, I was reminded that it’s OK and normal for the generative thinking early in a project to look like this squiggly mess, particularly when the user-base is a broad as it was in this project!
2) Use a ‘notes grid’ for our research and usability testing. I made a lot of handwritten notes during my guerilla interviews and tests with users that were hard to decipher afterwards. They also lacked a consistent structure due to my concentration being on the user and the environment around me. Taking notes in a notes grid would give me that framework to ensure that my data is consistent and easy to synthesise