Maven

Empowering community leaders to address the social needs of community members in San Francisco Bay Area and beyond.

DESIGN LEAD | STRATEGY (May 2020 - Present)

Challenge

How can we better understand and communicate Social Determinants of Health (SDH) resources that are culturally relevant to community members in San Francisco Bay Area and beyond?

One of many solutions to address the challenge

Provide a way for community leaders to share relevant and timely resources that address social determinants of health to community members who need them.

Our impact

Our co-design process that led to our MVP uncovered many other barriers to resource sharing in community-driven neighborhoods that are well beyond just the technology. This led us to examine different models of SDH resource sharing and community of practice, not just in San Francisco Bay Area but in more rural communities such as the Central Valley.

The Messy

DESIGN PROCESS

CLEARING THE FOG

Getting together with our partners

Our clients, the UCSF Center for Vulnerable Populations (CVP), together with a third-party non-profit group Streetwyze, collaborated with our team so we can understand how community members navigate their resource landscape. Our team’s role is to facilitate further discussions with community members to explore how technology might help.

Digital design exercise with community partners

We partnered with the community leaders from five organizations in San Francisco Bay Area and conducted a “digital safari” exercise with at least 10 members of different communities.

  • Given the pandemic, further investigation was limited to remote interviews.

  • Packets were mailed to participants to facilitate discussion.

  • Encouraged by our CVP partners to frame questions for healthy dialogue around participants’ environments and what technology they have at home, we conducted a “digital adventure” exercise, role-playing scenarios and asked them to imagine how their phone could help them.

Digital design safari exercise with community members. Physical packets were mailed out with activity instructions, phone cardboards, stickers, and mood board with cards.

Digital design safari exercise with community members. Physical packets were mailed out with activity instructions, phone cardboards, stickers, and mood board with cards.

The first design experiment failed, so we pivoted

Our interviews had very low participation due to the already existing digital divide that was exacerbated by Covid-19 shelter-in-place.

We had to pivot and focus our efforts on the challenges of community leaders (vs. members) around resource sharing, since they have vast amount of historical knowledge and have built trust with community members over time.

SETTING THE RIGHT DIRECTION

Failure leads to insights

Our failed experiment still informed our pivot from putting a tool in the hands of community members, to integrating it into a community leader's workflow.

Pivoting to focus on the community leaders

After refocusing our efforts on the community leaders, we conducted two focus groups with 3-4 participants. Our goals were to:

  • Understand how they are currently sharing resources, the tools they use, and pain points.

  • Understand their clients and partners.

  • Understand the types of resources they are collecting.

  • Understand existing barriers with policies and technologies.

  • Get inspiration for look & feel.

Design participatory sessions with community leaders

Interviews and storyboarding exercise to co-create scenarios.

Moodboards

We showed them existing websites of community organizations that they are familiar with. We then asked what elements resonated with them.

Co-prototyping, co-testing

We focused our designs to reflect and address these needs:

  • Receive timely, local, and personalized resources from community leaders they trust.

  • Bi-directionally communicate with each other through email and/or text.

  • Gain insights on the engagement of members with shared resources.

Themes

Our analysis highlighted several themes on the community leaders behaviors, attitudes, and motivations around resource sharing with their community members.

MAKING TRADE-OFFS

Buy vs. Build

After seeing the first mockups, the community leaders were excited. However, building this from scratch might be too costly. Instead, we relied on our partners at Salesforce to help us create a tool that could solve the needs, only for a fraction of the price.

We came to a decision point: Looks pretty, but should we use an off-the-shelf tool and light-weight customize it instead of building a new thing? Let’s use Salesforce instead.

First iteration that was unfortunately too expensive to build.

Understanding the benefits and risks of using a SaaS tool

We’ve come to a decision. But how do we convey completely different design to now using an out-of-box SaaS tool to the users? Highlighting the benefits and risks increased transparency and facilitated difficult conversations. In time, we were able to come to an agreement by understanding our tradeoffs.

Taking what we’ve learned from first mockups

When I presented the mockups, unfortunately the team was concerned that this was going to be too costly. Rather than starting from scratch, I combined the important elements from the mockups and “translated” these elements into our chosen out-of-box SaaS tool.

Taking “inbox/messaging” element from the mockups to “translate” into the chosen SaaS tool.

Taking “campaigns” element from the mockups to “translate” into the chosen SaaS tool.

SPEEDING AHEAD

Building a Minimum Viable Product with cross-functional teams

