FMQ - Senior Product Designer

Process

01

Discover

Understanding the problem
Understanding users and stakeholders
Understanding the product and context

02

Define

Location permissions architecture
Clock in/out end-end user journey
Action plan

03

Make

Design definition of location permissions flow
Design definition of the new clock-in/out journey
Clock-in/out interaction
Update hours flow

04

Test

User testing
Conclusions from user feedback

05

Iterate

Metrics and actions for improvement
Tweaks to the "update hours" flow
UI update from the design system

Process

01

Discover

Understanding the problem
Understanding users and stakeholders
Understanding the product and context

02

Define

Location permissions architecture
Clock in/out end-end user journey
Action plan

03

Make

Design definition of location permissions flow
Design definition of the new clock-in/out journey
Clock-in/out interaction
Update hours flow

04

Test

User testing
Conclusions from user feedback

05

Iterate

Metrics and actions for improvement
Tweaks to the "update hours" flow
UI update from the design system

Process

01

Discover

Understanding the problem
Understanding users and stakeholders
Understanding the product and context

02

Define

Location permissions architecture
Clock in/out end-end user journey
Action plan

03

Make

Design definition of location permissions flow
Design definition of the new clock-in/out journey
Clock-in/out interaction
Update hours flow

04

Test

User testing
Conclusions from user feedback

05

Iterate

Metrics and actions for improvement
Tweaks to the "update hours" flow
UI update from the design system

Discover

Context

Indeed is the #1 job site worldwide, with over 350M+ unique visitors per month. It owns Indeed Flex, a temporary staffing app that offer users (shift workers) access to work at their fingertips.

In the Indeed Flex app, when users book jobs, they can record their working times directly in the app, which allows to process payments. Although this fraction of the experience was working relatively well, it was far from being the best.

Discover

Context

Indeed is the #1 job site worldwide, with over 350M+ unique visitors per month. It owns Indeed Flex, a temporary staffing app that offer users (shift workers) access to work at their fingertips.

In the Indeed Flex app, when users book jobs, they can record their working times directly in the app, which allows to process payments. Although this fraction of the experience was working relatively well, it was far from being the best.

Discover

Context

Indeed is the #1 job site worldwide, with over 350M+ unique visitors per month. It owns Indeed Flex, a temporary staffing app that offer users (shift workers) access to work at their fingertips.

In the Indeed Flex app, when users book jobs, they can record their working times directly in the app, which allows to process payments. Although this fraction of the experience was working relatively well, it was far from being the best.

The Time & Attendance team aimed at providing a more frictionless and accurate experience for users like Sarah, and reduce workload for stakeholders like Operations.

When I joined the team, the design lacked a clear user-centred focus of the desired clock in/out method.

I learned that users had 2 ways to clock in/clock out :

A direct method through buttons
A QR code method.

When I joined the team, the design lacked a clear user-centred focus of the desired clock in/out method.

I learned that users had 2 ways to clock in/clock out :

A direct method through buttons
A QR code method.

When I joined the team, the design lacked a clear user-centred focus of the desired clock in/out method.

I learned that users had 2 ways to clock in/clock out :

A direct method through buttons
A QR code method.

The direct clock in method requires location permissions. This method enables quick payments since the recorded times go directly to IndeedFlex system, enabling processing payments faster.

On the other side, the QR code method is an alternative that the client (employer) has available for users to clock-in/out onsite. However with this method, the logged hours are kept at the clients’ records, therefore payments take longer. The reason is because clients have to register their timesheets in the IndeedFlex system first.

Challenges

The process started by talking to Support to understand users’ issues with this topic. I also partnered with our UX researcher and followed up on interview rounds. Some users stated:

“Not being clear why geolocation is required”

Some users like Sarah, didn’t understand why location permissions were requested. Users don’t want to be tracked, therefore didn’t provide them, missing the possibility to get paid faster.

“Clocked-out by accident”

This issue happened because after some users clocked-in, the screen’s interface had an active button to clock out. If it’s tapped by accident leads to clock-out earlier than the scheduled time (and as a result get paid less).

“Forgot to clock-out”

Users like Sarah, who in a rush could forget to clock-out. As a consequence, they would have to spend time chasing Support to record the right time so they could get paid accordingly.

“Jumping to action without clocking-in”

If their assignment’s venue is busy upon arrival, some users stated that may just jump into action and start working. If they forget to use the app to record the start time, they would need to reach Support.

“Lack of visual confirmation of having clocked-in”

