Illinois Tollway’s IPASS App

The Problem

I saw a user complaining about the IPASS mobile experience on social media.  I thought this would be a great little project to push my mobile skills.  For those who are not from the Chicago area, I-Pass is a system of paying tolls in Illinois and parts of nearby states without slowing down via a RFID transponder you affix to your windshield. You can also add cars to your account via the license plate in the event they do not have a transponder. An account is created on a desktop website that allows management of the account.  There is a, slightly, mobile optimized version of the site that suffers from text/areas that go outside the device screen.   Official Site    Wikipedia

Here is a screenshot of the complaint:

ipass_ins

I specifically wanted a shorter project and completed this in 2 weeks.

The Prototype

There are two different entry paths for a user to enter the app depending on whether they are a new or returning user.  The app was designed to include the entire functionality that the desktop/web version offered.  The most common use scenario would be that of the Returning User.

The key functionality of the redesigned app centers upon the interaction upon launching the app. Upon opening the app, the account balance is displayed with no other information. It was important that no personally identifiable information (PII) be displayed and the information about the balance has no context, it cannot be used to cause harm. If the user needs to make changes to the account they would have to log in.

Screenshots of the User Flow:

 

A new user would be presented with a screen asking them to log in or create an account. During account creation, the first page would require email address, transponder number, and driver’s license number. These three pieces of information, while different in scope, would allow duplicate accounts to be found quickly instead of interrupting the process in the middle.

Screenshots of the User Flow:

Finally there is a third user path which sits between the two in experience.  Part of the appeal of the app is the ability to see the balance when you open the app. In order to enable this functionality you have to authorize the device. There are many reasons that a user would choose to not enable this functionality. As such, they would be treated as a “New User.” From that screen they would choose the log in option and enter their credentials.

The following images show the user path (Login):

And here is the User Flow:

ipass_user_flow

Account Management

All three paths exit at the Account Management screen.

The following images show possible pages for a user to click (Account Management):

The Process & Sketches

Due to the short nature and time frame of the project, I skipped doing sizable user research. I did ask some acquaintances their view on the subject. They agreed with the initial statement. I considered this my goal: display the balance of the account on a mobile device. From there, I drew a couple rough sketches but stopped before getting too deep. I gathered information from the website about required fields and what should be displayed. After knowing the extent of what was needed, I went back and sketched out everything. After finishing with the paper sketches, I moved onto Axure to complete the prototype. While there are two (main) paths and to demonstrate it there are two different links to the prototypes, this is all easily combined into one app.

Original Website

Questions & Assumptions

  1. I assumed that the purpose of the app from the initial image was primarily for balance checking. As such, I thought it would work well if the balance is displayed at open without having to login. This could be provided to phones based on the “UDID, IMEI, and/or IMSI” information.
  2. This identifier, along with if the user checked the ‘Authorize Device’ would be required to display the balance of the account upon running it. To access account functionalities, the user would have to then provide the full credentials.
  3. Would revealing balance information expose individuals to any harm? I could not envision a scenario where this information could cause harm. Nothing identifying would be revealed. The balance itself does not show which car has the balance. If the phone is stolen, no personally identifiable information is revealed to the thief. On the other hand, if an individual in the car steals the transponder because they saw the balance, the user should know who was in their vehicle. Further, I believe the tollway authority records information which would quickly identify the offender.
  4. What platform will be used – Android, iOS, Windows Phone? I decided to go mobile neutral at this point. I think the designs could be easily adapted to any device.
  5. Would the app be mobile limited or would it offer full functionality? Initially, I was leaning towards limited but then the more I thought on it, I realized that this should probably never be the case. More and more people only have mobile internet and we shouldn’t punish them (experience-wise) by not allowing them to do what they need with the website via our app.
  6. Account creation requires a lot of information from users, I broke this down so that the first step would block the majority of duplicate accounts from being created. Each step after this followed a basic ‘like-group’ approach.

Problems

  1. During account creation, I included a customizable setting to adjust the behavior of refilling the account. This was based on what I remember of the default settings when I originally created my account. This information could be tailored much better with access to the data the Tollway Authority keeps on usage. Additionally, the define a replenishment amount could be fleshed out more. I don’t feel this was needed for this level of prototype.
  2. Creating an account on the website is not possible for testing procedures as it requires brand-new account information (transponder), which I do not possess.

Results

I reached out to the original commenter and provided a link to the Axure prototype for them to review.

ipass_results

Illinois Tollway Board

A couple months after I finished this project, I realized that while I had designed an excellent solution to a real problem being faced by the Illinois Tollway Board with their digital IPASS experience more could still be done.  So, I gathered my materials, made some decks, and presented the work I did and my philosophy behind it to the Illinois Tollway Board.  It was a great experience.  Before I spoke, there were a couple presentations which made it clear that a lot of effort is put forth to provide better service to the drivers of Illinois’ Tollways.

The Future

It can be easy with personal projects to lose sight of reality or the complex dynamic that stakeholders can bring to projects. I think by including the original complainant, I have bypassed this concern to some degree and this is a tactic many companies use today when designing, going back to the individual who first spoke. Although I am missing out on the dynamic that a governmental authority would bring to the project which might be an explanation why the original site is set up the way that it is.

There are areas of the design that could be further expanded on if access to statistics and data were provided. At this point in time, rough guesses were made. I also considered added functionality to the initial display by included a metric for users to know when the next refill might take place. “Based on current usage, refill with take place in 10 days, refill now?” Or something similar. I believe this might lead to future uncertainties from uses, perhaps as an option then?

Leave a Reply

Your email address will not be published. Required fields are marked *