SAP DESIGN GUILD

A Proposal for Playful Interactive Persuasion: The "Employees' Commute Calculator" (ECC) – Part 1: The Easy ECC (E2C2)

By Gerd Waloszek, SAP User Experience, SAP AG – December 15, 2011

In this series of two articles, I will propose and roughly sketch an "Employees' Commute Calculator" (ECC)*, which allows a company's employees to explore the environmental consequences of their commuting behavior in a playful way. My proposal was inspired by SAP's sustainability report for 2010, which allows readers to interactively investigate certain sustainability aspects (greenhouse gases, total energy consumed, proportion of renewable energy), but at an aggregated level only. The ECC, on the other hand, addresses the personal level. I propose the ECC because I am convinced that employees are generally interested in environmental topics and that they are therefore willing to engage with such a tool. It can sharpen their awareness of how their own behavior affects the environment and help them answer questions like,"How much carbon dioxide (CO2) will I save when I travel by bus or bicycle 75% of the time when commuting to work?" And, like other design projects in the sustainability field, this proposal also aims to nudge people into the direction of a more sustainable behavior.

While the ECC might also be realized as a physical, calculator-like device, I will pursue a software approach here for a number of reasons:

For a software application you can pursue different routes: You can either decide on a simple version (or "app") dedicated to mobile devices (smart phones, tablet computers), or you can decide on a more extended version for desktop computers. "Intermediate" versions are conceivable, too. In the future, the boundaries between these scenarios will probably diminish and eventually disappear, but, for the moment, this is a useful distinction. At a later stage, the ECC might also be extended to explore further sustainability aspects and might thus turn into a flexible "Employees' Sustainability Calculator" (ESC). Again, such a transformation is easier to achieve if the ECC is implemented in software.

When I started to write this article series, my plan was to sketch prototypes for both routes in one article: a simple version for exploring the idea, and a more ambitious version based on the room metaphor that would be more playful and challenging. Soon, however, I realized that even a simple version has the potential to easily exceed the scope of one article. Therefore, I decided to split the article into two parts and present a simple version that I will call EasyECC, or E2C2 for short, in the first part and point to ideas for a more ambitious version in the second. (In some cases, I will also talk of the EECC or the (E)EEC.)

*) Please note that various commute calculators can be found on the Internet (see Figure 1). The ones that I have looked at focused on estimating the daily, monthly, or yearly cost of using one's own car to compare the cost with alternative, hopefully more cost efficient, solutions like car- or van-sharing or public transportation. Only a few commute calculators took environmental impacts into account as well.

Figure 1: Example of a commute cost calculator from the Web (CommuterPage.com)

 

An Easy Start: Applying the E2C2 to My Own Potential Commute Scenarios

In the following, I will sketch a simple version of the EEC, the E2C2, to provide a rough idea of its concept. The E2C2 might be implemented as a simple app for mobile devices but might, of course, also be used on a desktop computer, for example as a dashboard widget. To illustrate how the E2C2 addresses the personal level, I will apply the prototype to my own potential commute scenarios. Figures 2 and 3 show my current transportation alternatives: my electric bicycle (a so-called pedelec), my car, and the public bus between Mühlhausen and the Wiesloch/Walldorf railway station (from there I might take another bus to SAP, use a bicycle, or continue on foot). I am also interested in including additional alternatives, for example, one or more potential cars that have lower CO2 emissions than my current one. I will further simplify matters by not using several means of transportation on one route (this situation is addressed in Part 2).

Two of my transportation alternatives   The public bus

Figures 2-3: My own transportation alternatives – my electric bicycle (a pedelec) and my car (left) and the public bus (right)

Data Requirements

The minimal data requirements for an initial crude E2C2 design are:

There are some figures that I do not know, and probably nor do any other SAP employees either. For example, what about the CO2 emissions of an electric bicycle, a bus, a train, or a power station? This data is required for the calculations and therefore has to be provided by the E2C2. For the prototype, I collected this data from the Internet and hard-wired it into the application; I present it and how I arrived at certain figures in the Appendix. Please note that different sources list different figures for a specific transportation means, so I had to make decisions... Therefore, please take this data with a pinch of salt – it serves only for illustration purposes. The E2C2 might allow users to inspect and edit this data and also to update it over the company network. Moreover, the E2C2 might provide default data for "average" cars of different sizes, for flights of different lengths, and so on.

Using the E2C2

