Grid mobile iOS.
Team: 4 Members   Duration: 10 weeks   Tools: Figma, Miro   Project Type: Mobile App
My Role: I oversaw early development and brainstorming. Also collaborated with my team as one of the Lead UX Designers and Researchers throughout the project cycle from design strategy, to wire-framing and content development.
OVERVIEW
In my Design Methods class, our team was tasked with choosing a United Nations’ Sustainable Development Goal and crafting a project, from scratch, that targeted a particular objective. Choosing Goal 11, Sustainable Cities and Communities, we developed Grid over the course of the academic quarter.
Grid, a smartphone application and social platform, serves to help students with mobility disabilities navigate the University of Washington Seattle (UW) campus. Using high-quality practices, Grid maps routes for students, including up-to-date traffic, construction, and various other obstacles with information provided in real-time by community members. Developing upon currently available resources, our app reimagines accessibility technology by centering efficient design and community in order to make accessibility discourse a continuing and purposeful discussion around the Seattle campus.
"...Grid maps routes for students, including up-to-date traffic, construction, and various other obstacles with information provided in real-time by community members."
THE CHALLENGE
Amongst the University of Washington's (UW) Disability Resources for Students (DRS), our team identified an enormous gap between digitization and information accessibility–an issue of sizable importance given the 2,400+ students the DRS serves. Put simply, information, while available on the website, struggled from three main issues:​​​​​​​
1) Information was outdated and undetailed
2) Difficult to navigate quickly on a commute
3) Incompatible with the cellular devices students used
"...our team identified an enormous gap between digitization and information accessibility..."
Delving into this issue in relation to larger structural failures, we spoke to community members in the disability community to better understand the bridge between design and legislation. Specifically, they highlighted the disregard many designers often have for high-quality practice in favor of meeting Americans with Disabilities Act (ADA) compliance—compliance that has historically been vague and reductive. This is often why campuses like UW are falsely accessible.
Having said this, Grid was created with a consideration of how digital accessibility can be furthered. Looking at audio and visual descriptions, Bluetooth connectivity, crowd-sourced information, intrinsically-driven reward systems, and a myriad of pictures and videos, our app envisions accessible design with empathy at the forefront.​​​​​​​
EXPLORATORY RESEARCH
Exploratory research was conducted with the intent to identify particular pitfalls we wanted to avoid in developing Grid. First with smartphone accessibility applications, and next with UW-affiliated user interviews to make our solution campus-specific. This was done in order to hone in on the scope of our project by understanding what was lacking in the larger market before addressing the needs of our specific communities.
Analyzing existing solutions, I led investigative research on mobile applications, particularly focusing on the reactions and interactions users had with these solutions and their intended purposes. Comparing existing Solution A and Solution B, two interactive mobile map applications that allowed wheelchair users to see what spaces were easily navigable via information provided by users, I identified their most attractive features:
Solution A: wheelchair users can actively add wheelchair-friendly locations of toilets and parking spaces.
Solution B: users can traverse a large array of data synthesized into ten different categories (​​Bathroom, Elevator, Parking, Shop, Other, Station, Lodging, Ramp, Barrier and Favorite).
Where both of these apps fell short, however, was in their lack of instructions and abundance of incorrect information provided by users. Moreover, because usage and interactivity were understood through the lens of ableist design practicesrequiring mobility-impaired users to stop, use the app, and then go about their daythese solutions were insufficient. Thus, while the features they presented were desirable, the way crowd-sourced information and the interface was integrated into the app struggled from misinformation and a lack of knowledge about understanding accessibility. 
Moving forward, this shaped the 3+ user interviews I conducted with those in the disability community. Interviews ranged from students to disability studies professors, to family members of people with disabilities.  Time and time again participants highlighted the lack of care in accessibility design in UW-specific ways. One particular student stated that a working knowledge of accessibility around an area like UW is often changing and institutions are not willing to direct efforts towards it, thus it can be difficult to create solutions
"One particular student stated that a working knowledge of accessibility around an area like UW is often changing and institutions are not willing to direct efforts towards it, thus it can be difficult to create solutions."
Corroborating this with the other interviews, I was able to synthesize the team's notes into Observations, Problems, Opportunities, and Needs.

