For this particular design challenge I was asked to extend the existing hum app to allow customers the ability to find and interact with auto repair service providers when the app identifies a service is required. 

Extend the existing hum app to allow users the ability to find and interact with auto repair service providers


For this particular design challenge I had several assumptions I based everything that follows off of.

  1. Beyond the visual clues and indicators demonstrating something is wrong, the app would provide instructional information to help the customer understand the particular error or failure circumstances and what might be causing the problem.
  2. The app would utilize proximity to the customers location to initiate a search for finding a participating service provider.
  3. The service already has accumulated a bevy of participating service providers that allow the kind of integration needed for scheduling capabilities and messaging within the app itself.
  4. The app provides a messaging mechanism that allows the service provider technician the ability to reach out and message the customer. In an effort to save time, I am assuming this functionality exists.
  5. For any places where I demonstrate potential payment processes, it is assumed that participating service providers are already part of the equation and do in fact have these types of integrations in place.
  6. If you have determined that a particular service provider is your preferred, the app will take you directly to them versus going through the "Find a provider" process. 
  7. In order to save some time, I did not create designs for wearables, even though the use of such devices would be a potential added valuable.
  8. A very important assumption for this particular design solution is that it isn't based on any formal audience behavioral analysis work. The individual components that make up the defined interface and experience are derived solely on my own assumptions versus relying on any qualitative insight.


Data Model

Click to view larger

To begin the definition part of the project I initially created an exemplary data model to map out the possible content pieces that might need to be used within the user interface.

Initial Flow

Click to view larger

This flow diagram represents thoughts around the initial flow for receiving a notification and moving through the new app pieces to support finding participating service providers.

Repair Management Flow

Click to view larger

This flow diagram represents my initial thinking around repair maintenance and the ongoing management needed while using the app.


Notifications would become a big part of this added functionality and provide several different ways in which the customer can be informed of any pending issues or when an error is identified. 

Dash Notification

Click to view larger

This is an example of a vehicle error message presented via the dash. Ideally the applications notification would appear around the same time or shortly after your vehicle identifies an issue.

Mobile Notification

Click to view larger

The above sketch represents potential mobile and wearables based notifications that provide the vehicle error message.

notification detail

Click to view larger

This example represents sketches around the mobile notification. The sketch on the left is the base-level notification and then the right represents when pressed and the possible actions that could appear. These are: Learn More, Talk to a Technician, and Remind Me Later. The later could potentially be a number of different options or simply something that says "Remind me Tomorrow". This would allow the customer to ignore the message and receive it again via their control.

Screen sketches

Click to view larger

To work through the different scenarios and possible interaction areas I created quick sketches to represent the different screens that would be needed to move through the app in order to support the discovery of an issue and finding a participating service provider. 

  1. This is an example of the existing notifications screen. I cannot access the real screen so I made some assumptions on what might be provided here. This is simply just a reference to see how the customer might use this screen to access a particular vehicle alert, versus relying on the notification directly.
  2. This is an example of the vehicle alert detail screen. This screen provides details on the alert provided and description information to help inform the customer on how important it is and what they should do to possible remedy it.
  3. This is example of the screen used to locate a potential service provider. This utilizes the map control and allows the customer to scroll around the map or enter specific search criteria. It is assumed the app would utilize the customers proximity to initiate the map view.

Click to view larger

The screens above represent what would be needed in order to view a service providers details and scheduling a service repair. 

  1. This is an example of the service provider details screen. This screen gives the customer the details surrounding the chosen service provider, including: Name, contact info, what services they offer and the option to make them your preferred provider for future uses.
  2. This is an example of the scheduling screen. Here we see a calendar control that allows the customer the ability to choose the desired date and time slot. When there are dates / times that are not available they would be grayed out. This information would be pulled directly from the service provider.
  3. This is an example of the scheduling confirmation screen. Once the customer chooses to make a reservation they will be taken to this repair confirmation screen. This screen provides details around the date and time they are to drop off the vehicle off. It also provides the ability to set a reminder on your mobile device (even though I am assuming a notification function will be part of the app itself - this was more of creating a reminder in your default calendaring app). There is also a mechanism to change the schedule if needed, which would return the customer to the previous screen.

Click to view larger

The screens above represent accessing and managing an ongoing active repairs.

  1. This is an example of the "My Repairs" repair management screen. Here is where you can get access to any active or completed repairs made. This would become a main navigational area within the app itself and can be accessed by the main menu.
  2. This is an example of the active repair. Here the customer can see the service provider details again and the status of their given repair. 
  3. This is an example of when the repair is complete. This screen provides the details on what the service provider did and if there is a charge and how much that charge will be. It also provides a mechanism to pay for the services rendered directly (this assumes there is payment capabilities associated with the given service provider built into the app itself).


For the purposes of this design challenge I decided to move from sketches directly into screen designs and utilized Sketch to create the various screens / states needed.

Click to view larger

The design examples above represent fourteen (14) screens that were created. Each screen then gets exported into their own individual screen asset, which I then utilized in Invision to create a quick click-through prototype (see below).


All Screens

Below are all the various screens, including different state variations. Click on any to view larger and then use the right / left arrows to cycle through all images.


Now that I have created a design concept there are some outstanding questions that should be reviewed in order to validate any assumptions used during the creation of this functionality. The list below represents most of the questions that I think would need to be answered in order to make final design decisions.

  1. There are several assumptions defined prior to any work created. Obviously these assumptions should be taken into account during any evaluation with this design concept.
  2. Is the right content being used to convey the appropriate service provider?
  3. Is the right content being used to represent your vehicle during a repair?
  4. What information is most important to the customer during the repair process?
  5. Do we have the right hierarchy of information on each screen?
  6. Is their a better way to display the date and time slot pieces in order for the customer to select a service repair reservation? 
  7. Do folks understand the visual cues for what isn't and is available in the date and time slot selection process?
  8. Should you be able to go directly to "Pay Invoice" when your vehicle repair has been completed - from the notification screen?
  9. Should there be an additional option in the notification for when your vehicle repair is complete for viewing the detail?
  10. Should the access to finding an authorized service provider only be available through notifications or should their be another section within the app itself devoted to service providers? 
  11. Should there be ratings and comments for individual service providers for everyone to view?