Case Study: Time Entry Application

Creating an intuitive experience for employees recording time off from work

Includes: wireframes, UX consulting, usability testing

Situation

Duke University is in the middle of a multi-part project to create mobile versions of a suite of employee software using the SAP Mobile Platform. This phase of the project was focused on an app used by salaried employees for entering time taken off from work.

When I joined the project, an initial set of wireframes had been approved, but stakeholders wanted to revisit the workflow. Management had expressed interested in seeing a “one-tap” time entry process, and I was asked to work through some ideas to achieve that goal.

I started from the existing wireframes, which allowed users to toggle between two view modes: a list with more details about the time entered, and a calendar that provided a more compact view. In some initial usability testing, a colleague and I had found that both views were fairly intuitive, and users’ preferences were split fairly evenly between the two.

calendar view

calendar view, new entry

list view

list view, new entry

Process

I started by creating new wireframes reflecting several of the ideas that had been proposed, then brought them to a meeting of the advisory group for the project.

alternate time entry screen

confirmation screen

balances hidden

balances hidden in header

form plus timecard

form plus list

approval as separate step

leave type as button

In the meeting, I started the presentation by pitching a different framework for thinking about the project:

  • User scenarios: I broke the general scenario of “employee enters time” down into four more specific use cases for the app: entering time off on the day the time was taken; entering time off before or after the time was taken; entering time off at the end of the month and submitting the completed timecard; and submitting the completed timecard without entering any additional time off.
  • UX principles: I explained that current UX research suggests there is no optimal number of clicks or taps to complete a task. Instead, what’s important is information scent, and how obvious it is to users what to do next.

With that framework established, I walked through half a dozen wireframe variations and explained the upsides and downsides of each in relation to the relevant scenarios and principles. The group discussed the options using the framework I had provided, and we settled on an approach expanding on the best of the existing options (outlined below under Solution).

From there, I revised the wireframes to reflect the new workflow, then walked through it again at the next advisory group meeting. At that point, everyone agreed on the workflow.

The main open question left after that meeting was what wording to use for the link to let an employee add multiple entries on the same day. To resolve that last question, I showed three different variations of the wireframe, each with a different wording for the link, to several users apiece. Two of the options caused confusion, whereas everyone understood the third. Based on that outcome, I recommended the third option to the advisory group.

Solution

The finalized workflow is a loop starting with the timecard; the employee sees any entries already made for that month and their remaining leave balances.

start screen with no entries

start screen with entries made

Adding an entry is a two-step process: the employee selects a date from a calendar, then selects a leave type and number of hours. Common options are used as defaults, and rarely used leave types are deemphasized in an expandable “Other” leave type option.

new entry: date picker

new entries: details

editing an existing entry

entry with two leave types

After submitting the new entry, the employee is returned back to the timecard / list view, with a confirmation message, the new entry added to the list, and updated leave balances.

new entry added

entry deleted

By introducing a UX perspective to the project, I was able to reframe the decision criteria and steer the group toward a better solution. Wireframing a range of ideas, and then looking at them through the lens of likely user scenarios and usability principles, helped to demonstrate what the experience of different approaches would be like in practice. The initial usability testing unearthed some advantages for each view in the original toggle workflow: the calendar felt familiar and easier for finding the right date, while the list view showed more useful information. But testing alone didn’t point to a new approach; focusing back in on the user scenarios was necessary to get us to a more opinionated interface that presented clear options at each step. The final workflow incorporates the strong points from both of the original options into one clear path that works well across the different time entry scenarios.

▲ Top