DEDICATION

I dedicate this modest piece of labor firstly to the Almighty, then to my family and friends.

A first thank you to my parents Hichem and Sarra, whose words of encouragement and push
for tenacity ring in my ears. A special feeling of gratitude to my loving wife, Arij, my first
partner in this project and my second hand in all decisions. A thank you to my parents in
law Kamel and Rayda for their encouragement, presence, and kind words. My brother and
sister, Ahmed and Imen , and brothers and sisters in law have never left my side and are very
special.

I also dedicate this project to my many friends who have supported me throughout the pro-
cess. I will always appreciate all they have done. Especially my friends from Google Club,
I Rise association, Weare Moon, and InstaDeep for helping me develop my hard and soft
skills.

A thank you to everyone that stood by my side and to everyone that I love. No words are
sufficient to thank you all.
ACKNOWLEDGEMENTS
First of all, I wish to express my sincere gratitude to my supervisor Mrs. Feyrouz HAMDAOUI
for the guidance and freedom she granted me to experiment, and for the continuous support
and push for excellence.

I would also like to thank Dr. Nabil BELGASMI for his huge support and for opening my eyes
to many possibilities, which incented me to widen my research from various perspectives.

A thank you to Dr. Malek BEN SALEM for the insightful questions and tips he offered during
the pre-defense.

Last but not least, I want to acknowledge and thank my school division, and every teacher
that motivated me and helped me reach this position during this academic period.

A sincere thank you to each and everyone.

“Design is not just what it looks like and feels like. Design is how it works.”

— Steve Jobs
 TABLE OF CONTENT

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

General Introduction 13

1 Project Presentation 16
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 InstaDeep Ltd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3.1 The Why - Presenting the Problem . . . . . . . . . . . . . . . . . . . . . . 17
1.3.2 The How - Solving the Problem . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.3 The What - Presenting the Solution . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4.1 Few Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4.2 Used Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2 Requirement specification 21
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 Review of the existing competitors . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.1 Commercial competitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.2 Comparison of the existing Commercial products . . . . . . . . . . . . . . 25
2.3 Preliminary Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.1 Identification of Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4
 2.3.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.3 Non-functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 UX and Market Research 27

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 UX Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.1 Persona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.2 User Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.3 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.4 User Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.5 Wireframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3 Business Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.1 Business Model Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.2 Revenue and Fees Breakdown . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4 Brand and Product Design 37

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Branding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.1 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.2 Typeface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.3 Color Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.4 Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Product Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.1 Design System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.2 Screens from the Final Design . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Implementation 43
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Technology and Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.1 Front-End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.2 Back-End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.3 Payment service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.4 Development and Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.5 Version Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Page 5
 5.3.1 State Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3.2 UML Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4 Final Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.4.1 Worth Mentioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.4.2 State of the code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.4.3 Screens from the App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6 Testing 54
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2 Unit Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2.1 Testing Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2.2 Tools and Libraries Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2.3 Benefits and Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.3 Usability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3.2 Extra Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

General Conclusion 58

Page 6
 LIST OF FIGURES

1.1 InstaDeep logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2 BioNTech logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 Waterfall x Design Thinking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.1 SpotHero Logo and screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 EasyPark Logo and screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 ParkWhiz Logo and screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 SpotAngels Logo and screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5 Passport Parking Logo and screenshots . . . . . . . . . . . . . . . . . . . . . . . 24

3.1 Persona Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Typeform logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Survey Result Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Survey Result Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5 Survey Result Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6 Diagrams QR Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.7 Simplified Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.8 General User Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.9 A few Wireframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.10 Whimsical logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.11 Empty Business Model Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1 Satoshi font . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7
LIST OF FIGURES

4.2 Color palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.3 Drafts and rejected propositions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Termus logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5 Figma logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6 Design System Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.7 Screens from the UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1 Flutter logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2 Firebase logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 ClicToPay logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4 Android Robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.5 Android Studio logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.6 Git logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.7 GitHub logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.8 Entity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.9 Payment sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.10 Booking sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.11 Screens from the app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.1 Hotjar logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.2 Heatmaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Page 8
 LIST OF TABLES

2.1 Apps Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Use case description table (Client part) . . . . . . . . . . . . . . . . . . . . . . . . 30

5.1 Entities description table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2 Relations description table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3 Firebase tools worth mentioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.4 Flutter packages worth mentioning . . . . . . . . . . . . . . . . . . . . . . . . . . 51

9
 ACRONYMS

API Application Programming Interface. 45

B2B Business To Business. 34

B2C Business To Customer. 34

e.g. Exempli Gratia (for example). 18

IT Information Technology. 18

JSON JavaScript Object Notation. 50

Ltd. Limited. 4, 16, 17

MENA Middle East and North Africa. 18

MRR Monthly Recurring Revenue. 35, 36

MVP Minimum Viable Product. 14, 26

MVVM Model–view–viewmodel. 47

NoSQL Not Only SQL. 50

SDK Software Development Kit. 55

10
Acronyms

SEO Search Engine Optimization. 38

SVG Scalable Vector Graphics. 51

TND Tunisian Dinar. 35

UI User Interface. 15

UML Unified Modeling Language. 47

UX User Experience. 14, 19

WCAG Web Content Accessibility Guidelines. 39

XP Extreme Programming. 18

Page 11
ABSTRACT
This work is part of the final graduation project presented for the computer engineering de-
gree. The main objective of this project is the creation of a mobile application for parking spot
discovery and reservation. We went through different phases, including research, business,
design, and development. We adopted a custom methodology and structure that suited the
tasks we had in hand and the time constraints.

Keywords: Parking reservation, UX Research, Market Research, Branding, Product Design,

Android, Flutter, Firebase, Testing

RÉSUMÉ
Ce travail fait partie du projet de fin d’études présenté pour le diplôme d’ingénieur en infor-
matique. L’objectif principal de ce projet est la création d’une application mobile de décou-
verte et de réservation de parking. Nous sommes passés par différentes phases, y com-
pris la recherche, les affaires, la conception et le développement. Nous avons adopté une
méthodologie et une structure personnalisées adaptées aux tâches que nous avions en main
et aux contraintes de temps.

Mots-clés : Réservation de parking, Recherche UX, Etude de marché, Identité visuelle,

