1 Introduction

Since 2011, we are concerned with improving public transport experience and usage for persons that are momentarily excluded from using it due to their age or a range of different mobility impairmentsFootnote 1. In previous efforts, we developed and validated a human-based technology aided service in the city of Saarbrücken, the capital of the federal state of SaarlandFootnote 2, Germany [1]. Currently, mobisaar aims at extending this service to include rural regions of the federal state of Saarland. The pilot service was established 2014 and is based on human support provided by so-called mobility guides together with a technology component. The main purpose of the mobility guides is to accompany and support passengers who cannot use public transport on their own, due to physical limitations or perceived obstacles. Mobility guides help to overcome every-day hurdles occurring during the use of public transport, such as gaps or unlevelled entry and exit points between transport vehicles and pavement, complicated ticketing systems. In general, the guides foster a feeling of security among clients as experienced and trained public transport companions.

The technology component consists of software for intelligent positioning, scheduling and coordination of the mobility guides as well as user interfaces (UIs) for both guides and passengers. The coordination software directs the guides to the requested point of service, see Fig. 1. The passenger UIs have been implemented such that all passengers can interact with it. In addition to traditional telephone calls, personalised and adaptable user interfaces running on smartphones – APPs – allow users not only to order trips, but to receive real-time support during the trip. This functionality includes a bus/tram tracking service as well as notifications and alerts. The long-term goal of the system is to deliver coordinate personalised interaction and service that allows – in principle – everyone to use public transport.

Fig. 1.
figure 1

Overview of the mobisaar system. The passenger can request the service via telephone, website or app. The “mobisaar backend” matches the request by searching for suitable mobility-guides and barrier free public transport routes. The guides are directed to and sufficiently informed about passenger, place and time of the requested service by his smartphone app.

Full size image

The service targets a broad range of people from different social backgrounds with different requirements, living in areas with varying public infrastructure. We followed a user-centred design (UCD) approach [4, 5] to tailor the developed solution to the needs of these different people. UCD is an iterative methodology that puts the user in the centre of the development process thus supporting the creation of solutions solving real needs. Additionally, our efforts are implemented and continuously improved so that passengers can evaluate and contribute to the improvements of the service.

The basic methodology of UCD was adapted as described in [1] to enable a continuous improvement of the system and in particular, to adapt the user interfaces to the changing requirements as the service evolves over time. To achieve a maximum output and feedback from the users, as well as to engage them deeply in the project and create stronger personal commitment to the project, we ran so-called regulars’ tables that were held on a monthly basis. We invited the mobisaar users to an informal meeting, serving coffee and cake, to discuss their experiences with the use of the service. Not only app users were invited but the whole customer group, whoever was interested to share their experiences and opinions. For a detailed review of positive effects of these regular’s tables see [14].

The regulars’ tables managed to create the desired strong commitment and engagement in terms of regular use of the service. In terms of experience exchange however, the broad open set-up often led to undirected feedback session with more or less repeating topics. The main discussion points arising in each of the sessions evolved into complaints about bus drivers and the insufficient expansion of public transport within the users’ hometowns. Furthermore, the heterogeneous group of people and the large number of participants led to private discussions and inattentiveness to the main theme. These inattentive phases appeared increasingly during the parts of the meetings dealing with the app and the web interface. This was further aggravated by the fact that not all people attending the regulars’ tables were actually using these interfaces. A call centre was established to ensure access via telephone [1, 3] and to avoid exclusion of passengers that shy away from technologies like the internet or smartphones. Technology-disinclined users were therefore separated from those actually using the app for discussing the current state of the application and suggesting improvements. By creating a more calm and focused environment, the sessions produced more directed feedback. Nevertheless, our passengers did not productively work out possible solutions themselves. Instead, developers took feedback home and re-evaluated new designs/mock-ups at the following regular’s table. These suggestions were often either accepted straight away without any critical regard or plainly rejected. A vivid and active participation of the users could therefore not be achieved but would have been necessary for producing better solutions.

This is partly due to the fact that in UCD, researcher and users are still very much separated as the user is not part of the development team [10]. Therefore, we decided to proceed with rather active development methodology involving the users in a more hands-on co-creative way - as co-developers.

