By Anisha Jain

Safety is fundamental to Lyft. Thus, as part of the Safety & Customer Care Web team, we strive to provide the safest experience for our users. Our focus is to bring safety and support features to our riders’ web experience (ride.lyft.com); this allows riders to request a ride from their browser without needing the mobile app. In doing so, we also maintain consistency with the mobile app experience.

Safety team members analyze reports submitted by our riders and drivers to identify root causes, and then develop critical insights about the ways we can enhance safety on the Lyft platform. They share this information with our Product team — a group of engineers (including us), designers, user experience researchers, analysts, and safety experts. We then use these frontline insights to develop new features and evolve existing ones.

Below I will outline some of the features we have worked on, technical and design considerations we must make to support all of our users, and how we leverage Lyft’s frontend stack based on React, NextJs, TypeScript, and microservices. Some of our most important considerations include best practices for implementing accessible features and integrating with our design system for consistency throughout Lyft’s platforms.

Lyft’s safety features

Share Location & Trusted Contacts

The Share Location feature enables riders to easily share relevant trip information, such as current location and ETA, with their family and friends. Users are able to text the link to their friends and family themselves, or can automate this functionality for all or some rides. This automation feature can be enabled by adding trusted contacts in the user settings and choosing their sharing preferences: always, never, or for late night rides only. Riders can toggle this sharing feature on or off at any point. At the end of the ride, their live location is no longer shared, but ride details remain viewable for 24 hours. Each trusted contact receives a unique URL via SMS and will be able to view location via this link during the 24 hour window.

Emergency Help, supported by ADT

With Emergency Help, if a rider or driver ever feels uncomfortable or unsafe, they are able to immediately connect with an ADT security professional silently or by voice. Riders are able to choose whether they want ADT to text them, call them, or silently alert 911 on their behalf. If requested by the user, ADT will alert authorities so they can arrive at the user’s live location, equipped with ride details like the vehicle’s make and model, license plate number, and the intended drop-off location. If someone signals they need help and subsequently does not respond to a call or text from ADT, ADT will contact 911 and share the user’s location and other relevant information.

Furthermore, if ADT does not service their area or there is a lack of information (i.e. the rider chose not to share their location with us), we immediately provide a different user interface that prompts riders to call 911. They would be able to use the call 911 button on this interface to easily and quickly dial 911 for immediate assistance.

Smart Trip Check-in

In some instances, if we notice a ride that appears to be irregular, we reach out to riders directly. This may include rides that have ended far from the intended destination, been canceled after pickup, gone off-route or stopped for an abnormal amount of time. We do this via a check-in panel that is shown to the riders if we detect any irregularities. They see this panel on their web view while they are in a ride. We ask users if they need help and, if appropriate, connect them to our own Safety team or emergency assistance. We recently integrated ADT’s capabilities into Smart Trip Check-in. This means riders can utilize emergency support via ADT through this check in as well if they need assistance.

The technical side

Accessibility

We are using a11y best practices to make features accessible to all users. Accessibility is essential for rider web, especially for safety features. Our goal is to ensure our safety features are easy to find and use, for all users regardless of ability, in case of any emergency.

It is important that all users are aware of the safety tools menu and of how to get there — for visually impaired users this means we must implement our feature such that it is announced by voice over. Often, this involves rigorous testing using voice over to ensure that relevant information is announced when an a11y user navigates to any page, and that tab indexing works properly. Sometimes this involves the use of a `tabIndex` property on the respective element that is not usually announced but is essential for our use-case; however, using the base HTML elements or role attributes correctly is always preferred over this to prevent us from having to break the general flow of a screen reader.

If a user requests emergency help, they will be redirected to our active emergency interface. Here they can find updates from ADT on the status of their safety incident. This involves text that is changing on the page and needs to be announced to an accessibility user since they won’t always be aware of these updates otherwise. This behavior also applies to our share location webpage, a widely used feature, since the status of the ride is constantly changing on the web view without a page refresh. In this case, we use an `aria-live=”assertive”` prop on the relevant component to ensure that these important updates are announced.

Buttons are also very important to consider for accessibility. We are used to very subtle visual changes which help us differentiate text from buttons and enabled from disabled buttons. However, if a user is visually impaired, then these subtle changes are irrelevant, and we need to ensure that the screen reader tells such users when they are on a button vs not, and lets them know how to click on the respective button. For this, if we choose to use a non-traditional button (aka a custom button that does not use the pre-build html `button` tag), then we must add a `role=”button”` to ensure that screen readers are able to announce these as buttons.

