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.
MY DESIGN PROCESS
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:
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.
"How might we close experience gaps in the current hiring process?"
- 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
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.
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
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.
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.
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.
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.
In addition to this, the task-focused interface is infused with progress indicators.
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, 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.
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.
Designing an enterprise system with high data density
See case study →