Bird is organized into several mission teams, and my areas of focus were GovTech (features within the Rider app that deal with compliance, safety, positive behavioral shifts) and our internal Operations tools.

•  •  •

The Challenge

Changing basic human behavior for new tech

Bird is a company with a lot of noble ideals and a little bit of a tech bro reputation. As the company has evolved, my team’s mission has been to mend and build relationships with cities by creating a self-regulating, safe, and reliable transportation option.

• Use data to improve city infrastructure. We need to collect and analyze data that we can use to provide cities with meaningful reports that lead to acceptance at a minimum, and ideally to inform decisions on infrastructure improvements.

• Empower marginalized communities. We can provide a means of equity for disadvantaged communities, so we need to figure out what that means and how to achieve it.

• Establish rules and safety precautions as a norm. We need to help people safely navigate the wild wild west of transportation while still having fun. People need to understand how to stay safe themselves as well as treat this new private-public property respectfully that will not cause harm to the community.

Operationally our challenge is that we have very small margins. Nobody using these scooters “owns” them so ultimately Bird is accountable for the behavior of not only their users, but the entire community in any market Bird is present. Internally we need a tool that handles logistics, employee/contractor coordination, accounting, data tracking and analysis, and task assignment.

NORMALIZATION

Creating a self-regulating community

Community Mode was our first GovTech feature within the rider app. It allows Riders to report Unsafe Riding, Bad Parking and Damage from a quick-action button on the map.

In our initial research we got a very consistent, singular response: "this is cool, I hate when people do these things, but realistically I would never take the time to do this.” However - we quickly realized peoples’ idea of what they will do is very different than what they will actually do.

We learned a lot about user testing for a physical experience that has a lot of stressors - time, environmental anxiety like traffic, etc. In reality, we immediately got tens of thousands of complaints through this feature - too many to be actionable.

Our Solution

We needed to re-work a few small things in the near term. Scanning and photo are required for damage reports, and our data science team is working on creating a model for correlation with user-reporting with real damage assessed by mechanics. We are testing different sets of tags to figure out what is the most reliable. For future features, we needed to allocate more resources for creating a MVP for testing with users out in the wild. Finally, we will test if we need to expand our user base altogether by testing this feature as a tool for parking enforcement officials.

RULES & PR

Visualizing the map in different contexts -

Cities, universities, parks, neighborhoods, etc. needed a way to manage on a small scale where Bird can or cannot operate. We needed these zones to inform users where they need it in context but not turn the map into a swiss cheese of color, especially given all kinds of ideas on markers, layers, filters and more that could be added in the future.

Types of zones we have have are No Park, No Ride, and Slow. If you enter a small zone, it needs to be clear how you can leave. If there is a very large zone near you - such as a park or university, you need to have the necessary context to avoid it altogether so you won’t get stuck in the middle.

For the MVP of this feature, we focused on correlating information with your current zoom level on the map. For small zones, you see them only when zoomed in or if you are inside of one. Large zones are less visually harsh but never disappear.

SUSTAINABILITY

Adding value while taking away convenience -

We have given cities a tool to manage where Birds can and can’t be, but we didn’t yet provide a positive counterpart for Riders to help them figure out what is ideal.

Parking sounds a lot like docking, which is very much against everything Bird set out to be. One of the biggest issues for us to solve is that we are taking away previously given convenience. We need to shift focus to improving the experience of the entire community - and rewarding and fining people in ways they have already accepted for other modes of transportation.

Considerations for the physical experience are more important here than anywhere else so far. Unlike looking at a map for something like driving directions or Pokemon Go, users are not able to (and shouldn’t) use their phones. We needed users to be able to find and end their rides in small, geofenced zones - so we needed markers on the map to have corresponding markers in the real world.

View Google Slides Deck - My documentation approach for giving context to early stage design concepts.

IN-RIDE EXPERIENCE

Creating a faux-hardware solution with software

An In-Ride Display is a feature that is very technically expensive - but would be a more ideal solution to a lot of pain points that the primary app can’t fix as well.

This concept is designed under the preface that we have attached phone holders with clamps and clear screens that you cannot touch while in ride. This concept requires a huge amount of validation with users to see if we are actually achieving a more safe experience and not less.

Upgrading our features -

Users will be able to enter a destination before they begin their ride, or at any point during the ride. From there, they can enter a super-simplified In-Ride display that shows only Turns and Speed while moving.

Once a user reduces to 0 MPH, they get slightly . more detail - the following two turns, ride stats, and a few quick actions that would be relevant while in a ride. They can toggle between the list and map view if they need to better understand where they are, change their route settings, exit the In-Ride Mode.

Users can toggle between prioritizing bike lanes vs. quickest trip time, and routing to Parking vs. routing direct to the front door of their destination. This allows us to avoid our policy zones and also lead users directly into parking so they are not doubling back.

To limit the time users need to look at their screens, we can flash color to alert them when they are very close to a turn. We can also use color and simple messaging to alert users who have gone off route and entered one of our policy zones.

DATA + POLICY

Changing our world’s transportation infrastructure

City Dashboards were the first project I worked on at Bird. The original goal was to provide Regulators with consumable data that they could use to ensure we were meeting compliance, and then eventually use to make infrastructure decisions. We explored a lot of ways this could be both a huge PR mechanism as well as legitimately creating change in communities.

Many regulators either only want APIs, or do not trust the data we gather about ourselves in the first place, so we are now re-thinking how we can work with third party non-profits to achieve these same goals.

ACTIONABLE DATA

Turning complaints and reports into tasks -

Once we had a framework for complaints and reporting, we needed a way to make that information actionable.

The concept of dispatch was a vague but highly prioritized ask from every department. We had a new hourly role called Bird Watchers, but were also paying gig workers an un-tracked amount to do special tasks like collect piles of Birds. We needed efficiency, accounting and the ability to respond directly to reports and complaints from the community.

• Gather context. I conducted interviews with internal stakeholders about pain points and goals.

• Info architecture. I organized the types of incoming issues and reports and mapped them to tasks to fix them.

• Design concepts. User flows, design concepts, and coordination with the designer working on the Bird Watcher app.

View Google Slides Deck - My process for approaching an initiative without any set requirements that involves cross-functional teams.