Conception de produits, Android, Flutter, Firebase, Tests
 GENERAL INTRODUCTION

O ur dynamic, rapidly evolving world, makes it critical to combine business, product de-
sign, and engineering for innovative problem-solving. This interdisciplinary approach pro-
vides the tools to address a wide range of societal challenges. However, in Tunisia, the
integration of these disciplines is still in its nascent stages, often resulting in sub-optimal ex-
periences for users. Many attempts to create solutions lack a strong focus on quality, leading
to products and services that fall short of their potential and often struggle to achieve long-
term success.

By this project, we aim not only to provide a polished product, but to inspire a shift in paradigm.
Our goal is to demonstrate that a commitment to quality, coupled with the effective blending of
business mind-set, design thinking, and engineering skills, can result in products that are not
only commercially viable but also offer superior user experiences. We hope this project will
serve as a catalyst, encouraging others to prioritize quality and interdisciplinary collaboration
in the quest to solve complex, real-world problems.

About the Project

The intersection we just discussed of business, product design, and engineering, can unlock
novel solutions to some of our most pressing societal challenges. One such issue is city
parking, a seemingly mundane, yet critically important aspect of urban living.

In this era of rapid urbanization and constant movement, the simple act of finding a parking

13
General Introduction

spot has escalated from a minor inconvenience to a significant challenge. It is a problem felt
daily by millions of people around the world, Tunisia included, and has substantial implications
for urban planning, environmental sustainability, and quality of life. Yet, despite its ubiquity,
this problem also represents a latent opportunity: to transform a widespread nuisance into a
streamlined, efficient process, and in doing so, create value for both individuals and society
at large.

This project explores the development of an MVP designed to address this problem. Our solu-
tion is not simply about creating a useful tool; it’s about crafting an experience. An experience
that blends the principles of business strategy, innovative product design, and cutting-edge
engineering to not only solve a problem but to do so in a way that is user-friendly, efficient,
and profitable.

The Motivation behind the Project

The genesis of this project extends far beyond its function as a requirement for graduation.
Rather, the concept for this parking solution has been brewing in my mind for a considerable
time. It was born out of personal experiences, and observations of my surroundings.

We have all experienced the frustration of finding a parking spot - from the business pro-
fessional running late for a meeting to the parent struggling to find a parking spot during the
school rush hour. The more I witnessed these scenarios, the more I was convinced that there
must be a better way. This conviction was the spark that ignited the development of our park-
ing solution. Moreover, I see a distinct potential for this product in our market. Unlike some
other countries where similar solutions might exist, Tunisia and North Africa still have a signif-
icant gap in this domain. This gap is not just an opportunity for a successful business venture
but also a chance to significantly improve the day-to-day lives of countless individuals.

By choosing this as my graduation project, I am not just fulfilling an academic requirement.

I am taking the first step towards turning a long-held idea into a reality that could have a
meaningful impact on society and potentially pave the way for a hopefully successful en-
trepreneurial venture.

Project Structure
Our project will adopt a comprehensive, step-by-step approach that ensures every aspect of
the mobile application is thoroughly planned and executed. We will start with a UX study to
understand the needs, behaviors, and expectations of our potential users. This UX study will
guide us in crafting an app that is not only functional but also user-friendly and intuitive. Fol-

Page 14
General Introduction

lowing this, we will conduct market research to gain insights into the competitive landscape,
market trends, and potential opportunities. This research will help us identify our unique sell-
ing propositions and make informed strategic decisions. Next, we will delve into the branding
aspect of the project. This involves creating a brand identity that resonates with our target
audience and stands out in the market. With a clear understanding of the users’ needs and a
solid brand identity, we will then proceed to the UI design phase. In this stage, we will focus
on developing an aesthetic and interactive design that aligns with our brand and enhances
the overall user experience. Once the design is finalized, we will move into the development
phase, where our ideas and designs will be transformed into a working mobile application.
The final phase of the project will involve rigorous testing to ensure the application performs
as expected, is bug-free, and provides a seamless experience to the users. The insights
from testing will be used to fine-tune the app, ensuring it is market-ready and positioned for
success.

Page 15
 CHAPTER

PROJECT PRESENTATION

Contents
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2 InstaDeep Ltd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3.1 The Why - Presenting the Problem . . . . . . . . . . . . . . . . . . 17

1.3.2 The How - Solving the Problem . . . . . . . . . . . . . . . . . . . . 18

1.3.3 The What - Presenting the Solution . . . . . . . . . . . . . . . . . 18

1.4 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.4.1 Few Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.4.2 Used Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

16
CHAPTER 1. PROJECT PRESENTATION

1.1 Introduction
In this chapter, we’ll get more into the "Why, What, and How" of the project.

Before the realisation, it is quite essential to carry out a detailed study on certain concepts,
which might affect not only the general aspects of the project, but also its execution. We will
start off by presenting the host company, InstaDeep, mentioning their specialties as well as
their qualities. As for the second part, it will be more dedicated to the core context of our
project.

1.2 InstaDeep Ltd.

InstaDeep was founded in 2014 and acquired by BioNTech in early 2023. It specializes in
creating artificial intelligence products for businesses. The company is known for delivering
AI-powered decision-making systems for enterprises. They have expertise in both machine
intelligence research and concrete business deployments, providing a competitive advantage
to their customers in an AI-first world. The company is headquartered in London, with ad-
ditional offices in Paris, Tunis, Lagos, Dubai, and Cape Town, employing around 300 people
worldwide. [1]

Figure 1.1: InstaDeep logo Figure 1.2: BioNTech logo

1.3 Project Overview

Here, we will present the problems and industry needs that led us to consider this project.
Then we will propose a solution and outline the execution plan.

1.3.1 The Why - Presenting the Problem

Have you ever tried to find an available parking spot on a Monday at 10 am in Tunis? Yes,
good luck. People usually find themselves going out an hour earlier than they need, to catch
a half-an-hour meeting, only in the hope of arriving before everyone else to find an available
spot. I have seen people block other people’s cars, and leave their hand brakes off, so the
person in charge of the building can push the vehicle if needed to fit another one or unblock
someone. This is simply wrong, and it’s bound to get even worse.

Page 17
CHAPTER 1. PROJECT PRESENTATION

