Flint Water Crisis
API UX Design / Digital Prototyping and Content Design
|
Project Overview
Flint Water Crisis: The water crisis in Flint all began in 2014 when the city switched its water supply from Lake Huron and the Detroit River to the (cheaper) Flint River. By February of 2015, tests confirmed that concerningly high levels of lead were found in the water. Problem Area: There’s a lot of pipes in Flint, and the city doesn’t know the location of all of them. It’s a long and expensive process. Based on our research, we have determined that this location process is often one of the most difficult parts of the total pipe replacement process, so we wanted to help with this step so that we could help Flint implement a long-term solution. Challenge statement: How can we make replacing and locating pipelines easier for the pipe replacement construction team. Solution ideas:
Team: A team of three. Program Developer, UX researcher, and UX designer. My role: Sketching, wireframing, information architecture, interface design, data visualization, visual design, prototyping, testing, iteration Technologies used: Sketch, Adobe Illustrator CC, Figma As a group, we came up with two challenge statements.
This process is broken down in detail below, or you could scroll down to the deliverables to view the final products.
|
My Process
To being our process we came up with a short term goal and a long term goal for this particular project giving the fact that we had only 4 months. Our first approach was to tackle the short term goal by creating an app that would be beneficial to both residents in Flint and construction workers. This isn’t necessarily a long-term solution in terms of the water crisis, but it’s an issue that needs to be addressed as a more permanent solution (replacing the pipes) is being worked on. Thus we came up with a second solution that was more of a long term solution of creating a wearable device that: Enables construction workers in Flint to detect pipes underground and have the capability to distinguish lead pipes from non-lead pipes.
Getting familiar with the project
In terms of the construction aspect, a newsfeed with general construction updates seemed like a simple and familiar way to get updates to the Flint population. However, I also felt that including a more specific, long-term plan of action would help appease frustrated citizens. Thus, I decided to include a timeline to show the current plan for pipe replacement across the entire city. I also wanted to give residents a voice, so there is a report form that users can fill out if they live in or by an area that was supposed to have already been completed (according to the timeline) but hasn’t yet been worked on. This holds the city accountable and gives residents a way to bring incomplete areas to their attention.
Function 1: Gives construction updates Function 2: Provides construction timeline
Function 3: Allows residents to report incomplete areas Function 4: Helps residents find clean water
The map feature is also likely a familiar format for most users; it includes icons so users can see where in the city bottled and filtered water is available. By clicking on the icons on the map, users can get additional details (contact info, address, etc.) and they can see user reviews of the water location. This way, if there is some kind of problem with a water filter or bottled water stand, residents will be able to let others know.
While wireframing, I tried to keep a few user goals in mind. These goals were to get updates about construction, to view a long-term construction plan, to be able to report uncompleted areas if they conflicted with the timeline, and to find clean water in the meantime. The four wireframes above are the more intuitive ways I could think of to achieve these goals. My additional wireframes simply display a few additional screens: the login page and extended information on a certain water location.
Defining our goals
Once I showed my wireframes to my team, they had a few suggestions for my app. First, they thought that the newsfeed and timeline were two distinct features, but they had enough similarities that it didn’t make sense to have both as a “core page” of the app. In other words, they suggested having a button for the timeline on the newsfeed screen instead of having a timeline button on the nav menu itself. Additionally, they liked the report feature but felt that some people might not even know if their pipes need to be replaced. They suggested adding a function that would allow people to request to have their water tested. For the most part, though, my team thought the wireframes were looking good, and they liked the incorporation of construction updates.
Organizing the information
To accomplish the goal of being able to see construction updates/progress, I thought a newsfeed would be an intuitive and familiar way to get information across. I wanted to include a way for people to communicate to city officials that they wanted their house pipes to be replaced, but I knew that making that an open option would likely just result in the city getting bombarded with requests. Thus, the timeline feature is a way to limit people asking for pipe replacement to those whose houses should have already been done. Similarly, the water map seemed like the most familiar way to allow users to see where they can go to obtain clean water; it is reminiscent of many GPS or map apps that are popular today.
Diagram of app usability and functionality
After the changes were made on my lo-fi wireframe, I began to start with the UI framework of our app using Figma. The next steps were to take from my lo-fi wireframe and update it to a hi-fi wireframe and then get users to test the usability and functionality. As I explored the existing interface, I used Jakob Nielson's usability heuristics for interface design to identify usability issues I would want to pay attention to in a fresh design. This helped me shape my thoughts into goals for the new design.
Interface design before user testing and feedback
For the most part, the users were able to complete each task very quickly and without confusion. This makes me confident that designing with the user goals in mind allowed me to create fairly intuitive navigation. However, there were a few notes from each user that I found helpful. They were:
- It’s not 100% clear that the icons are clickable
- The bottom nav menu looks a little odd with only two items
- There aren’t a ton of ways to get involved
- The “stacked button” look of the request and report buttons makes it confusing that they are two separate things
- Instead of “see reviews,” rename the button “reviews” because users cannot only see reviews but write them
User testing was, of course, extremely valuable throughout the process, as it gave me the feedback that I needed to make my app as good as can be at meeting the user goals. I am glad I got the chance to implement my user test takeaways.
Interface design after user testing and feedback
During my user testing, everyone suggested getting rid of the search icon on the form, login, and contact page since it served no purpose. The work form page had no option to put in your via phone number so that was added in the final version. A big change that I made on that page was renaming it from “work form” to “job request” and adding a small description of what the page is about. A lot of people thought that this page was to fill out a job application. Some users wanted to see the login be at the top of the menu and replace the home icon but doing so would mean that there would be no way back to the home page. I ended up adding an information feature for each stand and drinking fountain but this time I added an image placeholder for a picture of what building it’s in or the surroundings. Most people don’t have time to read over multiple reviews, so I added a star rating system with a link to view more reviews if the user wants to read them.
Deliverable
My primary deliverable was the final design and video of interacting with the UI of the app.
