U-Shift - A Work-Shift Management App
This application manages a user’s work shifts, weekend shifts, holiday shifts, and PTO requests.
Overview
U-Shift is an application that manages a user’s work shifts, weekend shifts, holiday shifts, and PTO requests. My challenge was to build an app from ground up which would give the employers of a company a better way to manage their employees. I set out to design a solution that would meet the needs of the target user without depending on GitHub pages, Excel sheets or any kind of scripts, and make the app a pleasure to use.
Project Length: 3 weeks
My Role: Research, interaction design & visual design
The Problem
Working in a very fast and evolving field, we often had to be very flexible in our work availability times and work in shifts to cater to the demands of our clients.
The everchanging work shifts due to an individual's absence or assignment to a different project often caused a lot of shift mismanagement in our team, leading to a lot of confusion and often inefficient productivity.
The lack of a centralized place to view and/or request for PTO, weekend shifts and holiday shifts.
The usage of local copies which an individual would often fail to update during the ever changing work shifts has lead to a lot of confusion.
The inability to update the individual local copies of weekend shifts which would often change either due to swapping among the analysts or due to someone's day off.
The inability of the team lead to keep track of multiple PTO requests, especially during holidays.
A script used to calculate the weekend shift.
Weekend shifts on a text file.
The Solution
The Struggle …
After seeing the struggle for a couple of years I took it upon myself to build a tool which would automate most of the scheduling. I knew how to build a tool and which programming language to use but I did not know where to start with the design. There were many apps and the learning curve was a bit steep.
When the designer is also a user…I know .. I know.. its not right, but hear me out.
Even though it is not right as designers to assume that our users are similar to us or that they share our beliefs and will behave similarly in a given context.
The key word here is “assumption”, I am not assuming anything.
It so happened that I was a user who took it upon myself to design an app for the problem we as a team have been facing for many years. It helped a lot that I knew exactly what the issues were and what me as an individual and others as part of the team were going through.
User Research & Flow Charts
I started by making a list of what I thought the user requirements would be for this scheduler app. I came up with around 5 requirements and felt that for this web app to be very robust I needed input from my teammates, who after all, would also be the end users.
After discussing a few times with everyone, we came up with a list of about 10 basic requirements for the application.
Finally I created a flow chart to understand how I can address the problems and where each section would go.
Wireframes
My next step was to create wireframes by drawing the basic skeletons using the Procreate drawing app. I started with the sign in page and mapped out each page, deciding which information would work best where and where I could place the interactive elements so that they would be as efficient and clean as possible. The flowchart helped a lot in drawing up the wireframes.
The first Mock-ups
Once I had all the wireframes ready, I also wanted to create a couple of quick mock-ups to show it to the users. I used Procreate again to give some colors to my wireframes.
User Feedback - Features
Since this is a reimagination of the original web-app, I took feedback from many users. The submitted wireframes and mockup received a lot of feedback along with appreciation.
For example:
I designed the landing page such that the analyst could see the shifts just for the current day but my teammates wanted an option where they can select and view the shifts for different dates.
In the View PTO page, my original design was that an analyst could view only their own PTO. However, my teammates wanted an option to view everyone else’s PTO and also see if their PTO conflicts with anyone else’s.
User Feedback - The Visual
Though the wireframes received mostly positive feedback with many feature requests, not everyone was happy with how the mock-ups turned out. The users were of the feeling that even though this is not a customer/client facing app and is for internal consumption only, the app’s design is very basic and is not exciting.
Back to the Drawing Board…
Since almost everyone suggested a visual overhaul, I went back to the drawing board to redesign the app, right from the wireframes. When I asked the users what exactly didn’t they like about the app, they could not pinpoint an exact reason, but I thought I understood what the problem might be.
I had designed the app in a way that it looks very boxy and heavy. So I went about removing the huge boxes, and information banners, making use of the negative space to highlight what is important.
After more feedback, I moved the circular notification button at the top to the Tap Bar and increased the size of the segmented control in order for the users to be able to tap on them easily.
Finer Details
The Colors
When it came to the color scheme, I wanted to select colors which were simple and not over the top, preferably something from the same color family and are subtle and unobtrusive. I mostly stayed within the blue family and used the color white as much as possible to make the app feel light and airy. I used brighter colors to highlight the users or anything that needs to stand out.
Typography…
Since I had to work on a Windows machine, I chose to use the font Segoe UI and then later chose Lato. Although it is different from my favorites like Helvetica or SF Pro, it was still very light and elegant, something I was looking for.
Due to the relatively limited screen size of a phone, I ended up having widows in the text. Because decreasing the font size beyond a point made the text unreadable, I employed kerning or tracking to remove the widows.
A Few No’s
When it came to navigating through the pages of the app, I actively avoided using nested pages and instead opted for a combination of Tab Bar and Segmented Controls to display different views. When I no longer could effectively use them without crowding the screen, I used something similar to a popup page which could be dismissed by a flick down if no changes are made or tap on done if any data has been changed.
It was also tempting to place shadows on all blocks of information on a page, but I intentionally didn’t do this in order to avoid placing everything at the top of the visual hierarchy. I wanted to emphasize the buttons and segmented controls, so they are the only elements which have shadows.
Final Feedback & Impact
I have shown the final clickable prototype to the users with whom I collaborated during the research process and they were very happy with the outcome of the app. They believed that such an app would definitely help any team which either is not previously using a similar app or does not have access to one. I had people record their screens during the usage of the app and send me, I noticed that most of the usage was very instinctive.
