Worklink Dashboard | Dsahboard Design

Worklink is enterprise software designed to help the NYU Client Services Center manage on-campus facility needs and maintenance requests for the University's buildings.

How can we...?

How can we redesign a legacy software and adapt to users' system knowledge?

Prototype

This project's timeline is about four years (2022). We separated the project and started with the most basic user flow. Below is our prototype after the testing.

This is only a partial design of the system. All design element follows the NYU Design System and design guideline.

Research Insight

We spent a couple of days doing field observation to understand users' current process and legacy software.

Legacy software: Specialized search

"Sometimes we don't know the work order number, if we can search through locations and other data points that would be really helpful"

Work request identifier:

CSC* employees are used to a eight digit work request identifier which represents NYU department, account payable, and work categories

Information Architecture

With research insight, we mapped out the high-level dashboard structure (navigation and main pages). We started with the most used feature and elaborated from there

User Flow

To fully understand the scope of each feature and functionality, we diagrammed use cases to visualize how information travels through the system. In doing so, we can better identify how each feature works and who would have access to modify it. Below is an example of how we imagined notification would work in the system.

Sketches

After the research, we started from the drawing board and iterated through various versions. Below are some examples of the dashboard sketch:

Wireframe

After the first drawing board and brainstorm session, we build low fidelity wireframe for the first user testing. Below is an image of the wireframe.

User Testing I

We conducted the first user testing with low-fi wireframes. We wanted to verify our design (especially in layout and interaction) before we build a prototype. Below is an example of what we set out to do in this user testing.

Goals:

- To understand if the navigation is similar to their current work request process
- To explore other opportunities to help users with work efficiency

Results:

- 80% of users were able to go through scenario testing fairly quickly and successfully
- Improved navigation highlight so users knew exactly where they were

Opportunities:

- "Will the new software helps us identify duplicate request"
- "Is there any way to prevent students from entering the wrong floor or rooms etc?"