Linköping University | Institution of Computer Science Bachelor Thesis, 18 ECTS | Industrial Engineering and Management

Spring term 2017 | LIU-­IDA/LITH-­EX-­G-­-­17/031—SE

Easyfleet – A Customised Fleet Management -­ A case study in developing a web application that supports navigation, simplicity and customer satisfaction

Jonathan Axelsson Viktor Cheng Renata Felippe da Silva Galeano Eric Hermansson David Lindholm Simon Olefalk Cecilia Shadman

Supervisor: Dennis Persson Examiner: Aseel Berglund

Copyright The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read,

to download, or to print out single copies for his/hers own use and to use it unchanged for non-­commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when

his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its

procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. © Jonathan Axelsson, Viktor Cheng, Renata Felippe da Silva Galeano, Eric Hermansson, David Lindholm, Simon Olefalk, Cecilia Shadman

Abstract More vehicles are used in as part of business operations and the need for obtaining an overview of a vehicle fleet is increasing. This study sets out to examine whether or not it is possible to implement a web based application to manage a vehicle fleet that promotes navigation, simplicity and customer satisfaction, with the Finnish Border Guard as the customer. Theory regarding design, navigation, simplicity in web development, usability and customer satisfaction testing was studied. A prototype was initially formed to provide the customer with expectations of the project. During the implementation phase, user tests were conducted in order to measure to what extent the purpose of the project had been fulfilled. The user tests were partially used as a basis to further implementation and eventually as the final evaluation of the project. The final study shows that improved navigation can be achieved by having a static and constantly reachable navigation bar and a minimalistic design can conduce to simplicity, although it is unclear whether you can generalise that fact.

Table of contents 1. Introduction .............................................................................................................. 1

1.1 Explanatory statement ....................................................................................... 1

1.2 Purpose ............................................................................................................. 1

1.3 Question formulation .......................................................................................... 1

1.4 Limitations .......................................................................................................... 1

2. Background ............................................................................................................. 3

3. Theory ..................................................................................................................... 4

3.1 Cooperation and Communication ...................................................................... 4

3.2 Customer satisfaction ........................................................................................ 4

3.3 Design ................................................................................................................ 5

3.4 Usability ............................................................................................................. 7

3.4.1 Navigation ................................................................................................... 7

3.4.2 Simplicity ..................................................................................................... 9

3.5 Method-­theory .................................................................................................. 10

3.5.1 Agile working methodology ....................................................................... 10

3.5.2 NABC ........................................................................................................ 11

3.5.3 Prototyping ................................................................................................ 11

3.5.4 Customer Satisfaction testing ................................................................... 12

3.5.5 Usability Test ............................................................................................. 15

3.5.6 Evaluation scales ...................................................................................... 19

4. Method .................................................................................................................. 20

4.1 Pre-­study ......................................................................................................... 20

4.1.1 Marketing plan ........................................................................................... 20

4.1.2 Product backlog ........................................................................................ 20

4.1.3 Prototype ................................................................................................... 21

4.2 Implementation ................................................................................................ 21

4.3 Evaluation ........................................................................................................ 22

4.3.1 Customer satisfaction testing .................................................................... 22

4.3.2 Usability testing ......................................................................................... 23

5. Results .................................................................................................................. 26

5.1 Pre-­study ......................................................................................................... 26

5.1.1 Marketing plan ........................................................................................... 26

5.1.3 Prototype ................................................................................................... 27

5.2 Implementation ................................................................................................ 28

5.2.1 Technical overview .................................................................................... 28

5.2.2 System overview ....................................................................................... 29

5.2.3 Database structure .................................................................................... 36

5.3 Evaluation ........................................................................................................ 36

5.3.1 Usability testing ......................................................................................... 36

5.3.2 Customer satisfaction test ......................................................................... 38

6. Discussion ............................................................................................................. 40

6.1 Result ............................................................................................................... 40

6.1.1 Pre-­study ................................................................................................... 40

6.1.2 Implementation .......................................................................................... 40

6.1.3 Evaluation .................................................................................................. 44

6.2 Method ............................................................................................................ 46

6.2.1 Pre-­study ................................................................................................... 46

6.2.2 Implementation .......................................................................................... 47

6.2.3 Evaluation ................................................................................................. 47

6.2.4 Source criticism ......................................................................................... 49

6.3 The project in a broader context ...................................................................... 49

6.3.1 Ethical aspects .......................................................................................... 49

6.3.2 Societal aspects ........................................................................................ 50

7. Conclusion ............................................................................................................. 51

8. References ............................................................................................................ 53

9. Appendix ............................................................................................................... 57

Appendix A -­ Marketing plan .................................................................................. 57

Appendix B -­ NABC ............................................................................................... 72

Appendix C -­ Prototype .......................................................................................... 74

Appendix D -­ ER-­diagram ...................................................................................... 79

Appendix E -­ User tests ......................................................................................... 80

1

1. Introduction When vehicles are an important part of companies as part of their business operations, it arises a need for obtaining an overview of their vehicle fleet. Storing this information using old-­fashioned means such as spreadsheets or whiteboards is time-­consuming, inefficient and not accessible at all time.

In this day and age, a web application could not only fulfill existing needs but also provide new and valuable functionality. The main advantage of storing information about a vehicle fleet in a web application would be to provide easy access to information for everyone in the organisation at all time.

1.1 Explanatory statement A couple of years ago, the US Coast Guard developed a web application for the same purpose. The Swedish Coast Guard learned about the existence of their system and determined that it could be useful for them as well and subsequently developed their own version. Their Finnish counterparts, the Finnish Border Guard (hereafter referred to as FBG) have similar needs and a similar vehicle fleet. However, they do not currently possess a similar system.

With this knowledge, the project team initiated a discussion with FBG about introducing this kind of system. There was considerable interest and willingness to participate from their side, which led to an agreement between the team and FBG. This concluded in an agreement in which this project will have the purpose of developing a web application that can provide a better overview of their vehicle fleet. The web application was designed with usability and more specifically with navigation and simplicity in mind in order to minimize the resistance to change to a new solution.

1.2 Purpose The purpose of this project is to develop a web application that can help the FBG store and display information about their vehicle fleet and make this information more accessible within their organisation.

1.3 Question formulation How can a web application with the purpose of improving vehicle management and interdepartmental cooperation be designed and implemented in a way that leads to high customer satisfaction and usability with regard to navigation and simplicity?

1.4 Limitations This project has focused on the specific needs of the FBG and been developed in accordance with the requirements set by the FBG. While this type of web application

2

could be useful in other types of companies such as car rental companies, possibly with additional functionality, that was beyond the scope of the project with regards to the development of the web application.

Other limitations regarding FBG is that the application will be implemented on their intranet. The internal system will be maintenanced by an internal administrator.

As to the customer satisfaction construct, dimensions that will be considered in this thesis are design, simplicity and navigation.

3

2. Background Due to the fact that FBG was the customer for the project, the application had to be designed to fulfill their requirements. Through discussions with FBG, the following list of features was established as necessary to fulfill their requirements: Several users should be able to simultaneously access the system to view the

availability of vessels. The system should contain 10-­15 data elements (‘descriptors’) in order to

accurately describe the current vessel (e.g. name, location etc.). Users should be notified in the web application when there are changes in the

status of a vessel. Users should be notified via e-­mail when vessels are marked as “not in use”. Support for uploading and attaching documents for each vessel. Every vessel should have a complete history log stored in the database. Each user should have an individual user profile and belong to one of the pre-­

defined user classes with pre-­defined user rights. There should be an administrator class with the ability to modify user profiles.

Beyond the external requirements from FBG, the project group was given free reins in regards to other functionality within the system. FBG did not express a wish for a purchasing process, which resulted in that particular functionality being removed in the final version that was delivered to FBG.

4

3. Theory In this chapter, the theory the project is based on is presented. It starts off with the theory for the working method for the project. Thereafter continues with presenting the theory used for the three phases of the project;; pre-­study, implementation and evaluation, chronologically.

3.1 Cooperation and Communication For large companies, a management information system (MIS) is of great importance. It is a system that satisfies communication and information needs of managers for organisations. Such a system concerns the process of collecting and storing relevant information amongst other tasks. The key focus of MIS is to contribute to decision-­making in a timely and accurate fashion at a minimum of cognitive and economic cost, for all managers at each level of an organisation (Felix, 2009). Managerial issues can widely be seen to pave the way for an absence of cooperation (Cheney & Dickson, 1982). According to Felix (2009), a successful MIS contributes by: Providing warning signals. Mechanising routine operations in order to relax human work. Assisting managing functions with mundane decisions. Providing necessary information for non-­mundane decisions. Gaining advantages on a market.

Communication and interdepartmental cooperation, in general, is a necessity for a successful organisation. To provide for prosperous interdepartmental cooperation, studies show that there is a need for high quality and credibility of the information that is being carried on between different departments within an organisation (Pinto & Pinto, 1990, p. 202).

3.2 Customer satisfaction Customer satisfaction is a broad concept which could be described as the satisfaction a customer get from being supplied with a product or service. Several factors have been recognised to affect the customer satisfaction on web applications, both regarding design and basic functionality of the application (Kassim & Asiah Abdullah, 2010) (Gao, 2005). McKinney et al. (2002) argue that things that impinge customer satisfaction can be divided into system quality factors (SQ) and information quality factors (IQ), and the expectations regarding these quality factors. McKinney et al. (2002) further reason that there is no real consensus regarding what kind of dimensions of SQ and IQ that

5

are the most important, but they present five IQ dimensions: Relevance Timeliness Reliability Scope Perceived usefulness.

as well as four dimensions in accord with SQ: Access Usability Navigation Interactivity.

Nonetheless, there are several models to be considered while studying customer satisfaction on web applications, perceived simplicity of web design is an imperative parameter to consider (Gao, 2005). Other design dimensions to consider are design content, organisation, the basic structure of the site, where visual content is placed etc. (Kassim & Asiah Abdullah, 2009). Moreover, there are several models, for example, TAM – Technology Acceptance Model, which evaluates the customer satisfaction primarily based on perceived ease of use. There seems to be a strong correlation between customer satisfaction and ease of use. As perceived ease of use is a somewhat loose term, it could be defined as the simplicity of the website with the level of user interaction and level of understandable content as well as the level of navigability provided by the application (Straub et al. 2002) (McKinney et al., 2002). Gao (2005) also argues that perceived simplicity as a usability term is a factor which can positively affect the overall customer satisfaction, although he means that there is a discrepancy between simplicity and ease of use. The concepts of design and usability as navigation and simplicity will be further theorised below.

3.3 Design User-­Centered Design (hereafter referred to as UCD), which is a method that aims for a collaboration between the user and the designer, can be utilised to make the web application suitable for the user in terms of design. The design of the web application can be based on user information gathered from mapping their preferences and behaviour of use. The UCD method has three core activities, design research, design and design

6

evaluation. During the first phase, the users and their needs are detected. During the design phase, the information from the design research is used to design the web application. During the third phase, the design is evaluated and eventually revised to better suit the user. Following these steps will, in theory, contribute positively to the usability of the web application (Williams, 2009). Usage and the choice of colours affect the user’s overall experience of a web application. According to Issa & Isaias (2015) they attract the user’s attention and appeal the mind moreover they help users to understand information, memorize certain parts and acts as reminders. Different colours have various effects on the mind. Cold colours as blue, green and mixes of them give a feeling of seriousness, honesty and cleanliness. Hot colours such as red draw attention, and light colours are used to provide a feeling of openness. Light green, yellow and red are examples of colours that should be avoided using too much because they make the eyes tired as a result of the structure of the human eye. Mixing bright and light colours also makes the eye tired and is not to recommend (English et al. 2002). Other clean and tidy colour conventions, that support simplicity and are highly intuitive, are white, black and several shades of lighter grey (Kontratova & Goldfarb, 2007). Though images can give a web application a richer visual environment, too many animations and flashing images can be distracting. Large pictures slow down the load time, on the other hand, users prefer graphical approaches on icons and buttons (Fang & Salvendy, 2003). Fessenden (2017) means that modals were initially used to grab users attention in case of an error or a system issue that requires the user’s attention. Modals were accordingly used to interrupt the user to fix the error. Hence, the usage has developed to additionally grab user’s attention for less sincere reasons. When modals are considered to be put in place, there are both pros and cons to evaluate. Cons are that they cover information in the background which can make it harder for the user to respond to a question at the modal when the information needed is covered. Modals also created an extra task for the user that can cut off the user if not containing important information. Though, Fessenden (2017) advises to use modals to simplify complicated processes that ask for a lot of information of the user which requires mental involvement. They attain the users’ focus on the specific matter and should therefore not contain what is not necessary for reaching the user’s goal. When creating a form, the design of it matters in terms of simplicity. A form should not stand out too much when it comes to design, it should look clean and tidy. One column should be used and the fields and the text should be placed symmetrically. Eye-­tracking experiments show that putting labels above the fields is preferable because it helps the eye to get a quick overview of the fields. If the form requires the user to fill in a date, only making it possible to do so manually should be avoided. Jarrett & Gaffney (2009) means this is because it can cause confusion when the user

7

has to relate the date to a specific time or happening, for example, tomorrow or the week before the holiday. To simplify date picking, a calendar that pops up when a date is to be picked should be used. Hence, the possibility to write in the date manually should always be a choice (Jarrett & Gaffney, 2009). Users access a web application from different devices with different sizes of the screen. For the interface to be user-­centered, the design should be responsive to match the user’s needs and the capability of the device. Techniques regarding how to make a design responsive can involve scaling the layout and changing the order of content on the page to prevent the user from scrolling too much (Majid et al. 2015). The resolution of computer screens is in general low, which results in a higher risk of eye tiredness. Because of this reason and to prevent serious effects on a user, online typography is an issue specifically important to consider which includes the choice of font. There are two major types of fonts, the serif and the sans serif. The word serif refers to the short lines, or feet, that are attached to the edges of a letter or symbol. Serifs are due to their professional appearance suitable for printed media such as books or newspapers, but not as preferable for digital media due to the low resolution of screens which tends to clog the serifs together. Therefore, the sans serif is recommended for text in web applications in order to make it simpler to read and attain information for the user (Kalbach, 2007). When deciding where to place the company logotype on the web application, Whitenton (2016) means there are favourable advantages doing so at the top left corner. Additionally, by making the logotype clickable with the purpose of taking the user to the homepage simplifies the navigation for the user by the following reasons. Firstly, the user is reminded of its position at the web application and secondly, it provides an opportunity to whenever needed navigate to other parts of the web application or goes back to the start position.