In the following, I will sketch a prototype of the E2C2 and describe how it is used. The prototype is based on three main screens that employees can either work through in sequence or randomly to apply changes to the data and observe their effects.

Brief Overview of the Steps and Screens

Employees start on a screen where they enter environmental, cost, and distance data for the relevant means of transportation into a form (similar to the one in Figure 1). Then, on another screen, they can simulate the effects of various commute scenarios by varying the time schedule, that is, how often they will use each of the transportation means during a year. The simulations output figures for the scenarios, such as CO2 emissions, fuel/energy consumption, cost of tickets or fuel/energy if available, and so on. They can store the simulation results and, on a third screen, compare selected ones using a table and a bar chart.

The screens that I present below are crude sketches, not designs. They are not functional, but are based on a functional prototype that I built with Excel. Thus, they reflect my experiences of using the spreadsheet and performing simulations with it.

Note: The three sketches that I present as images below can also be seen in their original, non-functional HTML version.

Screen 1: Enter Data for Means of Transportation

Figure 4 below sketches the data entry screen. It comes with a number of predefined means of transportation. Employees can also add new ones (by clicking the "+" icon) and remove irrelevant ones (by clicking the "-" icon). On an extra screen, not shown here and called by clicking the "+" icon, they can select from predefined means of transportation or configure and create new ones.

