This story talks about our first approach with Service Design, the quintessence of what we like the most: highlighting purpose making it shine through technology.
A2A is the largest Italian multi-utility company, a leader in the energy, environment, heat and networks sectors.
The Environmental Service Department was already providing a mobile application to its customers but they thought it needed a change, on performances mostly.
At the end of April 2015 they came to us with a list of concerns they had about how the application responded to user inputs and the hard time they had dealing with back-end problems.
As it often happens in a client/provider relationship, we discovered that the needs they thought they had were expressions of something deeper: that was for us at Commonsense the step we call Problem Setting.
Problem Setting vs. Problem Solving
As UX experts we know for sure that the problem solving part is just the final end of a much longer analysis process aimed to the user requirements identification.
UX doesn’t (only) resolve problems, it makes them arise: this is specially true in a service design related project. In this special context function is not only shown, it is the backbone of the service itself.
The business context is very complex: the A2A Environmental Service Department is actually a group of companies operating locally in different cities along different policies.
The data structure provided by the web services was the same used by the web site and didn’t reflect the proposed environmental services at all. The existing app reflected this state of things: there was no information hierarchy whatsoever and the experience was strictly related to the city selected when first accessing the app.
The previous version of the app displayed all the main functionalities on a flat grid without providing any hierarchy. This surely guaranteed a simpler approach to the development phase and a greater control over the different services provided by each of the different companies, but on the other hand it considered the user merely as an operator rather than the key player as the recipient of a service in a specific time and place.
Considering the framework described by Gianluca Diegoli in his “Intimate Computing” we can say that PuliAmo in its previous version didn’t target the Relationship Zone: the needs it aimed to satisfy were mostly business and technological needs, leaving aside the users needs.
Still quoting Diegoli, our main purpose was “to achieve that continuous – or regular -, intensely engaged interaction” which “stimulates a strong, voluntary and highly valued reaction”, always staying inside that technological and institutional identity area carefully nurtured by our client over the years.
Our “As Is” analysis didn’t just concerned the context of use and the final product users were already dealing with. In fact, we also considered the whole environment PULIamo was originally built in, the same environment we had to work in to create our solution. To do this we had to start the process we judge as the most important: the Research phase.
Here in Commonsense the research phase is first of all a negotiation phase: at this stage we define together with the client each participant’s role. Asking for us to be freest as possible in our research process we’re asking a big investment on client’s part, in a series of actions that aren’t strictly operational and that give not an immediate economic return: we gain the clients’ trust providing them all the necessary deliverables to make them understand how critical this phase is and, at the same time, building an effective dialog with them.
The first step has been to consider who would have been the user of the new version of the app. We interviewed both actual and potential users which allowed us to create several personas and their related scenarios. We also took into account internal users, the people involved in the data production: thanks to this approach we even anticipated problems associated with the quality of data. Through speaking the same language as the client we could make him become a feedback collector and make the application become a dialog between the company and its customers.
A discussion we needed to have has been the one with the third party involved in the web services development. Since they are the same services used by the website, we needed to know them well to see how far we could go in our effort to separate ourselves from the web design logic in order to base our app on a mobile logic. In many cases – though not how many we hoped – through this dialog we could achieve modifications on the data structure so that our application could be more operational than informative.
Analysing the users’ scenarios we obtained the needs our application had to satisfy and for each needs category we extracted a functional area.
This way we could identify the required features, grouping similar features, cutting out the unnecessary ones and creating new ones. The information hierarchy has been based on the time component united with the space component already used by the previous version. This way only we could take advantage of the main feature of mobile devices: their ubiquitous and intimate presence in our daily activities. Doing this we could go far from a too web-oriented design style, giving the data a new dynamism.
Access and addresses management
Purpose: finding the user’s “here”
As in the previous version, at the first access the user is asked to provide the address the entire experience will be build around. Unlike the previous version though more than just one address could be provided without exiting the app context.
Purpose: given the “here and now”, defining which activities the user can perform
This section sums up which services are available for a certain day and address:
- the different types of door to door waste collections and their scheduled time
- the streets washing operations and their scheduled time
- the nearest active collection points and their opening time
To promote that continuous and intensely engaged interaction we talked about before, we thought it was mandatory to provide two necessary interaction tools:
- the possibility to define a point of interest radius for the streets washing service
- the possibility to set up a reminder for all the other services
Oggi is the top of the complete calendar of services, directly accessible from this screen. The calendar, previously represented by an almost empty grid with a minimum amount of information, is now populated with the relevant days only. When a day is selected a screen similar to Oggi is displayed, showing the active services for that specific day.
This part of the application is completely new and it represents to us the farthest point from the website logic. In its initial form the time factor was very important: the service schedules gave us the direct information about the availability of a service (i.e., what waste collection centre was open at a given time, when would take place the next door to door collection) and we thought it would have been useful to have automatic reminders enabled.
But the data structure representing the schedules – a set of strings instead of a timestamp – doesn’t give us a reliable information to perform the activity we imagined. A change of the web services in this direction would have caused a shift of the deadline. We then decided to look for a temporary alternative solution and wait for the next release to implement what we wanted to do.
Dove lo butto
Purpose: giving the user a guide to follow to correctly recycle waste items
This section make the user become an active part of the main A2A services purpose: increase the percentage of well recycled waste.
With this goal in mind we grouped in one section two activities of the old application: the vademecum and the collection points map.
With our intervention on the PULIamo app we wanted to reach the Relationship Zone. To do so we put into practice the main UX design principles adding a new creative effort through which we could outdo the mere informative level. We got to a new operational phase giving a new value to the user.
There’s a lot more to do to make the application become a faithful companion to those who want to participate to the recycling process. Our next steps will be aimed to a change to the web services in order to take more advantage of the ubiquity of the mobile devices.