Co-creation can be classified as a participatory design approach. Although first descriptions of the approach occurred already in the 1970s [13] it took researchers until the 2000s to discover the need for new methodologies moving beyond pure user-centered to participatory approaches. Prahalad and Ramaswamy defined the term co-creation for the first time in 2000 [8] identifying an evolution of the customer’s role from a passive to a more active one in the value creation process. In 2002, Sanders coined the term postdesign [10], a new method moving away from designing for the user towards designing together with them. The method aims at blurring the borders between the different roles involved in the development process, between designer, researcher and the user, actively including all parties. The work tries to fit participatory design into a methodology by giving it a new name, nevertheless it lacks a strong definition for it. Spinuzzi discovered the lack of clearly defined methodological approach for participatory design in literature in 2005 [13] and started reviewing studies concerning this topic starting back in the 1970s. He defined three initial stages that all reviewed approaches have in common:

  • Stage 1: Initial exploration

    In this stage, designers meet the users and familiarize themselves with the context of the activity. This exploration includes the technologies used, but also includes workflows and procedures, routines, and other aspects.

  • Stage 2: Discovery processes

    In this stage, designers and users employ various techniques to understand and prioritize organization and envision the future qualities of the activity, enhanced by the new solution. This work is often conducted on site.

  • Stage 3: Prototyping

    In this stage, designers and users iteratively shape technological artefacts to fit visions of Stage 2. Prototyping involves one or more users.

These stages should be iterated several times.

As mobisaar is a follow-up project to a finished research project, building on experiences and a solution developed under the methodology of UCD, a complete repetition of all 3 stages mentioned above was beyond scope especially as stages 1 and 2 had been extensively worked out in Mobia already [3]. The clear aim of this work was to take the existing solution and co-creatively refine and co-develop it further to meet the new requirements [9]. Therefore, we focus on stage 3 on an iterative basis including all underlying concepts and tools of co-creation [11, 12, 15] as described in Sect. 2 below.

A literature research shows that co-creation methodologies applied in the field of public services including public transport often utilize social media and features within smartphone applications as a feedback channel. These approaches neither include face-to-face interaction with users nor hands-on prototyping of new solutions [2, 6, 7]. As this approach does not fit our needs in mobissar, we have adapted our methodology. According to lessons learned, we prefer relying on a close and persistent relationship to our target group as described in the following section.

2 Materials and Methods

Co-developers

The literature reveals problems with several participatory approaches. Concerning feedback channels, a face-to-face solution was preferred over social media channels. Beside the fact that the target group is rarely active to completely inactive on social media platforms, close contact including meetings turned out to be crucial for the development of the interfaces and the service itself as experienced and published in [14]. Another strategy unsuitable for the framing conditions in our effort is the frequent change of participants over multiple co-creation cycles, e.g. inviting people for a one-time feedback and co-creation session.

An important aspect is the regular use of our service and user interfaces to a long-term evaluation of the applications in different real-world scenarios over a longer period of time. Introducing new people into the system and the complex scenarios arising with the use each time would not lead to fruitful results. In the frame of our efforts we therefore define co-developers as follows:

A Co-Developer is an active user of the system who takes part in regular meetings to deliver feedback and participate in the development process by delivering suggestions as well as prototypical implementations in an experimental frame accompanying the project over a significant period of time.

We further defined prerequisites tailored to the special requirements of our project:

A Co-Developer:

  • is an active user of the mobisaar service (8 times per month)

  • has a smartphone or at least PC with internet access

  • is aged 50+

  • faces mobility impairment when using public transport

Recruiting was done via newspaper articles. In order to address those willing to participate actively in the development process, the expression co-developer was stressed, chosen deliberately and mentioned repeatedly. A monthly ticket for the public transport covering the whole federal state of Saarland was offered to facilitate an active participation in the public transport. The search lead to numerous responses resulting in a heterogeneous group of co-developers representing different residential areas within our test region – Saarland, differing in age, smartphone experience level, and experience in other public transport apps.

Co-developer Workshops

The workshops primary goal has been to provide a basis for regular exchange concerning passengers’ experiences with the user interfaces. One intention was discussing problems with the app in daily use. Co-developers’ suggestions should be worked out with a focus on interactive sessions to implement these changes in a prototypical way. In the attempt of combining these two sessions, we merged a plain feedback approach with an active co-creation approach using pen and paper prototyping. Other tools of participatory design like collages, cognitive and context mapping, and storyboards, have not been used as we are in an advanced stage of the project where the service and technology is up and running. Future functionalities however and the establishment of profound changes in interaction principles should be talked through and worked out in a conceptual stage with one of these tools.

To encourage active participation and ensure every opinion to be heard, the group size was limited to a maximum number of 4 co-developers per instructor. The classroom like atmosphere created within the regulars’ tables with one presenter in the front and the participants rowed up facing the projection screen was relaxed to a round table approach. The instructor sat at the top of the table while the co-developers took a seat around it, facilitating face-to-face discussions with room for pen and paper prototyping in the middle.