Interview notes were synthesized into four categories to better understand our intentions with Grid. All names and identifying information has been changed to protect the privacy of those interviewed.

Looking at some of the pitfalls identified in this process, these were our main takeaways and goals:
1) Our team will create a solution that provides comprehensive information for people, specifically UW students, with mobility disabilities.
2) We will address the lack of awareness about accessible navigation around UW, which actively marginalizes people with disabilities.
3) Our solution is an application that will allow UW students with disabilities to easily and quickly navigate to their desired destination by accounting for a wide range of accessibility barriers inside and outside buildings. Additionally, users will be able to to upload information to the community and navigate the app using voice and touch interactions.
4) We hope that our solution will provide open access to information about accessible pathways.
USER PERSONAS
I aided in crafting personas to better understand how our users would interact with Grid. These personas were created through a combination of the individuals we interviewed and who we intended to reach with this project.

Natasha's user persona.

Our description for Natasha is based on our interview with a user who is mobility-impaired and struggles to find wheelchair-accessible entrances outside and inside of buildings. We decided to create our main user persona around a mobility-disabled student because they are the main user of our application that aims to provide accessible directions and information.

Sam's user persona.

We created our second persona around an able-bodied student because the application can also be used to find classrooms and navigate in-building and out-building areas that might be confusing or inaccessible if they are new to campus, biking to class, etc. This also recognizes that some students will want to contribute to the app regardless of if they are disabled, to help the community.
LOW-FIDELITY PROTOTYPE
Using what we gathered from our exploratory research and persona creation, I created low-fidelity prototypes to use in our usability testing phase. Specifically, I aided in developing the overall information architecture of the app, the Contributions page, and the Profile page.

Low-fidelity prototype development

Generating the low-fidelity prototype, we took the concerns voiced by our focused community and input them into a simple interface that reflected the main interactions of the app. Each button on the bottom dashboard of our app was given a row, in which pages were developed to communicate the general architecture of Grid as a map and social app.
USABILITY TESTING
We completed three usability tests to gain feedback on the low-fidelity prototype of our app, Grid. We decided to keep our prototype low-fidelity for usability testing to gain more constructive and in-depth feedback before moving into high-fidelity. In each test, we asked the users to complete seven tasks so we could observe how they interact with Grid and our design’s overall intuitiveness. This was our general testing procedure:
1) For each task, we carefully observed their reactions and emotions.
2) After the task was completed, we asked the users to rate the difficulty of the task on a scale of 1-5 (with 1 being very easy and 5 being very difficult).
3) Before moving on to the next tasks we asked if they had any additional questions/comments/feedback to make sure we fully understood their experience and what they wanted from a high-fidelity prototype.
By following this approach for each of our three users, we were able to better understand how others would interact with our app, as well as gain suggestions for improvement. Using a metric of sorts, while subjective and individualistic, also helped us gain insight into the ease at which different user groups could understand the app. Here were our main takeaways from testing:​​​​​​​
"Using a metric of sorts, while subjective and individualistic, also helped us gain insight into the ease at which different user groups could understand the app."
Usability Test #1
Our app lacks discoverability thus more standard icons, labels, and buttons are needed to streamline the user experience. 
Usability Test #2
Certain design and grammatical choices convey a lack of professionalism and take away from the branding of Grid. 
Usability Test #3
Information architecture is very unclear and feedback is inadequate. Content seems scattered around the app instead of interconnected and circular. 
HIGH-FIDELITY PROTOTYPE
Going into the final stages of development, our exploratory research and insights from usability testing shaped what these mock-ups looked like. Once again, I developed the overall information architecture of the app, the Contributions page, and the Profile page while also helping on smaller secondary tasks.
Design typography and color schemes.
The color scheme of our application consists of a dark purple background with pops of white, beige, and lighter purple shades. For our font choice, we chose Work Sans for the main font and following hierarchy of information. 
We decided to be minimal and intentional with our design choices to ensure they would not take away from the accessibility of our app. Moreover, these colors and fonts can be changed in the Settings page to better ensure our user is prioritized.
INTRODUCTORY PAGES
Introductory pages the user first sees when opening Grid.
When a user first opens Grid, they are prompted to log in with their UW Net ID, create a new account, or continue as a guest. Initially, we planned to keep the application exclusive to UW students however, after our exploratory research and usability tests we recognized that the app is likely more useful for users who are not affiliated with UW (as this would mean they are new to the campus and not familiar with accessibility features and/or they are an incoming student).
Once navigating past the initial page, users are given a welcome to the app and a tutorial of how to use various features. These tutorials are accessible on the Profile page within the app to ensure users always have access to app literacy and interactions.
MAP TAB
Map screen where users can filter for an accessible path or building feature.
In our Map tab, we kept buttons to a minimum to limit the number of taps. Here, users can search for their destination in the search bar and select a route there. 
Users can filter their route for obstacles that might block their pathway or influence their building travel. These filters were brainstormed by users during usability testing as obstacles they often had to be aware of on a college campus. To show these blocked paths, we used a higher contrast map and easily understandable icons to inform of areas that users shouldn’t go through–this was a development from our low-fidelity prototype where users couldn't understand how to add filters or location details.
From this tab, users can also click on certain buildings to navigate there and get more information about accessibility details. They can also directly tap on the Disability Resources for Students (DRS) icon to easily contact the organization. 
SAVED TAB