1.3.2 The How - Solving the Problem

Today, you can book in advance your place in the cinema, you can book a taxi while still at
home, why not book your parking spot too and get rid of that anxiety? Some companies have
succeeded in doing this, but none in Tunisia nor most of the MENA region, so we have a
fertile territory. The goal is to allow a user to find and book the nearest parking spot to his
location or his destination, pay a small fee until he reaches the spot, then unlock and use it
once there. We’re also giving building owners the chance to monetize free space.

1.3.3 The What - Presenting the Solution

The final product will mainly consist of a mobile application that allows users to quickly find
the nearest available parking spot, book it, so it remains available until they reach it, and
unlock it once they’re there. This app aims to make parking in busy cities hassle-free, and
allow building owners to generate a passive income by granting us access to use their parking
spots for a small fee on each reservation.

1.4 Methodology
Executing any IT project requires the adoption of a specific methodology that guides it through
its various phases. There is no ’one-size-fits-all’ methodology; the most suitable model often
depends on the unique requirements of the project and the team working on it. The following
section will present several potential methodologies and elucidate the reasoning behind our
selected approach.

1.4.1 Few Options

Agile Methodologies (e.g. Scrum, Extreme Programming...)

These are usually the default ’Go-To’ for most teams, and for a good reason. They have been
proven over and over to be effective and assure a smooth project landing.

Agile methodologies are flexible strategies employed in software development. They stress
rapid, incremental product delivery, adaptability, and regular feedback. Scrum uses short
"sprints" for work organization and progress check-ins, while XP emphasizes engineering
practices to boost software quality and adaptability. These methods are ideal for projects
requiring quick delivery and flexibility.

Page 18
CHAPTER 1. PROJECT PRESENTATION

Lean UX

Being in the design field for quite a while, I’m most familiar with this methodology. It encour-
ages iteration and optimization. Lean UX is a user experience design approach inspired by
Lean and Agile principles. It emphasizes a rapid, iterative cycle of design and testing with
a focus on obtaining feedback directly from users. This approach minimizes waste by pri-
oritizing work that enhances user experience and discarding features that do not add value.
By promoting collaboration and reducing extensive documentation, Lean UX accelerates the
design process and facilitates swift adaptation to user needs and market changes.

Waterfall

This one is a classic, and we don’t really hear much about it anymore in this modern age.
The Waterfall model is a linear and sequential approach to project management often used in
software development. It’s structured in distinct stages - such as conception, initiation, anal-
ysis, design, construction, testing, implementation, and maintenance - that flow downwards
like a waterfall. Each phase must be completed before the next one begins, with no overlap-
ping or cycling back. This method is suitable for projects with well-defined requirements and
little to no anticipated changes.

1.4.2 Used Methodology

Each methodology has its own pros and cons, and has a different fit for each workflow. After
studying the available options, we concluded that Scrum was out of the equation, since this
is mostly a solo and personal project. Scrum requires a team and client to get back to after
each sprint. Lean UX seemed appealing at first, but was out of reach since we have a very
limited time frame, restricting the flexibility of testing and iterating. Waterfall may be a good
option, since the project is well structured, and we don’t expect much overlap, however it
could be limiting.

Contrary to what most people think, we shouldn’t stick to a singular methodology when work-
ing on a complete project. We are free to get inspired by the existing, and adapt a method-
ology to our exact needs. Thus, we will be using adopting Waterfall, with a touch of Design
Thinking.

Page 19
CHAPTER 1. PROJECT PRESENTATION

Figure 1.3: Waterfall x Design Thinking

The workflow is mostly linear, as you can see in figure 1.3, following a pre-determined road-
map while also granting us some freedom to iterate and optimize along the way, to assure a
near perfect solution that can be ready in time.

1.5 Conclusion
This chapter helped us better define the project by understanding the root problem, and how
we intend to solve it. We also decided on the methodology that will draw the path of execution
and help is never get lost in process.

Page 20
 CHAPTER

REQUIREMENT SPECIFICATION

Contents
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 Review of the existing competitors . . . . . . . . . . . . . . . . . . . . 22

2.2.1 Commercial competitors . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.2 Comparison of the existing Commercial products . . . . . . . . . 25

2.3 Preliminary Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3.1 Identification of Actors . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3.3 Non-functional Requirements . . . . . . . . . . . . . . . . . . . . . 26

2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

21
CHAPTER 2. REQUIREMENT SPECIFICATION

2.1 Introduction
Indeed, we don’t have much competition in Tunisia, which gives us a great head-start, but we
still need to study how other companies approached this problem, so we can learn from their
experiences and avoid their mistakes. Also, we should be ready to be in direct competition if
we decide to expand out of Tunisia.

2.2 Review of the existing competitors

2.2.1 Commercial competitors

SpotHero

Figure 2.1: SpotHero Logo and screenshots*

* Taken from the Apple App Store

Page 22
CHAPTER 2. REQUIREMENT SPECIFICATION

EasyPark

Figure 2.2: EasyPark Logo and screenshots*

ParkWhiz

Figure 2.3: ParkWhiz Logo and screenshots*

* Taken from the Apple App Store

Page 23
CHAPTER 2. REQUIREMENT SPECIFICATION

SpotAngels

Figure 2.4: SpotAngels Logo and screenshots*

Passport Parking

Figure 2.5: Passport Parking Logo and screenshots*

* Taken from the Apple App Store

Page 24
CHAPTER 2. REQUIREMENT SPECIFICATION

2.2.2 Comparison of the existing Commercial products

Our experience with the mentioned apps was limited since we can’t directly test all major
features (This requires being physically where the app operates and finishing the app flow,
including creating a reservation, driving to the spot, and finishing the payment). We couldn’t
also find detailed reviews that answered all of our questions. But based on our research and
on what the app developers provided, we managed to get some insightful results that we
discuss in table 2.1.

App Availability Ease of Use Pricing Rating*

SpotHero Medium Easy Average 4.4

EasyPark Medium Medium Expensive 4.6

ParkWhiz High Hard Average 4.3

SpotAngels Low Medium Cheap 4.5

Passport Parking Low Medium Cheap 3.7

Table 2.1: Apps Comparison

