QAD Configuration Data
How might we enable our customers to more easily configure their environments without the need for QAD involvement?
Roles & Responsibilities
UX Designer, user research, prototyping, testing, product launch, product management, training
Mar 2021 - Sept 2021
23 minute Functional Training Course that I put together showcasing the Configuration Data solution.
Understanding the User
Product managers and functional experts were interviewed to gain a better understanding of who would use this feature, and how our customers are currently managing their environment configuration processes. This was further discussed and validated with customers during user research sessions that were conducted later.
In addition to defining use cases and interviewing experts, I initiated some competitive analysis to understand how other products handle the exchange of customer configuration settings. I reviewed solutions from competitors such as:
Defining the Problem
I created Storyboards for the primary use cases to illustrate the business scenario the user would be working in and the primary tasks they need to complete in their user flow. These were shared with the primary stakeholders and development team so they could learn about the different types of users, their needs, and the primary workflows the solution needed to support.
To begin the design process, I created environment configuration transfer workflow diagrams to visualize and communicate the expected end-to-end solution.
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
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.
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.