Another important consideration is forms and form elements. In some cases, we implement forms that involve selecting an option from a list of options. Often, there is use of radio buttons and dropdowns for this case. We notice that these options are difficult to understand via screen readers for accessibility users and prefer to find a way to represent them as buttons for such users. If a `role=”radiogroup” is assigned, the screen reader is able to let the user know how many options there are in the radio button group and the user is able to use arrow keys to navigate among these options. The selected option is announced as selected so the user is aware of their current and/or changing selections. However, we continue to test, discuss, and implement better solutions to improve this user experience.

Ensuring awareness and ease of use for our a11y users is essential for the Safety team. Proper navigation, announcements, and form elements are only a few of the items we must consider when implementing. We continue to test and update our features to better support all users with the help of our accessibility specialist and team of dedicated engineers and designers.

NextJs Architecture

NextJs is a react framework built for easier development of complex applications with code-splitting, server side rendering, and dynamic content loading. The ride.lyft.com webpage is built as a progressive web app (PWA) built on NextJs and utilizes Typescript, LPL, and other Lyft services to serve riders the web experience for Lyft.

Progressive Web Apps are web applications that have been designed so they are capable, reliable, and installable. Using service workers and a web app manifest makes the web application reliable and installable. We use a Service Worker to ship a fully responsive, Progressive Web App. Service worker unlocks many features for a modern web experience: installability on the users mobile home screen and desktop, push notifications (Rider in-route), background fetching, and offline capabilities. Service workers also provide performance/reliability features like mitigating poor network conditions.

In addition, we use a multi-app architecture. A multi-app architecture provides a highly flexible environment for web dev that allows new web products to be built in weeks rather than months. Thanks to NextJs’s dynamic loading features, we maintain a clean separation between different product codebases while still being able to leverage shared backend tooling and services (auth system, IDL definitions, business & API logic) and complex UI components on the frontend (global navigation, responsive mobile/desktop layout, app panels, modal system, calendar pickers). Additionally, all products within the multi-app suite benefit from the team’s long-term investments in areas such as web performance, accessibility, and fraud prevention.

I18n — Translatables

One of our teams at Lyft has put together a service that handles all translations by intercepting. We use this service to handle translations throughout the app. This means that users using our app are able to see content in the language they choose on their device and/or browser of choice.

Design consistency

We strive to provide all our users a consistent experience on our features. We are able to accomplish this with the help of our designers and the Lyft Product Language (LPL). The LPL library at Lyft includes designs and pre-built web and mobile components that engineers can use in all services at Lyft. This is a collaborative effort among all engineers and designers to update and maintain with the help of our LPL team.

When we plan to implement a new feature, we realize that achieving our desired design consistency is a 3-step process:

Step One: Designs

Our designers help us translate the native app feature designs to fit web user experience by considering existing styling practices on ride.lyft.com and those among the native safety feature. The designers put together a Figma board outlining the user journey with their designs and share those with the frontend engineers. Often, as a creative frontend engineer, I also have the opportunity to collaborate with our designers to help create these Figma boards; this in turn helps us bring more technical questions when designing and navigate those early on.

When translating these designs, we must consider how capabilities differ among the native app vs the browser experience. For example, web browsers on a laptop do not have touch screen capabilities, but on an iPhone, it does have a touch screen. Additionally, a web browser can deal with various screen sizes, such as phones, iPads/tablets, and computers. Thus, we must consider different scenarios and determine what the best user experience would be for each user.

One such example is design and placement for safety settings (i.e. trusted contacts) in ride.lyft.com in alignment with the settings on the native app. Since the design and hierarchy here differed significantly from the native app, we decided to create a separate category in the sidebar in the settings menu. This allows for consistency in design across the platform and makes all safety settings easy to find for web users.

Another example is our emergency help button. In the native app, this is a slider button, where the user would slide across the button horizontally to confirm that they require assistance. This works well for devices with touch screens as users can easily use their fingers to slide through the button. However, for non-touch screen devices, using a mouse or trackpad to slide through the button can be rather tedious. In that case, we decided to use a regular button when touch screens are not available.

Step Two: Lyft Product Language

The LPL design system consisted of the slider button for native apps, but the implementation for this was not yet supported for web due to its usability concerns on non-touch enabled devices and accessibility users. This gave us the opportunity to collaborate with the LPL team to propose a usable and accessible solution for slider buttons for the web. This would then enable all Lyft services to use this button design.

We proposed a slider button with a regular button fallback for non-touch enabled devices, such that a regular button click could be used for non-touch devices, and we could continue to provide slider buttons for touch-screen interfaces. Additionally, we proposed an implementation technique using an underlying button tag to ensure screen readers detect this custom button as a regular button and users are able to click it as such when using screen readers. Once approved, we proposed an implementation plan and integrated this feature into LPL with manual and unit tests.

We were now ready to bring this into ride.lyft.com for our safety feature.

Step Three: Implementation

The next step was bringing this into ride.lyft.com. This involved approval from their team prior to feature implementation. Once we addressed any further concerns, we were able to easily import the slider button from the LPL web library and use it for our feature.

Testing

It is very important to us that we test our features on browsers, devices, and versions that represent our users. During the pre-deployment testing phase, I generally set aside time to plan and test these different devices and versions, often in collaboration with other engineers in the team. This helps us catch and resolve any device/browser related issues early on.

In addition to this, we try to enforce rigorous unit testing to help ensure that our components and methods work as we expected, with mock data and mock api responses for as many scenarios as possible. This helps to proactively mitigate our feature testing process pre-deployment.

Enterprise users

Enterprise users fall into the category of concierge users; these are users that have requested a ride on behalf of somebody else using our concierge platform. This is often used by businesses such as hospitals to request rides for patients, especially less tech-savvy users. Once the ride is requested by the concierge, the user is texted a ride link. This behavior feels similar to a share location link, however it has a lot more capabilities similar to a users ride view because this link is used by users actually in a ride vs. friends or family viewing another user’s ride. Since we integrated the concierge route in the same codebase, we are able to provide them with the same features as all users. It is especially important that we provide easy-to-use safety features for these riders since they might not be especially tech-savvy. For this reason, we have integrated all of our safety features as described earlier in this blog for concierge.

Key Takeaways

Thanks for reading! Here are some key takeaways:

• Accessibility support integration is essential for design and implementation of features
• Designs for a feature on the native app may not always provide the best user experience for web
• Building with nextJs provides a modern tech stack