With a clear direction, we assembled a scrappy team of one designer (me), two engineers (build and QA), one solutions architect, and a project manager to build an MVP.

Getting everyone on board

I used Mural to paint a picture of the entire product — the vision, the goals, the users, the timeline, and the stories.

We also explained why the decision was to go with a SaaS product and to be cautious and aware of its tradeoffs in development.

Produce board I created to visualize the big picture (vision, goals, users, MVP, stories, timeline, agile dictionary for our clients)

Agile Development

Prior to building, I walked through the mockups and had our engineers think about how this would translate into the chose SaaS tool. Fortunately our engineers have a ton of knowledge about the tool and experience on how to customize it. Our scrappy team had hybrid rituals of scrum and non-scrum, and it was important for me to elevate the voices of our clients and users in every scrum meeting, usability testing, and demo.

“Good enough” to let it out in the wild

The final design was obviously far from the original design. We had to compromise on some of the standard elements that the SaaS provided, with very little design control within the UI. However, we made sure that the experience was as close to our original mockups — from creating contacts, sharing resources, and sending messages. Being nimble and creating a “good enough to test” product allowed us to get feedback fast.

One of many product demos in between sprints.

Minimum Viable Product

ROUND TWO...

Our MVP taught us of many, many lessons

  • Data upkeep: In the second iteration, we wanted to explore solving the challenge of getting and updating the data from a reliable source. We learned that community leaders do not have much time to spend adding, editing, and updating resource data.

  • SaaS design limitations: Relying on an out-of-box solution presented many trade-offs, mainly customizability in the experience.

  • Onboarding was hard: the sign up/log in process that we implemented was a huge barrier to entry (including dual-factor authentication).

Maven Phase 1

Maven Phase 2

Iterating with a few new features

  • How to solve for data upkeep challenge: integration with a third-party, vetted resource database called SF Service Guide.

  • How to solve for onboarding challenge: developed password-less login.

  • More targeted outreach: with the integration in mind, we also integrated a plug-in called ServiceMatch to get a more personalized list of resources depending on the member’s demographics.

Another iteration with new features: more personalized client-resource matching based on their profile.

Another iteration with new features: integration of resources from a third-party database and a more streamlined referral process.

WIDENING OUR APERTURE

Learning from our community

I did some usability tests and training in person when covid restrictions were more lenient. Here are the takeaways:

  • Barrier to entry with technology was still very high. They had a hard time with the onboarding process and got too complicated.

  • There was excitement around the use of technology to replace old binders of resources. Some early adopters advocate for technology as a means of additional support.

  • Language is important. Though the resources were available in other languages, the ability to communicate in the language that the community speaks is crucial to adoption.

  • Community leaders are overwhelmed with work to think about updating and managing resources within the technology.

Retrospective interviews with our partners.

Learning from our partners

We also wanted to learn from our partners about our approach and what we can do better. Though there were some challenges with the technology rollout, we were motivated to take our learnings and apply them in the way we conduct research and address a purpose. Here are the takeaways:

  • Meet the person where they are. Understand people’s environment (language, socio-economic background) and include people they trust to have a healthy and inclusive dialogue.

  • We need to include community members from the get-go (from the inception of the grants).

  • Things are different in reality. Sometimes things just don’t get prioritized because reality is vastly different from conceptual.

  • The community members are the experts. We (designers) are not the experts. We are there to help them feel understood and facilitate discussions around their purpose.

It’s not JUST a technology problem

The many trial and errors for Maven helped uncover some of the underlying issues that are much bigger than technology. We’ve seen time and again that resource directory upkeep is hard, so we needed to understand that this can only work if there is a system designed to create a successful organization around data upkeep, data sharing, and referral follow ups.

Exploring different models that exist

We have the privilege of learning from our different engagements in the past. We explored different models of resource sharing and what’s been done (we should’ve done this from the get-go!) and shaping our design sessions to focus not just on technology, but on the processes and organization around those processes.

Another round of focus groups with the communities in the Central Valley.

Insights from our focus groups.

Expanding to the communities in the Central Valley

With these lessons in mind, we are starting from the ground up. We want to explore how we can engage a new audience differently this time. Engage them in a way that would help all of us think about the overall systems organization around these resources. Not only the technology piece but how to work collectively to organize, systematize, and be accountable for the resources that are being share in their communities.

I will be co-facilitating design sessions with the Central Valley communities soon, in the meantime, check out the practice session I did with my team.

Practice workshop session with my team.

Practice workshop session with my team.