Creating impact through a new online DMV IIMS portal ✨

“Currently, 10,894 ignition interlocks are installed in the vehicles of DWI offenders in North Carolina. […] Prior to implementation of the new web-based system, the NCDMV had been implementing the ignition interlock program through labor intensive, manual processes."Source: fy2019 North Carolina Governor’s Highway Safety Program annual report

Goal:
Interview stakeholders to outline features and UI

The day 1 research also consisted of existing application pages and database information. This gave a good idea of the types of information that would need to be stored, parent-child relationships, and possible UI groups. With the interlock participant in mind we now turned to the end-user, IIMS DMV employees in charge of managing the data. We sought to answer questions such as:

• How does the current system handle data changes?
• How will authentication and restricted access work?
• What are the main goals of employees managing the system?

I consulted with the internal project lead. We unified on a strategy before driving downtown to meet with the project owner. We defined:

• User flows
• Team needs/goals
• Technical limitations and process

What do these interviews/sessions tell us?

We now had a better understanding of the types of actions needed to manage a participant: create, edit data, modify account, delete, etc. Special attention was given to important dates/decisions and how that information would be alerted to employees and vendors monitoring accounts. If dates were missed or no action was taken, decisions were made on what kind of automated actions would occur. The employee’s main needs are accuracy, ease of access, and download options.

Altering the UI approach from digitized form to integrated process

Identifying data structures and user flows

Based on the existing research, the backend and API teams had already begun identifying data sets. Using the outlined user flows and UI pages I led the process to categorize the data into components and pages. Any issues in structure identified at this point was brought up during weekly standups.

Organizing the data into components

The existing physical form was taken and broken down into into a table for the individual data: first name, last name, address, etc. This information was then cross referenced when outlining components. Was all data being used? What was the severity or importance of information?

Components and features were categorized into four page types:

• Dashboard: Users need only high-level information and quick access to reporting options
• List view: Users need the ability to manage multiple accounts simultaneously and are more focused on who and where
• Group view: Users are very focused on dates; participants are grouped by action item deadline dates
• Detail view: Users need detailed documentation access for a specific participant to aid in preparing resources or violation resolutions

Overcoming project challenges

SharePoint and templated components

Moving away from SharePoint Lists has the team look into JavaScript templating languages with would allow more flexibility while still being browser compatible. The final portal is built with a combination of ASP.Net Core and VUEjs. Atomic design methodology was used to create reusable components.

Legal challenges

Per department and NC system standards profile data needed to be retained for years. Users also needed to be able to remove accounts whether due to error or dismissal from the program.

Solution:
Deleted data would be removed from the main API and added to a separate API for deleted accounts. This delete API would auto remove data after a certain amount of time, according to state regulations. This process would allow users deleted in error to be reinstated. Accessibility considerations Stakeholders of this project did not consider accessibility a huge concern since the application was not public-facing. If you have some familiarity with UX and WCAG you’ll know that internal applications need to be compliant too. People will need to access it so make it a good experience. During frontend development attention was given to accessibility issues I could control such as headings, tables, and some interactive elements. I briefed the team that would be managing the code base going forward on best practices and easy-to implement improvements if both backend and frontend worked together to make it happen.