3.4 Usability Usability is a widely studied concept the in human-­computer interaction field. Researchers mean that it plays an important role in succeeding while implementing and designing computer systems and web applications. Poor usability in a web application can be linked to a broad variety of factors, e.g. navigational difficulties, inefficiency, difficulties in understanding the application’s content and disorientation. Upon identifying common dimensions of usability within a web application, several constructs are described, which seem to be the fundament of usability. Among these constructs, navigation and simplicity are included. (Lee & Kozar, 2012)

3.4.1 Navigation To keep a web application user-­centered in terms of effectiveness and simplicity, the

8

navigation is of big importance. Poor navigation opportunities leave the user confused, frustrated and lost which can result in the user leaving the web page (De Angeli et. al, 2006) Leavitt & Schneiderman (2006) points out various focus areas to bear in mind when developing a web application. The conclusions are based on the information that the human eye navigates from the top to the bottom of the page, starting at the center and going to the left, lastly the right. Since the user is initially searching for important content at the top of the page, relevant information, buttons and functions should be placed at top of the page. According to Nielsen & Loranger (2006), navigation within a web application refers to the way of letting a user access what is necessary for an efficient way. Consequently, in order to maintain a user-­operational application, dynamic and customised navigational items must be simple to manage. Keeping the site responsive, but not too responsive can be a key because over-­sensitive functions and menus tend to become misleading (Nielsen & Loranger, 2006). Moreover, a well-­recognised fact presented by Issa & Isaias (2015) is that a minimalistic edge design is cardinal to aid to navigation. Additionally, studies show that an essential way of supporting navigation on a website is to have a constantly reachable navigation bar on each page, to decrease the likelihood of confusion (Issa & Isaias, 2015). To simplify navigation, Issa & Isaias (2015) and Nielsen & Loranger (2006) advocates using links that are labeled and placed properly. Furthermore, they mean that there should be a clear consistency in labeling, referring to link names, product names as well within searching mechanisms on a website. One of the fundamental factors of overall navigation and usability is a search function. When a user scans a web application or website, they typically look for a placeholder where you can input words to navigate yourself to a requested layer of the application. Therefore, a placeholder as “Insert word or thing to find” plays a basal role in web application usability, especially in accord to navigation (Nielsen, 2012). Upon creating a web application it is also fundamental to keep a consistent way of navigating. Other than keeping consistent labels, changing the navigational structure can lead to discomfort for the user. If the navigational structure changes from one page to the next, e.g. if you use search bars on one page and a filter function which performs the same actions on the next, the user’s attention drastically changes which can lead to dissatisfaction (Nielsen & Loranger, 2006). A way of helping the user navigate on the page is by preventing mistakes from being made. User control and freedom is about helping the user leave a function when it has been chosen by mistake. This is usually done with an exit button or similar.

9

Errors can also be prevented by presenting confirmation options or by selecting information for users (Nielsen, 1994). In case that an error is made, it is also important that the user gets a clear response from the application of what had occurred and how the problem can be solved (Squires & Preece, 1999).

3.4.2 Simplicity Nielsen defines simplicity as the lack of complexity, or in other words, the lack of obstruction. It is one of the key components when creating a usable design and having a web application with high simplicity means that users are able to get what they came for when they use the application (Karvonen, 2000). To reach simplicity in an application, there are four important factors: reduction, organisation, integration and prioritising. (Lee, Moon & Kim, 2007). Reduction is the main factor behind simplification of a web application. The core of reduction is figuring what the essential parts of the application are. After that, the complexity of the application is reduced as much as possible while still maintaining it's essential functionality and design. When reducing, Waloszek(2004) concludes there are many different aspects of the complexity of applications that can be focused on: Terminological complexity Interface complexity Procedural complexity Navigational complexity.

The terminological complexity can be reduced by making sure the same names are used for the same functions and objects throughout the application. The reason behind interface complexity is usually bad screen design. Components can be badly arranged or misaligned. Correcting this helps to reduce the interface complexity. Reducing the procedural complexity is done by reducing the number of steps it takes to complete the different procedures in the application (Waloszek, 2004). Organisation can be improved by grouping components into categories that are not abstract and makes sense to the user (Waloszek, 2004). When having a lot of elements of the same kind, grouping them in a list also helps with the organisation of the application (Maeda, 2006). When simplifying an application, an issue is often that the application ends up as a collection of isolated tasks and functionalities. To reach simplicity, these need to be integrated in an intuitive way. Using abstract such as a tree or net structures can lead to the application being perceived as more complex and thus less simple. Instead of using simple lists or graphical represents helps to reduce the perceived complexity (Waloszek, 2004).

10

Prioritising is the issue of having the application focus on its essential tasks. It is those which should be the most visible and accessible (Lee, Moon & Kim, 2007). This is connected to reduction since some functionalities with low priority should be discarded. Others should be marginalized so they don’t take focus from the essentials (Waloszek, 2004). Another way of influencing the user’s perception of simplicity is keeping consistency and standards when it comes to choice of words and expressions. To avoid confusion the web application should use conventional words and expressions, that the user is already familiar with (Nielsen, 1994).

3.5 Method-­theory

3.5.1 Agile working methodology In software development, agile methodology is commonly used due to its framework that is “designed to help small, close-­knit teams of people develop complex products” (Sims & Johnson, 2012). Agile methodology consists of various iterations, called sprints in scrum methodology (Sims & Johnson, 2012), and describes the different faces of the project. Iteration will hereafter be referred to as sprint. Figure 1 describes an iteration face, a sprint, and all its different steps (Otaduy & Diaz, 2017).

Figure 1, Agile methodology. The process starts with defining a product backlog based on the features wanted in the final web application by the product owner (Sims & Johnson, 2012). The product owner can update the product backlog during the project to reflect for eg. changes in the needs of the customer (García-­Magariño et. al., 2009). During the Sprint Planning stage, the team determines which features are going to be developed during each sprint and a sprint backlog is created. The next step of the process is the actual development of the features in the sprint backlog. These developed features are then sent to the customer for user acceptance testing. The feedback that the customer returns is then processed by the team and a list of changes is produced. These changes are then integrated into the product backlog. This marks the completion of one full sprint. Otaduy & Diaz (2017) state that a sprint should not be longer than 1 to 4 weeks depending on the size of the time frame.

11

3.5.2 NABC According to Cristian (2015), NABC is a method used for the development, assessment and presentation of an idea. It was developed by the Stanford Research Institute in the USA -­ originally for use in business situations -­ as a structured approach to defining the value of an idea. NABC is used to pitch an idea, i.e. to try and convince others of the value of the idea. The acronym NABC stands for:

N → Need, which describes the need on the market that the idea will satisfy. A → Approach, which describes the approach to satisfying the need. B → Benefit, which aims to quantify the experienced benefit of the customer. C → Competition, which describes other competitors that can satisfy the need.

3.5.3 Prototyping The process of prototyping is a significant part in expressing the design of a system or a product, and in mapping and exploring possible alternatives (Houde & Hill, 1997). According to Nielsen (2003), prototyping can also be used in usability testing, before the implementation stage of a project is started. By gathering user data to test the usability of the functionality and design before starting to code, it is possible to facilitate the programming phase. Prototypes are usually classified according to their fidelity – high-­ or low-­fidelity. Sauer, Franke & Ruettinger (2008) describe prototype fidelity as the degree to which the prototype resembles the finished system. A model, therefore, needs to show close to identical performance, functionality and design as the finished system, in order to be classified as a high-­fidelity prototype. A low-­fidelity prototype is on the other hand more of a cardboard example of what the finished system would look like (Blackler, 2009). Advantages of low-­fidelity prototypes are that they are cost effective and that it is easier to refine the design of the system. By using successive design refinements, the system can easily evaluate the usability of their system and functionality, although it might not be to the same extent as with a high-­fidelity prototype (Rettig, 1994) (Rudd, Stern & Isensee, 1996). Sauer, Franke & Ruettinger (2008) claim that the limitations in recognising issues concerning usability come from the fact that a low-­fidelity prototype enables different behaviour than a finished product. High-­fidelity prototypes enable making more realistic comparisons to actual designs (Blackler, 2009). However, high-­fidelity prototypes are more time-­consuming to manufacture as well as modify. As high-­fidelity prototypes focus more on the navigation and flow of the system, usability tests relying on these prototypes can lose

12

their focus (which is rather that of assessing the real functionality of the system). Assembling a high-­fidelity prototype (e.g. an expensive functional physical prototype) before testing a low-­fidelity prototype (e.g. a paper model) is also a matter of risk taking because a single manufacturing error in the high-­fidelity prototype can make the evaluation stage impossible to complete (Rettig, 1994). This can be contrasted with the fact that a low-­fidelity prototype can easily be remade, thus mitigating the effect of any errors and increasing the possibility of successfully completing the evaluation stage.

3.5.4 Customer Satisfaction testing Several methods can be used when evaluating customer satisfaction. The most common ones include in-­depth interview, evaluating the product/service with a focus group, telephone interview, mail survey and personal interview (Grigoroudis & Siskos, 2010). Other tests and methods, such as usability tests can be used to gather information about customer satisfaction dimensions. According to Grigoroudis & Siskos (2010) mail surveys can be an appropriate solution in cases where directly contacting the customer is either too costly or difficult to perform. Among other advantages, Grigoroudis & Siskos (2010) mentions the following ones for conducting a mail survey to evaluate customer satisfaction: Respondents are not under pressure to provide quick answers. Different geographical areas may easily be covered. There is no interviewer bias.

The disadvantages mentioned by Grigoroudis & Siskos (2010) include: The questionnaire has to be short and questions should be simple. Questions can be skipped. Open-­ended responses are more complicated to analyse.

Grigoroudis & Siskos (2010) covers six main steps that can be used to plan a survey. These steps consist of:

1. Determine survey objectives. 2. Determine satisfaction dimensions. 3. Determine measurement process. 4. Determine sample size and survey procedure. 5. Develop questionnaire. 6. Test questionnaire and refine.

Some general points for designing a questionnaire will be covered before step 2 is

13

discussed in more detail. Grigoroudis & Siskos (2010) talks about that it is important that the questionnaire is made simple, with specific and single-­minded questions and that the structure should help respondents when they are giving their answers. This can be summarized in with the KIS rule “keep it short, keep it simple, and single-­minded” (Grigoroudis & Siskos 2010, p. 179). Grigoroudis & Siskos (2010) argues that the survey typically contains four main sections: Introduction:

Information about the survey, why it is conducted, how the customers have been selected.

Demographics: Questions that are related to the demographic characteristics of the customer answering the survey.

Satisfaction: Questions about the how satisfied the customer is with parts of the product or with the whole product.

Behavior: Questions about the customer behavior and attitude towards the product or service.

Determine satisfaction dimensions As discussed in the earlier section customer satisfaction is often related to other concepts. Grigoroudis & Siskos (2010) argue that product attributes, customer requirements, and performance among other factors also have an impact on customer satisfaction. Grigoroudis & Siskos (2010) state that it is of high importance to determine relevant factors that might have relation with customer satisfaction. These factors clearly depend on the problem that the product/service is trying to solve. Grigoroudis & Siskos (2010) mention one set of eight dimensions that can be used to measure customer satisfaction for general cases: 1. Performance (basic operating characteristics). 2. Features (secondary characteristics added to basic features). 3. Reliability (probability that product will operate over time). 4. Conformance (the degree to which a product’s design and operating characteristics meet established standards).

5. Durability (a measure of product life). 6. Serviceability (speed, courtesy, competence, and ease of repair).

14

7. Aesthetics (subjective personal judgments regarding how a product looks, feels, sounds, tastes, or smells).

8. Perceived quality (general image of the company, reputation, and other subjective perceptions based on advertising, brand name, etc.).

Another dimension that is relevant to consider is how satisfaction has a relationship between expectations and result. Grigoroudis & Siskos (2010) argue that a question about the overall satisfaction always should be included in the questionnaire. One definition of satisfaction is that it can be viewed as a function, equation 1, of an initial standard and some perceived discrepancy from the initial reference point (Oliver, 1980, p. 460). 𝑆𝑎𝑡𝑖𝑠𝑓𝑎𝑐𝑡𝑖𝑜𝑛 = 𝑓(𝑒𝑥𝑝𝑒𝑐𝑡𝑖𝑜𝑛, 𝑑𝑖𝑠𝑐𝑜𝑛𝑓𝑖𝑟𝑚𝑎𝑡𝑖𝑜𝑛) Equation 1: Satisfaction function. Where disconfirmation is defined as follows: the outcome that has a worse result than expected in regard to the initial point is defined as a negative disconfirmation. Whereas outcome that is perceived better than expected is defined as a positive disconfirmation (Oliver 1980, p. 461). When determining satisfaction dimensions that are to be used in the assessment process of customer satisfaction criteria one can consider the customer to be deciding when evaluating a product or service. Therefore, the model presented below about identifying decision making can be used when defining the satisfaction dimensions (Grigoroudis & Siskos 2010, p. 183). Properties in modeling process of decision criteria: 1. Essential, to indicate consequences in terms of the fundamental reasons for interest in the decision situation.

2. Controllable, to address consequences that are influenced only by the choice of alternatives in the decision context.

3. Complete, to include all fundamental aspects of the consequences of the decision alternatives.

4. Measurable, to define objectives precisely and to specify the degrees to which objectives may be achieved.

5. Operational, to render the collection of information required for an analysis reasonable considering the time and effort available.

6. Decomposable, to allow the separate treatment of different objectives in the analysis.

7. Non-­redundant, to avoid double-­counting of possible consequences. 8. Concise, to reduce the number of objectives needed for the analysis of a decision.

15