Saved Tab and the Kane Hall saved page.

The Saved tab serves as a place where users can switch between buildings, paths, rooms, and contributions that they visit often. 
A path or location can be saved by the user while using the map feature, which will then be added to the Saved tab. Users can click on each listing in the tab to get directions or view detailed information regarding the address, accessibility details, uploaded media and Contributions, and average traffic. This page was created to limit active time spent on the app, especially during a commute. In doing this, users can quickly find the location they want to navigate to. 
CONTRIBUTE TAB

(left to right) Initial Contributions page and Kane Hall Contributions page.

Our Contribute tab creates a space for community members to provide accurate, up-to-date crowdsourced information.
Here, users can look for Contributions that provide pictures and insights about buildings, rooms, and paths around UW–as written by other users. These Contributions ultimately ensure that our data is student/faculty-made and constantly updated so users can gain valuable insight from others.
Upon arriving on the page, users first view top Contributions–split into buildings, rooms, and paths ranked through their accessibility rating; the averaged accessibility rating is calculated through the five-star rating that Contributors must fill out about the subject of their Contribution
Top Contributors are users that regularly write a myriad of Contributions about campus while garnering a high amount of upvotes–they are profiles that users can rely on for accurate and thoughtful information.
Clicking on a building, users are provided information about the building rating, related classrooms, and user contributions which can be filtered. Moreover, users can upvote a rating, save it to their Saved tab, flag the review, or expand the review and view additional information provided by the contributor about features such as elevators, bathrooms, Panopto classrooms, accessible seating, automatic doors, and additional features–as shown through symbols on the bottom left of the contribution.​​​​​​​

(left to right) User flow for writing a Contribution for Kane Hall.

Clicking the Contribute button to create one on the page or within a building page, such as Kane Hall, users will be prompted to rate how accessible their building/room/path is. Next, they’ll have the opportunities to add photos, leave comments, or rate the aforementioned features. Upon choosing to rate a feature, users will once again rate the feature, add photos if possible, and write comments about what makes the feature accessible or inaccessible. By clicking Submit users will then receive feedback that their contribution has been received.  
Centering our app around these Contributions, our hope is that crowd-sourced information will enable larger discourse about accessibility around UW. With some accessibility ratings ultimately being low, perhaps it will encourage UW to continue to make their campus navigable and accessible to all. To add on, we believe the form to create Contributions will allow all users to create concise yet thoughtful reviews, something competitor apps lacked because of a lack of format. Overall, these Contributions will aid in creating a community around accessibility; one that exemplifies the fluidity and nuance needed to enter the conversation. 

