Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Design Brief - Status Code Triggered Actions

Design Brief: Status Code-Triggered Actions

Date: July 16, 2025
Project Lead: @Douglas Erickson (Deactivated)
Lead Designer: [Designer Name]

Project Background

Our users need a way to automate routine tasks based on record status changes (e.g., "when status is 'Delivered', send a notification"). Currently, this requires technical expertise and custom code, making it inaccessible to the average user.

Discovery has validated that providing a simple, no-code interface for this functionality is a high-value, high-demand feature. This design brief outlines the requirements for integrating "Status Code" triggers into the existing Maintenance > Actions page, which is currently being built for "Label" based triggers.

Design Goals & Objectives

The design must make a powerful automation feature feel simple, intuitive, and safe to use. The key objectives are:

  • Integrate Seamlessly: The new "Status Code" trigger option must feel like a natural and consistent extension of the existing "Label" trigger workflow. The goal is to reuse the existing page layout to create a unified user experience.

  • Prevent User Error: The design must guide the user to success. This includes using a predefined dropdown for selecting status codes (to avoid typos) and ensuring the distinction between trigger types is clear.

  • Provide Clear Feedback: The user must be able to easily see and understand the rules they have created. The main list view must clearly differentiate between Label-based and Status-Code-based actions.

  • Maintain Simplicity: While the underlying logic is powerful, the UI should remain simple and uncluttered. The design should not introduce visual complexity that could intimidate a non-technical user.

Target Audience

  • Primary User (Administrator / Operations Manager): A process expert, not a developer. They are comfortable with configuration screens but need a guided, error-proof experience. The design must be clear and logical for this persona.

  • Secondary User (Standard User): An indirect user. They will not be configuring these rules but will trigger them in their daily work. The design of the core feature has no direct impact on them, but its success will simplify their workflow.

Key Features & Scope (What to Design)

The design work will focus on extending the existing Maintenance > Actions page.

  1. Trigger Type Selector:

    • On the "Create/Edit Action" screen, design a mandatory UI control (e.g., radio buttons or a dropdown) for the user to select the Trigger Type: Label or Status Code.

  2. Conditional Input Field:

    • Design the interaction where selecting "Status Code" as the trigger type changes the subsequent input field to be a searchable dropdown menu, pre-populated with all system status codes.

    • Ensure that selecting "Label" presents the existing label input field.

  3. Updated Actions List View:

    • Modify the design of the main Maintenance > Actions table to include a new "Trigger Type" column.

    • This column must clearly display whether the rule is triggered by a "Label" or a "Status Code."

Constraints & Considerations

  • Reuse Existing Patterns: The design should leverage the existing UI components and layout of the Maintenance > Actions page as much as possible to ensure consistency and reduce development time.

  • Out of Scope for V1: The design should not include concepts for multi-step workflows, triggers based on status code removal, or a user interface for creating new "Action" types.

  • Error Handling: While the full error handling logic is an engineering task, the design should consider where and how potential configuration errors might be displayed to the user.

Timeline & Deliverables

Given that this feature is already in development, the design deliverables are focused on finalizing and documenting the UI changes.

  • Finalized High-Fidelity Mockups: (Due: July 23, 2025)

  • Interactive Prototype demonstrating the conditional UI flow: (Due: July 30, 2025)

  • Design Specifications & Asset Handoff for developers: (Due: August 6, 2025)