Anna Atiagina, UX/UI Designer in Seattle, WA
Able, Mobile App
Able is a smartphone app aimed at connecting volunteers with organizations and making volunteering easy and satisfying. It is designed for busy people and people who are not very comfortable with mobile apps. I worked on the interaction design, UX/UI of the app.
Timeframe: 6 weeks.
Collaborators: Isabel Blue, Julia Rundberg.
My roles: UX/UI designer, Interaction designer, front-end developer.
Skills: UX Research, Sketch App, InVision app, HTML/CSS, Principle.
Challenge/Problem: Create a scalable service that could contribute to social change. We chose to work on a smartphone app that would allow busy or not very tech-savvy people to find volunteer opportunities based on their location, skillset, and schedule.
Project Goals and Objectives: As a team, design a mobile app and supporting deliverables including research, branding, printed materials, video and a landing page. I worked on: research and branding; user personas, customer journey map, user flow, app screens (low-fidelity and high-fidelity), the final clickable InVision prototype and Principle mock-ups.
Solution: Able is a smartphone app aimed at connecting volunteers with organizations and making volunteering easy and satisfying. Onboarding includes customization options that allow a higher level of personalization for notifications and volunteer postings that are offered to user. It is designed for busy people and people who are not very comfortable with mobile apps. We aimed to make each screen contain as few choices as possible to minimize complexity. Most of the screens have only one prompt for a user. To make it even less complex and distracting, we chose a very minimal UI and overall app branding.
Customer journey
One of the first steps that we took was customer and competition research. We looked at similar apps as well as interviewed people around us about volunteering. We focused on users who were actively volunteering as well as the ones who didn’t (but would be interested). We wanted to know more about the key moments when the decision to volunteer was being made, and what made people ready (or especially NOT ready) to commit to doing some work in their free time. I interviewed some people and we created two personas based on our findings.
We also discussed the view from the non-profit / social worker perspective. Our app was focused on the volunteers but we also considered some of the requirements on the other side, which cause to some changes in the flow, such as adding the background check.
The personas that I’ve created were inspired by some of the people that we spoke to.
Whiteboarding and user flows
Defining our scope and whiteboarding the MVP feature.
Flow for a new customer (fragment).
Flow for a new customer.
Low-fidelity screens, clickable InVision prototype. Iteration.
Based on the user flow above I have created a low-fidelity prototype that eventually included 63 screens (not all of them different, some of them very similar to show specific taskflows in detail). I have created screens for the following taskflows:
Onboarding (including test search, creating account, identity check step 1, identity check step 2 and start of background check step 3). I have made some screens for error handling and also gave users opportunity to stop the process at any time with an option to come back and finish it later as an ideal AbleApp experience requires detailed customization).
Profile customization: schedule (time when available to volunteer)
Profile customization: skills
Search for volunteer opportunities
Volunteer opportunity: add to favorites, share, apply
Favorites, calendar screens.
I have tested it on a couple of people (choosing potential users is easy because AbleApp is targeted towards a very broad audience). For example, I had to do two iterations on a schedule task flow. In my first version I had a matrix-type schedule screen that was inspired by what I saw in other apps, for example, Golden.
After user testing I had encountered an issue: my matrix didn’t allow to specify time periods in a very detailed way. I had time ranges (for example, 12pm-6pm, 6pm-10pm etc) but the user asked me what if they want to be available in some different time ranges. I rebuilt the same screen with dropdowns and after the second round of showing it to potential users I simplified the screen even more which was so much closer to our initial goal.
High-fidelity screens based on brand guidelines.
As the UX designer of our team, I advocated for more accessibility in our design, by changing our color scheme: our original branding idea was to have black type and icons on one of five background colors, but each type of task would always have only one color associated with it. It meant that user would have to look at (and read from) a screen with the same background color for a few minutes. In my opinion, our initial color scheme was too bright for it, so together at our team’s meeting we changed the colors to a different set. While designing the high-fidelity prototype for this app, I spent enough time looking at each screen and at the same background color so I can say that my eyes weren’t tired of the color palette that we ended up choosing.
Design system that became the base for the UI.
Our user flow consisted of 63 screens, and I have designed a high-fidelity prototype based on visual guidelines created by my teammates. I have also created an InVision prototype and a couple of animations in Principle to show possible interactions.