Swim lane diagram for the first Contribution a user creates.

PROFILE TAB

Profile screen.

From the Profile tab, users can contact the DRS, rewatch tutorials, change their settings to their specific needs and preferences, see their stickers, and view their Contributions.  
PROMOTION OF USER INTERACTION

Viewing a Contributor's page

Because our app relies on crowdsourced information, we encourage users to leave reviews and photos by giving stickers for completing goals, such as creating their first contribution and submitting five contributions. Users can collect stickers which can be accessed in the profile tab under Stickers
We decided to design an intrinsically driven system where users progress towards goals and achievements because there is much research showing that this motivation is more likely to sustain user engagement and foster a sense of purpose; this also helps lessen the likelihood of misinformation posts.
VOICE MODE
Voice Mode screen where users can interact with the application by voice and navigate around the platform hands-free.
The entire app can be interacted with using the voice user interface. After tapping on the blue icon to activate the voice interface, users can speak commands such as searching for a location and hear responses. Users can tap the blue icon again to turn off the function and interact with the app using the touch interface. This hands-free interaction allows the user to continue using the app even if both of their hands are occupied.
LIMITATIONS
Grid is currently limited to the scope of the University of Washington Seattle campus as its target audience. This is because we discovered that a significant portion of the undergraduate student body–more than 2400 students–find it difficult to locate information about accessibility resources. Moreover, in creating Grid, we hoped to foster a more tight-knit community as users share more common points of interest and can more easily connect. Having said this, we recognize that our particular scope is limiting as it does not help students who travel off-campus into the larger Seattle area. 
Furthermore, while our app improves the visibility of information about blocked paths, many obstacles will likely remain unknown to users until it is too late and the user has to turn back to find another route. An example of such obstacles includes Lime Bikes that are often left in the few accessible routes available. Raising awareness about the consequences of such actions to both users and the general public would help minimize such obstacles. While our app intends to make information quicker to find, accessibility is a nuanced and changing experience all the time. Consequently, our app cannot reflect that to its full capacity but we can aim to make progress in accessibility design on the UW campus. ​​​​​​​
"While our app intends to make information quicker to find, accessibility is a nuanced and changing experience all the time. Consequently, our app cannot reflect that to its full capacity but we can aim to make progress in accessibility design on the UW campus." 
Lastly, our app mainly focuses on providing accessibility information for people with mobility disabilities. While we designed features such as voice mode that also accommodates people with other disabilities such as visual, we would like to extend our app beyond those who have mobility disabilities. 
REFLECTION
Working on Grid I learned many lessons: 
Collaboration is important. I wouldn't have been able to iterate so many times on a design without my peers telling me it could be better. Having a strong team with good communication skills was crucial to a successful design. 
Always design within context. Never design in isolation without understanding the larger context of what you are doing. Many times during the process my team and I got lost in ideating and forgot to recenter my goals towards our intended scope. It can be easy to get carried away when designing so always be intentional. 
Deadlines and accountability. If we design proactively, in a group where everyone is supported, the work being done will always be of higher quality. When we check in with our team and hold everyone accountable, while being aware of their needs, we can care for our team and consequently care for our users.
Moving forward, this project has ultimately taught me how designing and UI/UX can be elevated through teamwork and dedication. As someone who is in the very early stages of my career, it felt extremely rewarding to put a lot of effort into a project and see the fruits of our labor. Undergoing the design process was strenuous however the end product was something I was extremely proud of.
If I could do something different about this project, I would change the circumstances it was developed under. Collaborating during a pandemic, it was difficult to communicate to the degree necessary to succeed, however, I felt confident in my group's dynamic and ability. That being said, I'm curious to undergo this design thinking process in person where we can communicate more powerfully. Overall, however, I am truly proud of the work that went into Grid and strongly believe it is a testament to the creativity and strength of the design thinking process.

Back to Top