Shift Start Time

The Agent Mobile App

This interaction is part of an app called "Agent Mobile". That app's primary purpose is to allow employees of large organizations, primarily in contact centers, to see and manage their schedule. If those employees change their schedule, the information is then fed into the Intradiem rules engine, which will determine whether the changes are allowed.

My Role & Responsibilities

  • UI Design
  • Prototype Design
  • Interaction Design
  • Icon Design
  • Information Architecture
  • User Flows
  • User Tester
  • User Researcher

Background

I had to design an interaction that would allow users to change their scheduled start time, while restricting them enough so that the data they sent to the rules engine would not be invalid or overly complex. This interaction would have to be easy and quick, as many situations that it could be used would be when other life events, such as a sick child, or a broken down car could elevate the user's stress.

Users

  • 22-35 years old.
  • Work in a contact center.
  • Some or no college degree.
  • Paid hourly, need to make sure that their quarterly performance metrics are met.
  • Financially incentivized to keep communication with managers if they need to change their schedule.
  • 32-40 hours a week, trying to fill extra hours to get to 40 if under full-time.
  • Primary work experience is in service industries.

Testing Method

Intradiem does has not historically developed mobile apps, and as a result I did not have access to budget for formal studies. Instead, I chose to go to area coffee shops, malls, and colleges, to do guerrilla-style usability tests. The contact center worker demographic aligns very well with retail/college-age people, so while it was not a perfect environment, I did get some good feedback. The prototypes demonstrated here were all built to be testable first, and then were reworked for UI specs and dev documentation. Overall I did around 6 rounds of testing, starting with the prototypes that have the black box in the center of the screen. The ideas previous to those did not align with the technical requirements for the project and were never user-tested.

Prototypes & Interactions

v1

The first versions that I designed emulated the behavior of many calendar applications, by placing small dots on either end of segments that made up the overall schedule.

Issues with this version:

  • Allowed users to send requests that would be invalid.
  • Segments became disconnected from each other.
  • No location for the user to know what they were requesting.
  • Conveyed a false sense of direct manipulation of a schedule. Needed to reiterate the request nature of this app.

Revisions for v2:

  • Make the segments more "sticky" to each other.
  • Increase touch target size.
  • Decrease chance of invalid request.

v2

Also, at this point of the process, we thought we would be able to communicate the odds of success of a request to the user. That later turned out to be not possible, but I started thinking about conveying that to the user.

Issues with this version:

  • Still allowed for invalid requests.
  • Prototype was buggy, leading to poor test results.
  • Still not enough room for content.
  • Odds of success was not clear.

These, again, tested well with my coworkers and some peers, but the issue became one of invalid requests. We almost started scoping the second option to be built, but the data that we would have to compose and send would not work. We had to take a step back and think about schedules differently than other calendar applications. Simple dragging of segments would not work.

v3

After doing a little digging, we found that the smallest unit we would need to use in the application would be the shift, as opposed to the individual chunks of the shift. The former is what is maintained and scheduled, the latter is then filled in when a shift is given to a user.

With this in mind, I changed the control from one that would manipulate parts of a shift, to one that would manipulate the entire shift. Also, I changed the user interaction from dragging dots, to a fixed manipulation point, with then entire schedule being the draggable element.

Issues with this version:

  • Too complex to develop
  • No clear summary of text
  • Information about request was too dense, limiting.
  • Users were tapping on the black box instead of dragging it when first presented with the UI.

v4 - Production Version

The information containers I had been using up to this point were too limiting, and as a result, I took some inspiration from Apple Maps and added a bottom sheet so that I could display more information.

This turned out to be a good decision, as that bottom sheet information center has now been able to be reused throughout the application, and later allowed an easy revision for Android.

Also, in this version, I added a controls for users who tapped on the black box instead of dragging it on first impression.

Aligning the UI with the User

I ran into 50% of users who thought to drag the black rectangle and 50% who tapped on it. My earlier versions had relied on an overlay to teach the user how to interact with the UI, or a bounce when they took the wrong action, but I decided to make both methods of interaction correct instead of one or the other. If someone wanted to swipe, then nothing was stopping them. If they wanted to tap, then they'd encounter a familiar iOS control.

Both are fine, and both give inference to the other control, just in case the user would want to change their interaction method later on. By adding this to the prototype, my success rates doubled, and I began to only have issues when users pushed the edges of the prototype or tried to go in an unplanned direction. With these results in mind, it was pushed to development and product management for production.

Android Functionality

After the iOS version had been vetted, I took the ideas and concepts and tried to recreate them as closely as possible for Material Design on Android. This video shows a side-by-side comparison of the feature on each platform. I tried to keep material in mind throughout the iOS process, but some things did end up being different for each platform, while keeping the overall flow and presentation relatively similar.

Takeaways

Technical complexity + user testing will rule out our first ideas. My initial thoughts to emulate Apple's methods for interacting with a calendar were not incorrect, but rather turned out to be impossible for a problem like the one I was trying to solve.

Want to work on a project with me? Just want to chat?

Let's grab a cup of joe, go over the details, and get to work.
Contact Me ⇗