3.5.5 Usability Test To evaluate and ensure that a product meets the requirements set by the customers and the developers, usability testing needs to be conducted. The overall goal of usability testing is to secure that the product is useful to and valued by the customer, is easy to learn, helps the customer to be effective and efficient at what they do and that the product is satisfying to use (Chisnell & Rubin, 2008). Dumas & Redish (1999) also states that the primary goal of a usability test is to improve the usability of a product. By eliminating problems with the design of products, frustration from using the product is reduced. This will also ensure that the customer will find the product useful, effective, efficient and satisfying (Chisnell & Rubin, 2008). Although usability testing can result in a better product, there are still inherent limitations associated with (usability) testing due to its artificial nature. Regardless of whether the test is conducted in a laboratory setting or at the actual site where the product will be used, there is no certainty that the test will resemble a real-­life situation. This is partly because the act of conducting a test can itself influence the result. Another limitation is that it can be hard to test the product on the whole target population. This is because it can be difficult to identify every type, or the whole range, of possible end users (Chisnell & Rubin, 2008). Chisnell & Rubin (2008) have defined three different tests that can be conducted during a product's development lifecycle, these are stated in the list below. The different tests are Exploratory Study, Assessment Test and Validation Test. At the beginning of the lifecycle, regardless of whether it is a new product or a follow-­up test on the previous release, an exploratory study is usually conducted. During this stage, the product is usually still being defined and designed. The objective is to examine how effective the product or the early preliminary design concept is. The exploratory study is conducted so that the developer or designer can determine to which degree the end user's intended usage goal is fulfilled and how well the navigation interface of the web application works. An exploratory study can also answer some of the developer’s questions about the user(s), such as how they perceive the product and if the product’s basic functionality has the intended value for the user. The developer also receives a first impression of how well user(s) can navigate and which functions that might need to have written documentation to support their usage. (Chisnell & Rubin, 2008) An assessment test is conducted after the fundamental product design has been established, which is in the beginning or in the middle of the product's development lifecycle. The main purpose of the test is to follow up on the exploratory study and evaluate the usability of the product. For example, if the exploratory study put the focus on page-­navigation and design then the assessment test should focus on the functions supporting the front-­end functionality and evaluate how effective the

16

implementation is. The exploratory study evaluates how intuitive the product is to use and the Assessment test examines how well the user can perform the intended task and identify usability deficiencies. Assessment tests are designed so that the user will perform tasks and the result will be quantified. (Chisnell & Rubin, 2008) The validation test is the last test in a product's development lifecycle and often conducted in close proximity to the time of release. It is conducted to certify that established benchmarks or predetermined usability standards have been reached. It is also conducted to confirm that problems that were identified in earlier tests have been solved and to ensure that no new problems have been introduced. The predetermined usability standards usually originate from usability objectives, which in turn are developed from earlier usability tests, interviews with users or educated guesses by the development team. The usability objectives are usually focused on efficiency and effectiveness such as how effective the user can perform chosen tasks. The objectives can also focus on ranking or rating from users based on their preference criteria. An important objective of the validation test is to ensure that components work together with other components in the final product as intended. (Chisnell & Rubin, 2008)

Usability test design When designing a test, it is important that the research questions are as measurable, accurate, precise and clear as possible. It is important to have a clear goal of what the test is supposed to evaluate or test. Without a clear goal or well-­formulated questions, the test might be a success but the outcome might not be usable (Chisnell & Rubin, 2008). Dumas & Redish (1999) states that the test participants should perform real tasks when conducting the usability test. Chisnell & Rubin (2008) gives an example of two research questions that are too vague and unfocused. The example of questions is as follow:

Is the current product usable? Is the product ready for release or does it need more work?

While the questions are understandable, they do not indicate how the results are to be quantified or measured. With this kind of question, there is a risk that those involved identifies different problems that some participants agree is a problem and some don't. This makes it hard to identify what problems need to be prioritised and dealt with. This also might lead to no problem identification at all (Chisnell & Rubin, 2008). Following is a list containing a set of examples, defined by Chisnell & Rubin (2008), of product research questions that are suitable for websites or web applications:

17

How easily do users understand what is clickable? How easily and successfully do users find the products or information they are

looking for? Where in the site do users go to find Search? Why? How easily can users return to the home page? Can users perform common tasks within established benchmarks? How does ease-­of-­use compare between our product and the competition?

Research questions should be designed as close-­ended questions. Scales, statements or checkboxes will help to minimize the amount of responses that require extensive writing (Chisnell & Rubin, 2008). A complement to a written form is the “concurrent thinking aloud” technique. The participants are asked to, while conducting the test, to actively tell the test moderator what they are thinking about while conducting the different tasks. This method helps to find tasks or problems with the product that makes the participant feel frustration or confused. Advantages with this technique are that it can give early indications on problem areas and help some participants to focus more on the test (Chisnell & Rubin, 2008). Other advantages are that it can result in a clearer overview of the problems that a user can encounter. (Van den Haak & De Jong, 2003) Disadvantages are that the technique can be unnatural and distracting for some participants. The participants might also become exhausted before the test is over if the process goes on for too long (Chisnell & Rubin, 2008). To ensure that the research questions are well designed, unambiguous and unbiased, a pilot test can be conducted. A well-­conducted pilot test will indicate how well the research questions are eliciting the sought for information. A pilot test should consist of the research questions plus a set of questions with the aim to evaluate the actual test. One example of such question is "Were the questions confusing?". It is also imperative to look for biased questions that might lead the test person to the correct answer. When designing research questions, it is easy to, unknowingly, design the questions in a way that leads the answers in "the right direction". The pilot test can also provide ideas on new questions or identify questions that are redundant. (Chisnell & Rubin, 2008)

Usability test participants When choosing participants for a usability test it is important to know who the end users will be and choose participants that suit this description of characteristics. It is imperative to distinguish between the purchaser and the end user (Chisnell & Rubin, 2008). Participants should consist of end users or participants who represent end users (Dumas & Redish, 1999).

18

The number of participants will be important for the statistical validation of the test and according to Chisnell & Rubin (2008), 10 to 12 participants from a specific group of end users is minimum. This is also reinforced by Faulkner (2003). Chisnell & Rubin (2008) also state that in some, less formal usability tests, 4 to 5 participants who represent the same type of end user will find about 80 percent of the usability deficiencies of a product related to that group of end users. Chisnell & Rubin (2008) are skeptical of involving only 4 or 5 participants because the risk is greater that a severe problem is overlooked. Faulkner (2003) states that at least 10 test participants are needed to ensure that 80 percent of the usability deficiencies are detected. An important factor is that the number of participants will depend on the required degree of confidence in the result and the availability of required type of participant (Chisnell & Rubin, 2008). Chisnell & Rubin (2008) defines a set of groups of participants that can be used for the study or test. Some of these groups are stated below: Internal participants:

Cheap and easy to find. Can be biased because of affiliation to the company. Good for testing the test. Good for conducting an early exploratory study.

Qualified friends or family: Known in advance to be qualified. Kan be biased but not as biased as internal participants.

Website sign-­up: Good for when conducting extensive testing. Motivated test subjects. Might be biased because test participants are "fans of the company".

Societies and associations: Good participants who have a specific hobby or a specific profession. Easy to reach through email-­servers or forums.

Referrals from personal networks, co-­workers and other participants: Good for finding participants from the whole age-­scale.

Existing customers from in-­house lists: Excellent source of experienced participants.

Usability test analysis When the test has been conducted, the data needs to be analysed (Dumas & Redish, 1999). As soon as the test has been conducted, a preliminary analysis is done so the worst, most urgent, problems are identified. This is done so that the developers can start to work on these problems while a more extensive analysis is conducted. The next step is to compile the data and summarize it. It can be beneficial

19

to start compiling the data during the test period to make this stage more effective. When summarizing the data, each question with a limited choice answer is separately summed up to give a clear overview of trends. The next step is to analyse the data to get a better view of trends and patterns. Important during the analyse is to identify all the task that does not reach the benchmark goal and the tasks where the participant did not solve the task in an intended way (Chisnell & Rubin, 2008).

3.5.6 Evaluation scales Grigoroudis & Siskos (2010) and Maurer & Pierce (1998) states that Likert scales are the most common one used in surveys. The Likert scale measures the agreement with a given statement, the scale consists of intervals that gives a degree of how much the participant agree within two adjectives of opposite meaning. According to Grigoroudis & Siskos (2010), there is no consensus on how many options of answers that should be present in a scale, but they mention that earlier research indicates that the scales should not constitute of more than five options. If choosing an odd number of options in the scale, one should be aware of that the participant might interpret that there exists a neutral option which could be used to express indifference.

20

4. Method In this chapter, the methodology of the project is presented. It is divided into the three phases of the project: pre-­study, implementation and evaluation.

4.1 Pre-­study This segment is related to the first iteration in the project, sprint 0. Firstly, an idea for the end product was formed as well as the basis for the product backlog. Within the time frame for sprint 0, a marketing plan was constructed as well as an NABC analysis. Furthermore, a simplistic prototype was designed and presented to the customer.

4.1.1 Marketing plan The marketing plan was initialised by a contemporary social and environmental analysis in order to examine the value of such a product on the market. Marketing strategies and goals were set based on the analysis. On a more detailed level, segmentation, customer targeting and market positioning were evaluated and set. Lastly, an examination of the ideal marketing mix was added so that pricing, product positioning, the value of the product and the right promotion was established. The idea of a fleet management web application was formed by having a conversation with the FBG. In addition to the requirement specification from the FBG, the project group aimed to add some more functionality to the web application. To develop and evaluate the idea, a NABC analysis was performed, aligned with the theories of Christian (2015). When proceeding with the analysis, a wider perspective of the market for the idea was considered. The idea was developed and evaluated towards general companies with a vehicle fleet, not only towards the requirements expressed by the FGB. The analysis helped the project group to assess the idea and identify functional aspects that the web application would include. Different aspects of the analysis were discussed within the project group, such as the needs of the market and the procedure in how to satisfy these needs, benefits with the idea and a competitor analysis. The discussion resulted in a number of key takeaways, which are presented in the result in this report.

4.1.2 Product backlog The user story for the product backlog was initially based on ideas created by the group during a concept generation meeting in the early stages of the project. Later on, as the customer provided the specification of requirements, supplements to the user stories were added to the product backlog. All user stories were given a specific priority, in order to create a scheme during the implementation stage of the project, which can be related to the theory presented by Otaduy & Diaz (2017).

21

4.1.3 Prototype The prototype that was compiled was based on the product backlog and the specification of requirements that was provided by the customer. As the requirements were given at an early stage of the project, along with the fact the customer gave the project group space to develop other functionality quite freely, the focal point for the prototype that was formed was to showcase the functionality and basic layout. The prototype showed the structure of the web application without specific regards to the actual implementation of the system. This is a prototype that is in line with what Rudd, Stern & Isensee (1996) call a low-­fidelity prototype, where the prototype only provides some basic visuals and workings of the finished product. An advantage with a low-­fidelity prototype is that it has a high value in early design process stage because it can easily be evaluated (Blackler, 2009) and the possibility of changing the design can be managed in early stages of the project. The main factors behind the decision to use a low-­fidelity prototype were that it was less time-­consuming and that it would facilitate the implementation stage. Rudd, Stern & Isensee (1996) argue that a high-­fidelity prototype can address navigational issues and it provides for realistic comparisons with other existing products. However, for this project, it would have been too time-­consuming and the matter of presenting functionality proposals in time for the customer was integral. Therefore, a low-­fidelity prototype consisting of wireframe mockups was created using the free software Balsamiq.

4.2 Implementation The implementation stage of the project relates to the rest of the sprints, sprint 1, 2 and 3. Sprint 1 related to the first implementation stage, where core structures for the application were formed. During sprint 1, basic navigational functionality and a vessel list were implemented. Sprint 2 was the iteration where fine adjustments and special functionality, as well as more specific functionality, was implemented. The back-­end structure was finished during this stage of the project. Sprint 3 was partly an implementation-­based iteration where finishing front-­end touches were made. The back-­end of the application was built with Python and by using the web framework Flask. Data was stored in a SQLite database and SQLAlchemy was used to access it. For the front-­end, the standard techniques used were HTML, CSS and Javascript as well as two large frameworks to simplify the process, jquery and Bootstrap. The database structure was designed by first creating an ER-­diagram which included the most important and initially necessary elements and then continuously and thoughtfully expanding it when new elements needed to be added throughout the project. The database was designed in such way that it would be simple and intuitive

22

to retrieve data from while still not having duplicates of too much data. See appendix D for the final ER-­schema. One requirement from the customer was the ability to log on to the application with different accounts with different levels of authorisations. To satisfy this, different HTML-­pages were rendered depending on what user was trying to access it (this was saved in something called “session” in the Flask framework). The user’s authorisation-­level was also checked on the server side every time an action needing a certain level of authorisation was performed.

4.3 Evaluation This part is related to the end of sprint 3, and partly the end of sprint 2. Three different user tests were formed and evaluated on the strength of the theory chapter.

4.3.1 Customer satisfaction testing The group chose to conduct a mail survey to evaluate the customer satisfaction. The survey was sent out to the FBG and the group expected to receive answers from three persons. The objective of the survey was to measure customer satisfaction and the general usability of the web application. The group chose to evaluate the following satisfaction and usability dimensions:

Design Navigation Simplicity.

A general question about the overall expectations and the overall satisfaction was added to the survey since this is standard in these evaluations which are discussed further in the theoretical chapter 3.5.4. Design, navigation and simplicity have a positive relation with customer satisfaction, these dimensions can be connected to the aesthetics and functional dimensions discussed in the theoretical chapter 3.2, and on some level also be assumed to be essential for the service provided by the web application. The dimensions were defined as: Design:

How appealing and serious the user perceives the web application to be.

23

Navigation: The user perception of how easy and intuitive it is to navigate on the web application.

Simplicity: The user perception of the simplicity of the functionality and design of the web application.

Later the questionnaire was developed. The introduction part of the questionnaire was made in the mail informing the customer about the questionnaire and its purpose. Questions about demographics were not used in this questionnaire since the customer is well known to the group. Neither behavioral questions were given much importance, although used to a small extent. When the customer entered the questionnaire, a list of actions was presented. This list consisted of performing basic actions that test the functionality of the page, such as:

Log in and out with different user types Change statuses on vessels Upload inspection documents Perform basic operations within the admin page.

After the customer had performed these actions, a set of questions were presented and the customer was asked to answer these. These questions are presented in the task list of appendix E.3.

4.3.2 Usability testing Common for both tests was the agenda with the following steps: 1. The participant was greeted. 2. A short introduction to the test was held. 3. Introducing the participant to the Concurrent Think Aloud concept and start the session whilst the participant was browsing the application.

4. Have the user perform a set of basic tasks, in accordance to what Dumas & Redish (1999) call real tasks, to test the functionality of the application.

5. Made the user answer questions in regard to the application’s navigation and simplicity etc.

Meanwhile each participant was performing tasks, a test moderator concentrated on finding troubles that the participant could have, related to the navigation of the application, e.g. how intuitive it was for the participant to find a functionality after being told to perform a specific action or how easily the participant could understand

24

