For this project I was prompted to add a new feature to an existing product. For this example, I chose to add a feature to a small city’s (Keene, New Hampshire) government website.
Overview:
Sole designer, focused on information architecture and the end to end design of the added feature.
Responsibilities:
Timeline:
80 hours
Project type:
Designlab case study.
In creating a new feature for this city’s website, I worked under two specific constraints provided to me by the project prompt:
“Redesigning is out of the question.” I had to ensure that I was designing within the system that was already created for this city.
“We would like to focus on the information architecture of the site. There’s a lot that residents can do here, and everything seems equally important, so it’s imperative that we help residents find the information they need, when they need it.”
Constraints:
The problem: Users are faced with a lot of information when using Keene’s website, which contributes to increased cognitive load when trying to complete a task.
Before moving forward with any user-based research, I first wanted to gain an understanding of how Keene’s website was currently organized, and performed a heuristic analysis, and noticed one major issue.
There is a lot of information offered when citizens visit the “residents” tab on the main navigation bar. Hick’s law states that the more choices a person is presented with, the longer the person will take to reach a decision. With keeping this law in mind, I wanted to create a way to increase the efficiency of this website, decrease the time it takes for users to find what they are looking for, and decrease the information overload users are experiencing when visiting the site.
The solution: creating a “service finder” tool to streamline the process of finding and utilizing the website’s online services.
The chosen research methods for this project were the following: surveys, in order to gain a significant amount of qualitative and quantitative data, and card sorting, to gain an understanding of how users would sort the tool that I was brainstorming.
Research Methods:
The majority of my survey participants were between ages (83.3%) were between ages 26 and 35.
Participants reported using their local government’s websites for a variety of reasons, ranging from paying bills to using online DMV services.
When asked to rate how easy their local government’s website is to use, most participants (66.6%) rated their local governments a 3 out 5 (1 being very difficult, and 5 being very easy).
100% of users reported preferring using their government’s online services rather than going in person.
Key Insights:
“I put it in the middle because for things like paying bills or fines, it’s pretty cut and dry. When looking for laws and regulations, however... it can be a nightmare”
“Finding what I need was easy enough, it was the general design of the website that made it somewhat difficult to know what was a link and what was information.”
From the survey data, I created personas that capture two types of users that utilize government websites and their paint points.
Personas:
Chris represents users who utilize government websites to access information rather than just services. This might be residents or others with a variety of interests such as moving to the town.
Jill represents a resident who wants a quick and easy way to access online government services.
From my card sort, I was able to discover how users may go about using this service finder, and which services they would expect to see available online. With this information I went forward with creating a sitemap and some task flows.
Sitemap & Task Flows:
Once I had the information architecture sorted out, I went ahead and began my wireframing. I also studied and took note of some of the UI elements and general aesthetic of the website, to ensure my high fidelity wireframes integrated well with the existing site.
Wireframes:
I created my prototype using the Figma Prototype tool. I conducted unmoderated remote usability tests using Maze (a remote usability testing tool).
A total of 6 participants for my usability test were asked to complete three specific task flows. The key metrics used were time on task, number of errors, and completion of task.
Below is a gif of one of the tasks users were asked to complete: use the service finder to find any outstanding tickets you may have.
Usability Testing:
100% of participants were able to finish their tasks.
5 out of 6 of my total participants clicked the “pay” option rather than the “find info” option for task #3 (finding outstanding tickets).
The average duration of each task was about 35 seconds.
2 participants recommended another service within this tool to schedule appointments with local offices.
Key Insights:
Based on the results of my usability tests, I iterated on my design accordingly to ensure a frictionless user experience. I also took some time to add another task flow based on the recommendation of a research participant, booking an appointment, to expand on my added feature.
Priority Revisions:
This project was a truly valuable exercise in practicing information architecture, as well as designing within a system or brand that is already well established. I truly enjoyed the challenge that both of these constraints had to offer, and it expanded my knowledge and skill as a designer. If I had the opportunity, I would like to test the usability of my added task flow, as well as add more appointment booking forms for other offices.
Next Steps & Conclusion: