Design

Going paperless: setting the standard for a global transformation

Accompanying an industry as old as the railroad into the paperless area can be quite the challenge.

A profound transformation

Today, when car mechanics are fixing a freight car, it requires them to manually record the performed repairs onto a paper form, and then entering them into a computer, so the work can be billed to customers.

But working with paper today is considered more and more as a thing of the past. And Canada’s harsh weather does not make things easier. Rain, wind, snow, and negative temperatures (sometimes bellow 40°Celsius) can turn a simple task into a challenge. At the end the day the paper is ruined. The car mechanics have to rewrite everything on a new work order, then fax it to someone who will enter its content in a computer. Recording the work on paper, in harsh conditions, is now looked at as a struggle. Car Repair Billing app is a mobile app that aim at replacing the paper, unifying the recording of the work, and simplifying the billing process.

The goals

• Transform the process to remove the use of paper
• Make recording of the work easy no matter the weather conditions
• Unifying the process across the network
• Seamlessly send the work for billing at the end of the day

The solution

a mobile app for the car mechanics, to record the work they do and bill it to the customer. The app is here to help the users. By unifying the practice, it simplify the work-recording process: the app can auto fill certain informations, based on initial input. Other functionalities have been added: team creation, time tracking, work submission and offline mode to name a few.

The team

another parameter made this project a pilot: it was the first project in CN history to use the Agile methodology. The Scrum team was composed of a Scrum Master, a Product Owner, front-end devs, back-end devs, a tester, two functional designers and two UX designers.

My role

I co-led the research, design, and test of the app with the other UX designer. I worked primarily on the Home screen, the initial car check-up screen, the time recording process and the Yard Workflow.

The company

The Canadian National Railway Company is a Canadian Class I freight railway headquartered in Montreal, Quebec that serves Canada and the Midwestern and Southern United States. CN’s slogan is “North America’s Railroad”. CN is a public company with 24,000 employees.

Discovery phase: car mechanics do not operate the same way across the network

I went to the field with the other UX designer. The first day, we conducted usability testing with 5 users. The next day, we performed contextual inquiries (shadowing and user interviews) by following a team of car mechanics. Talking with them, we quickly realised that the reality of the field is very different from what we thought we knew.

First, not all yards operate the same way across the network. And even in the same yard, car mechanics don’t always enter the work the same way.

Second, the paper used to record the work is not always the same. It is sometimes adapted to the reality of a yard.

Finally, there is not a single type of user, the work of the car mechanics is different wether they operate in the yard, in the field or in the wheel pit. The app had to work for each situation.

We knew that the car mechanics population vary in age and technical knowledge. One of the main concern they express was that the app would need to be easy enough so that the less technical savvy users would be able to use it. They also wished that the app would not require any training to use. The work of a car mechanic is already heavy in training and they were afraid that changing for a digital process would mean more training time.

Defining the problem

Car mechanics not only have a highly technical job, they need to know a lot a code numbers. Those numbers correspond to the repairs they do and to the car parts they fix. They are used to simplify the billing process. Because there are so many codes to learn, this knowledge is time consuming in terms of training and recording of the work.

Another issue is that some car mechanics do not bill the work themselves. Only a handful of car mechanics actually know the billing process. When there is an error on the paper, the billers prefer to correct the error themselves instead of returning the paper to the original car mechanic for correction. The most common reporting errors are wrong code number, missing code number or unreadable code number… This require a lot of effort on the person responsible of the billing. And can lead to frustration.

Steering away from the paper form

The initial thought that because we were replacing a paper form, a simple app the with a few fields, dropdowns, and checkboxes would be enough to cover our needs. The insights we gathered dissuaded us to follow that path. We were not transposing a paper form into a digital form. We were transforming a process and improving it. To do so, we did the following (and more).

Different workflows

Car mechanics work is different depending where they operate. They perform quick repairs in the yard, and they execute heavy reconstructions in the shop. Because of that the recording of the work is done very differently. I will not list the difference here. But because of those difference we choose to create two workflows. They require the input and the display of the same kind of information with a few exceptions. But the importance of a given information is not the same depending on what type of work you do. In the Yard certain codes need to be highlighted, whereas in the shop, the same codes don’t need to be in the forefront.

Also, even if adding a repair require the same informations in the Yard and in the Shop. Because the work in the Yard is fast pace, not all the informations are mandatory. And even the ones that are, don’t necessary need to be entered right away as not to break the flow of the repair. In the Shop, repairs are more complicated and can last for a few hours, sometimes a few days. The recording of the work happens at the end of the repair or at the end of the day. At this point all the informations are mandatory. The flow is more linear and rigid.

Offline mode

One of the main challenge car mechanics are facing when working in remote areas across CN network is that sometime cellular network drops. When that happens we didn’t want them to be stuck, not being able to enter the work they do. And go back to the paper form. We needed an offline mode and a way to switch seamlessly between online and offline mode. We took the approach to to create the first MVP completely offline and wait for the second iteration of the app to plug it into the servers.

Mapping the way

The app can never beat paper & pen in terms of speed. The hand writing will always be faster in recording the work than a mobile app. We knew that we would not save time in the recording process. We would save time in the billing process. But still, for the work recording, there was something to be done. We wanted to make thing easy, fast and error proof for the car mechanics. We introduced a mapping that did not exist so far. It takes several codes to record of a repair. Between five to ten different type of codes depending on the repair. But we discovered that a lot of those informations have relation between them could. And because of that, they could be auto-selected by entering only the first few codes. I am being voluntary vague about this, because this is sensible information. But the result of this mapping was that the user only needed to select manually half of the information and the app would deduct the rest. This reduced the margin for error and actually served as training information for some car mechanics as we discovered later during our usability testing sessions.

The story of the first usability testing at CN

In many ways, the CRB application was a first at CN. Like I said, it was the first attempt to replace paper and the first time an application was developed following an Agile methodology. But it was also the first time that usability testing was conducted to verify UX assumptions. When I entered the project, the development was only a few month underway. The app was functional with only a handful of features and was ready to be released as a first MVP. It was the perfect time to perform usability testing. The team was really enthusiastic with the idea to go in the field and meet the users, but didn’t know how to do it.

The release of the first MVP was schedule in the Halifax yard, two weeks after my on-boarding on the project. I decided it was the perfect opportunity to meet real users, learn about their work, and conduct usability testing. In two weeks, the other UX designer and myself, we listed our assumptions and questions, we wrote the testing scenarios, performed dry-runs, and bought the recording equipment.

We performed 5 sessions of usability testing with 5 different users that had never seen the app before. A couple didn’t even know what the app was about. I will not go into much details into how the sessions were conducted. But I can say that they lasted between 30 mins and 45 mins each and were recorded using 2 cameras and a screen capture software. Those sessions provided us with so many valuable feedback that the team was ecstatic. The word spread across CN quite fast and the videos of the usability testing was shown many times to different managers and VPs. Since then the Usability Testing practice has been improve and unified and is now used on several projects.

After the launching the first MVP

After our Halifax trip, the first MVP was revised. We corrected the the bugs caught during testing and used the feedback given by the user to improve certain functionalities. Because there was so much feedback, not all it made it to the app right away. We had to prioritize. The first release was then introduced to another yard, then another, the number of users growing slowly across the network. Before each major addition, we performed other Usability Testing sessions using Adobe XD clickthroughs. That way the functionalities were being tested before development.

The result

Initially, when first introduced to a new yard, the paper was still being used alongside the app. That way if the app was not performing the way it should, the work of the car mechanics was not impacted. Quickly though, the app showed very good adoption rate amongst all the different car mechanics populations. And it does not face any issue with the less technical savvy mechanics. A very short training is being given by specific trainers, but only because we are still in development and adding new features. It is thought that, in a near future the trainers could be replaced by car mechanics evangelist amongst the early adopters.

Now, the app is mature enough that it has already replaced the paper in most of the yard where is app is present. And for new yards, the app is replacing the paper on the first day it is introduced. The satisfaction rate of the car mechanics is good and stable from release to release. And we are able to perceive a positive impact on the car repair process across CN network.