↓ THIS


Janus


ABOUT


Timeframe: Feb-Dec 2018
Role: Product Designer

USING


User Research
Wireframing
Systems Thinking
Prototyping
User Testing



Janus 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
My design process in timeline form

Primary stakeholders for this project


1. Understand and ask questions
The product owner and my project manager briefed me about the NYU Tandon Summer Research Program ↗, the hiring process that is currently in place, and primary audiences involved.

I studied the legacy system:

The legacy hiring process for the NYU Tandon Summer Research Program

The Problem

In current process, administrators

transfer and duplicate data across a range of applications.

They spend

five months

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.



Additionally,

opportunities are lost

when students miss deadlines or are rejected due to incomplete documents as a result of the

disjointed process.



User Goals
  • 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 the three user groups)– I needed to ‘digest’ the current workflow and all possible use cases.

Janus user flows highlighting each stakeholder


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 (a.k.a. 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

Setting system design expectations
Instead of taking on all three users’ ends simultaneously, I decided to delve deeper into the faculty side first their input is key to launching the rest of 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.

Janus application form for faculty members who want to endorse their research projects for posting
"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

dashboard.



Faculty view of the Janus dashboard

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.

Six use cases (including edge cases) for selecting and hiring student researchers

4. Create designs that nudge decision-making and behavior

The checklist format provides users with contextual guidance.



"How can each stakeholder best accomplish his/her tasks?"

The checklist format for completing steps in the process provides the user with

contextual guidance

at any given time.

In addition to this, the task-focused interface is infused with

progress indicators

.

The progress indicator guides the user as he/she accomplishes tasks
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.


Users have access to high-level information visible throughout the system.
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.
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.

View Prototype

5. Host focus groups and feedback sessions


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 critique/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.


Takeaways

1. It’s practical to build by component.
For the student and admin sides, I could reuse (and possibly expand) the design system I had already created to unify all three ends under the same umbrella platform.

2. Anticipate interactions among all three ends.
Keeping the color-coded workflow in mind, even while designing for just one stakeholder at a time, enabled me to identify features that facilitated end-to-end data transmission and communication.

3. Seek out feedback by organizing feedback sessions.
Feedback is the most powerful driver of my design decisions– whether it involves backtracking to a previous solution/decision or testing a range of hypotheses.

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 if I want to accommodate as many kinds of people as possible– tech geeks, busy bees, disabled users, etc.