↓ 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.

MY DESIGN PROCESS


My design process in timeline form

Primary stakeholders for this project

1. UNDERSTAND THE SPACE 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:

The legacy hiring process for the NYU Tandon Summer Research Program

PROBLEM STATEMENT



In the existing process, administrators 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. REEEAALLY 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 which helped make the complex workflow more digestible.

Janus user flows highlighting each stakeholder


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 USER INTERACTIONS AND EXPECTATIONS



Setting system design expectations
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.

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

As a result, I was able to scope out the features and functionality of the MVP.

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

4. DESIGNING TO 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 contextual guidance at any given time.

The checklist format provides users with contextual guidance.

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.


Project cards provide high-level information and status visibility for each project.

Users have access to high-level information visible throughout the system.

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.

After completing their share of tasks, faculty mentors can monitor the status of each hired student in real-time.
View Prototype


5. GET FEEDBACK, ITERATE, REPEAT




Whenever the product’s surface area, design-wise, was expansive enough to elicit valuable discussion and feedback, we held in-person user feedback sessions.

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. Building with reusable components makes for easier scaling.

2. Feedback is the most powerful driver and validator of my assumptions and design decisions.

4. It pays to go out of my way to get to know users, their habits and behaviors in person.
treasury portal

↓ NEXT


Treasury Portal


WEB APP



Designing an enterprise system with high data density

See case study →