As a Product Designer at Nulogy, I was responsible for identifying, analyzing, and communicating user, business and design requirements to all product stakeholders. I lead user research and user testing sessions to inform the creation of project success criteria and the design of workflows, domain models, story maps, sketches, wireframes and prototypes.

As part of the Nulogy Design team I lead the design of Nulogy’s QCloud and GO applications and was one of four designers responsible for the UX and UI design of Nulogy's core application, PackManager. I was also given the opportunity to lead the work creating a unified visual design language that will be applied to Nulogy’s design system.

QCloud is a cloud based quality control application for packaging and manufacturing operations. 

Process | Researching & Defining problems

As the lead designer for QCloud, I was tasked with research and requirement gathering for projects to ensure feasible solutions while providing a consistent experience with the existing product. Constant collaboration was required with the engineering and quality team to gain alignment on project goals and UI/UX requirements. Below are examples of research and requirement discovery exercises I lead during my time at Nulogy

Execution | Feature Implementations

Through every new feature designed and developed, I looked to improve all aspects of the product while making sure to consistently maintain the best user experience possible. My priority is to always keep users at the centre, offering them a more efficient and effective way to work through new or improved functionalities. Below are examples of design projects tackled during my time at Nulogy.

Example 1: Regulatory Compliant Inspections

Background:
As Nulogy looked to serve customers within more regulated industries, we were asked to make changes to our applications to meet the demands of these new industries

Problem 1:
QCloud could not provide proper traceability of who filled an inspection or a sheet, given that we allowed multiple inspectors to collaborate on inspections and did not keep a record of changes made to an inspection while being filled out.

Problem 2:
FDA and European regulations do not allow digital records to be deleted. QCloud allows inspections to be deleted at multiple points throughout the application. And inspections are records... sometimes.

Understanding User Data:
Through Pendo (a usage tracking application) and many calls with key customers, we were able to come up with some key metrics that affected the overall solution

Customer surveys/calls

Problem 3 (!!!)

Workflow Mapping
Through the mapping of all inspection workflows we were able to see:

• At which points inspections become records.
  » Only after an inspection is submitted.

• When a Sheet CAN be deleted.
  » A sheet can only be deleted before a header or an Inspection is submitted

• How and were an inspection discard workflow could fit in the application.

• Appropriate points in which to disable user collaboration on inspections

• An easy way to “submit” Sheet headers in Sheets that allow more than one inspections

The workflow was eventually simplified - reducing the number of collaboration points, inspection deletion instances and adding a sheet discard workflow.

Preventing Collaboration and Submitting Headers

The final design focused on replacing the Save/Edit Header button with an in-line Header submission form, and the submission information after the header has been submitted.

Inspection collaboration was limited by only allowing a user to continue an inspection if they started it. Only one open inspection is allowed per sheet to reduce the potential error of multiple users simultaneously filling an inspection through different devices.

Discarding a Sheet

Example 2: Navigation AND USER PERMISSIONS REDESIGN

Background:
QCloud worked with a fixed set of 3 user roles (manager, supervisor and inspector). As our QCloud customers became more sophisticated, so did their company structures and it became apparent that our user role model could not support the types of user permission sets our customers were asking for.

Problem 1:
We needed to provide new user roles/permissions set to match our increasingly complex customers company structures. Our solution had to be flexible enough to adapt to each of our customers’ demands

Problem 2:
Historically, QCloud was designed to have divided desktop and mobile interfaces. Through researching device usage numbers, it became evident that ~70% of our user were using desktop intended pages on mobile devices. This would only become worse as increasing flexibility in user roles would lead to more users using QCloud on mobile devices. As part of this work, we had to find a way to create a seamless experience between both interfaces.

Customer Feedback:

Creating Permission Sets:

Final Design - User Permissions:

Creating a User Group:
A User Group page was created to give user administrators the ability to create and manage user groups. The create/edit user group modal layout follows our existing visual language, providing toggles to turn on/off each permission set for a specific group.

(Click to expand)

Creating/Editing a User:
The User creation flow was updated so that users can be assigned to a user group. We decided to add help text to the user group drop down to provide a quick way for users to know the allowed permissions of each user group. The table in the Users page was also updated to include a User Group column.

(Click to expand)

Conceptualizing and Testing - Navigation

Because the information architecture was not changing, I only had to focus on the user interactions. I started by sketching out different ideas with pen and paper

A few of the ideas were mocked up and tested both internally and externally to find the best possible solution. This idea was then polished to create the final design

Navigation - Final Design:

More Examples