As we can see, each app has its pros and cons. One common flaw we observed in all apps is
how they all try to mimic the real-world parking experience, which may sound logical at first,
but in reality (where we can automate most of the process), this adds unnecessary steps
and roadblocks. Like for example, forcing the user to pick an estimate of how long he will be
staying.

2.3 Preliminary Study

2.3.1 Identification of Actors

• Admin: Will be able to manage all the variables in the system, from the spots to their
pricing and other things.

• Client: Will use the app to find and book a parking spot.

• Building owner (Out of the scope of this project): Will provide the space and will
be able to monitor his earnings.

* Score calculated based on reviews form the Google Play Store and Apple App Store

Page 25
CHAPTER 2. REQUIREMENT SPECIFICATION

2.3.2 Functional Requirements

The functional requirements of our app include the ability for users to find available parking
spaces in real-time within a chosen radius, reserve a parking space, and receive a confir-
mation of their reservation. Additionally, the app should be able to calculate and display the
cost of reservation based on duration and location, provide directions to the reserved parking
space, and manage user profiles, including their reservation history and payment details. Of
course this is open to change and improvements once we do the actual UX study that will
give us the exact use cases required for this MVP

2.3.3 Non-functional Requirements

The non-functional requirements encompass aspects like performance, where the app should
respond quickly and operate smoothly under varying levels of user load. Security is also
crucial, with the need for secure user authentication and data encryption to protect user
information. The app should be user-friendly, with an intuitive interface and easy navigation.
Lastly, the app should be reliable and available 24/7, with minimal downtime, and scalable to
support an increasing number of users and parking spaces. And based on what we discussed
in table 2.1, we aim to get an "Easy" rating for the ease of use, "Average" rating for the pricing,
and we don’t mind a "Low" rating for the availability as we don’t plan on targeting multiple cities
at the time-being.

2.4 Conclusion
Our review of existing competitor apps has provided valuable insights about the current mar-
ket landscape. Armed with this knowledge, we are now ready to tackle the design and devel-
opment of our mobile application.

Page 26
 CHAPTER

UX AND MARKET RESEARCH

Contents
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 UX Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.1 Persona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.2 User Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.3 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.4 User Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.5 Wireframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.3 Business Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3.1 Business Model Canvas . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3.2 Revenue and Fees Breakdown . . . . . . . . . . . . . . . . . . . . . 35

3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

27
CHAPTER 3. UX AND MARKET RESEARCH

3.1 Introduction
Before we start dreaming about the design and worrying about the development, we first
need to lay down the foundations for the app. We will start by studying the market and doing
the necessary research.

3.2 UX Research

3.2.1 Persona
Based on our observations and logical assumptions, our user base will mainly consist of:

• People with a quick mission to do (Shopping, Picking up someone)

• People who have a rendezvous at a specific time

• People who work in crowded areas

This helps us create a few personas to capture the general target users.

Figure 3.1: Persona Examples

3.2.2 User Survey

We gathered a few questions that would make it easier to decide on the features. Then we
picked a group of people that fit into our personas and shared the survey with them. We
used Typeform for this phase. The questions range from general to specific. We started
by validating that these people do really struggle from the problem we want to solve, then
slowly steered them to proposing an idea to solve that problem, and finally showed them our
concept.

Figure 3.2: Typeform logo

In the next page we have a few results from the survey (Figures 3.3, 3.4, and 3.5).

Page 28
CHAPTER 3. UX AND MARKET RESEARCH

Figure 3.3: Survey Result Example 1

Figure 3.4: Survey Result Example 2

Figure 3.5: Survey Result Example 3

Page 29
CHAPTER 3. UX AND MARKET RESEARCH

3.2.3 Use Cases

The results we got from the survey helped us validate some of our hypotheses and gave
some insights on what features to focus on. Which can be translated into the use cases
diagram in figure 3.7.

Usecase Description

Authenticate Self-explanatory. For authenticating users.

Search spots near destination To find available spots near a location the client is headed to.

Search spots nearby To find available spots near the client location.

Book a spot Reserve a parking spot for the user.

Monitor parked vehicule Monitor how much time has passed and the current price.

End parking session For when the user is about to leave

Pay parking fees Pay the fees for the parking session based on how long it was.

Top-up wallet Add money to the wallet for quick future payments.

Table 3.1: Use case description table (Client part)

For a better viewing experience, use

this link to Figjam or scan the QR code in
figure 3.6.

Figure 3.6: Diagrams QR Code

Page 30
CHAPTER 3. UX AND MARKET RESEARCH

Figure 3.7: Simplified Use Case Diagram

3.2.4 User Flow

Now that we have the principle use cases outlined, we can map out the user flow in figure 3.8
and fill any gaps the user may encounter when using our app.

Page 31
CHAPTER 3. UX AND MARKET RESEARCH

Figure 3.8: General User Flow

Page 32
CHAPTER 3. UX AND MARKET RESEARCH

As described by the figure 3.8, when the user first launches the app, they are either directed
to the login screen if they are not logged in, or directly to the home screen otherwise. In the
home screen they can either take the main path of finding a spot and booking, or they can
visit their profile to refill their wallet or change some settings.

For the main flow of finding and booking a spot, they need to pick a spot based on the
available ones on the map, book it, once they reach it physically, they will use the app to
unlock the barrier and start the parking session. Once the session is done, they pay from the
in-app wallet and unlock the barrier again to leave the spot.

Alternate flows include: Redirecting a user to refill his wallet if there is no enough money to
pay a balance, and show a message in case there are not spots available at the moment.

3.2.5 Wireframes
Among the final touches in a UX study, is wireframing, where the app finally starts taking
shape, and we can even start user testing if needed. In figure 3.9 we added a few screens
from our wireframes.

Figure 3.9: A few Wireframes

We used Whimsical to create the wireframes. A great freemium tool for collaborative wire-
framing and diagram design.

Page 33
CHAPTER 3. UX AND MARKET RESEARCH

Figure 3.10: Whimsical logo

3.3 Business Model

Our app consists of B2C and B2B parts, the clients that will use the app to find and pay for
parking, and the building owners that will provide the space and get a percentage on each
reservation.

3.3.1 Business Model Canvas

Figure 3.11: Empty Business Model Canvas

Key Partners