For the regular cycle we agreed on two-hour workshops every 6 weeks. We started with a complete redesign of the application informed by other popular public transport applications on the market, while maintaining the main design principles developed in Mobia and mobisaar. Our Co-Developers did not receive any introduction to the app and were left alone for the first six weeks to evaluate the app with a focus on usability and easy comprehension.

First results of the Co-Developer Workshops as well as general impressions concerning the adapted methodology compared to the previous approach (regulars’ tables) are reported in the next section.

3 Results and Discussion

Until the point of publishing three co-developer workshops were held and the number of co-developers stabilized at a group of 6 people aged between 45 and 82. The presented results are based on these first three workshops, while the meetings continue on a regular basis.

In general, the co-developer approach delivered the desired team-like atmosphere. Starting from the term “co-developer”, the participants demonstrated higher commitment to the project and its solution compared to the previous approach with the regulars’ tables. While during the preparation of each regulars’ table it was a gamble to guess how many registered participants would actually show up, the co-developers were a lot more reliable. This facilitates planning and the selection of appropriate tools and methods for the workshop taking into account the expected number of participants. Furthermore, the developed group dynamic was an astonishing result. As the co-developers are a heterogeneous group of people bringing along different smartphone skills, some had minor problems with the use of the app in daily life. Without the instructors’ impulse, the experienced participants teamed up with the unskilled ones and arranged trips together to explain basic usage of the app. Compared to the regulars’ tables, this was a big success, as at each regulars’ table a refresher about the app and its’ use for some of the participants was a crucial and time-consuming part.

The small group size allowed each co-developer to bring in his/her own feedback which was one of the main advantages over the regulars’ tables. Regulars’ tables turned out to provide a platform for those who wanted to speak out problems often not related to the app/solution or the service in general which often dominated the discussions. Unfortunately, it may be that valuable opinions and feedback got lost in these complaint-oriented sessions.

Choosing users with smartphone experience could be seen as a limitation, as experienced user might tend to envision new solutions too strongly rooted in existing public transport applications. This would lead the development not necessarily in the direction of the special context requirements in mobisaar. As an example, the interaction principle of multiple confirmation dialogs to prevent triggering unintended actions in the app, bothered one of the participants. This navigation mechanism was a relic from the former project focusing mainly on older, less-tech-savvy smartphone users who asked for more safety layers when ordering help through the app. Nevertheless, the person voicing the complaint himself understood the reasons behind this approach and considered it as useful for unexperienced users. This way of thinking from different points of view, on the one hand regarding the own experience and on the other hand taking the view point of other target group un-experienced user, was well established throughout the workshop and all co-developers and provided creative solutions.

In the following we will highlight three detailed cases that arose during one of the first co-developer workshops starting with identifying a problem, developing conceptual ideas for a solution and finally working it out together with the users in pen and paper mock-ups. These mock-ups have later on been implemented in first prototypes by the software developers to present and discuss them at the next co-developer workshop.

Case 1 – Communication Passenger - Mobility Guide

One of the co-developers uses the mobisaar-Service and the application for his way home from work. The co-developer is working in a bigger office building with several entrances and the mobility guide receives only the main address. The mobility guide and the user did not find each other on several occasions. In contrast to most of the problems mentioned at the regulars’ tables, the co-developer already came up with solutions he could imagine for this problem and discussed them together with the group. Earlier, a direct communication via telephone and sharing the phone numbers of the mobility guides was rejected due to privacy reasons. Therefore, it was agreed to use a messaging solution instead. For privacy reasons the co-developers came up with the idea of an input field for additional information during the process of booking a trip. Within this message, the user can inform about certain circumstances concerning the start/endpoint of the trip or any other additional details. This idea was further developed with the group via pen and paper mock-ups (example see Fig. 2) and for a following meeting it was implemented by the software developers in a prototype, see Fig. 3.

Fig. 2.
figure 2

Examples of pen and paper mock-ups created in our first session. For each of the views positive points were placed left and the negative points on the right. The feedback was followed by an interactive pen and paper prototyping session to directly apply changes. The created screens were attached at the bottom section to summarize the process at a glance.

Full size image
Fig. 3.
figure 3

Prototypes created after the co-developer workshops from the pen and paper prototypes, to present and discuss them with the users at the next workshop. From left to right the mockups represent the results from the evaluation of case 1, 2 and 3.

Full size image

Case 2 – Information about the Surroundings

In another instance, the passengers claimed that their journey would profit from more information on the suggested locations in the autocomplete of departure and destination selection, especially for places not visited before. The rationale behind this was that it would provide insights on the surrounding area. The proposed solution was an “info-button” appearing in the application at each geolocation, i.e. start, end or any stop in between of a route. Furthermore, it was suggested that additional information should be provided in form of a picture and a map highlighting the position. Showing cultural offerings or shopping possibilities nearby was recognized as useful but categorized with lower priority and postponed to future workshops. Pen and paper mock-ups resulted in a prototype depicted in Fig. 3.