The interface lacked of stronger visual confirmation of the actions completed. For example, the only success indicator was a small portion of the UI that displays the registered time.

“Inaccurate payment that required Support’s help”

Users in many cases realised that was something wrong with the recorded hours when they got paid. They needed to reach Support to sort out the part that what was missing.

Challenges

The process started by talking to Support to understand users’ issues with this topic. I also partnered with our UX researcher and followed up on interview rounds. Some users stated:

“Not being clear why geolocation is required”

Some users like Sarah, didn’t understand why location permissions were requested. Users don’t want to be tracked, therefore didn’t provide them, missing the possibility to get paid faster.

“Clocked-out by accident”

This issue happened because after some users clocked-in, the screen’s interface had an active button to clock out. If it’s tapped by accident leads to clock-out earlier than the scheduled time (and as a result get paid less).

“Forgot to clock-out”

Users like Sarah, who in a rush could forget to clock-out. As a consequence, they would have to spend time chasing Support to record the right time so they could get paid accordingly.

“Jumping to action without clocking-in”

If their assignment’s venue is busy upon arrival, some users stated that may just jump into action and start working. If they forget to use the app to record the start time, they would need to reach Support.

“Lack of visual confirmation of having clocked-in”

The interface lacked of stronger visual confirmation of the actions completed. For example, the only success indicator was a small portion of the UI that displays the registered time.

“Inaccurate payment that required Support’s help”

Users in many cases realised that was something wrong with the recorded hours when they got paid. They needed to reach Support to sort out the part that what was missing.

Challenges

The process started by talking to Support to understand users’ issues with this topic. I also partnered with our UX researcher and followed up on interview rounds. Some users stated:

“Not being clear why geolocation is required”

Some users like Sarah, didn’t understand why location permissions were requested. Users don’t want to be tracked, therefore didn’t provide them, missing the possibility to get paid faster.

“Clocked-out by accident”

This issue happened because after some users clocked-in, the screen’s interface had an active button to clock out. If it’s tapped by accident leads to clock-out earlier than the scheduled time (and as a result get paid less).

“Forgot to clock-out”

Users like Sarah, who in a rush could forget to clock-out. As a consequence, they would have to spend time chasing Support to record the right time so they could get paid accordingly.

“Jumping to action without clocking-in”

If their assignment’s venue is busy upon arrival, some users stated that may just jump into action and start working. If they forget to use the app to record the start time, they would need to reach Support.

“Lack of visual confirmation of having clocked-in”

The interface lacked of stronger visual confirmation of the actions completed. For example, the only success indicator was a small portion of the UI that displays the registered time.

“Inaccurate payment that required Support’s help”

Users in many cases realised that was something wrong with the recorded hours when they got paid. They needed to reach Support to sort out the part that what was missing.

Users’ feedback demonstrated that the interface didn’t help them to be aware of their possibilities with quick payments. In addition, having no control over the recorded hours couldn’t avoid relying on Support and other teams to resolve payment issues.

Define

From the insights collected, I worked with the team to put an end-to-end user journey and analyse the current experience. To tackle the problem of location permissions, it was necessary to understand the technical constraints first. The user flows came from several iterations in collaboration with the engineers and stakeholders.

Define

From the insights collected, I worked with the team to put an end-to-end user journey and analyse the current experience. To tackle the problem of location permissions, it was necessary to understand the technical constraints first. The user flows came from several iterations in collaboration with the engineers and stakeholders.

Define

From the insights collected, I worked with the team to put an end-to-end user journey and analyse the current experience. To tackle the problem of location permissions, it was necessary to understand the technical constraints first. The user flows came from several iterations in collaboration with the engineers and stakeholders.

For the case of the definition of the new clock-in/out experience, I mapped the current flow to the desired one and presented to the team for understanding. The current experience lacked of feedback, so besides of improving that, I wanted to bring a spark to the UI.

I worked in a live document in Figma where I incrementally mapped the ideal experience evolving from the old one. The QR code screen was static and lacked of active feedback about the shift status.

I thought that it would be worth to inform the user through their journey, and see a progress before, during and after the shift. So besides of improving the feedback, I wanted we delivered a more delightful experience through a better looking UI.

Make

Location permissions enablement

The experience improvement was delivered in 2 phases, starting by bringing first the location permissions part to the flow. I started to work in te first wireframes to help users to make a more informed decision about providing or not the location permissions.

The solution would consist in linking the current clock-in/out screens to a new screen that would explain the purpose of enabling location permissions. If users agreed with it, they would be redirected to the settings page to enable them.