what is clickable on the application. Test 1 Usability test 1 was conducted before the graphical user interface for the application was fully implemented. However, most functionality was set and implemented and the test set out to evaluate how well the functionality corresponded with the user’s perception of a similar application, which is what Chisnell & Rubin (2008) call an assessment test. The focus of this test was to get a view of navigational issues as well as issues regarding the simplicity of the application. The concurrent think-­aloud method was practiced at the start of every test, in order to understand initial issues with the application. Other questions asked during the test were related to Chisnell & Rubin’s (2008) theory about close-­ended questions. The participants consisted of a group of qualified friends, which is a cost-­effective alternative, easy to find and more unbiased than using internal participants for example. Test 2 Usability test 2 was conducted as what Chisnell & Rubin (2008) call a validation test. The test was set out to answer whether the application can be seen as simple and navigable, and if the goals of the application were met according to a user. As well as for test 1, a concurrent think-­aloud session was used at the start of every test. In this case, some tests were held per telephone. Upon creating this test, the question sheet that each participant had to answer was examined closer, in order to get results with enough substance to be examined and presented, which corresponds to Chisnell & Rubin’s (2008) “close-­ended questions”. The participants consisted of qualified friends and family, defined by Chisnell & Rubin (2008), where four of them had experience from working with a vehicle fleet. The last four participants were classified as representatives of the end user in accordance to Dumas & Redish (1999). 4.3.3 Scaling and evaluation

For evaluation of the user tests, a Likert scale was used with five options, from 1 to 5, which corresponds with the theory of Grigoroudis & Siskos (2010). The Likert scale was graded as follows:

1 → totally disagree 3 → agree 5 → totally agree

25

However, some questions were graded 1-­5 without having specific labels, when the purpose was basic and intuitive rating. A quantitative study was compiled with all test results from each test, which was later analysed into more generalisable concepts. The concurrent think aloud evaluation was based on the collocation of participants with a similar way of thoughts as well as spotting singular opinions and evaluating what factors that could influence this result and if there were any error factors to consider, which could make the result less reliable. During the test session, the test moderator both listened to the participant as well as interpreted distinct troubles or notable actions that were unclear. These were also taken into account while examining the concurrent think aloud-­practise.

26

5. Results In this chapter, the results of the project are presented. These are divided into the three categories pre-­study, implementation and evaluation.

5.1 Pre-­study In pre-­study, the resulting prototype that was developed in the beginning of the project is described. The results are presented such that the different prototypes of the web application are presented separately.

5.1.1 Marketing plan An NABC, see appendix B, was created to further develop the business idea of the project. The most important Need was identified as to obtain information about a vehicle fleet in an accessible way, this was to be solved with a customisable web application with the major benefits of it being cost effective and easy to use. In the marketing plan presented in appendix A, further analysis was made regarding the business idea and how the company, going under the name EasyFleet Inc, should act to establish themselves on the market. A marketing strategy was made using Ansoff strategies for diversification which resulted in that EasyFleet should establish themselves with a market penetration strategy, that is trying to reach out to customers on its existing market, which is the Swedish market. Furthermore, evaluation of Porter’s generic strategies resulted into that an overall cost leadership strategy was chosen to attract these customers, which means offering the product to the lowest price on the market. Analysis of the marketing environment, divided into macro-­ and micro-­environment, showed that the are few competitors on the market, there exist possible customers and that there exist no big threats in the macro-­environment. A segmentation targeting positioning (STP) strategy was used to identify the customers and the place of the product in the market. It resulted in that the best choice of a customer is private actors that have a reasonable amount of vessels, such as boat taxis, smaller ferry operators and touristic boat companies. To obtain these customers EasyFleet chose to position themselves as both an affordable and customisable alternative on the market. The market objectives were further discussed in the marketing mix using a 4-­P analysis, consisting of Product, Price, Promotion and Place. As for the product, the details of the included services and the focus of the product was discussed. A price strategy was developed and the distribution and promotion were considered to be

27

most effectively done on the internet.

5.1.3 Prototype The prototype is a low-­fidelity prototype consisting of wireframe mockups. Below, each part of the prototype is described. The prototype is attached in appendix C.

Home This is the default/home page of the web application. At the top, there is a simple navigation bar with three buttons. The current page is indicated by dark shading of the corresponding button. There is also a “Log in”-­button in contrasting colour on the far left side, that leads to the “Log in”-­page. The design is simple and minimalistic, and the number of elements is deliberately kept to a minimum. There is a text element which contains information about the service and an accompanying image element. The purpose is to provide the least amount of information that is required to give a simple overview of the service.

Home -­ logged in This is the default/home page of the web application, for users who are logged in. The navigation bar is exactly the same for all regular users, with the only difference being that users who are not logged in see a “Log in”-­button whereas users who are logged in see a “Log out”-­button in a contrasting colour. There are three key elements on this page. “Notifications” provides information about actions and events that concern the user or vehicles that are assigned to the user. “Calendar” provides information about scheduled events that concern vehicles assigned to the user. Finally, there is a “Vehicle register” which provides an overview of all vehicles and offers filtering capabilities.

Vehicle info Each vehicle in the “Vehicle register” is assigned to a page which contains detailed information about the vehicle, the usage history of the vehicle and the possibility to purchase services for the vehicle. The purchasing capability is featured using a button for each service available. There is also a possibility of returning to the previous page (i.e. “Home, logged in”).

Contact The key feature is a contact form which enables users to get in touch with the website administrators. They are asked to leave their name, email, subject and message. There is also an (optional) information element that accompanies the contact form. After having written their message and submitting it, the message will become available for administrators to deal with.

28

Login Regular users can login and authenticate through this page. The login form is simple and centered in the middle of the page. There is also a related “Remember me”-­checkbox, for users who want their login to be persistent. Above the login form is an (optional) placeholder for a logotype or similar image.

User profile page Each user is assigned a page which contains detailed information about the user and their vehicle usage history. It is also possible for them to update their information (if the ‘user administrator’ has granted them access) or change their password.

Admin login Administrators can login and authenticate themselves through this page. It is visually identical to the regular login page except for the title which clearly indicates that the page is only for administrator use. After a successful authentication, the user will be directed to the default admin UI (vehicle management).

Admin UI -­ vehicle management This page is only accessible to administrators. The navigation bar is populated with two additional buttons which are only visible and accessible to administrators. A “vehicle register” provides an overview of all vehicles in the vehicle database and offers filtering capabilities, as well as the possibility to modify or delete attributes and/or values. There is also a button for adding new vehicle objects, which redirects to an interface that handles communication between the front-­end and the back-­end.

Admin UI -­ user management This page is only accessible to administrators. The navigation bar is populated with two additional buttons which are only visible and accessible to administrators. A “user register” provides an overview of all users in the user database and offers filtering capabilities, as well as the possibility to modify or delete attributes and/or values. There is also a button for adding new users, which redirects to an interface that handles communication between the front-­end and the back-­end.

5.2 Implementation In the implementation chapter, the system overview describing the resulting functionality of the web application is presented. Additionally, the structure of the database is described and illustrated.

5.2.1 Technical overview The back-­end was written using the Python micro-­framework Flask. When needed for certain features, the appropriate flask extensions were used. For sending a mail to the responsible people every time a vessel changed status, Flask-­mail was used. For

29

authorisation, Flask-­login and Flask-­security were used. And when creating the admin page, Flask-­admin was used. In the front-­end, apart from the standard techniques, programming languages and frameworks, a few different external javascript plugins were used: FullCalendar and moment.js were used to simplify the implementation of the calendar and bootstrap-­datepicker was used in the implementation of datepickers.

5.2.2 System overview In this chapter, the functionality of each page in the web application is described.

Log in page

Figure 2: Log in modal. When accessing the web application, a log in button is instantly presented in the middle of the page underneath a headline that welcomes the user to the application. When clicking on the log in button, a modal including the log in form appears, and the background image is shaded (see figure 2). The modal has a white background and the header is named “Log in” and is in a light grey colour. The modal has one column including two text fields with the labels above and a button named “Sign in”. If the wrong log in details is typed in and the “Sign in” button is clicked, an error message appears. The modal can be closed down either by clicking on a cross in the upper right corner or anywhere else on the page. If the user closes down the modal or types in the wrong log in details by mistake, the text is stored in the fields of the modal. Directly when clicking the “Sign in” button, the home page appears on the screen.

Home page Here, the functionality on the homepage is explained in depth. The layout of the homepage can be seen in figure 3-­4.

30

Figure 3: Homepage, with number indicators for further references.

Navigation bar The navigation bar (see figure 3, number 1) is fixed on the top of the page when navigating on the web application. The logotype and name “EasyFleet” is on the left, and to the right “Admin”, “Account” and “Log out” is placed. When scrolling down the vessel list, an arrow appears on the bottom left side of the page which allows the user to directly go to the top of the page. When scrolling down the notification list, a direct link called “Go to top” to the bottom right directs the user to the top, and the same link appears at the bottom of the page underneath the vessel list when scrolling down the page.

Search bar A search bar is visible on the top of the home page where the user can search for a vessel in the vessel list or the notification list (see figure 3, number 2). To the right of the search bar is a button called filter. It can be used to filter the vessels on either their location or their vessel type.

Vessel list On the home page, a list of all the vessels in the database appears on the left side of the page (see figure 3, number 3). The list can be sorted by either length, speed or crew size by clicking on a drop down button that displays the alternatives. The list can be arranged by either increasing or decreasing order by clicking on a button with an image of two arrows. The buttons are placed above the list and are fixed to their positions when scrolling in the list.

31

Notification list On the right of the vessel list, notifications are displayed (see figure 3, number 4). Each notification is created by a user, and contains a title, a timestamp, a short description and two buttons. One button is for displaying more information about the notification, i.e when the vessel is expected to be fully functional again. The other button redirects the user to the vessel the notification is concerning.

Log out By clicking on the log out page in the navigation menu, the user is logged out and redirected to the startpage (see figure 3, number 5).

Figure 4: Calendar, containing an example of information about the status and booked inspections.

Calendar Underneath the notification list, a calendar is displayed (see figure 4). A monthly view is set as default though the user can change to a weekly or daily view. All notifications created by the user ends up in the calendar as a coloured block. It is possible to delete notifications from the calendar by dragging a block to a symbol of a bin which is located underneath the calendar along with an instruction on how to use the delete function.

32

Figure 5: Account page.

Account page In figure 5 the account page is shown. The account page is user-­specific. Regarding the functionality, there is a possibility to change your password and to review your service/order history. If the “Change password” button is clicked, a modal appears on the screen that requires the user to fill in their username and the new password, as well as repeating their new password. Underneath the section for changing the password, the user’s service history is shown in a list. Each historical service purchase contains a button that shows the receipt in a dialogue modal and a button for refunding. When clicking the refund button, a modal appears asking if the user is sure. If clicking “Yes”, the purchase is marked as a refund and put in another section with the title “Services refunded” underneath the section “Service history". It is possible for the user to delete the information about the refund by clicking on a delete button next to it, and to confirm the action by clicking “Yes” on a “Do you wish to delete this refund history?” modal.

Figure 6: Detailed vessel view, with number indicators for further references.

33

Detailed information about vessel By clicking on a vessel in the vessel list, a new page appears specifying information about that specific vessel (see figure 6, number 1). The title on top of the page is the name of the vessel, to the left of it, there is an image of an arrow that takes you back to the vessel list when clicked. The notification list shows notifications related to the current vessel, and the calendar is placed underneath it. On the page, there is a section with detailed information about the vessel along with an image of it. Underneath the information, there is a line of buttons named “Change status”, “Buy service”, “Book inspection”, “Change location”, and underneath them a button named “Inspection documents” (see figure 6, number 2-­6).

Figure 7: Change status modal.

Change status If a user clicks the “Change status” button (see figure 6, number 2), a modal is shown (see figure 7). It requires the user to fill in either the vessel is fully functional, partially functional or not functional with help of radio buttons, Title and a description of the status change and an estimated end date for the change. The user can submit the change or close down the modal, in which case the information just filled in is stored in the modal. When changing the status, the information from the previous status change for that vessel is pre-­filled in.

Buy service If a user clicks the “Buy service” button (see figure 6, number 3), a modal is shown showing the amount and a button named “Pay with card”. When clicking on the button, a new modal appears that lets the user provide email address, credit card information, a “remember me” option and a button, “Pay”. When clicking the “Pay” button, the user is redirected to the home page where the purchase is visible on the notification list.

34

Book inspection If a user clicks the “Book inspection” button (see figure 6, number 4), a modal is shown that lets the user provide a description on which inspection is needed, estimated start and end date.

Figure 8: Change location modal.

Change location If the user clicks on the “Change location” button (see figure 6, number 5) a modal is shown (see figure 8). The modal contains a function that lets the user change the location for a vessel from a current to the new one.

Figure 9: Upload inspection modal.

Inspection document The drop down button named “Inspection documents” (see figure 6, number 6) opens up a modal (see figure 9) with a description of which documents are acceptable to upload, lets you choose a file and add a description. When choosing a file, the user’s local computer library is shown and lets the user pick the desired file. On “submit”, a

35

dialogue appears and lets the user know the file has been uploaded successfully. The file is visible in a list underneath the button of the drop down menu, named as a timestamp and with the earlier description.

Figure 10: Admin page.

Admin page If having admin authorisation, the user has access to the admin page which is located in the navigation bar (see figure 3). The admin page (see figure 10) lets the user, for example, handle the database, get an overview of notifications made by employees and add employees to the database making it possible for them to log in to the web application. The user can whenever go back to the home page by clicking on a link marked as “Return to main page”.

Graphical interface The overall colour scheme consists of white, a slightly more grey shade of white called whitesmoke, black and two shades of green/blue. The background image at the log in page is almost plain coloured in green/blue but with some shading. The text is white and the button is a lighter shade of green/blue with a white hoovering. The navigation bar and the footer are dark green/blue with white text. The background colour is whitesmoke and all the text is in black. Buttons on the page and in modals follow the same interface with a dark green/blue background colour and white text. Hoovers are used with all buttons and come in a green/blue colour but different shades as background. Every other row in the vessel list is in the same colour as the background, whitesmoke, and every other is in another shade of grey. The hovering on all rows is in white. The links which allow the user to go to the top and the previous button on the detailed info page are in light grey. The rows in the notification list are separated by a horisontal black line which is also found as a divider between the detailed info about a vessel and the buttons for the various services. The contours of the calendar are in black and take place on a whitesmoke background. The admin page follows another colour scheme including white, grey and black. The

36

link that allows the user to go back to the home page is in the same light grey as on the rest of the page.

Dialogue modals The majority of the buttons existing in the web application opens up a modal for the specific matter. The modals have the same look when it comes to structure and graphical design (see figure 7, 8 & 9). The background colour is white, the header light grey where the purpose of the modal is shown as a title. Each text field has a label placed above the field, which are all places in one column structure. The modals have two buttons at the bottom to either submit the information or close the modal. By clicking on the cross in the upper right corner or anywhere else on the page, the modal is closed. The information put into the modal is automatically saved and stored if the modal is closed down either by submitting or closing the modal.