Case 3 – Personalization

Following design principles for the elderly we ensured an easy to use and “secure” interaction concept. This included several confirmation dialogs preventing unintended interactions. One of the co-developers described this fact as disturbing and mentioned as an example the steps needed to book a trip with the service. Subsequent to entering trip details, such as departure, destination etc., the system calculates and presents an overview of possible routes. The user selects one of these suggestions and is presented a detailed overview of the trip with all the stations and stops in between and the passenger can select where a guide is necessary. To continue the process, the passenger has to scroll to the bottom of the page and click a button, with the intention having to check the route and all points of service again. Having clicked the button, another confirmation dialog appears, summarizing the trip and the points of services asking the user if he really wants to send a request for the given route. In the group a discussion arose about the necessity of that many dialogues. Although all of the co-developers agreed that they do not really need it, they also agreed that it might be helpful for users less experienced with smartphones. In the end, it was the idea of the group to use personalization and show an adapted view of the interface depending on the smartphone experience level. Developing the concepts behind personalization itself might have covered a whole developer workshop. Therefore, we started with the development of a simpler screen for a more direct way of booking routes. Instead of switching to the detailed view after selecting one of the suggested routes and proceed with the confirmation dialog, the confirmation dialog should be shown directly and the selection/deselection of guides for the stops along the way should be possible from within this view. If more details are needed, the user can switch to the detail view by clicking a button in the footer (see Fig. 3).

Ultimately, using the co-developer framework we were able to increase efficiency thus saving a lot of unproductive time. Furthermore, regulars’ tables require intense preparation where the feedback collected at the previous meetings had to be transformed into several mock-ups. These solutions had to be presented often resulting in ceiling or floor effects: either flat rejection or flat acceptance.

On the other hand, in the co-developer approach the participants created solutions themselves based on their own feedback. Typically, this resulted in one concrete mock-up that the software developers had to implement until the next session.

Although saving time in general, the active and engaged participation lead to time constraints within the workshop itself and not all parts of the app scheduled for discussion could be worked out in detail. For future workshops the time frame should be extended covering probably half a day.

4 Conclusion

The paper proposes a participatory approach called “co-developers” to extend the methodology of user-centred design applied within the mobisaar project aiming for public transport for everyone. The solution consists of a human-based service in form of mobility guides – persons available within the public transport supporting anyone that cannot use public transport of any reason. The second component is a technology that coordinates the guides such that they are available as needed for the passengers. From a development methodology point of view, the regulars’ tables have been established as tool for the advancement of user interfaces and provided valuable insights. Active participation however was a rare commodity so that personal requirements arising with the use of the app in daily life were not discussed in detail as desired. Presentations of solutions for known issues provided by the developers during the regulars’ tables resulted in flat rejection or acceptance without providing nuanced feedback. Hence, the value of the design and suggestions could not be assessed. To overcome these and similar problems and engage users deeper into the development process, we introduced the concept of co-developers.

Building on common participatory design approaches, the concepts of close personal contact to the target group was a crucial aspect. Considered important especially by elderly persons, as experienced in the regulars’ tables, this concept was maintained within the co-developer approach. The expression “co-developer” resulted in the desired team-like atmosphere and increased engagement of the users. Compared to the regulars’ tables the co-developers showed a stronger commitment and a kind of feeling of responsibility emerged in their role as “developers”. This reliability facilitated the planning and the selection of appropriate tools and methods for the workshop.

The biggest benefit however was the saving of time due to the active participation of the co-developers. Whereas for the regulars’ tables known issues were collected and worked out as several possible solutions by the developers in advance, the co-developers produced solutions themselves in the form of mock-ups. In contrast to the regulars’ tables, the co-developer workshops led to discussion rounds taken into account different points of view resulting in one solution to implement for the developers until the next meeting.

Two hours meeting time every six weeks was chosen based on the experiences of the regulars’ tables. This turned out to be too little mainly due to the increased output delivered by the co-developers. Future workshops will be extended to half a day every fourth week. To support co-developers tagging ideas and problems occurring in daily life, as well as collecting feedback in advance to the workshops in a standardized way, we plan to hand out diaries.

Furthermore, a concept to include functionalities establishing profound changes within the interfaces needs to be developed, as the current co-developer approach with prototyping sessions only evaluates existing UIs. Methods like cognitive or context mapping could be used to develop such profound features in a process of co-creation on a conceptual stage, whereby most suitable tools still need to be evaluated.