Make

Location permissions enablement

The experience improvement was delivered in 2 phases, starting by bringing first the location permissions part to the flow. I started to work in te first wireframes to help users to make a more informed decision about providing or not the location permissions.

The solution would consist in linking the current clock-in/out screens to a new screen that would explain the purpose of enabling location permissions. If users agreed with it, they would be redirected to the settings page to enable them.

Make

Location permissions enablement

The experience improvement was delivered in 2 phases, starting by bringing first the location permissions part to the flow. I started to work in te first wireframes to help users to make a more informed decision about providing or not the location permissions.

The solution would consist in linking the current clock-in/out screens to a new screen that would explain the purpose of enabling location permissions. If users agreed with it, they would be redirected to the settings page to enable them.

In this first phase, we were limited of what we could change from the current clock in/out screens, but I proposed some minimal changes that could start solving some of the current user problems. These improvements were:

To hide the clock out button, as it wasn’t required when clocking-in.
Replace custom buttons for the design system ones (primary)
Implement a confirmation modal to avoid users clock out by accident.

In this first phase, we were limited of what we could change from the current clock in/out screens, but I proposed some minimal changes that could start solving some of the current user problems. These improvements were:

To hide the clock out button, as it wasn’t required when clocking-in.
Replace custom buttons for the design system ones (primary)
Implement a confirmation modal to avoid users clock out by accident.

In this first phase, we were limited of what we could change from the current clock in/out screens, but I proposed some minimal changes that could start solving some of the current user problems. These improvements were:

To hide the clock out button, as it wasn’t required when clocking-in.
Replace custom buttons for the design system ones (primary)
Implement a confirmation modal to avoid users clock out by accident.

Negotiating these first small UX improvements was a win in this first stage. Having one action (button) and ‘protecting’ users from involuntary clock-out was necessary. In addition, incorporating corrections using the design system of that time, helped to have a more consistent UI.

The end-to-end clock-in/out experience

As mentioned before, the old clock-in/out experience apart of lacking feedback, it lacked spark. I decided to explore some ideas that we could apply it our user’s journey and gain inspiration from other UIs.

In the current experience we were showing logged times, but not an actual times and the status of the shift.

The end-to-end clock-in/out experience

As mentioned before, the old clock-in/out experience apart of lacking feedback, it lacked spark. I decided to explore some ideas that we could apply it our user’s journey and gain inspiration from other UIs.

In the current experience we were showing logged times, but not an actual times and the status of the shift.

The end-to-end clock-in/out experience

As mentioned before, the old clock-in/out experience apart of lacking feedback, it lacked spark. I decided to explore some ideas that we could apply it our user’s journey and gain inspiration from other UIs.

In the current experience we were showing logged times, but not an actual times and the status of the shift.

The idea was designing a timer UI that displayed the time status and shift progress through the user journey to give users a sense of completion.

This UI element also would help to give more sense to the context of manual/direct clock-in (by using the buttons) instead of the QR code that needed a secondary placement.

The idea was designing a timer UI that displayed the time status and shift progress through the user journey to give users a sense of completion.

This UI element also would help to give more sense to the context of manual/direct clock-in (by using the buttons) instead of the QR code that needed a secondary placement.

The idea was designing a timer UI that displayed the time status and shift progress through the user journey to give users a sense of completion.

This UI element also would help to give more sense to the context of manual/direct clock-in (by using the buttons) instead of the QR code that needed a secondary placement.

Through the user journey the timer would display the shift status progress depending on the context of the workday:

Before the shift; the user would see the remaining time for the shift to start with an empty timer.
Before the shift, late to clock-in; the user would see the timing filling up in red.
During the shift, remaining time for the shift to end; the user would see the timing filling up in blue.
Break time progress; the user would see the time filling up in green.
Completed shift, not yet clocked-out; the user would see the timer totally filled up in blue.
Shift not clocked-out; the user would see the filled timer in grey as ‘expired’
Clocked-out; the user would see a green filled timer as ‘complete’ or ‘ended’

Through the user journey the timer would display the shift status progress depending on the context of the workday:

Before the shift; the user would see the remaining time for the shift to start with an empty timer.
Before the shift, late to clock-in; the user would see the timing filling up in red.
During the shift, remaining time for the shift to end; the user would see the timing filling up in blue.
Break time progress; the user would see the time filling up in green.
Completed shift, not yet clocked-out; the user would see the timer totally filled up in blue.
Shift not clocked-out; the user would see the filled timer in grey as ‘expired’
Clocked-out; the user would see a green filled timer as ‘complete’ or ‘ended’

