QAD Mobile Inbox
How might we enable our customers to more easily review their tasks and notifications when away from the office?
Roles & Responsibilities
UX Designer, user research, prototyping, testing
Duration
Oct 2020 - Aug 2021
The Problem
The web based ERP already had an Inbox with both Tasks and Notifications, but this experience needed to now be designed for the new Mobile App experience. Customers would need to be able to perform the same functions but in a mobile format, such as: Approving requests, denying requests, adding comments, viewing notifications, and navigating from the notification to the relevant record.
The Solution
The QAD Mobile Inbox feature was designed as a streamlined mobile form factor that allows customers to carry out all of the same Inbox functions as the Web application but on the mobile app.
Understanding the User
Requirements were gathered by reviewing existing use cases with Product Managers, as well as identifying current pain points that could be improved upon. Certain roles were identified as the expected primary users of the mobile app.
Defining the Problem
To begin the design process, we identified critical Roles and which tasks they would need for the mobile app by use of Red Routes. We identified the most common Inbox Approvals needed and the frequency of the tasks.
Working with our product teams, we developed storyboards relating to the use cases that would be most commonly needed for the mobile app and the inbox.
Defining Parameters
Among the issues that needed to be solved for were technical considerations:
-
How do we differentiate between the QAD configurations and their purpose, and the customer configurations?
-
What can be transferred?
-
How do we communicate clearly what these types of data are to the users?
After some research and iteration, I developed some definitions:
Artifacts:
The specification of a physical piece of information that is used or produced by a software development process, or by deployment and operation of a system.
Artifacts were defined for the users the types of data they would be transferring. Artifacts were things like Design Layouts, Themes, and their Roles and Menus.
App Data vs Configuration Data
Creating a distinction between App Data and Configuration Data helped define between how QAD would configure environments, versus the customer configuring the environments for their own business needs.
Prototype Designs
I created Axure high-fidelity interactive prototypes leveraging the existing ERP UI patterns and solutions already in place. Users would save their environment configurations to our new type of data, Configuration Data. Then they would view their data on one screen, and from that screen they can pick and choose their artifacts to export into other environments to configure them as well.
The prototypes were used to review the solution design with management, key internal stakeholders, and customers to validate or iterate on the design according to the feedback.
The main Configuration Data screen shows a list of the environment configuration "artifacts" (layouts, themes, etc.) that can be transferred.
Users can export their artifacts to a zip file.
Then, when in another environment, users can upload the zip file and import those environment configuration artifacts and are able to configure the layouts, themes, and other elements to their business needs.