Project Brief
The DUAA app was created as a solution to help Inkling users who manage properties in the field to better control end-users within the Inkling platform. Not all managers had access to the Inkling product and therefore needed a way to manage the Inkling users outside of the Inkling platform.
🤦♂️ In my opinion, this product was an entire work around to a whole other problem; however, the investment in this product and the usage of it meant we needed quick agile solutions, rather than investing new features into the core product.
I was the UX Designer and conducted research, ideation, and finalized the design for handoff. I collaborated with a Product Manager.
Inkling's product "DUAA", or Distributed User Admin App, was developed by a third party. As a result the product was developed as an "add-on" solution to the Inkling platform without User Experience resources. The product was suffering from poor user experience and integration with Inking's core products. The project manager started us off with three basic problems to solve:
- Users need more seamless navigational between DUAA and our core products.
- Users were confused or frustrated by the UX of DUAA. Actions often took too many clicks or non-intuitive workarounds.
- DUAA was built without our design system and didn't visually look like one of Inkling's products.
User Research
I conducted user interviews to learn more about user’s objectives and their pain points. In summary, what we generally learned was:
- Every single Field Manager is using the DUAA product, but HQ Admins don’t have access to the properties stored within DUAA.
- Users have to bookmark DUAA's webpage, because the URL is not human-friendly, and it’s not linked to anywhere from within the core Inkling platform. This makes it obscure to locate.
- Field Managers have no way to find, create, delete, or change users within DUAA. They have to get on the phone with HQ Admins, who then have to perform these actions on their behalf.
- HQ Admins cannot see users in DUAA. When Field Managers move properties, this is hard to track, and there ends up being duplicate users.
- After user set up, there are issues with Field Managers needing to reprint a welcome sheet that has learner information on it. This sheet is often lost or forgotten and cannot be recovered.
A majority of these issues were already being addressed in an upcoming update to the DUAA product, but the overall usage of the product even with those updates was behind in UX.
Personas—Goals and Problems
The problem involved three types of users, but only two were of concern. The third user wasn't accessing the DUAA product, but was merely being affected by changes within it. In other words, DUAA is a separate product from Inkling which helps to manipulate users inside of Inkling.
Felicia represents Inkling users who are Field Managers. Felicia needs to manage Learners, because she does not have access to Inkling. Flows we identified as red routes for Felicia were:
- Create a new user, individually and in bulk.
- Edit an existing user—to modify their information or settings.
- Deactivate or reactivate users.
Helen represents Inkling users who are HQ Administrators. Helen needs a better way to manage properties, managers, and learners; because the current options are confusing or have heavy cognitive load. Flows we identified as red routes for Helen were:
- Create a new property.
- Reset passwords of other users.
- Create a new user, individually and in bulk.
- Edit an existing user—to modify their information or settings.
- Deactivate or reactivate users.
How DUAA Works
When I started this project I wasn't as familiar with DUAA as I was with our other products. I worked with the project manager to diagram how the products work together. This was helpful in understanding how the user flows work now and how the should work in the future.
Heuristic Evaluation
I conducted a usability audit by taking screenshots of the DUAA product, and linking together the pieces within a given flow. I marked up the screenshots it Miro with my annotations. This helped to establish the red route. In addition to visualizing the red route for each of the cases mentioned above I also did a general audit of components and visual design.
A lot of issues stemmed from using inappropriate components with a given flow (such as using a dropdown component in place of a search input box). This confusion of components would make the user expect one thing, and then something different would occur. Plus, the general organization and amount of actions necessary to complete a flow were excessive.
In particular, the user had to download a CSV template, modify it with edits they'd like to make to their user database, and then upload the CSV back into DUAA for changes to take effect. There's also a lot of risk for human-error with incorrectly formatting the CSV file.
Ideation
As I worked through the audit I captured some of my thoughts and ideas off to the side.
After a check-in with my project manager, I got to work replacing some of the generic components with ones from our own design system. This way I was updating the visual design in addition to enhancing the overall UX debt problems.
Game Changer: One of my biggest frustrations was how none of the data for properties and users were being represented within the application. If we could pass this data to a table within DUAA—as opposed to the CSV files you had to export/import to manage that data—it would allow for a more seamless experience for users.
Prototype
The onboarding screen was based on our Habitat product.
Create a new user, individually or in bulk. Edit an existing user—to modify their information or settings.
The functionality to create users was purely through a CSV file upload. I wanted to eliminate this solution as much as possible because it relied on other software (and knowledge) to add users into DUAA. Now, there's a button for adding users directly into the system. The CSV file upload method was still useful for creating multiple users (bulk creation) at a time.
Deactivate or reactivate users.
User deactivation (or reactivation) required a complicated flow...
Reset passwords of other users.
Password reset is a feature only available to HQ Admins in Inkling. We wanted to now make this available to field managers who don't have access to Inkling.
Create a new property.
Properties would be created in very much the same way as users. The HQ Admin would have a tab at the top separating properties from users.
Conclusion
The primary objective when we took this work on was to improve the overall UX deficit of DUAA. Going through and methodically questioning of components were appropriate where and how they were used led to bigger questions. We found opportunities to align DUAA with our core design system, and improve the overall quality of life for customers who use DUAA. We wanted to leverage this opportunity in the redesign to address these things.