Through the user journey the timer would display the shift status progress depending on the context of the workday:

Before the shift; the user would see the remaining time for the shift to start with an empty timer.
Before the shift, late to clock-in; the user would see the timing filling up in red.
During the shift, remaining time for the shift to end; the user would see the timing filling up in blue.
Break time progress; the user would see the time filling up in green.
Completed shift, not yet clocked-out; the user would see the timer totally filled up in blue.
Shift not clocked-out; the user would see the filled timer in grey as ‘expired’
Clocked-out; the user would see a green filled timer as ‘complete’ or ‘ended’

In addition I explored the possibility of having a pulse interaction in the timer UI when the shift is live. Consulting with the engineers, it would a pretty simple interaction to implement if they got the animation in json.

I partnered with a UX colleague with knowledge in After Effects and guided me to produce a simple animation for the active statuses of the shift. I made animations to represent the statuses:

red for shifts started but running late to clock-in
blue for active shift in progress
green for meal break
and clock-out interaction of end of the shift (final two pulses interaction)

In addition I explored the possibility of having a pulse interaction in the timer UI when the shift is live. Consulting with the engineers, it would a pretty simple interaction to implement if they got the animation in json.

I partnered with a UX colleague with knowledge in After Effects and guided me to produce a simple animation for the active statuses of the shift. I made animations to represent the statuses:

red for shifts started but running late to clock-in
blue for active shift in progress
green for meal break
and clock-out interaction of end of the shift (final two pulses interaction)

In addition I explored the possibility of having a pulse interaction in the timer UI when the shift is live. Consulting with the engineers, it would a pretty simple interaction to implement if they got the animation in json.

I partnered with a UX colleague with knowledge in After Effects and guided me to produce a simple animation for the active statuses of the shift. I made animations to represent the statuses:

red for shifts started but running late to clock-in
blue for active shift in progress
green for meal break
and clock-out interaction of end of the shift (final two pulses interaction)

Enable updating worked hours

If we remember Sarah’s story, when she forgot to clock-out in her shift, she had to contact Support to resolve the issue and get paid.

The last part of the flow was defining how to provide users the ability to update worked hours. In this case, Sarah could be able to review and introduce the actual worked hours manually, instead of reaching Support.

To solve this problem, I studied 2 possibilities.

Enable updating worked hours

If we remember Sarah’s story, when she forgot to clock-out in her shift, she had to contact Support to resolve the issue and get paid.

The last part of the flow was defining how to provide users the ability to update worked hours. In this case, Sarah could be able to review and introduce the actual worked hours manually, instead of reaching Support.

To solve this problem, I studied 2 possibilities.

Enable updating worked hours

If we remember Sarah’s story, when she forgot to clock-out in her shift, she had to contact Support to resolve the issue and get paid.

The last part of the flow was defining how to provide users the ability to update worked hours. In this case, Sarah could be able to review and introduce the actual worked hours manually, instead of reaching Support.

To solve this problem, I studied 2 possibilities.

The team and other stakeholders preferred to make the “updating hours” feature an option, since the general assumption was that not always will be necessary.

Test

With the help of our UX researcher, we conducted usability testing with 4 users, and the outcomes were:

100% of users clocked in providing location permissions.
All users successfully identified that by enabling location they would get paid quickly and this would be a reason to use the direct method over QR Code.
Since the QR method was placed in a modal, users focused on the direct clock in method instead.
All users intuited the filling up timer behaviour before the shift started to indicate the remaining time.

Test

With the help of our UX researcher, we conducted usability testing with 4 users, and the outcomes were:

100% of users clocked in providing location permissions.
All users successfully identified that by enabling location they would get paid quickly and this would be a reason to use the direct method over QR Code.
Since the QR method was placed in a modal, users focused on the direct clock in method instead.
All users intuited the filling up timer behaviour before the shift started to indicate the remaining time.

Test

With the help of our UX researcher, we conducted usability testing with 4 users, and the outcomes were:

100% of users clocked in providing location permissions.
All users successfully identified that by enabling location they would get paid quickly and this would be a reason to use the direct method over QR Code.
Since the QR method was placed in a modal, users focused on the direct clock in method instead.
All users intuited the filling up timer behaviour before the shift started to indicate the remaining time.

