EB Let's talk

AI-powered mobile app simplifying complex legislation language into accessible, actionable guidance

AI Advocate app screens on two phones

Client

Love Never Fails

Role

Project Manager and Product Designer

Held both roles at once, for the full 16 weeks.

Duration

16 weeks

Platform

Mobile

Impact

26M+ Users

The app targets California's 26,032,160 voting-eligible residents, with a wider goal of expansion across the United States. The ultimate goal: getting the most underserved communities educated and engaged in the civic process.

End-to-End Design Delivered

Delivered 100+ screens across 3 complete flows, including a full component library, style guide, interactive prototype, and complete documentation, handed off ready to build.

Expanded the Audience

Research revealed the problem was universal, not unique to LNF's survivor community, expanding the app's audience to any Californian navigating complex legislation.

“

The Develop for Good team displayed utmost professionalism, not only in their technical work, but also in their communication, collaboration, and organization. The UX/UI design they created for our mobile app not only met, but surpassed every criteria we set. In addition, the documentation they provided was detailed, concise, clear, and easy to navigate. We are extremely happy with what they have created for us, and would not hesitate to recommend any individual member of the team for any future project.

Sergio Di Martino

Project Liaison, Love Never Fails

Context

Background

Love Never Fails is a nonprofit supporting survivors of human trafficking across California. They wanted to build a mobile app that could help their community understand the legislation that directly affects their lives.

The problem? That legislation was written in dense legal language most people couldn't parse, and no existing tool could simplify it, adapt it to different reading levels, and guide people toward acting on what they learned.

Goal

Design a mobile app that uses AI to make California legislation readable, understandable, and actionable, regardless of a person's education level or language.

My role

I led the project as both Product Manager and Product Designer, owning the research, the PRD, the design, and the handoff. I worked alongside a Design Manager, 5 designers, and the Love Never Fails team for 16 weeks.

Pain Points

Inaccessible language

Legislative bills are written at a college reading level, full of jargon, long sentences, and legal terminology that's nearly impossible to parse without formal training.

No trusted source

Users didn't know where to find reliable legal information. They pieced things together from social media, friends, and search results, with no way to verify what was accurate.

No path to action

Even when users understood a law existed to protect them, they didn't know what to do about it. Understanding and acting are different things, and the gap left people feeling stuck.

Initial challenge

How might we make California legislation readable, understandable, and actionable for everyday people, regardless of their education level, language, or legal background?

Design Process

  1. 1

    Client discovery

    I met with Love Never Fails to understand their mission, their community, and what they actually needed the app to do.

  2. 2

    Research

    I ran two rounds of surveys, reviewed five published studies on legislative complexity, and looked at three AI products to understand where people lose trust in AI tools.

  3. 3

    Ideation

    I partnered with my teammates to run HMW sessions, build empathy maps, and develop user stories and use cases.

  4. 4

    Technical validation

    I worked with two technically minded designers to validate the API and architecture before designing anything.

  5. 5

    Wireframes and user testing

    I designed lo-fi through hi-fi screens in Figma and tested the mid-fidelity prototype with five LNF community members. Testing surfaced a real gap: users could read a simplified bill summary but had no way to act on it. In response, I designed a new flow, an interactive questionnaire that walks users through their situation and drafts the relevant legal document from their answers, with the option to edit or save. That shift moved the app from explaining the law to helping people act on it, the actual goal from day one.

  6. 6

    Handoff

    I compiled everything from research, ideation, and user testing, along with the complete Figma file, into a final handoff package for the client. The team then presented the full project, answered every question and concern, and added supporting notes to guide next steps.

The Output

Sixteen weeks of research, testing, and iteration, condensed into one buildable system.

Everything below came out of that six-step process: research synthesis, information architecture, user flows, wireframes, and 100+ high-fidelity screens across three complete flows, delivered with a component library, a style guide, and an interactive prototype.

Research artifacts, wireframes, high-fidelity screens, information architecture, and user flows

Uncovered Hidden Challenges

The audience was wrong from the start

The project was originally scoped for LNF's survivor community. But research showed the problem was universal, even people with PhDs struggled with legal language. Mid-project, I redesigned the survey, expanded the audience, and rethought the entire information architecture.

How I handled it

I followed the research instead of the original brief. That meant redesigning the survey, expanding the target audience, and reworking the information architecture to serve a much broader group. It added real work mid-project, but it turned a tool for one community into a resource for every Californian navigating the law, a tradeoff worth making.

Real-time AI processing would have broken the experience

Testing showed 60+ second load times for real-time NLP simplification, a deal breaker. LNF also couldn't fund their own AI model, so we worked with Gemini and a pre-curated legal library, and proposed pre-processing bills in advance to eliminate the delay entirely.

How I handled it

By validating the API and architecture before designing a single screen, I caught the processing bottleneck early enough to solve it as an engineering decision, not a design patch. We moved to Gemini with a pre-curated legal library and pre-processed bills in advance, so the 60-second wait disappeared before it ever reached a user.

The team lost 3 members mid-project

Midway through the project, the design lead and two other designers left the team unexpectedly, right as we were entering the most demanding phase of the work, with a fixed client deadline that couldn't move.

How I handled it

I promoted one of the remaining designers into the lead role and redistributed the work across the four of us who stayed. We tightened our process, and kept the client informed every step of the way, delivering every core feature on the original 16-week timeline.

How It Landed

Delivered in full, on time, and ready to build.

All core features

Delivered within the 16-week timeline, nothing cut.

Demo Day

Presented to Develop for Good and the client team.

Buildable handoff

Handed to Love Never Fails complete and documented.

What it took to get there

Multiple design iterations 2 rounds of user testing Weekly client feedback Constant PRD updates An unexpected team restructure

Learnings

Research changes everything

I went in expecting to design for survivors of human trafficking. The research told me the problem was universal. Being willing to let go of the original brief and follow what the data said, even when it meant more work, led to a product with 26 million times more potential impact.

Designing for trust is not optional

When the stakes are high, legal rights, safety, justice, users need to trust the tool before they'll use it. Every decision around source citations, expert review, and transparent AI output came from understanding that trust is a design problem, not a marketing one.

The best work lives at the edges of the job

Validating the API, proposing the pre-processing architecture, consulting an engineer on privacy, none of that was strictly a design responsibility. But doing it made the designs buildable, credible, and handoff-ready. Great design work often crosses into adjacent disciplines.

Check out what else I've worked on