Primarily local businesses with parking spaces and real estate companies owning parking
facilities, then municipal or city authorities, potential investors, technology partners for app
development and maintenance.

Activities

App development and maintenance, partnership building with businesses and authorities,
customer service, data analysis, marketing and promotion.

Key Resources

Skilled developers, a reliable app platform, data (on available parking spaces, user behaviors,
etc.), partnerships, funding for operations and scaling.

Page 34
CHAPTER 3. UX AND MARKET RESEARCH

Value Proposition

Simplified parking space discovery and reservation, time-saving, reduced stress, efficient use
of resources, possibly cheaper rates through deals with parking space owners.

Customer Relationship

Maintain relationships through excellent customer service, regular app updates based on
user feedback, possibly loyalty programs for regular users.

Channels

The mobile app itself, a website for information and support, social media for updates and
user engagement, and possibly email newsletters for communication with users.

Customer Segments

City residents who own cars, visitors or tourists with vehicles, local businesses that need
parking spaces for their employees or customers.

Cost Structures

App development and maintenance costs, hardware development and installation, salaries
for employees, marketing costs, costs involved in partnerships, administrative costs.

Revenue Streams

User fees for reservations, partnerships with local businesses (who might pay to reserve
spots for their customers or employees).

3.3.2 Revenue and Fees Breakdown

Revenue Breakdown

Based on our survey, we saw that people are ready to pay an average of 0.050 TND per
minute. If we suppose that we have around 10 active spots available, and that they will be
booked for around 8 hours a day, our monthly recurring revenue would be like so:

M RR = 0.050T N D ∗ 60M in ∗ 8H ours ∗ 30Da ys ∗ 10Spots ≈ 7200T N D

Page 35
CHAPTER 3. UX AND MARKET RESEARCH

Fees Breakdown

As mentioned before, our fees include app development and maintenance costs, hardware
development and installation, salaries for employees... which for the most part are quite hard
to predict in this stage. We have an early draft on the hardware cost though.

300T N D(Bar r ier P r ice) + 200T N D(I nst allat ionsFees) ≈ 500T N D/SingleSpot

Partner Revenue

The equation for the partner revenue is not finalized yet, as we have a lot of pending questions
that wouldn’t be answered until we speak with a few partners. Like will there be a fixed
percentage or will it depend based on the location and importance of the place? Who will pay
for the hardware and maintenance fees?

Currently, we will suppose that everyone will payed equally (30% off of each reservation), and
that they will take care of the hardware fees. This would gives us this result for someone that
will be installing two spots in their building:

M RR = (0.050T N D ∗ 60M in ∗ 8H ours ∗ 30Da ys ∗ 2Spots) ∗ 30/100 ≈ 432T N D

So in less than three months they’d have payed off the fees and started making a profit, with
no effort required from them.

3.4 Conclusion
This part is one of the most dynamic parts of our work, and it needs to be that way. If we
notice any anomalies in the UX or in the business model, they need to be updated quickly,
as they will affect the whole system. Not that it’s a bad thing, on the contrary, it’s very natural
and expected as we grow and learn more about the market and our clients.

Page 36
 CHAPTER

BRAND AND PRODUCT DESIGN

Contents
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2 Branding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.1 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.2 Typeface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.3 Color Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.4 Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3 Product Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3.1 Design System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3.2 Screens from the Final Design . . . . . . . . . . . . . . . . . . . . . 41

4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

37
CHAPTER 4. BRAND AND PRODUCT DESIGN

4.1 Introduction
At this point, we have a clear view of the app logic and how everything is supposed to be. It’s
finally time we start polishing the product. We’re getting close to the final result.

4.2 Branding

4.2.1 Naming
Choosing a name for our product and brand was no easy task. We could’ve taken the easy
road and picked something like "Smart Parking" or "Parkini", but options like these scream
low quality and effort. We wanted the name to be easy and memorable; no more than two
syllables. We also wanted it to be abstract and new, giving it better chances for high organic
SEO.

With the help of AI tools, we generated and went through more than 300 names. Then after
multiple brainstorming sessions, we settled on "Termus". The name is derived from the word
"Terminus", which translates into: The end of the something, which in our case is the end of
the search and the end of a ride.

Amongst the deciding factors were the competition and availability of domain names, we
don’t want to get into any copyright issues, and don’t want to be overshadowed by another
business using the same name.

4.2.2 Typeface
Choosing a proper font is often underestimated, especially by non-designers. While this can
get a pass in most projects, -as the average user won’t even notice- choosing the right font
will add a special touch to the product.

For both the logo and and headings, the font we picked is Satoshi (shown in figure 4.1). A
modernist sans serif typeface designed by Deni Anggara for the Indian Type Foundry. It is
closed source, but free for unrestricted commercial use. [2]

Page 38
CHAPTER 4. BRAND AND PRODUCT DESIGN

Figure 4.1: Satoshi font

For any other case, we will fallback to the device’s default font (San Francisco for iOS and
Roboto for Android).

4.2.3 Color Palette

At this stage, the first thought when picking a color would be: "Parking? Then must be Blue!",
which makes sense in a way, but if want to stand out from the crowd, we need more than the
default. That’s why we opted for a vibrant, eye-catchy orange. It’s easy to spot from far away,
and has an industrial look that we liked.

Figure 4.2: Color palette

A secondary color was chosen too, we picked dark gray, as it works well with orange, and
passes the contrast ratio check for large text and graphical objects with a score of 4.32:1
(Based on WCAG). The color palette and shades are represented in figure 4.2.

Page 39
CHAPTER 4. BRAND AND PRODUCT DESIGN

4.2.4 Logo
We now have most of what we need for a brand identity, but we still have to merge them
and come up with a logo mark, the symbol that will represent our brand and product, which
is no easy task. It took us several hours of brainstorming and sketching to try and different
variations and to mix and match multiple ideas as shown in the figure 4.3

Figure 4.3: Drafts and rejected propositions

We finally decided on the logo in figure 4.4. It is quite simple and distinct. It features the
letter ’T’ for Termus, a dot signaling "the end", and a subtle background pattern resembling a
parking lot.

Figure 4.4: Termus logo

Page 40
CHAPTER 4. BRAND AND PRODUCT DESIGN