5.2.3 Database structure The database structure consists of seven prime classes, where the vessel class is the focal element. A vessel can have equipment, such as special equipment attached to that specific vessel, e.g. tow bar. A vessel must have an employee whose responsible for that vessel, whereas that employee makes notifications that concern a specific vessel. These notifications can be a purchase, refund or a status update. A vessel is located in a station and can have inspection documents attached to it. The whole database structure is visualised in the ER-­diagram in appendix D.

5.3 Evaluation In the evaluation chapter, the results of the user tests and the customer satisfaction tests are presented. The results for each question in the tests are presented along with notes from the concurrent think aloud tests.

5.3.1 Usability testing

Test 1 Six people participated in this test. The participants were qualified friends with experience from web application development. More raw data can be found in Appendix E.1. On a scale from one to five (where 1 equals to disagreeing, 3 means that you agree and 5 means that you totally agree) how well do you agree with the following statements:

37

Table 1: Result from usability test 1.

Concurrent think-­aloud session During the concurrent think-­aloud session, opinions were widely spread across the participant group. One common thought was that the colours, design-­wise were satisfying. Other thoughts were that the application could be seen as good for its purpose and well planned, although there were some troubles regarding responsivity of some implemented functionality. Divided opinions regarding simplicity and ease of use came up, as some participants agreed that it would become easier after the user got used to it, and some thought it was easy and simple overall from the beginning. As to navigation, the test group was divided in general as well. Issues were raised regarding the scroll functions which could be more structured and some participants meant that there were navigation issues basically because of the amount of information that each page contained.

Test 2 Seven people participated in this test. The participants were qualified friends and family with experience from working with vehicle fleets. More raw data can be found in Appendix E.2. On a scale from one to five (where 1 equals to disagreeing, 3 means that you agree and 5 means that you totally agree) how well do you agree with the following statements:

38

Table 2: Result from usability test 2.

Concurrent think-­aloud session Common positive response from the group of participants was that the styling and design were likeable and that the application was easy to understand. On the other hand, one participant had a hard time understanding the entirety of the application and some of the basic functionality of the application. Common troubles that the group had found was that the test vehicles that could be found within the vessel lists had weird labels (names) and that the go to top-­function or scroll functions were not performing as the tester expected. Moreover, the site could be seen as minimalistic although it was not necessarily a good thing, as it resulted in endless scrolling through a big list instead of keeping the view more thorough. Nevertheless, there was also positive feedback to the small view of the vessel list. Feedback regarding the calendar and admin page was mostly positive and related to its simplicity.

5.3.2 Customer satisfaction test This data was based on compiled answers of from two contact persons at the FBG. Raw data can be found in Appendix E.3. One person did not have the opportunity to answer the survey and gave general input instead. On a scale from one to five (where 1 equals to disagreeing, 3 means that you agree and 5 means that you totally agree) how well do you agree with the following statements:

39

Table 3: Result from customer satisfaction test. General input The application was clear and well structured. The application is easy to implement in an internal system. One complaint was that the ability to insert future reparations and docking was missing. The fact that the application had a user hierarchy was believed to improve and support trustable information.

40

6. Discussion In the discussion, the result of the project will be discussed followed by a discussion about the methods user to reach the result along with source criticism. Moreover, the effects of the project in a societal perspective are discussed in terms of ethical and societal aspects.

6.1 Result In this chapter, the result will be discussed. Firstly, the prototype will be compared to the results as a part of the pre-­study. Secondly, the implementation will be discussed in terms of usability from navigation and simplicity, along with weaknesses in the project. At last, the results from the acceptance tests and customer satisfaction will be discussed in an evaluation purpose.

6.1.1 Pre-­study Comparing the prototype with the result of the web application, many similarities can be distinguished. The views of the home page, account page and detailed info page was implemented nearly entirely the way as seen in the prototype, including the functionality seen in the prototype. Of course, some graphical design aspects were implemented differently in the result. The main difference that can be observed is that the contact page was not implemented. Further along the project, the project group realised that this functionality is not needed for the FBG since they will not need to contact anybody in the company in that sense. Neither was the “Log in” page implemented in the navigation bar, because of the requirement that the user have to be logged in to have access to the information in the web application.

6.1.2 Implementation In this segment, discussion concerning the connection between the question formulation and the actual implementation phase will be brought up.

Navigation According to Issa & Isaias (2015), aiming for a minimalistic design is desirable when striving for good navigation. Furthermore, Kontratova & Goldfarb (2007) support the choice of a neutral, white background colour and light grey shades for some elements on the application because it makes the base look clean and simple. The contrast that is created with the dark blue/green colour such as buttons and the navigation bar gives some depth to the application. The colour scale combined with the choice of not having any large pictures keeps the user from being distracted by what is not important on the page, according to Fang & Salvendy (2003). The “Go to top” links at the bottom of the vessel and notification list were placed and named in the same way to make navigation in the list consequent, in compliance to Nielsen & Loranger (2006).

41

To let the user know when typing in the wrong password or username, error messages are being presented on the screen. This is, according to Nielsen (1994) and Squires & Preece (1999), satisfying the usability in terms of error prevention. The possibility for the user to quickly return from a modal window by either clicking on an exit button or anywhere else on the screen is also supporting usability in terms of leaving the function if chosen by mistake. Leavitt & Schneiderman (2006) mean that important information should be put at the top of the page as a result of eye tracking studies, the placement of these elements and functions was placed according to the theory. The navigation bar is hence placed at the top of the page and the search function is placed directly underneath it because it is a central part of the web application. Combined with the theory of Whitenton (2016), the logotype was placed at the top left corner at the navigation bar and is furthermore clickable. This placement and style simplify navigation for the user, who will spot the logotype quickly and be reminded of its presence at the web application which is an important navigational aspect according to Issa & Isaias (2015). The logotype was made clickable to make it possible for the user to always be able returning to the homepage, which enhances easy navigation in accord to the theories of Leavitt & Schneiderman (2006). The navigation could be improved in some aspects. The log out button logs out the user directly when being clicked. This goes against Nielsen & Loranger (2006) theory about not using over-­sensitive functions. One way of solving this matter is to implement a “Are you sure?” dialogue to make the user confirm the action. At the “Account” page, there is no button that directs the user back to the home page. According to Nielsen & Loranger (2006), an inconsistent way of navigating can lead to discomfort. Having these effects on a user can risk the overall user experience and lead to a decreased customer satisfaction. To prevent this, a similar previous page button could be implemented as the one existing on the detailed info about a vessel page. Similar concerns regarding the admin page can be raised, where the same solution can be implemented. The graphical interface of the admin page does not compile with the rest of the application. This can in some terms clarify that the user is at the admin pages, but in some sense confuse the user by not having any sign of that the page belongs to EasyFleet. Regarding Lee, Moon & Kim (2007), integration should be made such that components should be put in a framework that feels intuitive to the user. The project group agrees on that the admin pages could be developed to fit the overall graphical interface, and to include a logotype. In order to maintain a fundamental cornerstone for navigation, in compliance with the studies of Issa & Isaias (2015), a navigation bar which could be found on each page

42

of the application was formed. The navigation bar was designed to be minimalistic, with few options and links to other application views. As the application was set out to handle a relatively large amount of data elements within different lists, a search function, as well as a filter function, was formed to simplify basic navigation for the user. In order to prevent the user from shifting its attention while browsing and reviewing freely, the structure of the navigation was static among each layer of the application. In addition to this kind of functions, scroll bars were implemented in order to make lists navigational. An important factor was to keep each scroll-­function moderately responsive to not create over-­sensitive functions which can mislead the user’s attention, in accordance with the studies of Nielsen & Loranger (2006). A core structure for the labeling of links was formed, consisting of minimalistic and consistent labeling. As for searching and filtering mechanisms, names and links within them were coherently set in order to preserve a logical way to follow the user’s actions at the application. This approach follows the patterns presented by Nielsen & Loranger (2015) among others. To obtain user control and freedom, all modules have an exit button at the top right corner and does also exit when the user clicks outside of the modal. When entering the page for detailed information about a vessel, there is a button at the top left side of the page to make it easy for the user to return to the home page when wanted. When navigating in the application, the home button is always accessible to return to the home page. In some modals existing in the web application, the user is required to fill in a date in a form. The date can either be chosen by typing in the date manually or by clicking on a specific date in a calendar which appears when clicking on the text field. The two possible options are implemented to support the studies of Jarrett & Gaffney (2009).

Simplicity The discrete and minimalistic design combined with the highlighted status symbols makes it easy for the user to quickly find information about the status of a vessel. The inspection and technical status symbols are coloured in red, yellow and green. This combination is generally known from the red-­light system which is highly recognisable. Keeping the background discrete along with the lack of complexity in design makes the application simple. (Nielsen, 1994) With the support of the theory of Kalbach (2007), which point out the advantages of using sans serif fonts in web applications, the sans serif Verdana was chosen. The choice keeps the letters from clogging together on screens and makes it simple for

43

the user to read the information. During the implementation, decisions regarding how to style the web application and how to present information to make it simple were made. In compliance to the theoretical reference frame of Fessenden (2017), modals were implemented to simplify processes for the user that requires the user to be focused and mentally involved. Changing technical and inspection status for a vessel are among others examples of processes made simpler. The modals existing in the application are structured the same way, it gives a consistent using experience for the user. Together with the fact that the modals follow the same graphical design interface and do not include any unnecessary information, the aim for usability in terms of simplicity is satisfied. The vessel list can in some meaning have the disadvantage to show a small number of vessels at the same time. This can aggravate the overall view of the vessels, which decreases simplicity as a matter of not prioritising the essential tasks of the application (Lee, Moon & Kim, 2007). To make the list show more vessels at the same time, either each row can be shortened or the view of the list can be implemented larger. Hence, the project group agrees on that different meanings can conflict here because of different opinions in the feedback from the FBG. Reduction and prioritizing are two of the key components to simplicity in an application (Waloszek, 2004). Different choices in the design of the application were made in regards to these. On the list view page, only the most necessary info was displayed. This was done to reduce the interface complexity. On the vessel info page, only the buttons connected that were needed for the essential parts of the application were placed. Adding additional buttons and functions would take focus from the prioritized functionalities. To obtain a structure in the application that is organised, features with similar functionality were grouped together. For example, all the buttons that open up a modal were grouped together on the detailed info page, while the button “Inspection Documents”, that does not open a modal, was placed a bit below the other ones. Also, to accomplish a better overall structure, each component was given a specific spot on the page that does not change if the user is on the detailed info view or the list view. When integrating the different components, focus was put on giving the application a simple structure. The main page was designed to give a good overview of everything and all the features and information was placed so they could be reached in an intuitive way with a very few number of clicks. This way, the hope was that the user wouldn’t even have to reflect on the structure of the application. It also helps reducing the procedural complexity of the application (Waloszek,2004).

44

Another action taken to improve the simplicity was making sure there was consistency in the use of text and images throughout the application, reducing the terminological complexity.

Cooperation and Communication To promote better cooperation and communication, firstly a user-­hierarchy was implemented. The hierarchy consisted of three different user roles, a read only-­role, a read write-­role and an admin-­role. The read only-­role had the ability to read the information about status updates and other notifications, but the inability to change any information that is provided on the site. The read write-­role had the ability to change status and purchase service but had the same interface as a read only-­role besides that. The admin-­role had the ability to enter an admin page which could change vessel names, add users and administer the site overall. This should ensure that the information is both credible and of quality that can be related to the studies of Pinto & Pinto (1990). To implement an application to simplify communicational issues and decision-­making, especially to provide necessary information for non-­mundane decisions, a historical notification view of a vessel was implemented. From a managerial standpoint, it can ease its decision making. On the other hand, it also gives coherent information for all users without using local systems with information that needs to be passed on per e.g. word-­of-­mouth or other internal communication ways, in a way that connects to the theory of Felix (2009). Furthermore, an automated mail server was used in order to get accurate and timely information for the people responsible for a vessel, in order to provide with warnings and simplify communicational issues.

6.1.3 Evaluation Below, discussion with reference to performed usability and customer satisfaction tests will be raised.

Usability tests The tests that were conducted provided good feedback for the application regarding both design and functionality. Because the application was developed to fulfill specifications set by the customer, some parts of the application may not have made sense to testing persons not employed by the customer. For example, the Finnish names in the application that lead to confusion. Distinctive feedback was that it was easy to navigate and to get a quick and accurate overview of the vessels in the application. Also, the choice of design and colours were perceived to be satisfying, which is backed up by the theory from section 3.3. This could to some extent lead back to the core of the question formulation and somewhat validate design choices made during the implementation stage. Due to

45

lack of specificity in the question about navigability in the user test, it is hard to point out what parts of the implementation that contributed to this result. Feedback from the concurrent think-­aloud test expressed problems with the scroll functions on the entire page meaning that it was difficult to scroll outside of the vessel list view and the notification list view. This indicated that the navigation in this point of view could be improved. Better navigation concerning the scroll functions could be achieved for example by having more blank space between the left and right sections on the home page in the application. Some critique was pointed to the vessel list, meaning that the rows were taking too much space resulting in a lot of scrolling. This can also be related to the theories regarding over-­responsive functions by Nielsen & Loranger (2006). The design was created based on the customer’s request and could have been discussed with them further.

Customer satisfaction When evaluating the customer satisfaction of the FBG, the result of the test they took part of is evaluated. The question that asked if the participants from the FBG were satisfied with the project got scores 4 and 5 on the 1-­5-­degree scale. This indicates that the customer satisfaction, for this project specifically, in its whole is high. Moreover, they believe that it is easy to navigate and simple to use because these questions got the same grading. This can be used as evidence to prove that the question formulation had been answered to a certain degree, since it is also backed up by Kassim & Asiah Abdullah (2010) and McKinney et. al (2002), because they mean that there is a clear correlation between increased simplicity and navigability and increased customer satisfaction. Although, it is possible to argue whether the customer satisfaction was high due to low expectations or not, as customer satisfaction partly is a function of expectations and disconfirmation as presented by Oliver (1980). The question regarding initial expectations and to what extent these have been realised are essential in the evaluation of these tests. Initial expectations were 3 on the Likert scale, meanwhile, the extent of which expectations were fulfilled rose to a 4. One interpretation is that setting clear and not too advanced initial expectations can lead to higher satisfaction, which is also supported by the theory presented by Oliver (1980). Although, some points of improvement were highlighted. Whether the web application would be useful in their daily work got 3 and 4. This can have to do with that they, after being introduced to the web application, came to the thought of other functionality they would like to be included. Due to the lack of time for implementing

