Exploration

Competitive Analysis

• DSN is not a robust and comprehensive tool for package management
• There is no UI for services such as web hook events and testing
• Packages cannot be published and shared across IMS orgs

Design Process

• View a list of available packages in IMS org
• View a list of available packages in the Global Library
• Onboard a package from the Global Library to current IMS org
• Create a package that is either: 1) DSN, 2) Bootcamp, or 3) General
• Deploy a package for testing
• View package testing results and progress
• View web hook events for debugging
• Publish a package to the Global Library

Version 1

Version 2

Improvement	Before	After
Problem Users cannot view or access the packages they created or onboarded. Solution Display a list of packages and their corresponding actions in ‘Authoring' Thought Process I initially planned to separate the authoring workflow and authored packages into different tabs but later combined them into a single page for better consistency. The package creation process was streamlined into three steps, removing the need for a separate tab. Additionally, the team preferred to differentiate authored and onboarded packages from those in the 'Marketplace' (now called the 'Global Library'). In the 'Authoring' section, users now immediately see a list of packages they can edit, deploy, or publish to the 'Marketplace.' A 'Create a use case' button in the top right allows quick package creation, consolidating package management into one cohesive and user-friendly interface.
Problem Users cannot monitor more complex steps of the authoring workflow. Solution Separate the deployment steps of the workflow into their own UI component. Thought Process As noted earlier, addressing this problem required further clarification of the distinctions between authoring and deployment. Given that deployment triggers the testing and validation steps, it made sense to enable users to start and monitor this process manually. In the current design, users deploy the package from the actions dropdown and see deployment results by clicking ‘View details.’ Meanwhile, 'Upload files' and 'Configure settings' were streamlined into a single form accessible via the 'Create a use case' button.
Problem The ‘Validation Results’ section does not scale to the amount of data in deployment. Solution Separate each deployment step into its own tab or page. Thought Process Deployment triggers several processes, including the health check, testing as a service, and web hook events. Each process generates a large amount of data that is pertinent to the user. In Version 1, all these steps were consolidated on a single page, requiring users to scroll through it painstakingly to review results. In Version 2, I introduced separate tabs for each step and an overview panel at the top displaying the start date and duration of the process (this was vague since ‘Webhooks’ does not have a definitive end). In the current design, I opted to represent these steps as individual buttons, each providing key information relevant to its process. Clicking on a button reveals the detailed data for that specific step to the user.

Current Design

Future Improvements