Timeframe: Feb-Dec 2018
Role: Product Designer
is a front-end data entry and storage application interfaced with university systems to optimize the hiring process for the NYU Tandon Summer Research Program.
Janus was my first project at NYU IT.
Simplifying a labor-intensive hiring process
My Design Process
1. Understand and ask questions
The product owner and my project manager briefed me about the NYU Tandon Summer Research Program ↗
, the existing hiring process, and primary audiences involved.
I studied the legacy system:
In the existing process, administrators
duplicate data across a range of applications.
organizing information and onboarding student hires for a 10-week research program.
Time and effort that could have been directed towards student engagement and professional growth is instead spent carrying out
manual administrative processes.
opportunities are lost
when students miss deadlines or are rejected due to incomplete documents as a result of the
- To eliminate as much manual labor (inputting, compiling, storing, and viewing data) possible
- To provide opportunities for data mining
- To minimize manual labor, paper and energy waste
- To introduce a process that encourages maximum engagement from both SRP faculty and students
"How might we close experience gaps in the current hiring process?"
2. Reeaaally understand
To deliver the solution–one that does not only hit all the goals identified but also maximizes opportunities (for everyone)– I needed to digest the existing workflow and all possible use cases.
Being an avid (and slightly obsessive) notetaker, I made color-coded diagrams!
The workflow’s complexities became more digestible to me as I grouped action points together according to the user in action.
I also spent time understanding all the interactions necessary for one complete cycle (ie. successfully hiring one student). The interaction illustrated by the back and forth and crossing over of actions in my diagram led to an insight that informed my design decisions:
The SRP workflow is highly procedural and response-driven.
Looking at the diagram I put together, my PM and I carefully identified which steps to adopt, automate, or omit from the current hiring process.
3. Identify process expectations for the system
Instead of taking on all three users’ ends simultaneously, I decided to delve deeper into the faculty side first as their initial input launches the three-way interaction.
After defining the workflows, constraints, and expected functions for each stakeholder, it was time to dip my toes in the water.
"Do I start with the dashboard? Page navigation?"
With the overwhelming amount of liberty I had at this stage, I decided to start with one core feature–
the application form.
I reviewed last summer’s project list to gain more insight on the pieces of information and the level of specificity required for a project posting.
From here, I asked questions like:
“How can a mentor access each application form? be notified of a successful posting?”
This brought me to design the
To expand the scope of my design, I diagrammed use cases ranging from the simple to complex situations that faculty mentors would most likely experience in their hiring journeys.
In doing so, I was able to better identify the expected functionality and features of Janus.
4. Create designs that nudge decision-making and behavior
"How can each stakeholder best accomplish his/her tasks?"
The checklist format for completing steps in the process provides the user with
at any given time.
In addition to this, the task-focused interface is infused with
These could be used to track higher-level interactions with other users in the system.
These features allow users to have a sense of control over a complex, response-driven workflow.
Project cards provide
high-level information and status visibility
for each project.
After completing their share of tasks, faculty mentors can monitor the status of each hired student in real-time.
Potential roadblocks in the hiring process immediately come to surface in this transparent ecosystem.
5. Get feedback from users
The more comprehensive the flows that we opened for feedback and testing, the more valuable and actionable the responses we received. For each session, we made sure that the product’s surface area, design-wise, was expansive enough to elicit valuable discussion and feedback.
We transitioned from showing stakeholders high-level screens and interactions to more personable, workflow-specific flows. Regularly opening the product to testing also gave our stakeholders an idea of the project development schedule.
1. Building reusable components makes it easier to scale later.
2. Anticipate interactions across all three ends.
Keeping the color-coded workflow in mind enabled me to identify features that facilitated end-to-end communication.
3. Seek feedback early and often.
Feedback is the most powerful driver of my design decisions– whether it involves backtracking to a previous decision or testing new assumptions.
4. There is always someone I can serve better.
It pays to go out of my way to get to know users, their habits and behaviors in person.