46

these types of further implementation, the project group believes that it is difficult to reach these types of expectations regards to the hard deadline of the project. A score of 3 and 4 was given on communication, whether the web application provides better opportunities for the communications in the organisation. Nonetheless, it can be hard to visualise this matter without using the application for a longer period of time. To determine if the web application improves the cooperation between different departments is hard due to this, and can better be evaluated when the system is in use. However, among the general input from FBG, it was stated that the user hierarchy was said to support the credibility of the information on the web application, which is a factor that can support the overall cooperation according to Pinto & Pinto (1990).

6.2 Method In this chapter, the methods used during the pre-­study, implementation and evaluation will be discussed. In the pre-­study, the development of product backlog, prototype and the explanatory study was discussed. The choice of sources will also be discussed.

6.2.1 Pre-­study During the pre-­study, most items in the product backlog were selected by various discussions and tools within the team. The customer was only partly involved in developing the first product backlog. However, the input from the customer was not enough to design the whole backlog necessary for the product. Due to lack of information from the customer, the team was obligated to make their own assumptions of whether a function was necessary or not. The team also had to make assumptions about how and by whom the application was going to be used, which is not standard of how a backlog should be developed according to agile methodology, in compliance with Otaduy & Diaz (2017). This resulted in that the original product backlog had to be re-­done a couple of times, depending on when the customer gave input, as is often done in a scrum project according to García-­Magariño et. al. (2009). A general prototype was developed and used for the project during the pre-­study. It was not very specific and due to that the backlog changed a lot it, and it was not possible to regularly update the prototype. Blackler (2009) states that having a more high-­fidelity prototype could have improved the overall view of the webpage. It could also help members develop the webpage with more consideration of front-­end from sprint 1-­2 instead of having to re-­do majority of the design in sprint 3. In order to achieve higher customer satisfaction, it would have been relevant to have

47

an exploratory study with the customer, as presented by Chisnell & Rubin (2008). By testing the product at an early stage it could help get a better picture of what was expected and have a space of open discussion and understanding. This could have helped the team to set guidelines with the customers expectations and need.

6.2.2 Implementation An agile work methodology was established during the project. This was an issue when it came to recurrent feedback from the customer, Otaduy & Diaz (2017) argue that this is usually done after each sprint in a user acceptance test. The customer was not always prepared to give feedback to a satisfying extent. This affected the overall perception of how the project was going to be structured (product backlog, sprints and user tests). This may be due to bad information about work methodology and as discussed above: not sufficient planning or lack of standards of communication. Replicating the thesis could be seen as complicated, especially in regard to the customer satisfaction segment, since it is highly dependent on the actual customer. Another customer could have had other demands and needs in regards to the application, which is followed by other perspectives of e.g. simplicity and navigation. With this in mind, it can be hard to follow the given method in this thesis.

6.2.3 Evaluation The questions in the evaluation forms used a 1-­5 grading system. By having an odd number of option gives the user an option of being neutral, as Grigoroudis & Siskos (2010) states. In the case of evaluating navigation and simplicity, a non-­odd grading system would maybe have been more constructive as the user always has to give a positive or negative opinion. On the other hand, when evaluating the design it is possible that the user sometimes does not have any opinion and a 1-­5 scale may be of better use. However, the group chose to set the third choice to agree, while the first choice being “strongly disagree” and the fifth choice being “strongly agree”, to force the answerer to give his opinion and not express indifference in any questions. When evaluating customer satisfaction a usability test was conducted with follow-­up questions with the goal to measure how well the result is in line with the initial expectations. To achieve a valid result when conducting a usability test, according to Chisnell & Rubin (2008), at least 4 to 5 participants are needed. Faulkner (2003) states that at least 10 participants are needed to achieve a statistically valid result. However, in this case, only three members of FGB gave input on the web application. Criticism towards this kind of method can be brought up, although the purpose of the customer satisfaction test was to evaluate whether or not the organisation was satisfied with the project. The customers, in this case, were the organisation and the two contact persons, as well as one member of the vessel unit directorate, that represented the FBG’s interests as an organisation. To ensure a valid result at least

48

4 to 5 participants from FBG would have been preferable but because the availability of participants was low from FBG’s side, this was not achievable. The group chose to conduct a mail survey to evaluate the customer satisfaction. The survey was sent out to the FBG and the group expected to receive answers from three persons. The objective of the survey was to measure customer satisfaction and the general usability of the web application. The group chose to evaluate the following satisfaction and usability dimensions:

design navigation simplicity.

A general question about the overall expectations and the overall satisfaction was added to the survey since this is standard in these evaluations which are discussed further in the theoretical chapter 3.5.4. While examining the reliability of the project, it is essential to discuss the techniques used in measuring the results. Surveys were handed to the FBG and the two usability tests were based on a kind of interview. Some of the participants in the usability tests were categorised as qualified friends, described by Chisnell & Rubin (2008). It is essential to question these results because it may be the case that, because of social factors, the participants did not advocate full honesty during the time of the test, especially in the case where the test consisted of a personal interview. Nonetheless, Chisnell & Rubin (2008) mean that there is a risk of bias, but that it is a qualified method in concern to its time and cost effectiveness. As for the validity of this project, one can argue that some questions raised in tests and surveys were too vague. This has to be taken into account in evaluating the results. Furthermore, each test participant had to answer questions regarding the navigability of the web application. Concerns in connection to the discrepancy of a test participant perspective of navigability or any other concept during tests and this thesis project’s theoretical definition of usability concepts are essential in evaluating the project’s validity and reliability. However, the theoretical concept of web navigation is built on scientific research with human interaction, which is beneficial for the tests and surveys presented in this project. Moreover, the customer satisfaction tests were set out to measure FBG’s overall satisfaction with this project. As customer satisfaction, in general, is a broad concept which creates the same issues as with the two usability tests.

49

6.2.4 Source criticism Many of the references used in the theory, regarding usable web-­design, were written during the 90’s. In terms of internet and web-­development, there has been a lot of change these last 20-­30 years. The technology has improved and the way of using the internet has changed. It is possible that the theory developed during the 90’s is outdated and no longer accurate. However many of these references are well-­cited in a newer publication which might support their relevance. In some areas, a very small variety of different authors is used. When discussing usability, the most frequently used source is Jakob Nielsen. He is commonly used as both as primary and secondary source. Such small variety can be criticised for only providing the theory of one (or a few) authors and therefore being one sided. In other areas such as design, there is a larger variety of authors. These can be considered more credible.

6.3 The project in a broader context This chapter discusses the work accomplished in the project and places it within a broader context by adopting a higher perspective. In particular, the ethical and societal ramifications of the project are considered.

6.3.1 Ethical aspects Security and privacy are two important aspects of online ethics. While the customer did not explicitly state any security requirements, common sense and sound engineering principles stipulate that any system should be designed with security in mind. This mindset was further reinforced by the special nature of the customer, a national agency subordinate to a government body. From a user perspective, the arguably most important factor is that their personal information remains both secure and private. From a system perspective, prevention of unauthorised access was the main concern. Hence, both privacy and security were factors to take into consideration when designing the structure of the web application. A contract was established between the project group and the customer, which stipulates that the system would be provided “as-­is” for the final delivery. In other words, when the customer takes ownership, they will also assume all associated responsibilities. This exoneration clause relieves the project group of responsibility for any security vulnerabilities or other flaws discovered at a later time. Only a minimum of security testing was performed before final delivery but this was deemed an acceptable compromise due to the system having to undergo more extensive testing once in the customer’s ownership.

50

The contract also stipulates certain arrangements regarding ownership of the intellectual property associated with the project. The project group retains full rights to use the codebase for both non-­commercial and commercial purposes, but may not make use any specific information associated with the customer. From an ethical point of view, this was seen as a reasonable compromise between the customer’s need for privacy, the overall need for security and discretion associated with the sensitive nature of the project, and the inherent rights of the project group as the de facto developers of said intellectual property.

6.3.2 Societal aspects EasyFleet, being a Swedish project with a Finnish customer, must be taken into consideration in social, political and legal aspects. The need for improved overview and accessibility of information regarding a vehicle fleet is far from unique to the project customer. As outlined in the marketing plan in Appendix A, there is a market opportunity to be found in the overall trend of digitisation. Communicating and performing administrative tasks more efficiently enables organisations to divert more time and attention to their core competencies. The nature of the customer means that the product has to undergo stringent security testing and adhere to certain standards before being used in-­production. Furthermore, ensuring correct handling of potentially sensitive government information has political and legal implications. This was beyond the capabilities of the project group and therefore, testing and certification were left to the customer.

51

7. Conclusion As for customer satisfaction, first of all, you can say that setting realisable initial expectations can lead to higher customer satisfaction. To some extent, focusing on simple design, simplicity and navigability while implementing a web application has also shown to affect the customer satisfaction in a positive way if you take the customer satisfaction test into account, which is also backed by theory (Straub et al. 2002) (McKinney et al., 2002). But it is hard to believe that general conclusions can be made based on this study since another customer could have had other opinions and customer satisfaction is a widely spread and complex research field. One way of developing a web application with simplicity and navigation in mind is to utilize reduction and minimalistic design (Issa & Isaias, 2015), to direct focus to the most essential parts (Lee, Moon & Kim, 2007), in our case the vessel status symbols and the notification. Modals have the advantage of simplifying complicated processes that require a high involvement from the user (Fessenden, 2017), and the font sans serif is favourable in digital media presented on screens (Kalbach, 2007). In the web application, navigability is promoted by a clear overview of vehicles as well as having a static and constantly reachable navigation bar at the top of the page. Moreover, homogenous design as for example consistency in labeling and navigational structure has shown to be important in this case to support navigation. (Issa & Isaias, 2015) (Nielsen & Loranger, 2006). It has also been shown that error preventive messages are of importance regarding navigation (Squires & Preece, 1999). The overall communication and cooperation within an organisation can be positively impacted by having a user hierarchy with different levels of responsibilities and possible actions, which supports reliability and quality of the information that flows on the application (Felix, 2009). However, it can be hard to generalise this matter and no direct conclusions regarding improved interdepartmental cooperation can be made, other than the fact that the customer seemed to agree on that the application would improve the cooperation between different functions within their organisation. It is also hard to generalise any type of conclusions regarding this project because the usability and customer satisfaction tests could be a bit vague in order to evaluate how to implement a navigable and simple web application. Also, some implementations features were not backed by theory because some decisions were solely based on the opinion of FBG. If the time frame of the project would be extended, further development of the web application would be carried out based on the outcome of the customer satisfaction tests. Specifically, implementation towards a consistent graphical interface on all pages in the web application would be carried out. To exemplify, having the same

52

design on all pages and place the previous buttons at the same place would be focused, in order to encourage the user to administer the same navigational patterns throughout the application (Nielsen & Loranger, 2006). Also, some adjustments to the vessel list would be made after further conversation with FBG to fit their preferences of the size of the overview.

53

8. References Alam, S. S., & Yasin, N. M. (2010). An investigation into the antecedents of customer satisfaction of online shopping. Journal of Marketing Development and Competitiveness, 5(1), 71. Blackler, A. (2008). Applications of High and Low Fidelity Prototypes in Researching Intuitive Interaction Prototype Fidelity. In Proceedings of the Design Research Society Conference. Cheney, P. H., & Dickson, G. W. (1982). Organizational Characteristics and Information Systems: An Exploratory Investigation. Academy of Management Journal, 25(1), 170-­184. Chisnell, D., & Rubin, J. (2008). Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests (2nd Edition). Indiana: Wiley Publishing, Inc. Christian, N. (2015). The NABC Method from Stanford Research Institute. De Angeli, A., Sutcliffe, A., & Hartmann, J. (2006, June). Interaction, usability and aesthetics: what influences users' preferences?. In Proceedings of the 6th conference on Designing Interactive systems (pp. 271-­280). ACM. Dumas, J.S., & Redish, J. (1999). A practical guide to usability testing (2nd edition). Portland: Exeter Intellect. Eid, M. I. (2011). Determinants of e-­commerce customer satisfaction, trust, and loyalty in Saudi Arabia. Journal of electronic commerce research, 12(1), 78. English, J., Hearst, M., Sinha, R., Swearingen, K., & Lee, K. P. (2002). Flexible search and navigation using faceted metadata. Technical report, University of Berkeley, School of Information Management and Systems, 2003. Submitted for publication. Fang, X., & Salvendy, G. (2003). Customer-­centered rules for design of e-­commerce web sites. Communications of the ACM, 46(12), 332-­336. Faulkner, L. (2003). Beyond the five-­user assumption: Benefits of increased sample sizes in usability testing. Behavior Research Methods, 35(3), 379-­383. Felix, A. O. (2009). Management information system to help managers for providing decision making in an organization. Management, 1(1), 24938. Fessenden, T. Nielsen Norman Group. (2017). Modal and Nonmodal Dialogs: When (and When Not) to Use Them. Viewed 18 May 2017 from https://www.nngroup.com/articles/modal-­nonmodal-­dialog/ Gao, Y. (Ed.). (2005). Web systems design and online consumer behavior. New Jersey: IGI Global.

54

García-­Magariño, I., Gómez-­Rodríguez, A., Gómez-­Sanz, J., & González-­Moreno, J. (2009). Ingenias-­scrum development process for multi-­agent development. In International symposium on distributed computing and artificial intelligence 2008 (DCAI 2008) (pp. 108-­117). Springer Berlin/Heidelberg Grigoroudis, E., & Siskos, Y. (2010). Customer Satisfaction Evaluation: Methods for Measuring and Implementing Service Quality. New York: Springer Verlag. Houde, S., & Hill, C. (1997). What do prototypes prototype. Handbook of human-­computer interaction, 2(1), 367-­381. Issa, T., & Isaias, P. (2015). Sustainable Design: HCI, Usability and Environmental Concerns. London: Springer Verlag. Jarrett, C., & Gaffney, G. (2009). Forms that work: Designing Web forms for usability. Burlington: Morgan Kaufmann. Kalbach, J. (2007). Designing Web navigation: Optimizing the user experience. " O'Reilly Media, Inc.". Karvonen, K. (2000, November). The beauty of simplicity. In Proceedings on the 2000 conference on Universal Usability (pp. 85-­90). ACM. Kassim, N., & Asiah Abdullah, N. (2010). The effect of perceived service quality dimensions on customer satisfaction, trust, and loyalty in e-­commerce settings: A cross cultural analysis. Asia Pacific Journal of Marketing and Logistics, 22(3), 351-­371. Kondratova, I., & Goldfarb, I. (2007, July). Color your website: Use of colors on the web. In International Conference on Usability and Internationalization (pp. 123-­132). Springer Berlin Heidelberg. Leavitt, M. O., & Shneiderman, B. (2006). Research-­based web design & usability guidelines. US Department of Health and Human Services, 2(1), 44-­57. Lee, D., Moon, J., & Kim, Y. (2007). The effect of simplicity and perceived control on perceived ease of use. AMCIS 2007 Proceedings, 71(1). Lee, Y., & Kozar, K. A. (2012). Understanding of website usability: Specifying and measuring constructs and their relationships. Decision Support Systems, 52(2), 450-­463. Maeda, J. (2006). The Laws of Simplicity (Simplicity: Design, Technology, Business, Life). Majid, E. S. A., Kamaruddin, N., & Mansor, Z. (2015, August). Adaptation of usability principles in responsive web design technique for e-­commerce development. In 2015 International Conference on Electrical Engineering and Informatics (ICEEI), (pp. 726-­729). IEEE.

