Configuration Data
Self-Service Environment Migration

Project Name: Platform Environment Configuration
My Role: Senior Product Designer/UX Design Lead
Company: QAD
Duration: 12 months
Team: Product Manager, Stakeholders, Architects
Basics




What Changed, and Why It Mattered
The Problem
Customers were trapped in a "cumbersome" cycle, unable to move simple UI configurations (like layouts and themes) between environments without heavy QAD Cloud Services involvement and system downtime.
What I delivered
Designed a self-service "Configuration Data" tool that allows non-technical users to package, export, and import environment settings instantly, bypassing the Software Development Life Cycle (SDLC) bottleneck.
Case Studies / Restricted Party Screening
Siobhan Duran
xx
Portfolio

What Changed, and Why It Mattered
The Problem
Customers were trapped in a "cumbersome" cycle, unable to move simple UI configurations (like layouts and themes) between environments without heavy QAD Cloud Services involvement and system downtime.
What I delivered
Designed a self-service "Configuration Data" tool that allows non-technical users to package, export, and import environment settings instantly, bypassing the Software Development Life Cycle (SDLC) bottleneck.
Case Studies / Restricted Party Screening
Siobhan Duran
xx
Portfolio
3-5 day lead time
Mandatory Downtime
Technical knowledge needed
Requires QAD Services
My Responsibilities
Research
Conducted SME interviews, stakeholder sessions, and a comparative analysis of competitors like Oracle, SAP, and IBM.
Leadership
Developed high level architectural concepts to help organize the data so that it’s clear for customers.
Redesign
Created storyboards, technical terminology frameworks, high-fidelity Axure prototypes, and interactive mockups
Training
Developed a 23-minute functional training course for global rollout and partnered directly with foundational architects and the QAD founder.
Context: The SDLC Barrier & Legacy Pain Points
The Gatekeeper: Configurations had to be bundled into "QAD Apps," a technical system architecture requirement.
The Wait: Exchanges required QAD Cloud Services to follow formal SDLC processes, taking days for simple changes.
The Disruption: Customers experienced mandatory system downtime just to update a theme or a "Stored View."
User Quote: “A solution they had been long waiting for... easy and straightforward.” (Post-launch feedback)

Understanding User Roles · Storyboards
Research & Discovery
Product managers, functional experts, and customers were interviewed to gain a better understanding of who would use this feature, and how our customers are currently managing their environment configuration processes.

Research & Discovery
Roles & Personas

The Persona Gap:
Interviews with SMEs revealed we weren't just designing for devs. We needed to empower "Citizen Developers" (BAs) who had limited technical knowledge but owned the business logic.
Technology Confusion:
Users couldn't distinguish between "App Data" (technical extensions) and "Configuration Data" (business-specific UI tweaks).
Roles & Personas
Competitive Analysis
Oracle Data Setup Manager

SAP

Symantec

Competitive Benchmark:
Following established patterns and standards here would help with mental models. Leaders like Oracle already used "Zip file" exports. This became our mental model for the "DIY" solution.

Storyboarding
I used storyboards to bridge the gap between technical system logic and a human-centered "DIY" narrative for Business Analysts. This visual alignment allowed the QAD founder and architects to see the value in bypassing the SDLC bottleneck for simple UI tweaks. By mapping the end-to-end journey, I identified a critical user need to audit and "cherry-pick" specific artifacts rather than performing bulk imports. Ultimately, this validated the "Zip file" mental model as the most intuitive solution for non-technical users.
Challenges · Solutions
Strategic Design Decisions
I redefined the system's mental model by separating technical "App Data" from business-focused "Configuration Data." This abstraction protected non-technical users from the SDLC requirements of core system architecture, allowing them to focus strictly on configuring business needs like themes and layouts.

The Conceptual Shift
Abstracting Complexity
I replaced a multi-day manual service request with a standardized, asynchronous "Export/Import" workflow that mirrors industry-standard zip-file patterns. By integrating "Contextual Differentiation" (metadata like Business Component and View) into the browse table, I ensured users could accurately identify and "cherry-pick" identical artifacts between environments with zero downtime.

The Interface Solution
Standardizing the Workflow
To simplify the mental model for non-technical users, I established a clear definition of an 'Artifact'—transforming abstract system data into tangible, manageable objects. By categorizing complex metadata into recognizable business entities like 'Themes' and 'Layouts,' I was able to bridge the gap between technical SDLC requirements and a user-friendly self-service workflow."

The Interface Solution
Standardizing the Workflow


Configuration Data Feature
Configuration Data Screen
The main Configuration Data screen shows a list of the environment configuration "artifacts" (layouts, themes, etc.) that can be transferred.
The screen has a grouping applied on initial view in order to clearly reinforce the complex concepts of artifacts as manageable pieces of data.
Saving Data
Artifacts that can be stored to Configuration Data have a dropdown select to chose to save into App Data or Configuration Data. This change required review of which artifacts should be included and updating the UI for each artifact on a case by case basis.


Importing and Exporting Data to the Environment
Exporting Data
Data from Configuration Data can be filtered based on the users needs: Date Created, Status, Artifact Type, Artifact Name, etc. Then those selected artifacts are reviewed in the Export screen before being added to a zip file for download.
Importing Data
Once in the new environment, the admin user can simply select or drag and drop the zip file. The configuration files will then be processed in the background and the user will be informed in their inbox when the process is complete.
Validation · Recognition · Measured Value
Demonstrated Value
Validation
Stakeholder Buy-in:
Conducted iterative reviews with the Foundational Architecture team and the QAD Founder to ensure technical feasibility without sacrificing UX.
Internal Adoption:
The tool was immediately adopted by internal QAD teams & Partners to manage their own environment migrations, proving its utility.
Recognition:
Awarded "QAD Champion" for delivering a solution that directly impacted customer autonomy and reduced service overhead.
Measured Value
Time Saved:
Process reduced from a 3-5 day service request to a 5-minute self-service task.
Cost Reduction:
Eliminated QAD Cloud Service fees for environment configurations.
Risk Mitigation:
Removed the "Downtime" risk, allowing businesses to iterate on their UI during peak hours without impacting production.
Lessons Learned
Reflections
Lessons Learned
The Technical Trap: Initially, I followed the architect's requirement to treat "Active Settings" as separate entities from the "Artifacts" themselves.
The Realization: Testing showed this was confusing. Users perceive an artifact's active state as a property of the artifact, not a separate object.
The Takeaway: In complex enterprise UX, it is vital to question initial technical guidance. I pivoted the design to treat the "Active State" as a metadata property, drastically simplifying the user's mental model.
2026
Siobhan Duran
Portfolio
Contact