On this screen, employees can enter data that should usually be available to them. Other data is provided by the E2C2. Employees can edit this data if necessary using the "Edit Read-Only Data" button. Then, all the read-only values will appear in input fields and can be modified (this is reminiscent of SAP's R/3 System).

Screen 1: Enter Data for Transportation Means

Figure 4: Prototypical sketch of an E2C2 showing a form for entering data for means of transportation

The "Simulate" button navigates employees to the simulation screen for defining commute scenarios and simulating their effects, while the "Compare" button leads to a screen, where they can compare selected commute scenarios that they have defined and selected by figures and in a bar chart.

Before moving to the simulation screen, I remove the "train" alternative, because there is no longer a train between Mühlhausen and Walldorf...

Screen 2: Enter Time Schedules and Simulate Effects of Commute Scenarios

Figure 5 sketches the simulation screen, on which employees can simulate the effects of actual and potential commute scenarios:

Screen 2: Enter Time Schedules and Simulate Effects of Commute Scenarios

Figure 5: Prototypical sketch of an E2C2 for defining the time schedule and simulating the effects of commute scenarios

This screen definitely looks confusing at first, but it captures all the important information without using any "gimmicks" such as sliders for manipulating the time schedule. First, employees have to define a time schedule by entering how many days they will use each means of transportation in the potential scenario. The total of scheduled days is displayed as a help. The total number of working days can be entered to check whether the schedule is correct. A slider control might prevent schedule contradictions, but may not be faster to use.

Simulation results are shown for two cases: (1) A means of transportation is used exclusively (column "Exclus.") for commuting, and (2) it is used according to the current time schedule. This way, I get an impression of how the various means of transportation influence the balance of my current commute scenario. For example, I can see that my car produces the most CO2 emissions, which suggests that I should use it on fewer days for commuting. I can also see how my new car will improve the CO2 balance for car use. Regrettably, not using my car at all for commuting is not a viable option for me.

As a "quick-and-dirty" solution for demonstrating the effect of the current commute scenario, one of the means of transportation can be selected to serve as an anchor point against which the scenario is compared. In Figure 5, I use my car as an anchor to compare the current schedule with. This tells me how my actual behavior compares with using the car exclusively. If I change the base alternative, the figures in the totals row and the "CO2 saved" fields will be updated. Pressing the "Calculate" button also updates the figures.

The "Add Scenario to Comparison" button adds the current simulation results (CO2 emissions and savings) to the comparison table and chart that is presented on the "Compare" screen; employees can give it a name for reference. The "Save Data Set" button saves the data, including the results of the current simulation, for later recall. The "Export Data Set" button exports this data for use in, for example, a spreadsheet application. Finally, by clicking the "Enter Data" and "Compare" buttons, employees can navigate to the other screens of the E2C2.

Screen 3: Compare Commute Scenarios

In Figure 6, I present only a very simple version of a comparison screen, because this screen is not necessarily required at the beginning and because it could present a challenging design task in itself. Dealing with it more extensively would definitely exceed the scope of this article.

Screen 3: Compare Commute Scenarios

Figure 6: Prototypical sketch of an E2C2 for comparing commute scenarios

On this screen, employees can compare the CO2 emissions of various commute scenarios that they have defined and explored. They can also add new ones (by clicking the "+" icon) and remove obsolete ones (by clicking the "-" icon), without leaving the screen.

In Figure 6, I have collected four "base" and three "mixed" scenarios that more closely reflect my actual behavior. At this stage of the sketch, comparisons comprise CO2 emissions only. Absolute emissions are presented as well as the savings relative to the comparison base, which is selected on the simulation screen. The data is presented in table and bar chart format (a more refined version would make it possible to change the chart type).

The "Save Comparison" and "Export Comparison" buttons allow employees to save the current comparison for later use and to export it for use in other applications. Finally, using the "Enter Data" and "Simulate" buttons, employees can navigate to the other E2C2 screens.

Complexities: Provided Data

Even such a simple commute calculator as this one can involve severe complexity issues. One such issue is to the data that is provided by the E2C2. On the entry screen, employees can override predefined values if they find data that applies more closely to their situation or that fits better than the data provided . But what happens if we offer an option to update this data online? Will the employees' changes be overridden? Will previous calculations be updated as well and produce new and perhaps, surprising results? Would it make sense to time-stamp data sets and select provided data sets based on time stamps? What about regional data? There may be significant differences between the United States, EMEA, and Asia. I am sure that a "one-size-fits-all" approach is not useful here. Questions, questions... which I will not be able to resolve here.

Conclusions

In all probability, most employees will not regard this prototype as overly playful and attractive. Nevertheless, the E2C2 might be useful for gaining initial, hands-on experience and a better understanding of the domain and its complexities.

 

Some Open Questions to End With...

The (E)EEC, or E2C2, concept raises a number of questions, some of which I will address in the following.

Yet Another Commute Cost Calculator?

Q: Do we need yet another commute cost calculator when there are already so many on the Web?

A: As I mentioned at the beginning, most commute cost calculators on the Web only address cost, not environmental factors. Therefore, they tend not ´to have the complexity of an (E)ECC, which offers quite a number of design challenges. Thus, the EEC is also an interesting project from a purely design perspective.

Systems View?

Q: Does the (E)ECC provide a systems view as is often demanded when discussion sustainability issues and comparing alternatives with regard to their environmental impact?

A: This is, of course, not the case, but the (E)ECC adds one more dimension to the considerations regarding commute alternatives and provides at least some transparency for environmental considerations in this respect. There are also many more variables to consider, which cannot be covered by such a device/application: the time and duration of commuting, traffic conditions (including congestion), private obligations such as the need to take children to the kindergarten or school (and fetch them again), options for car pooling, and so on. (The latter might be considered by taking the number of people in a car into account.)

Complexity

Q: Initially, you intended to present two versions of the EEC, a simple E2C2 and a more complex and playful version based on the room metaphor. In the end, you decided on the E2C2. Does this indicate that the "rooms" version, in particular, has the potential to result in a rather complex application? One might question whether employees will be willing to engage with it.

A: I do not know in advance and without letting users interact with some prototypes and observing them. However, I would also argue that complexity can be frustrating as well as fun, provided that users want to engage in this complexity and play around with all the options. As Don Norman states, a complex app reflects the world's complexity. Using it can remain fun as long as it is understandable and manageable. And in the case of SAP employees, I might add that software developers yearn for challenges and that a simple app might bore them fairly quickly.

Will it Work?

Q: Will the (E)ECC "work" and, particularly, will it nudge employees towards a more sustainable behavior?

A: This is an open question and one that pops up again and again with any design project in the sustainability field. Nevertheless, the (E)ECC touches personal aspects, which is a good thing, and it also has the potential to trigger considerable improvements.

Note: See also my article, Designing for a Workforce that Acts More Sustainably – Part 5: Using Persuasive Design/Technology.

 

After Word

When I started this design project, I had no clear idea of how the E2C2 would finally turn out. In truth, I thought that a few sketches would do and that I would be finished pretty quickly. That was, of course, complete rubbish. If you do not deeply engage with the topic and build some sort of – more or less – functional prototype that allows you to play around with possible scenarios, you may be dead wrong with your initial assumptions. There were so many small design changes and iterations in the project as I present it here – you would not believe it (even getting the terminology consistent was a challenge). And, of course, there would be many more if the E2C2 were actually implemented (I plan to use it as a programming exercise in learning HTML5, let's see...).

The second part of this article will present ideas for a more advanced version of the EEC based on the room metaphor.

 

References

 

top top