4.3 Product Design

This part is one of the most fun parts of the whole process. Now we finally get to see results
from all of the previous work. It’s starting to get easier to understand the concept of the app
and to spot any missing details to iterate.

Our tool of choice for 90% of the design work is Figma. As currently, Figma is by far the best
tool for UI and Product design, according to most designers, including well-known ones from
world-leading tech companies.

Figure 4.5: Figma logo

4.3.1 Design System

A crucial part of each design project is the design system. A well-thought-out design system
assures a consistent and scalable output. A snippet from the system is shown in the figure
4.6.

Figure 4.6: Design System Snippet

4.3.2 Screens from the Final Design

For the design, we used the 8px grid system as it gives us more flexibility then the classic
10px grid, and produces sharper designs no matter the scaling. We also took accessibility
seriously, all design elements pass the contrast check, and most interactive items are placed
in the bottom half of the screen for easy single-hand reachability. A few screens from the final
design are presented in figure 4.7.

Page 41
CHAPTER 4. BRAND AND PRODUCT DESIGN

For the icons, we used Phosphor icons, a huge open source icon family with over a 1000
unique icons in 6 different weights. [3]

Figure 4.7: Screens from the UI

4.4 Conclusion
The end of this chapter concludes the end of the UX Process and the beginning of the devel-
opment phase. After doing a few refinements, if any are needed based on users’ feedback,
we can start coding.

Page 42
 CHAPTER

IMPLEMENTATION

Contents
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2 Technology and Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2.1 Front-End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2.2 Back-End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2.3 Payment service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2.4 Development and Deployment . . . . . . . . . . . . . . . . . . . . 45

5.2.5 Version Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.3 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.3.1 State Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.3.2 UML Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.4 Final Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.4.1 Worth Mentioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.4.2 State of the code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.4.3 Screens from the App . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

43
CHAPTER 5. IMPLEMENTATION

5.1 Introduction
Now that we have everything well laid out, it’s time we bring our app to life. But first, we will
pick the right tools and prepare the architecture.

5.2 Technology and Tools

The right technologies and tool sets allow us to produce exceptional work, within the time
constraints, and without blowing up the budget, that if we had any.

5.2.1 Front-End
For the front-end, we picked Flutter for a couple reasons:

• It makes it easy to implement custom designs.

• It is easy to animate and make the app feel dynamic and alive.

• It is Cross-platform. So a single codebase allows us to test on both mobile platforms

with very minimal tweaking required.

• It has a large community that we can rely on if needed.

• It is quite performant, since it compiles directly to ARM machines.

Figure 5.1: Flutter logo

Flutter is an open source framework based on Dart by Google for building beautiful, natively
compiled, multi-platform applications from a single codebase. It is fast, since Flutter code
compiles to ARM or Intel machine code as well as JavaScript, for fast performance on any
device. Productive, since we can build and iterate quickly with Hot Reload. Update code and
see changes almost instantly, without losing state. And flexible, since we can control every
pixel to create customized, adaptive designs that look and feel great on any screen. [4]

5.2.2 Back-End
For the back-end, we picked Firebase for a couple reasons:

• It is easy for rapid testing and integration.

• It provides real time monitoring tools.

Page 44
CHAPTER 5. IMPLEMENTATION

• It has a large set of tools that make it easy for us to integrate new functionalities.

• It has generous limits. So we should not be worried about the cost in our early phases.

• As it is backed by Google, we can trust it with our clients data.

Figure 5.2: Firebase logo

Firebase is an app development platform that helps us build and grow apps users love.
Backed by Google and trusted by millions of businesses around the world. It accelerates
app development with fully managed back-end infrastructure. It allows us to release with
confidence and monitor performance and stability. And finally it helps boost user engage-
ment with rich analytics, A/B testing, and messaging campaigns. [5]

5.2.3 Payment service

Unfortunately, in Tunisia, we don’t have a choice in online payment. All online payments
must go through ClicToPay. And even if we used other available tools, they are nothing but a
wrapper for the ClicToPay API, providing maybe easier integration or a few more management
tools.

Figure 5.3: ClicToPay logo

ClicToPay is a secure payment solution offered to merchants who propose to sell their prod-
ucts or services online by bank card. The cards accepted are Tunisian (CIB, Visa and Mas-
terCard) and foreign (Visa and MasterCard) bank cards.

5.2.4 Development and Deployment

For the development of the app, we will be using Android Studio, as it provides great tools
to help us optimize and debug in real time. It is also the number one recommended tool for
Flutter, right before VS Code.

And since we are developing on a Windows machine, we unfortunately can only compile for
Android, as compiling for iOS requires both a MacOS machine and and iPhone. So we will
be deploying and testing the app on a Samsung S21 with Android 13 (API level 33).

Page 45
CHAPTER 5. IMPLEMENTATION

Figure 5.4: Android Robot Figure 5.5: Android Studio logo

5.2.5 Version Control

One crucial safety measure that should not neglected is versioning. This allows us to revert
back to any older version in case of failure and to branch and safely experiment without
affecting the main code base. To achieve this, we will be using a combination of Git and
GitHub. We choose GitHub because it was already integrated within Android Studio, making
effortless to manage everything without the need to ever leave the IDE.

Figure 5.6: Git logo Figure 5.7: GitHub logo

5.3 System Architecture

Software architecture is a key factor in the survival of an app. The main objective of an
architecture implementation is to ensure the scalability and maintainability of the system.

5.3.1 State Management

To give structure to our code, we need to adopt a pattern. That would not only make it easier
for us to maintain and organize the app, it also makes it easier to onboard other developers
and get them started quickly. Three of the most famous patterns for Flutter are BLoC pattern,
Provider pattern, and Redux. BLoC is more suited for medium to large projects, Provider for
small to medium projects, and Redux for large projects. Following our MVP strategy, we had
to pick Provider as it is the sweet spot between ease of use and effectiveness. We can also
safely trust it since it was awarded "Flutter Favourite" by the Flutter team, and it has a large
community to back it up.

Provider is a wrapper around InheritedWidget to make them easier to use and more reusable.
By using provider instead of manually writing InheritedWidget, we get:

• Simplified allocation/disposal of resources.

• Lazy-loading.

