An administrative app used to manage a volunteer and student database, collect interaction results, analyze data, and manage contact requests from volunteers serving high mobility youth at Community Education Partnerships (CEP), a San-Francisco based nonprofit.
Project Duration and Status
September 2021 - October 2021.
Currently in active development.
Role and Responsibilities
Lead UX Designer.
End-to-end design cycle, including user research, competitive analysis, interviews, persona development, journey maps, user flows, wireframing, prototyping, and high-fidelity visual design.
Admins are busy staff members who need an easy way to manage their volunteer and student database, survey volunteers after student tutoring sessions, collect and analyze survey data and volunteer time logged, and run reports, because this will enable efficiency savings and support grant funding applications.
Our admin app will let users manage their database, collect, analyze, and visualize data, and resolve support requests which will affect their ability to support volunteers and students, by creating business efficiencies and cost savings.
We will measure effectiveness by frequency of tickets resolved, successful database updates, and user adoption.
User interviews were the primary form of user research for this project.
Given that the users of the product would be CEP staff, I determined that meeting with them would afford me a much better understanding of their pain points, challenges, and needs. I was also able to determine which features were critical for MVP and which ones could wait for futures releases.
Participants are all CEP staff who manage volunteers and students with a lived experience of homelessness to improve their educational outcomes.
4 staff members interviewed, between the age of 30-45.
6+ hours of interviews.
4 hours of follow-up conversations.
Tracking Volunteer Time
Having the ability to track and analyze volunteer time spent on tutoring sessions is a critical business need. Volunteers do not consistently and accurately log time spent on tutoring sessions, since their current system is complicated and tedious to use.
Resolving Support Requests
If volunteers need support, they have to either email or call and wait to hear back, rather than being able to request support quickly and efficiently. These request can vary from casual to emergent requests, and can often languish in staff email inboxes instead of being resolved.
Their current system does not provide any way to gather feedback about student progress, needs, or individual sessions. This means that the organization is operating in a vacuum, without data to inform their programming needs and funding requests, affecting their sustainability.
Building an admin journey map revealed the complexity of the application and the many requirements and relationships that would inform the architecture of the app.
Mapping out a user flow enabled me to chronicle the path that a user would take through the app to manage the volunteer, student, and admin databases; collect, visualize, and analyze data such as youth interaction results, track and resolve support requests, edit organizational and individual profiles, and manage security such as password resets and changes.
Given the size and complexity of the user flow, I have split the user flow into two parts, showing the database section; and the survey, dashboard, and profile sections, separately, along with corresponding wireframes and high fidelity mockups.
I began the ideation phase by sketching a few key views, and then quickly moved on to digital wireframes, to leverage the components functionality in Figma, enabling me to create wireframes more efficiently, since there were several screens that needed to be designed.
Wireframes & Mockups
I created over 25 wireframes, and eventually designed over 35 high-fidelity mockups. Below are a small selection of wireframes, created in Figma, and corresponding high fidelity mockups by feature.
Using Figma’s ability to convert the wireframes into a clickable prototype enabled CEP staff to experience the app flow, and make the functionality more clear and tangible.
I used moderated usability testing to observe the user's interactions with the product, and I conducted 3 rounds of tests, with rapid iterations for further testing. Their feedback informed the changes I made to the wireframes before moving on to the visual design phase.
Issue 1: Assigning Relationships on Records
I did 3 rounds of user testing and iterated on the original designs each time. The volunteers, students, and admins share complex relationships that needed to be accounted for in the database. This was a critical piece of functionality that I worked on in conjunction with our senior engineer.
Issue 2: Displaying Relationships on Index Pages
The importance of the relationships between volunteers, students, and admins, came to the fore in the table designs for all of the index pages. The high-fidelity designs below reflect these vital changes.
Issue 3: Ticket Management Functionality
Collecting support requests are a part of the mobile survey and were included in initial wireframes. However, as we continued through 3 phases of testing, it became apparent that ticket management functionality (viewing and resolving), would be necessary for both support requests and contact info updates as well.
It is easy to think of any particular issue as unique to a specific cross functional discipline. Recognizing the perspective and capabilities that engineering and product bring to the table result in better, and more thought out, products.
On a dashboard there is an infinite number of types of data, and data combinations, that can be displayed to the user. We took a pragmatic approach and settled on what would give the stakeholders the most value, as well as, which would be easiest to achieve. This outcome was only possibly by getting the inputs of each part of the team.
The Path Forward
The dashboard statistics and reports generated from them are a critical piece of the nonprofit's recipe for success. They use these reports to gain new and maintain the grants that pay for their vital work. Our cross functional team will continue to work together to identify metrics to enable our stakeholders success in acquiring new grants.
Branding and Visual Design
I extended the brand aesthetic, color palette, and typography from the volunteer-facing mobile app to create a seamless, cohesive experience. I also used the component library as a springboard and kept building on it. The robust component library that I built enabled me to iterate quickly and pull together accessible and minimalist designs quickly and efficiently.
Follow the Process
Given that we had already built the front end portion of the application it would have been easy to assume knowledge and needs of the stakeholder for an administrative web application. I treated this as a new application, didn't assume knowledge, and followed the end-to-end design process. This initially slowed down the start of development, but resulted in a faster long term cadence and a better application overall.
Understand the Request
Our stakeholders early on insisted the application must export only as an excel file, something that would have been a larger technical lift for the engineers. Through extensive conversations I understood that the export didn't need to be in excel format but something that excel could use. This enabled us to export as a csv which saved a lot of developer time and allowed us to deliver more quickly.
Demo Early, Demo Often
I engaged the stakeholders and demoed wireframes and mockups as soon as they were built which enabled the stakeholders to visualize what was being built and to quickly provide feedback. This feedback allowed us to iterate and respond to stakeholder requests quickly and ultimately deliver a product that delighted.