Notification system for an everyday mobility app
A revamp of an existing feature driven by the ambition to better address user needs.
The situation
The company I worked for partnered with Deutsche Bahn to transform an already published mobility App into an everyday mobility solution tailored to users with specific needs, not only using public transportation but also new mobility players such as TIER and Voi.
I was part of a cross-functional vertical team with a Product Owner as well as Engineers (Backend, iOS, Android, QA) .
One of the products we owned was called Alarms:
Alarms enable users to activate push notifications on a given public transportation trip. In case there is a disruption or any important information regarding that trip, the user will receive a push notification, meaning they do not constantly need to check their phone for updates.
This feature can be used for repeating connections, which is handy for commuters who always take the same connection at a fixed schedule and want to be informed about possible disruptions.
We also offer the feature as a one time subscription which means that the user will receive push notifications for one specific trip only.
The original setup
We had some issues with the architecture of the original alarms, that were also validated by user feedback. We were convinced that this product is of value but not in its current execution, there are some things we could fix.
To make sure we really meet user needs we did extensive research on top of understanding the technical constraints of the current architecture.
The main pain points we identified with the current setup were:
Lack of user segmentation: the feature was designed for a "universal commuter" but research showed that due to Germany-wide public transport coverage, commuter experiences vary drastically. We needed to factor this information in and find a solution that works for each commuter segment.
Unnecessary complexity: the original setup contained two types of alarms which are rather difficult to explain and the majority of users did not understand.
Lack of transparency in the connections that the user subscribed to. Consequently, notifications were perceived as spam due to “irrelevant” content. There were different perceptions on what is relevant and what isn’t (user frustration).
The high push notification volume sent due to lack of customisation options on user side resulted in high operating costs.
How might we
Create
A useful and user-friendly alarms feature
For
Everyday commuters in Germany
To
Notify them about disruptions on their route
So that
They commute more efficiently
And improve
Everyday transportation
Goals
Keep it simple, make sure product is easily understood.
Make sure that it works for commuters with different needs meaning that it needs to allow for customisation & flexibility.
Only send information to the users that is actually of relevance to them. Let them choose what is relevant (empowerment).
Maintain the visual language of Deutsche Bahn, ensuring consistency between platforms. Take advantage of existing mental models and native behaviours.
What was my process?
Creating a successful product requires a cohesive and collaborative team effort, guided by a well-defined and systematic approach. Using transparent communication, we went on a dynamic journey that combined the collective creativity, research, and technical expertise. Even though the big picture was communicated from the beginning, the details of the process were shaped by trial-and-error or adjusted to fit our specific needs at the time.
Overview of steps:
During the product exploration phase, we identified the main pain points experienced by users, using data analysis. Additionally, we held a "How Might We" workshop to engage in creative thinking on how to address the identified challenges.
Next came the research and validation phase. We used various research methods such as user interviews, desk research and competitor analysis to understand our users and their needs. As a result, we came up with a user segmentation that recognised their different needs and represented them in a more realistic way.
Following that, we moved into the solution phase. It included a refined concept and a “look and feel” UI suggestion. This step included back and forth with the engineers as we needed their expertise on tech feasibility before we move on.
Almost parallel but later in time, came the tech feasibility and proof of concept by our engineers . Each of the suggested solutions/ideas were communicated and examined on how feasible it would be to implement on a reasonable time frame.
When we had finalised the refined concept we pitched it to our internal stakeholders. Their feedback was necessary before we moved on to presenting it to external stakeholders. We received 100% approval.
The final pitch to the external stakeholders came shortly after and we got a buy in for all our suggested solutions.
The last step of the process was to define MVP scope, break the solution down into implementation phases and translate it into a roadmap. The roadmap was shared and communicated internally and externally. Lastly, we introduced the broken down implementation steps to our OKR set.
Research overview
In the research phase of the product design process, we engaged with both beta users and non-users through interviews. These interviews played a crucial role in gaining valuable insights into user perspectives, preferences, and pain points.
Interviews with beta users
Understand their commuting needs and how they use our product during, before or after their trips.
Talk about the added value (if any) that our app brings to their everyday life. What is the frequency of use for our app during a typical week?
Investigate about the problems they usually face while using our app.
Open the conversation for features or functionalities they wish the product had.
Interviews with non users
Exploratory discussions about their regular commutes. Understand their needs and compare with beta users.
Talk about any digital products they might use to help with their commuting decisions. Understand why they chose the products they use and if these products cover their needs completely.
Navigate them into a realistic unpleasant scenario and explore how they would react in it.
Discuss about their wishes for the ideal everyday mobility app.
Research sample correction
During the initial two rounds of research, we inadvertently ended up with a sample that consisted entirely of male participants. While the data indicated that a significant portion of daily commuters were men, we recognised the importance of understanding potential deviations in the needs of women. To address this, we conducted a third round of interviews specifically with female participants. This additional research aimed to capture insights and gather a more comprehensive understanding of their unique perspectives and requirements. By broadening our sample and including diverse voices, we ensured a more inclusive and robust research process, enabling us to develop a product that caters to the needs of all commuters, regardless of gender.
Results
Achieved buy-in from our stakeholders, ensuring their support and involvement throughout the product design process.
Developed a prioritised roadmap, outlining the key milestones and deliverables for the project, enabling efficient planning and execution.
Quickly and successfully implemented the "Saved trips" feature. It was the first of the solutions proposed that were launched.
The pitched ideas worked as “door-openers” for further product improvements that were kept in the backlog for later exploration.
