The Aquapod is a web application that aims to assist the severe clean water and sanitation scarcity by providing local resources for both those in need of clean water, and for those who can help to make a difference.
Client
King County
Project Type
Front-End Development
Team
5 students
Timeline
Sept - Dec 2023 (3 months)
About
Problem
Water resources, specifically sanitized and clean drinking water, are not easily accessible to the majority of people. As the UN explains, “2.2 billion people still lacked safely managed drinking water services, 3.5 billion lacked safely managed sanitation services, and 2.0 billion lacked basic hygiene services in 2022” (Water and Sanitation - UN Sustainable Development). Although access to water is a basic necessity, the resources and supplies may not be publicly known, which can be a major barrier for those in need of them and thus negatively impacting our ecosystems and sustainable development. Likewise, there are many capable people who are willing to help donate these supplies or uncover services. However, information on where they can provide support may be limited or scattered, furthering the outward affect of the problem within our communities.
Reference: “Water and Sanitation - United Nations Sustainable Development.” United Nations, United Nations, www.un.org/sustainabledevelopment/water-and-sanitation/
Solution
To start with the focus of the problem, we start with the MVP: How might we educate the people of King County on water facilities to ensure they can locate necessary sanitation resources and opportunities to donate? Because many may not have daily access to clean water and sanitation, or many may want to give support to their community, our team's objective is to adopt a solution to promote the location of water, sanitization, and hygiene resources throughout King County in Washington.
Onboard
Resources
Donate
Learn
The Onboarding Process
Users are presented firsthand with an overview of the water and sanitation issue at hand, alongside a youtube video that properly explains the problem in depth.
Below, users can scroll down to see what kinds of features our application provides, and how users can navigate to each of them. Finally, users may click on our action button to start their story on our website, where we provide them three scenarios they may take: whether they are looking for resources, looking for donations, or looking to learn more about the cause.
Research
Understanding the Problem
Before we could decide on what kinds of functionalities we wanted to implement within our application in order for it hold as a solution, it was important for us to first understand what kinds of causes of the problem to tackle.
To grasp a better understanding of what purpose our solution will hold and how we can approach it, we address the following:
Cause 1
A huge factor to this problem is that water availability continues to be uncertain in areas that are scarce of water accessibility in the first place, thus negatively impacting sustainable development and ecosystems.
Response: We hope to promote daily access to water, sanitization, and hygiene resources throughout King County as a starting point.
Cause 2
There is not much awareness being generated towards communities who may want to help, or methods being publicized to those who want to participate in providing sanitation and clean water.
Response: We hope to create a platform to emphasize where people can find ways to help donate supplies or be proactive about accessible water services.
Stakeholders & Personas
We as a team recognized that with this issue at hand, there are multiple audiences that we were calling towards. We determined that in order to ensure that our solution was specific enough, we had to focus on the audiences who will have their life altered when using our web application. Our goal was to move beyond the one-audience assumption and pull different groups apart to understand them and see the common and not-so-common ground.
We scoped down on three stakeholders who would be most interested in the problem: someone looking to donate, someone looking for resources, and someone looking to learn.
We solely used these two stakeholders as they directly correlated to the type of users we were targeting for our application. Given the nature of cruise ships, we believed that the main types of groups were singles and families, which are those who would most likely be intrigued to use the app for their own personal use.
Design Decisions
It was important for the team to determine what decisions behind the front-facing design was in scope for us, and what was out of scope. The most significant design decision we made was that we decided to not use a visualized map, but rather make our interface more of a “catalog” of places based on the user’s personalized search. We narrowed down on three reasons why:
The importance of a user journey. We believe that giving our audience a catalog of places, it gives a better visualization of choices that the user can pick. From there, based on what the user clicks on, it is clear how they accessed the next page they are redirected to.
The function maintainability. With an interactive map, we determined that it would not be as successful of a solution unless it had full functionality such as showing the user’s current location, directions to map locations, clickable markers, etc. We believed by allowing users to search by zip code, it will allow them to get a list of some general locations within that zip code that they may locate to see if it is a feasible place nearby.
The technical accessibility obstacle. From a technical standpoint, we recognized that an interactive map will most likely require the use of a mapping library, which we found ourselves unfamiliar with. With our skill sets, a catalog would better display the information on these places and make it clearer for the user to find details that help them make informed decisions, without the hassle for ourselves to find a mapping library and adapt to it in a short timeframe.
These decisions allowed us to make the user journey smoother and serve our goal of providing easy and direct access to water resources. Given these circumstances, we decided that it would be best for not only us but the user to design our interface in such a way that makes it more user-friendly.
Ideation
Functional Requirements
In order for us to proceed with the design, we had to identify what features would be most important for our solution that properly depicts our solution responses. To categorize this, we separated features into three categories: Priority 0 (must have), Priority 1 (should have), and Priority 2 (nice to have). This allows us to detail which capabilities our solution must provide in order of what is most important for the problem.
P0
List of places with clean water access
Donation resources
Information on places (hours of operation, qualifiers, address)
Homepage direction (user direction to provider vs resource seeker screens)
P1
Services available at each place (ex. Sinks, showers, water refill stations, etc.)
Filter by donation type (volunteer, donate money, donate resources)
Filter by service type or facility type
Geo-location + filter by distance (Ex. 10 miles away or less)
P2
Places that provide free sanitation/hygiene products
Favorited places/saved places
Education page (stats within King County, link to other outside sources)
Initial Whiteboard & User Flow
For us, it was important to first see what kind of journey the user would experience, as well as factor in and out functions that may or may not be necessary.
To summarize, because we had three basic audiences who would want to explore a different journey from one another, we saw giving the user an option of which journey to explore first allows them to create a simple decision, and then provide them the story they were after. Of course, we wanted the user to have the freedom to explore any journey they would like to, no matter what persona they may fit into. Hence, all journeys are accessible through our navigation bar once the user makes their initial choice, allowing flexibility of where to explore in our website. Those where the main aspects of our function design draft.
The Second Iteration
After the initial mockup, one feedback we received was to think about including a tutorial or a preview that informs the user that they may switch journeys after their decision on the landing page, and making it more clear to the user about where they are currently located within our webpage to make their journey more understandable.
Here, we focused on establishing the functionalities we prioritized before and flushing out how the user would navigate through the functions, where they would end up, and how we could make it flexible for them to find their way back.
Usability Testing
We gained major feedback through 3 rounds of usability testing among students and faculty:
What they liked
The addition of Learn allows users to understand the issue better
Easy searching and filtering to lessen possibly overwhelming the user with selections
Filters are clear about what kinds of resources/donations are available
What could be improved
Onboarding could provide context about the issue before the user starts their journey
External link buttons should indicate that the user is about to navigate to another tab
Cards should give background to give users a better idea about the card itself
Better contrast between the text and the background
Bringing us to our final viable product application.
Takeaways
This project was a huge stepping stone into understanding how intentions can vary differently depending on the user. That being said, it meant gaining better recognition on how a user's personalized choices can affect the outcome of what they gain from their experience, and it is up to us to be able to properly provide the results they are looking for with clear indication of how the user got to where they are on our application. As a team, some takeaways we came upon included:
An experience tells a story • When a user is exploring a page for the first time, it is important to provide them context beforehand so they are aware of what they are about to use. If we were to assume they already knew what we have been researching for the past month, we are putting users in the middle of a story arc with no background of the story itself, which will lead to disorientation and feeling uninvolved on their end.
One click goes a long way • Alongside sensing how we wanted the user experience to be, we learned that a single click can change the user's perspective of our application, based on where we end up directing them on the page. To make the relationship between the user and the application feel effortless, it was important for us to prioritize easy navigation and accessible information.
Utilize what you can • There were many instances where my team realized some features were out of scope for us. However, that did not mean that we should take this as an impossible challenge. Instead, we wanted to utilize the features in a way that adapts to our solution. An example of this was although we could not make use of a functional map feature, we found we could display Google Maps as an external link that the user may use on their own to guide themselves as needed.