Page 46
CHAPTER 5. IMPLEMENTATION

• A vastly reduced boilerplate over making a new class every time.

• Devtool friendly – using Provider, the state of our application will be visible in the Flutter
devtool.

• A common way to consume these InheritedWidgets.

• Increased scalability for classes with a listening mechanism that grows exponentially
in complexity (such as ChangeNotifier). [6]

Provider is very close to the MVVM pattern in practice, and it mainly divides our code into 4
packages: Models / Providers / Widgets / Screens.

5.3.2 UML Diagrams

To better visualize our architecture, we also prepared the necessary UML diagrams that de-
scribe how our system functions.

Entity Diagram

An Entity Relationship (ER) Diagram (figure 5.8) is a type of flowchart that illustrates how
“entities” such as people, objects or concepts relate to each other within a system.

The tables 5.1 and 5.2 describe the entities and relations discussed in the diagram.

Entity Description

Client Where we store and manage all user data, also used during authentication

Parking Spot Used when fetching the list of available parking spots from Firestore

Booking For managing the bookings, refers to client and parking spot

Transaction For managing payments and updating the client account balance

Table 5.1: Entities description table

Page 47
CHAPTER 5. IMPLEMENTATION

First Entity Relation Second Entity Description

Client One to Many Transaction One client can make many transactions,
but each transaction is associated with
one client.

Client One to Many Booking One client can make many bookings,
and each booking is associated with
one client.

Parking Spot One to Many Booking One parking spot can have many book-
ings over time, but each booking is as-
sociated with one parking spot.

Table 5.2: Relations description table

Figure 5.8: Entity diagram

Sequence Diagrams

A sequence diagram is a type of interaction diagram because it describes how—and in what

order—a group of objects works together. Below, we will see two examples describing the

Page 48
CHAPTER 5. IMPLEMENTATION

Payment (figure 5.9) and Booking (figure 5.10) systems.

Figure 5.9: Payment sequence diagram

The main flow for the payment system include the user tapping on "Deposit" to refill his wallet,
the app UI will show a screen that asks the user about the amount they want to deposit, and
that amount is then sent to the payment provider, which will initiate the payment service
and show it to the user. The user will need to enter his details and confirm, and the payment
service will send a success status to the Payment provider which will update the user account
balance. If the status sent by the service is a failure status, we will show a message and abort
the transaction.

Figure 5.10: Booking sequence diagram

Page 49
CHAPTER 5. IMPLEMENTATION

The main flow for the booking system include the client tapping on "Find Spot" to load all
available spots near him or near his destination, which are provided by the Parking spot
provider after getting the user’s location provided by the Location provider. Then if the user
chooses to book a spot, the booking provider will initiate a booking session and send a
confirmation to the client. The only possible alternate flow here is if there are no available
spots near the user. The app will show a message and the user will need to refresh or come
back later.

5.4 Final Output

Before we get see the final shots form our app, It’s important we mention some of the Flutter
packages and Firebase tools we used.

5.4.1 Worth Mentioning

Firebase tool Description

Authentication Allows us to easily integrate different authentication methods, and man-

age user logins

Firestore Working as our database. NoSQL database that uses documents and
JSON like structure

Storage We’re using this to store the parking spot photos and get their links

Table 5.3: Firebase tools worth mentioning

Page 50
CHAPTER 5. IMPLEMENTATION

Flutter Package* Version Description

google_maps_flutter 2.2.5 Allows us to easily use and manage the Google

Maps API

firebase_core 2.10.0 Allows us easily integrate and use Firebase (Spe-

cific functions and tools require other packages)

flutter_svg 2.0.5 SVG images are not supported by default in Flutter.

This package solves that

geolocator 9.0.5 Allows us to get the user location with no need to

worry about permission

phosphor_flutter 2.0.0 A package for using the great icon pack "Phosphor
Icons". Works just like Material icons

animations 2.07 Allowed us to integrate smooth transitions around

the app

animated_splash_screen 1.3.0 Allowed us to integrate an animated splash screen

that also helps us fetch data before the app loads

lottie 2.3.2 A great package that allows us to add custom Lottie

animations (Like loading and splash animations)

Table 5.4: Flutter packages worth mentioning

5.4.2 State of the code

We took code cleanliness seriously. We tried to follow as many best practices, and dealt with
most warnings, even if they seemed harmless and good to ignore. This resulted in a stable
output with no accidental crashes. We also tried to use SVG images and Lottie animations
whenever possible to get the sharpest details and the lowest sizes possible. These practices
resulted in a total size of around 14mb for the release version of the app.

If there’s anything left to do, it would be to tweak the performance so we can reach the
minimum 60 fps promised by Flutter.

* All packages are provided by the official website https://pub.dev/

Page 51
CHAPTER 5. IMPLEMENTATION

5.4.3 Screens from the App

Figure 5.11: Screens from the app

Page 52
CHAPTER 5. IMPLEMENTATION

• Splash Screen: Shows a small splash animation as soon as the app launches, and
waits for the user data to be loaded in the background.

• Login Screen: Only shown to users that are not logged in. Uses Google as an authen-
tication method to make the process much faster and easier than requiring a username
and a password.

• Home Screen: This is the main intersection to all parts of the app.

• Nearby Spots: The user can find all available parking spots that are near him, and
book one.

• Profile Screen: The user can consult and update his account balance from here, and
has access to all app settings.

• Payment Service: This shows the screen provided by the payment service where the
user need to input his details and confirm the transaction.

5.5 Conclusion
The end of this chapter marks the end of the hard work. We picked the right tools for the right
job, finished some architecture related details, and finally coded the app with the UI being our
main reference. All that remains now is to test, optimize, and iterate based on user feedback.

Page 53
 CHAPTER

TESTING

Contents
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.2 Unit Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.2.1 Testing Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.2.2 Tools and Libraries Used . . . . . . . . . . . . . . . . . . . . . . . . 55

6.2.3 Benefits and Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.3 Usability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.3.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.3.2 Extra Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

54
CHAPTER 6. TESTING

6.1 Introduction
Testing a product falls into two categories:

Unit tests: which are technical tests we include in our code to make it easier for us to
test different functionalities as our app grow and as we keep refactoring and improving.