55

Maurer, T. J., & Pierce, H. R. (1998). A comparison of Likert scale and traditional measures of self-­efficacy. Journal of applied psychology, 83(2), 324. McKinney, V., Yoon, K., & Zahedi, F. M. (2002). The measurement of web-­customer satisfaction: An expectation and disconfirmation approach. Information systems research, 13(3), 296-­315. Nielsen, J. (1994, April). Enhancing the explanatory power of usability heuristics. In Proceedings of the SIGCHI conference on Human Factors in Computing Systems (pp. 152-­158). ACM. Nielsen, J. Nielsen Norman Group. (2012). Usability 101: Introduction to Usability. Viewed 13 May 2017 from http://www.nngroup.com/articles/usability101introductiontousability/ Nielsen, J. (2003). Paper prototyping: Getting user data before you code. Last Reviewed on September, 22, 2007. Nielsen, J., & Loranger, H. (2006). Prioritizing web usability. Pearson Education Oliver, R. L. (1980). A cognitive model of the antecedents and consequences of satisfaction decisions. Journal of marketing research, 17(1), 460-­469. Otaduy, I., & Diaz, O. (2017). User Acceptance Testing for Agile-­developed Web-­based applications: empowering customers through wikis and mind maps. Journal of Systems and Software. Pinto, M. B., & Pinto, J. K. (1990). Project team communication and cross-­functional cooperation in new program development. Journal of product innovation management, 7(12), 200-­212. Rettig, M. (1994). Prototyping for tiny fingers. Communications of the ACM, 37(4), 21-­27. Rudd, J., Stern, K., & Isensee, S. (1996). Low vs. high-­fidelity prototyping debate. interactions, 3(1), 76-­85. Sauer, J., Franke, H., & Ruettinger, B. (2008). Designing interactive consumer products: Utility of paper prototypes and effectiveness of enhanced control labelling. Applied Ergonomics, 39(1), 71-­85. Sims, C., & Johnson, H. L. (2012). Scrum: A breathtakingly brief and agile introduction. Dymax. Straub, D. W., Hoffman, D. L., Weber, B. W., & Steinfield, C. (2002). Toward new metrics for net-­enhanced organizations. Information Systems Research, 13(3), 227-­238.

56

Squires, D., & Preece, J. (1999). Predicting quality in educational software: Evaluating for learning, usability and the synergy between them. Interacting with computers, 11(5), 467-­483. Van den Haak, M. J., & de Jong, M. D. (2003, September). Exploring two methods of usability testing: concurrent versus retrospective think-­aloud protocols. In Professional Communication Conference, 2003. IPCC 2003. Proceedings. IEEE International (pp. 3-­pp). IEEE. Waloszek, G. SAP User Experience Community. (2004). Simplifying for Usability: Guide to Simplification. SAP Design Guild UXC. Viewed May 21, 2017 from https://experience.sap.com/basics/simplifying-­usability/. Whitenton, K. Nielsen Norman Group. (2015). Menu Design: Checklist of 15 UX Guidelines to Help Users. Viewed 18 May 2017 from https://www.nngroup.com/articles/menu-­design/. Williams, R., & Pollock, N. (2009). Beyond the ERP implementation study: a new approach to the study of packaged information systems: the biography of artifacts framework. ICIS 2009 Proceedings, 6. Lee, Y., & Kozar, K. A. (2012). Understanding of website usability: Specifying and measuring constructs and their relationships. Decision Support Systems, 52(2), 450-­463.

57

9. Appendix

Appendix A -­ Marketing plan

Introduction When companies use a considerable amount of vehicles as a tool in their operations a necessity to store information about their vehicle fleet arises. If this information is not stored in a way that makes it organized and accessible it might get outdated or overlooked. This is a common problem in companies now days and it might lead to overdue inspections or an inefficient usage of the available vehicles. To solve this problem, the Swedish and U.S. Coast Guard developed web applications that aim to give an overview of their vessel fleet. The project group came to realize that the Finnish Border Guard had expressed interest in a similar system and initialized a dialog with them which led to an agreement. The agreement stated that the group would develop a web application solution with the purpose of facilitating the storing of information about their vessel fleet. The solution aims to give the customer an accessible overview of the technical status of the vehicles used in a company, with the possibility to easily obtain more detailed information about the vehicles. The purpose of this marketing plan is to explore the possibilities for this concept and analyze what possible benefits and risks that could occur if the group were to create a company based on this concept. In this marketing plan, it is assumed that the company Easyfleet Inc was recently created. Easyfleet is a small company consisting of seven employees with their base in Sweden. This plan will first focus on which strategies that Easyfleet can make use of in order to establish the company and expand with primary focus on the Swedish market.

58

Marketing environment Market analysis is an important part of a market plan since it helps a company to identify potential possibilities and threats that might exist on the market. A company can be considered to be affected by forces that can be divided into the macro-­environment and the micro-­environment. The micro-­environment consists of actors that affect the company in its immediate area of operations, such as the company suppliers, marketing channels, customers, and competitors. The macro-­environment is defined by factors that affect the micro-­environment which lies outside the company’s ability to control (Kotler & Armstrong, 2016). Macro-­environment When analysing the macro-­environment, it is common to structure the analysis with the PEST method. PEST stands for Political, Economic, Social and Technical factors. These factors are external factors that the company cannot affect and therefore must adapt to in the best way possible. If a company adapts to these external factors well, they can make sure that the effect of these factors is positive instead of negative. Political: EasyFleet will primarily be active in Sweden and this will entail a set of laws that the company needs to abide by. Similarly, if the EasyFleet codebase is used for a customer located in another jurisdiction, this also needs to be taken into consideration. Some potential customers are connected to the Swedish government and to be able to sell to these groups, EasyFleet will have to follow the Swedish law about public procurement. Law (2016:1145) about public procurement states that the part of the government that is planning on procuring a product needs to evaluate all submitted tenders that meet the demands and special criterions set by the customer. This usually results in that the decision on which tender to take is based primarily on the price, provided that the functionality requirements are met by all tenders. This process can also take a lot of time and a well-­written description of the product have to be worked through. Economical: According to Konjunkturinstitutet (2017), Sweden is currently in an economic boom and the Swedish export companies are moving towards a potentially strong development. A lot of export companies either have a vehicle fleet or use the vehicle fleet of other companies. This can result in a lot of new customers who want to invest in EasyFleet’s product (Konjunkturinstitutet, 2017)

59

Social: Environmental trends on the Swedish market are pushing companies to work more with developing sustainable work processes. ‘The paperless office’ is a theme that has been active for some time but studies show that the adoption rate is slow. This can indicate that some companies exhibit a skeptic attitude towards new software services (ComputerSweden, 2016). Information can be of high value and the need of security is important. It is difficult to deliver assurances regarding the security of a web application. This can be a contributing factor to the skepticism regarding web-­based applications. Technical: The technical development is happening very fast. This can result in security standards or other parts of EasyFleet’s codebase becoming outdated and requiring improvements to stay up to date. EasyFleet must, therefore, be receptive to change. Applications need to be available in a usable way on both computers, smartphones and other devices such as tablets. EasyFleet’s product will, therefore, have to utilize a responsive design for maximum adaptability to a plethora of current devices as well as potential future developments. There is a risk that other programming languages supersede the ones currently used in EasyFleet. This is considered a low risk because the main languages Python and JavaScript have a long history of widespread usage and the TIOBE index from May 2017 show both Python and Javascript amongst the top 10 programming languages and having a positive usage trend (TIOBE, 2017). The demand for SaaS, Software-­as-­a-­Service, is increasing because more employees need to have information available on multiple sites. This is a trend that has a potentially positive impact on EasyFleet. (Veckans Affärer, 2017)

60

Micro-­environment The micro-­ environment consists of the company's customers, competitors, suppliers and the marketing channels. Customers EasyFleet's product is designed to meet the needs of companies whose operations include a large fleet of vehicles. EasyFleet will primarily target companies whose fleet is sufficiently large to be faced with difficulties in overview and management. The Finnish Border Guard is EasyFleet's first customer. The requirement specification from the Finnish Border Guard has laid the foundation for EasyFleet’s product. The product is developed with the intention of being easily adaptable to new customer requirement specifications. Potential customers may be companies engaged in transportation, such as courier companies, or services such as home or repair services. Other companies of interest are taxi or bus companies, car / boat rental companies and companies that have several work vehicles (e.g. trucks). Competitors There are no identified competitors whose product offers the same cost-­benefit mix as EasyFleet’s product.The alternatives are either costlier, such as a customized product made by consulting firms, or cheaper web-­based products that are not customizable and offer less functionality. There are several consulting firms in Sweden who are specialized in developing customized web applications for companies. These companies can pose a threat towards EasyFleet because they offer the same general product -­ a tool for fleet management. Customers might also need special features such as a graphical interface that suits their existing application ecosystem. EasyFleet’s product can to some extent be customized to suit a lot of customer needs. One key aspect that differentiates EasyFleet from other products is the low cost of development and subsequent customization. The other end of competitor spectrum is represented by competitors that offer cheaper products with no possibility to customize the product. These companies compete with EasyFleet primarily on a price basis, as they target customers that have the need for a fleet management system with few special features. The basic needs of these customers are easier to meet, and purchase decisions are made on a price basis rather than based on an evaluation of the functionality.

61

There are web-­based applications that offer features that are similar to those of EasyFleet’s product, but with a wider range of functionality such as GPS-­tracking of vehicles and other advanced features. These applications often require extensive training before use and are often subscription-­based. Most companies with a vehicle fleet have existing internal systems of varying complexity (databases, Excel spreadsheets, whiteboards) in order to keep track of status, inspections and other related information and tasks. The presence of existing systems can lead to a skeptic attitude towards new solutions. Suppliers The product is not a physical product and will therefore not require distributors as it can, and perhaps should be sold directly to the customer. There are a lot of suppliers of computer servers on the market, which mitigates the risk associated with the physical elements of this product. Marketing channels EasyFleet will primarily promote the product through web marketing, for example, a web page, and by contacting companies in person by using email. This because the customer segment is mostly defined by their use of a vehicle fleet and not by branch or geographical placement.

62

SWOT A SWOT analysis is conducted to summarise identified internal strengths and weaknesses, and potential external opportunities and threats.

Strengths

Flexible due to customizable Streamlines vehicle register Reduces the human error factor Increases communication Increases access to information -­ Real-­time information update -­ people everywhere will have the updated information

Weaknesses

Easy to replicate the basics -­ which means there is a risk of competitors.

Human errors -­ User can provide faulty information by mistake.

Newly started company -­ limited internal experience and financial resources

Not fully customizable to every extent

Opportunities New market segment Existing systems are time-­consuming for employees (low level-­human based systems)

Increased need for SaaS, Software-­as-­a-­Service

Potential trend to strive towards a paperless office

Threats Strong competitors (with a similar web application but stronger brand recognition or financial resources is potential competitors if deciding to enter the market.)

Skepticism towards new computer-­based systems

High technical development (might be hard to keep pace with the technical development)

Higher requirements for the product No computer available for responsible employee

63

Marketing Strategy Easyfleet’s marketing strategy will primarily focus on establishing customer relations on the Swedish market. As discussed earlier, the rivals are limited and there are good possibilities to expand in this market. Ansoff strategies for diversification To be able to formulate this strategy in further detail Ansoff strategies for diversification was used. This strategy is commonly shown in a matrix, see figure 1, below.

Figure 1, Ansoff matrix Ansoff (1980) describes four strategies for growth of companies, these are Product development, Diversification, Market Penetration and Market Development. Using a Product development strategy, a company focus on modifying the existing product line in order to attract new customers in a market where the company is already operating at. The Diversification strategy suggests that the company target customer areas in a market where the company is not operating and doing so with a new product. In a marketing development strategy, the company focus on attracting customer areas at a market where the company is not currently operating. Finally, a company that uses a market penetration strategy will either try to reach out to new customers in an existing market or increase sales to current customers with an existing product (Ansoff, 1980, p. 114). As discussed in the introduction, Easyfleet is a startup company and it is considered to have limited financial resources. Further development of the product would be both

64

time-­consuming and costly and is therefore not a reasonable alternative for Easyfleet in this moment. As discussed earlier, the segments of customers exist in areas that could be targeted at the market where Easyfleet are currently operating. Targeting these customers with the current product is the cheapest alternative for Easyfleet. This means that Easyfleet would follow a market penetration strategy. This strategy is also recommended for startups in the book Entrepreneurship and Small business: Start-­up, Growth, and Maturity by Paul Burns. Porter’s generic strategies Porter’s generic strategies suggest that a company can get a competitive advantage by pursuing one of the following three strategies;; Overall cost leadership, Differentiation or Focus (Kotler & Armstrong, 2016).

Figure 2, Porter’s generic strategies A company that uses the Overall cost leadership strategy competes over large market shares with help of the price of the product. The aim is to offer the lowest price for the product on the entire market. With a differentiation strategy, a company will focus on offering the customer a product that clearly stands out from similar products on the market. Finally, with a focus strategy, the company will target a smaller market segment and aim to get high market shares within this segment. If a company fails to follow any of these strategies it risks being “stuck in the middle”. The expression means that if a mixture of the strategies is followed, according to Kotler and Armstrong (2016), these companies tend not to have an efficient performance. On one hand, Easyfleet competes with far more advanced solutions, including competitors that offer fleet management solutions which contain a large variety of complex functionality. On the other hand, the systems that are made by the customer itself tend to lack necessary functionality and usefulness. Easyfleet’s solution could be useful for companies that are in need of having an overview and control over their vehicle fleet but does not need extra functionality such as GPS solutions developed for haulage firms. The solution that Easyfleet offers is thought to be simple, easy to use and can due to this reason be developed

