Designing for hybrid solutions
The challenge brought to us by the city municipality of Porto, as part of the European Commission initiative, EMBERS, was to provide a better service to citizens when driving to and from the city center, avoiding traffic congestion and wrongful parking, which, in consequence will mean a decrease of pollution both environmental and sound wise to the city center.
EMBERS is an EU-funded project under the Horizon 2020 program. The core of the project is to prepare a smart city mobility platform, called the Mobility Backend as a Service (MBaaS), for market. Central to this effort is the demonstration that the MBaaS can meet challenges posed by three cities.
This challenge would translate into a mobile application which should provide an easy way for citizens to find parking near a point of interest and a simpler method of payment. As a first approach the team worked on a Design Sprint to better understand the problems we would be facing and the opportunities that could arise from such an application. In terms of User Interface, our aim was to create a minimalist and pleasant interface relying on well-known design patterns, typography and illustration.
The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.
Understanding the problem
We started by analyzing the functional specification and the main problems presented, tackling business goals, constraints and opportunities. From there, we individually collected questions, concerns and final goals which were, then, collectively chosen. Below you can find the main goal and sprint questions selected.
“To provide a friction less way to park in the city, reducing traffic, pollution and stress” — Main Goal
“Can we make sure drivers will change their behavior when using parking lots? Can we provide enough value?” — Sprint question
User Research
The functional specification, provided by the municipality, already presented a brief exposure to our direct and indirect users and their specific needs. After a field analysis at the parking garage we came up with the below segments:
- Frequent: citizens with specific tasks in mind and a time frame;
- Casual: citizens with a specific task but no time frame;
- Tourists;
- Subscribers: local commerce owners; city hall workers; citizens who live around the park area.
We created several user flows to better understand each segment’s steps in order to reach the end goal of parking their car immediately, completing their tasks and leaving the garage in a swift manner.
As an outcome, we decided to focus on the booking feature, which was translated into specific user behaviors to test:
Do users see the value of booking ahead?
Would the users be willing to pay a booking fee?
Do users understand how to use a QR code to check in and out of the parking garage?
Our first field research led to a fine tuning of the user segments we had previously created and the definition of the actual personas. We developed an interview script based on user behavior patterns observed and the second user interviews process was very successful and also validated our assumptions regarding the user needs and goals.
Prototype and Testing
We developed paper prototypes as part of the final steps of our design sprint in order to design features and interactions that would answer the sprint questions and achieve the final goal. The outcome consisted of a well thought user journey with the features and interactions needed to guide the user.
A very quick prototype was designed in order for the team to test with real users.
Learn from feedback
As an outcome of the user research and testing we were able to identify user needs and expectations and compile them into lessons learned and opportunities to pursue:
- Users expect to find the parks near the destination through the map;
- Information on expected occupancy level is generally seen as useful;
- Users are comfortable with paying a booking fee and with it being non-refundable in case of a no-show;
- The function of the QR code was understood by all the testers.
Opportunities
- Add information about real-time availability and cost on the map. Cost is an important decision factor for the users of this park.
- Clearly separate the app section for finding and comparing parks and booking.
- Explore ways to get more booking (discounts for longer stays, points for frequent users, etc).
- Tell users the exact parking spot they booked.
- End the booking experience with an optimistic and rewarding feedback.
The software development team at bitmaker decided to use Google’s Flutter, a hybrid platform which allows for the release of both iOS and Android applications without the need for replication.
In terms of design this meant that we would be using patterns which should be intuitive for both Apple and Android users. You can find out how we did it on part 2 of this article.
The design sprint process was made in collaboration with The New Digital School and we would like to personally thank Miguel, Jamie and Lena for all their hard work and initiative and a special thank you to Sara, the facilitator who always gave us focus and direction.
This is a three part article sharing how we developed a mobile app with Google’s Flutter. Please read part two, explaining the design system we chose, here: Part Two