The insights about the ‘update worked hours’ section was a bit different. With an A/B test we asked where in the screen they would prefer to have that option.

3 of 4 users said they preferred to have it at the top since it helps to prompt them to check the time just in case.
However, since they weren’t in a real context of work, we still couldn’t know with certainty how effective it could be.

The insights about the ‘update worked hours’ section was a bit different. With an A/B test we asked where in the screen they would prefer to have that option.

3 of 4 users said they preferred to have it at the top since it helps to prompt them to check the time just in case.
However, since they weren’t in a real context of work, we still couldn’t know with certainty how effective it could be.

The insights about the ‘update worked hours’ section was a bit different. With an A/B test we asked where in the screen they would prefer to have that option.

3 of 4 users said they preferred to have it at the top since it helps to prompt them to check the time just in case.
However, since they weren’t in a real context of work, we still couldn’t know with certainty how effective it could be.

Iterate

The data showed an overall improvement the clock in/out process, resulting in:

a 95% reduction of sessions requesting location permissions, which means, more and more users started to clock-in/out using the direct method. As a result of this, more users took advantage of faster payments while the location settings would help to make sure those users clocked-in/out at the right location.  
On the other hand, in this first iteration there wasn’t a significative decrease of support tickets according to “wrong hours”. The assumption was that, not many users noticed the option to update worked hours. This assumption was taken from the “Tap to Update Hours after Shift Completed” metric.

Iterate

The data showed an overall improvement the clock in/out process, resulting in:

a 95% reduction of sessions requesting location permissions, which means, more and more users started to clock-in/out using the direct method. As a result of this, more users took advantage of faster payments while the location settings would help to make sure those users clocked-in/out at the right location.  
On the other hand, in this first iteration there wasn’t a significative decrease of support tickets according to “wrong hours”. The assumption was that, not many users noticed the option to update worked hours. This assumption was taken from the “Tap to Update Hours after Shift Completed” metric.

Iterate

The data showed an overall improvement the clock in/out process, resulting in:

a 95% reduction of sessions requesting location permissions, which means, more and more users started to clock-in/out using the direct method. As a result of this, more users took advantage of faster payments while the location settings would help to make sure those users clocked-in/out at the right location.  
On the other hand, in this first iteration there wasn’t a significative decrease of support tickets according to “wrong hours”. The assumption was that, not many users noticed the option to update worked hours. This assumption was taken from the “Tap to Update Hours after Shift Completed” metric.

To sort this out, we decided to apply the option 2 explained previously (clock-out -> review worked hours -> clocked-out). This way users would have to review their recorded times before to clock-out as a confirmation step.

In addition, thanks to the design system project, some improvements were subsequently introduced to the screens. While some coloured components were ‘stealing the spotlight’ from other status UIs, now they were able to do a better job in a cleaner interface.

This change brought a 100% success of reviewing worked hours post shift since now all users would pass through this step. It also reduced support tickets considerably

Final outcomes

This project was a great iterative process that made the UX better even when the UI wasn’t the priority yet.

Having a good communication with the engineers and negotiating small incremental UX improvements started to solve problems early in the process.

Users like Sarah now will be able to enjoy a more intuitive experience, and get paid faster by enabling location permissions. They also will be able to resolve any inaccuracies of their logged hours directly through the app when they clock-out, without depending necessarily of Support.

In this project, not just users won, but also the Operations teams working behind the scenes, that saw a reduced workload from user requests regarding to wrong hours and payments.

Final outcomes

This project was a great iterative process that made the UX better even when the UI wasn’t the priority yet.

Having a good communication with the engineers and negotiating small incremental UX improvements started to solve problems early in the process.

Users like Sarah now will be able to enjoy a more intuitive experience, and get paid faster by enabling location permissions. They also will be able to resolve any inaccuracies of their logged hours directly through the app when they clock-out, without depending necessarily of Support.

In this project, not just users won, but also the Operations teams working behind the scenes, that saw a reduced workload from user requests regarding to wrong hours and payments.

Final outcomes

This project was a great iterative process that made the UX better even when the UI wasn’t the priority yet.

Having a good communication with the engineers and negotiating small incremental UX improvements started to solve problems early in the process.

Users like Sarah now will be able to enjoy a more intuitive experience, and get paid faster by enabling location permissions. They also will be able to resolve any inaccuracies of their logged hours directly through the app when they clock-out, without depending necessarily of Support.

In this project, not just users won, but also the Operations teams working behind the scenes, that saw a reduced workload from user requests regarding to wrong hours and payments.