top of page
Mobile Inbox Tasks with shadow.png

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


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. 

Screenshot 2023-08-29 at 8.09.06 PM.png
Screenshot 2023-08-29 at 8.09.21 PM.png

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.

Screenshot 2023-08-29 at 8.32.51 PM.png

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. 

Screenshot 2023-08-22 at 7.37.41 PM.png

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:


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

Screenshot 2023-05-08 at 8.33.07 PM.png

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.

Screen Shot 2021-06-25 at 3.35.48 PM.png

The main Configuration Data screen shows a list of the environment configuration "artifacts" (layouts, themes, etc.) that can be transferred.

Screen Shot 2021-07-28 at 1.34.39 PM.png

Users can export their artifacts to a zip file.

Screen Shot 2021-07-28 at 1.33.27 PM.png

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.

bottom of page