Usability testing: where we test our final product with real user to see how they interact
with it and to spot any UX anomalies.

6.2 Unit Test

Unit tests are an integral part of software development, designed to validate that each indi-
vidual unit of software performs as designed. By testing the smallest pieces of code, such as
functions or methods, we can ensure that they work correctly in isolation.

6.2.1 Testing Strategy

In our application, we adopted a strategic approach to unit testing, focusing on critical and
complex parts of our codebase. We prioritized areas that handled state management and
database operations, given their crucial role in the application’s functionality. Through this
focused approach, we ensured that any changes or updates to our codebase would not
inadvertently disrupt the app’s core functions.

6.2.2 Tools and Libraries Used

Our choice of tools and libraries for testing was guided by efficiency, simplicity, and community
support. We used the flutter_test library, which is built into the Flutter SDK, for general-
purpose testing. To handle mocking, we used Mockito, a widely-used Dart library that allows
you to create ’dummy’ versions of your classes or services, enabling you to isolate the units
of code you’re testing.

6.2.3 Benefits and Challenges

Throughout the development process, unit testing proved to be invaluable. It provided us
with the confidence to make changes and refactors, knowing that we would be alerted if
we inadvertently broke existing functionality. However, we also faced challenges such as
the initial time investment to write tests and learning how to effectively mock dependencies.
Despite these challenges, the benefits far outweighed, contributing to a more reliable, robust,
and maintainable codebase.

Page 55
CHAPTER 6. TESTING

6.3 Usability Testing

User testing was the final phase we had to go through. And it’s usually one of the most fun
part of the work, as we get to see people’s reactions to what we’ve done, and we get some
valuable insights based on how they interact with the app.

The methods that we used are: Unmoderated + in-person and Moderated + in-person

Unmoderated in-person tests are conducted in a controlled, physical setting but don’t require
us to administer the test. This gives us many of the benefits of testing in a controlled atmo-
sphere and reduces the possibility that a moderator could lead or influence participants with
their questions.

Tests that are moderated and conducted in-person offer the most control. They are time
consuming but excellent for collecting in-depth information. [7]

The tool of our choice for the majority of the testing is Hotjar.

Figure 6.1: Hotjar logo

6.3.1 Results
Based on both tests, we concluded the following:

• We need to add an on-boarding, as some users fail to understand the core concept of
the app, that is parking spots are provided by us and are protected with barriers and
will be unlocked via the app.

• We need to think about including a notification system to let users know when a busy
spot they need became available (Although this may require AI functionalities)

• People get stressed in first usages as they think they have time limits, like in classic
parkings. The stress goes away once they learn that there is no time limit and they can
monitor their session from the app.

6.3.2 Extra Tests

We also conducted a few A/B testings early in the design process to decide on a few direc-
tions for the app. But unlike usability testing, which investigates user behavior, A/B testing is
about experimenting with multiple versions of a page to see which is most effective. It’s an
important tool for increasing conversions.

Page 56
CHAPTER 6. TESTING

Some final tests we did are Eye-tracking simulation + Heatmaps. Which again are tech-
nically not usability testing because they report on user actions in aggregate, but they are a
good way to observe and objectively measure behavior on our app. Below are a few results
in figure 6.2

Figure 6.2: Heatmaps

6.4 Conclusion
This chapter marks the end of our work. We did a deep research followed by a brand and UI
design, we laid down the architecture and coded the app based on the UI we designed, and
finally went through some tests to validate all that has been done.

Page 57
 GENERAL CONCLUSION

A t this point, we have a finished UX study, a thorough business model, a clean design,
and a working prototype.

This product, if marketed and maintained well, will solve all the issues we mentioned before,
and will create a whole new ecosystem in the region.

The Process
This project idea was in the back of my mind for a while, and it was way bigger and more
complicated. But executing it in that form would be a set up for failure, especially with the
time constraints and limited resources. So we started by brainstorming ideas to simplify our
project and turn it into a doable MVP.

Then we discussed the MVP with a few close people to get any insight that can help us further
tweak the idea and find loopholes to patch.

After that, we got to work. We took a deeper dive at some competitor products and surveyed
potential clients. Weeks later, we had a base UX study and Business model. And to validate
our work, we sat with a businessman to discuss our findings, and we’ve got very positive
feedback and support.

After having a strong foundation for the app, we started the design process, from the general
brand to the details of the app. We tried to simplify the design as much as possible. Our main

58
General Conclusion

inspirations for the UX and Design were the taxi booking app "Bolt" and a Scooter reservation
app in a foreign country.

Then we transformed the pixels into code. We tried to remain as loyal to the original design
as possible for an aesthetically pleasing result.

Lastly, we tested our app with few potential users to get feedback and confirm our decisions.

Future Work
As mentioned earlier, we now need to start looking for potential investors to fund the journey.
We also need to find early partners that are willing to provide the spaces, and we will pre-
pare a platform where they can monitor their revenue. We also have to prepare the needed
hardware for the barriers and physical spots. After that we will launch an early access or
maybe private beta version to start testing the whole system in real life scenarios, while also
preparing a V2 of the app that’s ready to go mainstream and to be used by hundreds of
people.

Final Thoughts
This project was an opportunity for me to merge my skills in business, design, and engineer-
ing, and to learn more along the way. It was a bumpy ride, but I enjoyed every part of the
process.

This project will one day become a well-known startup used by hundreds around Tunisia. And
hopefully will expand abroad.

Page 59
 BIBLIOGRAPHY

[1] InstaDeep Website. Last visited on 23/04/2023. url: https://www.instadeep.com.

[2] FontShare Website. Last visited on 27/05/2023. url: https: // www. fontshare.
com/fonts/satoshi.
[3] Phosphor icons repository. Last visited on 02/06/2023. url: https://github.com/
phosphor-icons/homepage#phosphor-icons.
[4] Flutter Website. Last visited on 10/06/2023. url: https://flutter.dev/.
[5] Firebase Website. Last visited on 10/06/2023. url: https://firebase.google.
com/.
[6] Provider Package Website. Last visited on 10/06/2023. url: https : / / pub . dev /
packages/provider.
[7] Hotjar Website. Last visited on 11/06/2023. url: https : / / www . hotjar . com /
usability-testing/methods/.

60