65

and sold cheaper than most existing alternatives. This suggests that it is appropriate for Easyfleet to compete with price and hence following the overall cost leadership strategy that Porter presents.

66

STP Segmentation, Targeting and Positioning, STP, is a marketing model that is useful when creating a market strategy. The model helps to identify segments to which a product should be directed towards and establish a position in that segment. Segmentation The segmentation will focus to define macro segments using geographic, customer type, customer size, and product use variables. Geographic As mentioned earlier, Easyfleet is in a start-­up phase with limited resources with regards to both finance and manpower. Reaching new markets would be costly and time-­consuming. For this reason, Easyfleet will focus on obtaining customers that are close to the current operating area, which is Linköping in Sweden. Customer Type The desired customer uses vehicles in their operations in some sense. Furthermore, they need to have a significant size of their vehicle fleet to have the necessity to use a solution similar to the one that Easyfleet offers. However, companies that use vehicles as their principal tool to create value, for example, haulage firms or a company that provides transport by train, commonly have a need for a more advanced solution. Functionalities included in such a solution could be one that gives a more intense control over their fleet, such as route planning tools or GPS solutions. It is preferable that the company has more than one location from where they operate their vehicles since it motivates the need to have a centralized solution to keep control of the vehicle fleet. Customer Size The requirement that the customer needs to operate with a substantial amount of vehicles and that the company should be active at more than one location implies that the customer needs to be at least small to medium-­sized. Large-­sized companies can to a greater extent be assumed to have an existing system that keeps control over their fleet and is therefore not considered to be an ideal customer for Easyfleet in its current phase. Product Use The product is intended to be used directly by four groups of users:

Corporate management -­ to obtain information about the organization’s vehicle resources

Guidance head office -­ to access information about which vehicles that can be

67

used at a specific moment. The entity in charge of maintenance entity -­ to access information about the

current technical status of the vehicle fleet. Strategic managers -­ to access information about the future technical status of

the vehicle fleet in order to be able to plan maintenance and other operations. The solution is thought to be able to in first hand give a quick overview of the status of the vehicle fleet and in second hand be able to give detailed information about the specific statuses of vehicles. The product is intended to provide necessary information when having meetings about operation scheduling, maintenance planning, and fleet investments. But it could also be used in daily planning work and when evaluating the administration of the vehicle fleet. Targeting The goal with the targeting part of STP is to evaluate the encountered market segments from the segmentation and choosing which ones the business should enter (Kotler & Armstrong 2016). The Coast Guard is an example of a favorable customer for Easyfleet. First, their vessel fleet has a considerable size and they operate from several locations. Second, the Coast Guard does perform patrols and other operations where for eg. fuel control, optimal route planning etc is not essential for their service. The police, home care service, fire patrol and ambulance service are examples of organizations that resemble the core service that the Coast Guard provide. All these organizations operate in several locations, can be assumed to not have the need for advanced fleet management solutions and are in need to have a good overview of their vehicle fleet. Considering that procurement is a demanding process that could affect the possibility for Easyfleet to sell their product to the organizations mentioned above, it might be preferable to target the private sector. Security companies, smaller ferry operators such as taxi boat companies and archipelago ferries, are examples of companies that have had similar needs as the examples mentioned above and that operates in the private sector. Other interesting segments include medium-­sized companies in the private sector that use a vehicle fleet as a tool in their business, these companies can be operating in different sectors such as industries in engineering, chemical, construction and food sectors, but also smaller courier and taxi firms and tourists companies. Furthermore, this segment can include different types of companies that deliver a service or product to a consumer's home, such as carpenters and stores that offer home-­delivery, for eg. food stores.

68

Even though the product can easily be modified to work with road vehicles, the most appropriate customers can be considered to be companies that use a vessel fleet. Targeting smaller ferry operators, taxi boat companies and other touristic boat companies would require small to none changes in the existing solution, which means that EasyFleet possible could establish themselves on the market using this customer segment. Positioning Positioning is used to compare the product with competing ones on the market, in order to find a desirable and well-­defined place of the product (Kotler & Armstrong, 2016). The solution that EasyFleet offers gives the user a direct overview of the fleet, both in it’s current state and possibility to plan coming maintainance and works. When necessary it is possible to gain access to detailed information about a specific vehicle. An EasyFleet solution is made to be an affordable and customizable alternative, that’s simple and easy to work with. Many of the existing solutions on the market are advanced fleet management systems, which provide lots of functionality. EasyFleet intends to compete with these solutions providing a system that’s first cheaper than these solutions and secondly easier to maintain and use. Thirdly, although these advanced solution may contain overview and planning functionalities it’s not the main purpose of those solutions and for this reason, EasyFleet’s solution is preferable for companies that only have a need for overview and planning functionality. Besides offering changes to the customizable EasyFleet solution, EasyFleet also offers education on how to implement the system in an organization, technical support, and maintenance.

69

Marketing mix When analysing how EasyFleet will achieve the set of marketing objectives in the target market a 4-­P analysis will be used. A 4-­P analysis consists of defining decisions linked to product, price, promotion and place. Product The core product that EasyFleet offers is a web application that enables an

overview of vehicles, in order to simplify the cooperation between different departments in an organisation using a vehicle fleet.

The product is designed with a focus on usability regarding simplicity and navigation. The design of the product is therefore focused on making the application easy to use and easy to learn.

The product can be customized to some extent to fit the customer's need. The product will be installed on site. If the customer has problems with the product then service is offered for free during the first half year. After this period a service fee will be charged.

If the customer is not satisfied with the product it can be returned with full refund during the whole first year. After this period a return is not possible.

All EasyFleet’s products will be branded with EasyFleet’s brand. Price In the beginning, a price-­skimming strategy will be used. This means that the price offered to early adopters will be higher than later on in the product life-­cycle. EasyFleet’s product occupies a unique place in terms of features and functionality compared to competitors, which justifies the initial price premium. A high price will also indicate that the product is of high quality compared to competitors products. When EasyFleet has achieved a sufficient amount of customers, a value-­based pricing model will be introduced. The value-­based price will be based on evaluations of customers’ reactions related to the price of the product regarding the size of the vehicle fleet. This strategy will be used because companies with different amount of vehicles have different needs and will, therefore, value EasyFleet’s product differently. Promotion As stated above when analysing the micro-­environment, EasyFleet will mostly promote the product through web marketing (e.g. by using a web page) and contact companies in person by using email. This because the customer segment is mostly defined by their use of a vehicle fleet and not by branch or geographical placement, which necessitates more a personal level of marketing compared to mass marketing.

70

Place (Distribution) EasyFleet’s product is not a physical product and will therefore not be an item that can be sold at a physical location. The product can be bought either by contacting a sales representative or send a message via EasyFleet’s website. Because every customer might have different requirements, it is important to tailor EasyFleet’s generic product according to their needs (e.g. different agreements, features etc.) This means that it will be impossible to purchase EasyFleet’s product directly from the website.

71

References: Ansoff, I. 1957, Strategies for Diversification. Harvards Business Review, Vol. 35 Issue 5, Sep-­Oct 1957. p. 113-­124 Burns, P 2011, Entrepreneurship and Small business: Start-­up, Growth and Maturity, 3rd edn, Palgrave Macmillan, NY ComputerSweden. 2016. Papperslösa kontoret ännu långt borta, visar nya siffror. Varför är det så?., viewed at 11 May 2017 <http://computersweden.idg.se/2.2683/1.654440/papperslosa-­kontoret> Konjunkturinstitutet, 2017. Robust svensk ekonomi förstärks av exporten, viewed at 11 May 2017. <http://konj.se/publikationer/konjunkturlaget/konjunkturlaget/2017-­03-­29-­robust-­svens-­ekonomi-­forstarks-­av-­exporten.html> TIOBE: The Software Quality Company. Index for May 2017. May Headline: the pack is closing in on Java and C, viewed at 11 May 2017. Veckans Affärer. 2017. De 10 Viktigaste Tekniktrenderna 2017, viewed at 11 May 2017. <https://www.va.se/nyheter/2016/12/15/de-­10-­viktigaste-­tekniktrenderna-­2017/> SFS 2016:1145. Offentlig upphandling. Stockholm: Finansdepartementet OU.

72

Appendix B -­ NABC Name of business proposition: EasyFleet (overview, control and service) Need

Describe the relevant customer needs and market needs that the idea is going to meet. What is the core problem to be solved? (arguments built upon relevant sources and data)

It is difficult to obtain an overview of all vehicles in a vehicle fleet. The rate of knowledge transfer regarding (for example) changes in the condition of

a vehicle may be limited by the fact that only certain people possess said knowledge.

Making information easy to access and view by having it all available in one place. There is a need for a single, unified platform which contains all relevant

functionality and information regarding purchasing services (such as repair and maintenance).

Furthermore, usage of an automated web application to keep track of information such as deadlines and reminders eliminates human errors.

Approach

Describe the approach that will be used to satisfy these needs. Develop an easy-­to-­use web application that provides an overview of a vehicle

fleet. Customize the application through continuous dialogue with the customer. Easily available purchase functionality for services associated with vehicles. Storage of historical data about vehicles and their usage. Ability to manage and register new users. Pre-­defined user classes and user rights for authentication and authorization.

Benefits

Describe the benefit in relation to the cost. What is the value (benefit/cost) for the customer?

Simple and minimalistic interface for ease-­of-­use and usability. Provides easier overview and greater manageability than current solutions in use

(spreadsheets and/or databases) Makes routine tasks possible to perform with increased efficiency. Affordable in comparison to other, more complicated solutions. Facilitates communication within an organization by improving dissemination of

information (e.g. making locally stored information available to a wider audience) Reduced administrative overhead and workload by enabling several users to

access and manage information. The web application is custom-­made according to user needs. Provides a simple, unified platform for all kinds of purchases related to vehicles. Automatically notifies users of events requiring user interaction, such as vehicles

becoming inoperable or requiring maintenance.

Competition

Are there competitors or other alternatives that can satisfy the need? Complete fleet management solutions currently exist and are used within certain

73

fields such as transport & logistics. However, their complexity is vastly increased due to the extensive functionality they have to provide (e.g. vehicle tracking, driving logs).

There are also internal systems developed by companies in-­house. However, these are not part of the target group. It is also unlikely that they would make their product available on the public market.

74

Appendix C -­ Prototype C.1 Front page

C.2 Home -­ Logged in

75

C.3 Vehicle Info

C.4 Contact

76

C.5 Log in

C.6 User profile

77

C.7 Admin Log in

C.8 Admin UI -­ Vehicle management

78

C.9 Admin UI -­ User management

79

Appendix D -­ ER-­diagram

80

Appendix E -­ User tests E.1 Usability test 1

Concurrent think aloud Two participants thought that the colours were satisfying. One participant mentioned that the functionality within the application were

good for its purpose One participant thought that the application was easy to handle One participant thought that you needed some time to get used to the

application in order to understand it cause One participant mentioned that there were a lot of information and had

troubles understanding what each functionality did One participant said that the design was well planned, but had some troubles

understanding what the vessel list actually was at first. The same participant also mentioned that it was obvious after a while.

One participant mentioned that it was a well planned application, but that the project group could make the refund button more responsive

One participant said that the application contained very much information One participant said that there were a little too many scroll functions

Task list: 1. Log in 2. Navigate freely 3. Go to Home 4. Scroll through the vessel list 5. Use the back to top-­button to get to the top of the list 6. Sort the vessel list 7. Get to the view of a specific vessel 8. Go back 9. Change the status of four vessels 10. Go back to the vessel list (using home, back to list not working) 11. Search for a vessel of which you changed status 12. Read detailed information about the status change 13. Go to vessel using the notification box 14. Change the status for this vessel 15. Go to a vessel 16. Purchase service 17. Refund service 18. Try to find notifications regarding your service 19. Log out 20. Log in

81

82

83

E.2 Usability test 2

84

Concurrent think aloud

One participant said that the application provided a reasonable view of status control for vehicles

Three participants liked the styling and the design One participant said that the choice of colour was good Four participants said that the application was easy to understand it in its

entirety Two participants was confused due to the fact the vessels that are presented

had Finnish name, but mentioned that realising that made it easy to understand the application

Two participants would like to see more vessels at the same time without scrolling through a big list

Two participants had troubles regarding the “Go to top”-­function One participant mentioned that the calendar was simple, but thought it would

be more user friendly to not having click on arrows in order to see for example next month

One participant would prefer more information about the vessels upon browsing to the specific vessel-­page

One participant asked what target customers the project group had One participant wondered why all vessels had the same service cost One participant asked what kind of service that was provided One participant mentioned that the application had a nice styling on its icons One participant asked why you could only see service history while you are logged in as a read_write or admin user

Two participants had troubles regarding the scroll function and one of which meant that they seemed to move by themselves

One participant said that there was a simple and clear feedback to the calendar and notification list upon changing status for a vessel

One participant liked the admin page One participant had troubles regarding the datepicker-­function

Task list:

1. Log in to the webpage (username and password was provided) 2. Navigate freely to the different pages 3. Go back to Home 4. Scroll through the list of vessels 5. Sort the list and change the order to be ascending 6. Click yourself into the page for a specific vessel 7. Go back to the list 8. Change status on 4 different vessel 9. Search for one of the vessels that you changed status on 10. Read the detailed information inside the notification for you vessel

85

11. Filter your vessels based on type or location 12. Navigate to the admin page

Navigate to Vessel Edit the vessel Turva Change location for Turva Return to main page

13. Enter the page for a vessel and change location on it 14. Enter the page for a vessel and upload an inspection document 15. Log out 16. Log in with a read_only user (username and password was provided) 17. Try changing status on a vessel

86

87

88

89

90

91

E.3 -­ Customer Satisfaction test Task list:

1. Log in (username and password was provided) 2. Navigate freely to different pages 3. Go back to Home 4. Scroll through the list of vessels 5. Sort the list and change the order to be ascending 6. Change status of a vessel 7. Search for one vessel and change status 8. Find detailed information about a vessel’s status 9. Filter your vessels based on type or location 10. Navigate to the admin page

Navigate to vessel on the admin page Edit the vessel “Turva” Change location for Turva to a station of your choice Return to main page

11. Change location on one vessel 12. Upload an inspection document to one vessel of your choice 13. Logout 14. Log in to a read_only user (username and password was provided) 15. Try changing status of a vessel

92

93

94

95

96