Internal Employee Schedule Management

While working at Gaslight, the first project I worked on was their team scheduling web app. Though the website and back-end data were built with Ruby on Rails, this specific part of the website leveraged React to display real-time information. The scheduler had been built over the summer by interns and while they had succeeded in creating a functional feature, they had not taken consideration for how it would be used. The end result had some significant UX/UI  hurdles that made using it awkward.

I was initially asked to give the web app a designers touch, specifically looking into how admin users determined the needs for projects at a glance.

I took some time to look over the architecture of the web app and followed that up with a user interview to determine how the web app was used. After the interview, it was clear to me that there were more UX/UI issues that could be addressed and there was an opportunity to get some of the work done while I was on the bench. After getting approval to expand the scope of work, the goals were:

• to re-evaluate the workflows of identifying needs for projects and assigning people to those needs
• to display how that affected the rates charged

There were a number of quality of life changes that improved the organization of information; small things like bringing buttons with related functionality to the same line instead of having one on the top and one on the bottom of the scheduler. But to address the tasks, there were more task-based changes that needed to be addressed.

The solutions I explored were:

• streamline engagement creation and needs assignment by including need assignment and filling with the engagement creation process
• reduce modal windows to a single modal for engagement CRUD
• Add a flyout window that would give more information on scheduler elements and act as a navigator for engagement and rate details.

Not all proposed changes made it into the final update for the scheduler. While they were lauded for effectively addressing the problem, the underlying data structures could not support the information architecture. That is to say, the changes were possible but the time and effort it would take to rewrite legacy data infrastructure outweighed the benefits that might be acquired by doing so, and would make it difficult to use the data that was already in place.

After spending a couple of weeks working the front-end react on a branch, I was placed on a client project and handed the project over to one a Sr. Developer to manage the back-end changes needed.