Pendlr allows you to easily check in into public transportation and share your route with your friends. It’s a new way to travel together.
While we were studying at the University of Applied Sciences Potsdam, Dominic Rödel, Constantin Eichstaedt and me as well as a lot of fellow students actually lived in Berlin. That meant we had to commute to Potsdam every day. Since that results in spending up to 15 hours in a train each week things can get quite boring unless you have to finish course projects on the last mile.
After a while we realized that we usually all take the same train but are scattered around different wagons and compartments. Therefore, we thought about a way how we could build an app that allows us to board the train at the same wagon and share information about delays (which might be crucial to being on time) and other annoyances or funny moments.
We came up with Pendlr, an App that allows you to checkin on a train with your friends and share related information. Eventually, we released a working Beta version to our fellow students that proved that our app technically worked really well but had flaws on the incentive.
In the beginning of our design process we started to evaluate all necessary steps that you need to identify a particular train and your position within the train. Hence, we decided to begin with a naive approach and just scribble out how we’d imagine the process without thinking about technical limitations and feasibility. Doing collaborative sketching sessions also allowed us to align and communicate our ideas and expectations about Pendlr within the team.
We also looked at how Foursquare dealt with different options in their more static checkin process and how people are using apps that allow way finding for public transportation.
Later on we started to have a dig into the raw data that we obtained from the Berlin public transportation network as well as other cities to validate that our concept works through out different networks with a diverse set of characteristics.
After we started to understand the scope of such a service a little better, we started to think about the holistic experience of the App. We asked our selves: „What is the minimal feature set?“ and „What kind of direction do we want to give the app after a checkin works?“.
As a result we realized that there are two approaches on how to share your current position in a public transportation network:
One approach to share you position is to manually select a train and the relative position on that train and then publish it to a checkin stream as we are used to it by platforms like Foursquare or Facebook who deal with static locations.
The system is easy to interrupt and allow for more manual control by the user in case a trains is late or a line interrupted. From the perspective of a minimal viable product it is easy to implement and should still allow us to prove our concept.
Manual control of the checkin also makes it harder for the user to actually select their particular train and it takes a significant amount of time to manipulate all necessary information even though we try to make very good guesses and guide to the most likely train.
The second variant on how to share your ride is to use the app as a routing tool. Simply select a start and destination point and select the route you’re going to use. As a result the checkin stream will automatically check you in to new lines along that route.
Routing has an aditional insentive to actually use the app since it allows to solve to problems at the same time. It also allows the service to check you in to all the trains on your route automatically.
Routing makes your checkins less flexible and relies on a public transportation network that is over 90% on time to work properly and not broadcast misinformation to your friends. It is also significantly harder for us to implement especially as we tried not to rely on an active internet connection to much since underground services alot of times lack good mobile data connections.
We quite quickly chose the checkin centric approach to build our first minimal viable product since we were limited in our engineering capabilities and were highly motivated to prove our use case and concept. Therefore, we aligned a basic set of necessary features and flows and started to create first wireframes and basic mockups, while we started to implement first features and server infrastructure to handle the vast amount of data of public transportation networks.
Design and Development hand in hand
We decided to run our design and development efforts simultaneously in order to validate our ideas quickly within the app with real data. Therefore we tried to separate the Interface Code strictly from all other modules and have most of the parts available in Xcodes Interface builder. Hence everybody on the team was able to make changes on all screens and could focus on their area of work while development speed was not affected by dozens of mini iterations or small visual changes.
This process allowed us to fluently influence our design decisions by what we observed in our early beta with real station, line and vehicle data. As a result we ware able to create a very streamlined app experience that enabled the user to have an interface that on one hand adapts a lot of common human interface guidelines and breaks those where it makes sense to show in interact with data on a different level.
Therefore we could create a symbiosis of common interface elements in terms of navigation and information architecture and new custom elements that fit the needs of a information heavy and very dynamic filtering process.
The biggest focus on our work was to create a consistent checkin flow that allowed the user to easily checkin. The challenge is to filter out a specific train and your position on that train from a potentially huge set of trains that come in questions to be the one the user is currently waiting for or already riding.
The first step to checkin is to select the station that you’re at. The map view show the next stations around you and let’s the user select and confirm the correct one.
The second step lets the user select a specific line and direction. At the same time the final checkin pill starts to take shape on the top, to enhance the understanding of the different sections
As the third and last step, the user selects a specific vehicle on his connection. The view shows the live position of a vehicle on its route. Taping on one vehicle reveals also reveals who else is on a vehicle and allows to wait for one with a friend in it.
In the end the current ride will be highlighted on the top of the main screen. As soon as the user approaches the next station, the station pill will be exchanged for with the new station.
Users can add additional informations to a ride. Different kind of moments allow them to inform friends about travel information, delays, funny or annoying moments.
The highlight section on top of the main screen also allows to show notifications that can be revealed with a simple swipe
Stream & Iterations
To let the users know about where their friends are using public transportation we had to design a stream that facilitates on one hand a chronological order of different checkins and at the same time could each checkin be updated with the current station or a change of lines.
Therefore, we came up with a solution that we call „checkin pills“ Each row in a table of checkin allows the user to easily read all necessary information. At the same time the content can change dynamically by moving in and out different pills of one row to indicate an update to the position of a user or that they changed to a different line.
On the left hand side, the profile picture indicates who checked in, the second item facilitates the information about the current line and direction of the friend. The last item show the current station of the user and is the one that changes the most frequently as the train moves from station to station.
Over the time we made dozens of iterations and small improvements to the stream. From a text only checkin to the pill design. From iOS 6 to the drastic transition to a design that was appropriate to iOS 7. The following video shows a few hundred of those small and big changes that we made during the design and development process.
Retrospection & Learnings
After we had run a beta test with our fellow students and friends we were convinced that the idea behind Pendlr has a big potential. We proved to ourselves that we were able to execute good design and development in a good amount of time.
Non the less we realized that we decided to go with the wrong concept approach in the beginning. The Data in our beta test showed that people are enthusiastic about using Pendlr but hard to convince to go through the whole checkin process every time they changed the train. In retrospect we should have taken the time to design and implement the routing centric approach as a solution. Though, we think with the knowledge we had at the time it was the best decision.
Even though, we were very close to shipping the product, we realized that our approach only works with a very small target group and put the project on hold. Anyway, we learned a lot about creating a mobile app from start to finish.
Also, we learned a lot about what we have to improve for future projects: Mostly we have to clearly define goals and responsibilities, and be more strict about removing features from a concept to be able to test basic functionality early on.
We are very happy about how our design process has worked out. The close connection between design and development has proven to be a successful way to implement a new product in a small amount of time and to iterate quickly. Dominic and I still use a similar approach to our Design process while working on our projects or work for clients at Craftwerk.io since then.