As we’re living in the era where digital applications and platforms make our lives a lot easier it is essential for businesses to follow up the mainstream pace in order to stay on the market and tailor their services towards the user's needs and bring out modern solutions to their everyday problems.
In this case I worked together with a tech company from Netherlands, Flying Fish Tech on a development of a water transportation solution that has a goal to help people use water transportation services in a very fast, reliable and easy way.
Development of this particular product was inspired by a similar product on the market that provides services but for a different type of transportation like Uber and NS app as currently there aren’t any similar products that provide these kind of services for water transportation.
This project was contract based and had a time limit of 3 months to be completed. For the time frame of 3 months we were supposed to build the MVP that will have the most important features so it can be presented to potential stakeholders as a working solution.
I was honored to work side by side with genius young developers and aerospace engineers on realisation of this project: Thore Roepman, Chiel Bruin and Gerben Schonenbaum. We had great support from the rest of the Flying Fish team during the process so I want to say big thanks to all of them as well.
The product owner had already an idea how the product should look and behave in three months but we as a team had hands free for any other ideas that might work better in this case.
My role as a UI/UX Designer was to conduct user research, create user personas, build wireframes and prototype that will be used for user testing in later stage of the product development.
Like mentioned above, the product was built for wider audiences with ability to be customised and tailored for different cities and countries but the primary focus was to build the product that will serve the local community.
I was provided with existing data from the potential stakeholders that would be interested in purchasing the product in the early stage of the project, Water Taxi Rotterdam. As the data is confidential I’m not able to provide any numbers in this study. This information showed us how their business operates right now and there was a clear vision of how this product we’re making will improve their business and deliver even bigger value to their services.
First step in the research process was to reach out to current and potential users of water taxis and find out why do they use their services in the first place and how do they feel when using them, are there any problems that they encounter in the process and what are good/bad things that happened to them when using these services.
I used google forms and made a short survey with questions that will help me create user personas later on:
Based on the answers from the survey I could find out that 70% of the participants have used the water taxi services already and had a great experience regarding the ride itself but had some issues with waiting for the taxi to come and not knowing where and which taxi would come to pick them up.
Some of them also had issues with where they will be picked up and dropped off afterwards.
One of the participants said that the payment method was unclear and the card payment too slow and that the booking process was unclear and outdated.
For suggestions of improvement of their services participants wrote about making the payment more easy and variable, better accessibility, booking via an app or through google maps on their phones and being able to see which boat they are boarding and where the boat is.
Besides the information I gathered in surveys I also swiped through the WTR user comments on google and tripadvisor. There I could find valuable insights about how people felt when using water taxi services, what they were frustrated about and what did they really enjoy:
2/5
Great way to travel around Rotterdam, but not very customer-friendly service. We were boarding at station 44 (depot), where many other tourists were walking around being confused as to where to board. Nobody from the staff present bothered to explain anything (except just telling people to wait outside); reception ladies were simply nasty brushing people off.
2/5
The service is quite straightforward, very reliable and the staff was in general helpful and easy going. The location can be shown a bit better as it was not very straightforward to be found, especially for people not familiar with Rotterdam.
2/5
Had a great ride the first time round, but for the second time my ride didn't arrive, even after 45 minutes waiting and two calls to check and reconfirm the booking. Sort your service out guys!
1/5
Not reliable, terrible service. Arriving first on the pier, was told on phone the wait would be max 30min. Waited more than an hour, called 3 times. All taxis served other customers, none of them were helpful when we were asking guidance. Sadly unless you are a local, don't count on it, you're better off walking or calling a taxi.Worst service company ever. Terrible customer service. Unreliable. Terribly late for a concept called taxi (promised to be in 15min but arrived in 40mins) don't waste your time trying it.
1/5
If you don't speak the language here, don't ever try, been waiting for an hour by the Euromast and no taxi for us when ordered by the phone. However another 2 taxis appeared to pick up someone else. Unreliable, no real customer service.
For today (2-7-2016) at 18.30 a water taxi was ordered via the website, (Stormpolder-SS boat Rotterdam and return) 3 days ago.
Wait today at 18.20 to 18.35.
Just called to you, where we were told that the reservation did not come through ... oh yes .. June 13 they had sent a confirmation …
Great if we only book 2 weeks later.
Unfortunately we could DISAPPOINT our friends who had come over from America! to share this "seemed to us" fantastic experience.
Find the BUT!
4/5
Nice & fast. Planning & scheduling messy. Nice place this, near Hotel New York, Hoerenloper, Katendrecht.
These valuable insights helped to raise some “how might we” questions so at the end of the first sprint we had a meeting where we discussed the main features of the app and what we should focus on building in the next 3 months.
1. The first question was, how might we improve the current booking flow ?
2. The second question was, how might we provide accurate information about the arrival of the taxi, dock location and vehicle identification?
Before these questions were to be answered in the next sprint I had a task to create user personas that will serve as fictional guides in the further app development.
After completing the first phase of research based on current and potential users of water taxi services I created user personas from the information I gathered.
As there was no question about the user gender in the survey because it wasn’t something that was really relevant to this phase of development I assumed that female users would have a bit more advantage when using the water taxi services than males so I created two female personas and one male persona.
What I was able to find out through survey is that there were three main groups of users:
-Locals that live and work in the Rotterdam area
-Local and international students that live and study in the Rotterdam area
-Tourists and international business people that often visit Rotterdam for business or pleasure
From these three groups of users I could identify similar pain points and frustrations when they use the water taxi services.
These three personas clearly point to the main problems that the app should deal with:
1. Working and accurate booking system
2. Good and reliable payment system
3. Clear explanation of boat arrival and its exact location
In order to determine the base for decision making in this stage of the project I created a user journey map.
This map is created based on the early feedback from our product owner where the potential clients referred to the “local people” as their main target users.
I focused on Lui as he represents this group of users and the whole journey refers to him.
The scenario:
Ordering a water taxi service in order to cross the river as fast as possible so he doesn’t come late for work.
Story:
When not using his bike to go to work, Lui likes to combine public transportation in order to reach his office. He leaves his home a lot earlier as he is aware that some delays can happen when switching transportation so he wants to be sure he will be on time for the morning meeting.
Lui catches the bus near his house and travels for 30 minutes until he reaches the transfer destination. Here he needs to cross the river as fast as possible but reaching the bridge would take him more time than he has so he likes to use water taxi as this is the fastest way across the river. While he was still in the bus, Lui called the water taxi central to book a ride and he was told that the boat would wait for him in the spot at the arranged time. When Lui reached the dock, the taxi wasn’t there so he had to call the service center to ask about the booking.
In the meantime the taxi arrived but Lui was told that this wasn’t his taxi and that he cannot travel with this one. Lui’s frustration builds up as he’s already lost a lot of valuable time and he is afraid that if his taxi doesn’t show up he will not make it on time to the office.
Finally his taxi arrives and he goes across the water. In all of the hurry Lui forgot to bring cash from the house and he was equipped only with his card and because of the very slow payment process in terms that he has to pay for the ride after, it took him extra time and he was late for the meeting for 5 minutes. This made Lui very frustrated and he is considering if he will ever again use the water taxi service.
Lui’s intentions:
- Trying to reach his office in the shortest time
- To combine multiple transport services (bus & water taxi)
- To schedule the water taxi while on the move (in a bus)
- To be sure that he will make the connections on time and will not have any delays
Goals and expectations:
- To get to work on time for the meeting
- To book a water taxi ride while still on the bus
- To be able to pay the ride with his card
These insights helped to determine how the app we’re building would affect Lui’s from home to work flow in a better, faster and more reliable way than it is right now and resolved with some main opportunities:
- To replace the current booking over the phone with a booking over the app
- To show the real time information about the booked trip
- To add a possibility to pay for the ride upfront through the app
After presenting the user journey map to the team we had a brainstorm session where we were supposed to re-order the user stories we’ve made in the beginning in that way that they follow the main feature which was replacing the current booking system over the phone/website with the booking through the app.
This was our starting point and main feature of the app so it was important to focus on this first.
In the next sprint my goal was to create a few simple booking user flows from where I will be able to start drawing low fi wireframes and present them to the team.
Before starting any wireframing we had a meeting to discuss both of these booking flows and discuss what would be fit as a better starting solution.
In the first booking flow we noticed that there is an extra step with the positive and negative time frame responses which could make the flow a little bit longer but on the other hand, leaving the user without a clear explanation in the process and having him to pick one of the already suggested trips like in the second booking flow, might cause a confusion in the booking which would relate to negative user experience.
This is why we decided to go with the first booking flow and I started creating wireframes from here.
The first step in creating low fi wireframes was to roughly scketch out the ideas on a paper with most important elements that will make the booking flow simple and functional.
Because the team was working very fast on this project regarding to the limited time frame we had, the largest part of the project development was lead with the high fidelity wireframes. This means that for all of the additional features I are based on the high fidelity designs from the booking flow.
All of the layout iterations were first made on the booking flow screens and later on updated on all of the other screens to keep up the consistent look and feel of the app.
The interesting note to mention is that when we were on the half way of the project we got to present the Water Taxi Rotterdam owners the first prototype and share our ideas.
A great success happened after we received their feedback where they decided to buy the product and involve themselves in the finalisation of it. This meant that we were on the right track from the start and that the app will be able to be tailored to their current needs until the end of the project.
In the first draft of the high fidelity wireframes I designed for the Iphone 6/7/8 screens. With this layout developers were ready to start implementing the code and the project was getting it's shape. We decided to wait for the first code draft and to test the layout in order to see what can be improved.
The first problem was noticed in the "arrival and departure" fields. They were too short for the ammount of text that was supposed to live in there as the primary language of the app will be Dutch and words on Dutch are much longer than on english. This required a better revised solution.
The second problem was noticed in the "adults and children" box fields. The "+" and "-" were too small and would mess up with each other when used so I had to create a different solution.
The third problem was noticed in the suggestions screen. It was showing only two suggestions without any aditional information about them which would be a problem in the future as the Water Taxi has more than 50 different locations that can be suggested and many of these are really close to each other. This meant that I need to create a solution that would show the user a better information about the suggested for the chosen time frame.
With the second draft there were already big improvements in the design as well as functionality. In addition to existing screens I started designing other features such as time and date picker. We switched from the english version of the app to the dutch version so we could present it to the Water Taxi owners in their native language.
In this revision I designed layout with larger "adults and children" pickers that have more space between "+ and -" so it doesn't interfere with each other. Made the "departure and arrival" location on the same side one below each other which gave more space for the longer dutch words and for the suggestions I created a card style options that hold all of the important information about the suggested trips such as price, duration time, start time and boat type.
Before we scheduled another discusson about the layout we had a meeting with WTR owners and we presented them the current design. The feedback we got was aimed more towards the native look and feel of the app with the focus on larger map.
This resulted an iteration based on the placement of the elements in the layout and how to place them so the map gets more space. The large map wasn't an issue on bigger screens but we had to think about the users that use smaller or older types of phones, for them it would be hard to interact with the map because of the lack of space.
The second problem was that the suggestion screen did not show any map at all and I had to find a solution to fit the map in there and to clearly show the first two most related suggestions.
The third problem was the time and date picker. Even if it was designed in a simple way, for the WTR owners it was a bit of confusing so they desired a more iOS native picker design and I had to create this as well.
The fourth problem was that the WTR owners wanted to show all of the available dock locations on the map but witouth making the icons overlap each other. This was something to think about and implement in the next draft.
In addition to these problems, in the WTR feedback there was a desire to implement native feel of the trip details screen, something like the google maps, as they were interested to show the users walking route towards the taxi dock locations in which way the booking would be available by typing not only the dock name but the real time current location of the user.
There were a lot of changes in the third draft, starting from the booking screen layout.
I made some more space for the map by removing the header bar completely and placing the menu at the bottom. Now the bottom navigation bar included the links to the primary destinations in the app which are booking screen and trip history.
The location fill in fields were designed a bit wider and the "departure and arrival" were swaped with "from (Van) and to (Nar) which made space for the longer sentences. For the children and adults pickers I removed the text and replaced it with icons that clearly represent what the field is used for.
The time and date picker was inspired with the iOS native picker but designed in the WTR brand and adjusted accordingly to the app identity.
The pre confirmation screen with trip details got a new look as well. It was inspired with google maps design and now felt a lot more native and understandable for the users.
The unavailable time frame screen with suggestions got a new, simpler and more modern look that doesn't take too much space with the information details but cover everything the previous one had. The map was inserted in to this screen as well.
The small blue dots in the map show the other WT docks and get bigger as the user zooms in the map.
Also, the place holder icons were replaced with new and more geometric and balanced ones.
These changes were presented to the WTR owners and were accepted with excitement. In a really fast time frame we received one more round of feedback and had to adjust some minor details.
With the final interface draft we had all elements ready for to finish the MVP.
The small changes in the layout refer to the header bar that was removed in every screen where the map is showing. This way I created even more space for the map so the users can have a better experience while interacting with it.
We added live location suggestions when users are typing from where are they going and where are they going to.
As there was just less than a month left to develop the MVP fully we had some space to add some aditional features so we made a list of the features that were possible to make in less than a month and sent that to the WTR owners.
The additional features from the last WTR feedback are represented in the prototype.
In addition to all existing features for simple booking the users can now see their current, upcoming and past trips and can create an account. At first the WTR didn't want to have an account feature but we managed to convice them that this is a must to have if they want to improve the payment and booking system for their services.
For now the payment system works in that way when someone books a ride, they get a confirmation e-mail with their booking which they would show to the taxi captain and than pay for the ride. It is not the perfect solution but it works.
The simple prototype was used in the internal testing purposes before the screens were developed further.
Results were good, showing 90% success rate with the participants where only one minor problem occured.
The problem was at the sign up process where some older users couldn't resonate what's written in the text fields with the bright gray color so I darkened the fields and the text.
This is as far as I went with the project regarding to the MVP. I have created screens for more features as I was constantly ahead of the development team so I had time to focus on the next steps of the project.
This project's biggest challenge was to create a fully functional MVP in just 3 months. I was able to overcome this by communicating and brainstorming with my team on a daily basis so we were able to determine what will be the most important features to develop in this time frame.
Our final design was successful and that was determined by very positive feedback from the WTR and their excitement to launch the product after one more series of user testing that will be performed with their trusted users.
During the project I worked on user research, user testing, wireframing and prototype design that was evolving constantly. The development of the app was in the hands of a very talented and genius duo Thore Roepman and Chiel Bruin who I worked very closely with.
The project is still not launched and is currently in the last testing phase. Before my job was done I created a testing guide for the WTR owners and management team so they can conduct the testing internally without any third party included.
Once again I want to mention that It was a great honor to work with Thore, Chiel and Gerben and with the other Flying Fish Tech team members as well. Special thanks to Gijsbert, Tim, Renzo, Jaime and Kees!
