STC SCHEDULING
Jan 2019 - Aug 2019
Role
UX Designer
Scope
User Research
Journey Mapping
Wireframing
Tools
Axure, Miro
Summary
Yale's Student Technology Collaborative (STC) employs around 300 students in IT roles. The organization provides walk-in tech help centers, equipment loan checkout booths, computer labs, and more.
Scheduling shifts is a big task: not only are there a lot of employees, they also have differing needs across branches and job titles. My job was to design an intuitive scheduling tool that would make scheduling faster and smoother.
MY PROCESS
(click on the boxes below
to skip to a section)
STAKEHOLDER INTERVIEWS
Laurel German
STC Program Manager
My first interview was with the project commissioner: Laurel German, the STC program manager. My goal in that interview was to better understand the scheduling system in place and the organization's workings in general.
The Problem
Laurel's main concern was how manual, slow and onerous the current scheduling process was. She found the collection of forms and spreadsheets in use very overwhelming and inefficient and recognized that, although functional, the system she had devised had become too convoluted for anyone else to understand, making all schedules necessarily dependent on her alone.
​
Main Insights
From our conversation and from further studying Laurel's make-shift scheduling program, I identified the first major issue to be tackled across all branches: input constraints. A disproportionally large part of the current process involved just parsing out incorrect or invalid data, and an easy fix would be to simply apply constraints to the incoming data by making the input sheets properly personalized.
Furthermore, I pinpointed differences and commonalities between the multiple STC branches. These findings would allow me to create one centralized system with branch-specific customizations - instead of many individual systems - making the project much more manageable.
​
The final takeaway from this initial meeting was deciding how I should approach the project moving forward. After gauging what kinds of tasks must be completed and in what ways the workload could be distributed, I ended up dividing the project into 3 parts:
​
​
​
​
My work would be to design the Input and Data Visualization sections. The Algorithm section would be left for the developers, although I hoped to minimize their workload with efficient designs.
My next step was to interview the program managers for each of the STC branches implicated in this project.
​
​
My goals were to:
​
1. understand each program's individual functioning
(and similarities with other programs);
2. identify problems with the current scheduling method used in each program;
3. grasp my clients' hopes and wishes for the final product.
I kept these goals in mind when devising my interview script.
​
Main Insight
From the conversations carried and the materials made available to me (i.e. the scheduling tools currently in use),
I identified some major overarching similarities: across all branches, there are only 2 types of locations (continuous staffing vs. non-continuous staffing) and 2 types of worker roles (leads vs. non-leads). These overarching dichotomies were not acknowledged by program managers themselves, but became clear to me when comparing their accounts - and were later confirmed.
​
STC​
Program Managers
Chen
Andrew
Annabelle
Media Tech
Student Tech
Cluster Tech
These similarities were a starting point for me to start designing template input sheets that could then be customized in a more uniform way across branches, shifting across dichotomies rather than across multiple arbitrary criteria.
​
I consolidated these findings into a comprehensive diagram, which proved to be immensely helpful not only for my personal use but for developers' understan-ding of the project (as was relayed to me during our team meeting):
USER FLOW
Before starting my wireframes for the Input and Data Visualization sections, I sketched out a tentative user flow. My goal was to map out all of the information gathered so far in the grander scheme of the project, including the Algorithm section and some tentative operations that it might cover.
​
The user flow to the left applies to the
Media Tech>Equipment>CCAM track.
​
This user flow served not so much as a tightly closed system to test out functionality (as was the case with the one designed for RRP), but was more so an abstraction of what all of the project's tasks and requests should add up to. It's basically a more fleshed out version of the 3 part plan shown before.
​
INFORMATION ARCHITECTURE
I then combined the two diagrams above in order to compare the Input sections across branches and that way settle pressing questions, such as: how many forms would be needed, what they would include, how they'd be divided, etc.
​
I laid down all the needs expressed by the program managers and looked for commonalities that would create a 'Basic Form' (a parent class, one could say, in object-oriented design terms).
​
Main Insight
While earlier the many different branches and tracks made the project seem a bit overwhelming, by boiling down the core needs I was able to create a good skeleton for developers to working off of.
​
The Media Tech>York>Leads branch appeared to engulf all the basic needs, so this was the track I sought out to wireframe most attentively, assuming it would be the first one to be tackled.
WIREFRAMES
Using ​the Media Tech>York track as a main example, I created wireframes for the parts of the process that would be visible to the user: the interactive input form and data visualization interface.
​
​
​
​
Alongside all of the other material and findings discussed above, the wireframes were presented to the developers, who were then able to start designing a proper plan of action.
​
MOVING FORWARD
I presented everything to the team and passed the project onto the developers, who occasionally consult me. After they deliver some MVPs, I intend to:
-
run them by the stakeholders and get some feedback
-
decide which other changes to incorporate or shelf
-
run user testing on admins and a small group students
​
My key takeaways for this project were:
-
improving my interviewing and note taking skills
-
refining my presentation style and communication with other team members such as developers
-
better understanding where UX responsibilities begin and end within a group project
