Extensive research has shown that one of the problems that NS-stations experience is users take the bike keys by accident. This happens about 2,000 times a year and renders the bikes useless because they have to be taken out of circulation. This costs a lot of money. To solve this problem, the NS developed a smart lock. This smart lock makes it possible to unlock the bike with your OV chip card instead of with a physical key. During the development of this smart lock, the NS asked INFO – since we are NS-stations’ partner – to chart the changes that are happening within the service. This way, we’ll make sure that the customers will continue to get the best possible service. 

The assignment was to research what users think of the service as it is now, what the smart lock’s impact is and how we can improve it. Through user research and the use of service design methods, we were able to chart this and were able to define a minimal viable product (MVP) that adds to the experience of the OV-fiets users. We built the MVP and, in combination with the pilot of the new smart lock, tested it with actual users. 

But where do you start? In order to solve this problem during the research phase, INFO chooses to use the same methods that service design also uses. Service design helps with defining the problem, mapping out the context, and involving the right stakeholders without immediately coming up with a (digital) solution. The phases that we always go through during such a project can be found in the Double Diamond Model: Understand (discover and define), Design (develop and deliver), and Implement (build). 

Double Diamond Model

Understand

1. Discover: the ecosystem, trends & competitors

During previous projects, INFO already looked at the current ecosystem and the corresponding services that OV-fiets offers. The conclusions that we have drawn together with NS stations were based on the results of this study and were the jumping-off point of this follow-up study in which the introduction of the new smart slot played a major role.

During the follow-up study, we first looked at the different competitors and trends within the market. This way, we were able to define the OV-fiets’ strengths and weaknesses. Because of the explosive growth of the popularity of the OV-fiets, various new and comparable services have come into existence. That is why we also included Swapfiets, Felyx, Keobike, Urbee, and Bobike in this analysis. 

In order to get a better picture of the OV-fiets user’s customer journey, we have used different research methods. First of all, we observed the customer service and several rental locations to gain more insight into the work that they do and the types of questions that customers have. We also interviewed a couple of different stakeholders that previous research identified in the stakeholder map. 

2. Define: Customer journey co-creation session

Twice, we organized a co-creation session with several stakeholders within NS stations. These sessions are also called design studios. Based on the data we gathered and the research we did, we defined six personas that could be used during the brainstorming parts of the design studios. These personas served as an inspiration and the jumping-off point for the needs of the various OV-fiets users.

OV-fiets personas

During the first design studio, we used the personas to identify the different needs of customers throughout their customer journey. A distinction was made between before, during, and after the ride. The themes that this first design studio revolved around were: general information, frequently asked questions, availability, subscription checker, and personal (user) information.

With the second design studio, we used the personas to map the different perspectives per topic. If we, for example, zoom in on being able to check the availability of an OV-fiets before a ride, we see different types of needs emerge (see image). For these needs, we have devised and clustered solutions, based on the “how-can-you” method. In most cases, the solutions could be divided into three categories: digital solutions (app shows availability), physical solutions (signs on the stations that show the availability), and contact (call the customer service). 

We used all this input to create a customer journey that connects to how people actually use the bike and the new service. In the complete customer journey, we have made the distinction between the “happy flow” and the “unhappy flow”. Eventually, we summarized all the pain points and created a service blueprint of the value that an MVP will add to this service. 

Painpoints OV-fiets user during introduction new smart lock

Design

3. Develop: prototyping

During the first stages of the development of the prototype, we again looked at the pain points that were identified during the research. This showed that the “pain” can be removed through:

• creating qualitative and consistent content. Streamlining one story/truth that can be used in multiple outlets is an important part of this;
• better structured questions and answers. The frequently asked questions section was an essential part of the prototype that was eventually validated with customers;
• more insight into the ride and clarity about whether or not you can rent a bike.

Before we started building, we made multiple iterations concerning the design of the prototype and the different functionalities. The different stakeholders were closely involved with the design process and shared their feedback, which made fast iteration rounds possible. 

Design OV-fiets Service app

4. Deliver: testing

Together with NS stations we also organized some user tests where different (potential) users between 22 and 70 years old had to perform tasks within the prototype. The assignments the participants were asked to complete were aimed at validating the use of the prototype for the various options offered by the OV-fiets service.

As mentioned, our test panel consisted of a wide variety of people of different ages. This led to interesting situations where the mobile app sometimes posed a challenge. Using texts and visualizations, we worked on better explaining the service and the functionalities of the prototype for the next iteration. In addition, various developers did multiple checks during the development of the prototype to see what was technically (im)possible. 

One of the main functions of the prototype was the possibility to request a bike number. With the introduction of the new smart lock, the physical keys with keychains (that had the bike’s number on it) were rendered obsolete, which made it hard for users to see which bike was theirs. To provide the users with this information, we wanted to use an NFC reader, which is now standard on new phones. The phone could then, with the use of the OV chip card, provide the user with the desired information. 

The OV-fiets is, as we saw during the user test, an inclusive service, which means that it’s paramount that everybody can use it. Because of this, when choosing the technology and a platform, we preferred to create a Progressive Web App as a prototype. However, we found out soon that Progressive Web Apps don’t really support NFC technology that well yet. Because the prototype is now only used as support for the pilot, we continued building a mobile app for Android devices. 

Painpoints resolved with MVP

Implement

5. Build: MVP & pilot

In the end, we built a couple of features for the MVP. For example, people could now view their rides, they had insight into their subscription and which specific bike they rented, they were able to check locations and opening hours, and report bike defects. Streamlining and structuring content wasn’t really important at this stage: together with NS stations, we decided to first test other functionalities in the pilot, where the prototype could have a facilitating role for the users that came into contact with the new service and the smart lock. 

MVP OV-fiets service app

The pilot is run at the beginning of 2020 for approximately one month in Apeldoorn, the same place where the OV-fiets with the smart lock were introduced. In the meantime, we are recruiting more potential participants and are gathering more data and feedback. This is to continue to learn together with the NS, to iterate if needed, and to continue to improve the service. This way, the service for OV-fiets users remains optimal while the NS innovates together with us.