UX Spec: Playbooks on Mobile v1.1 (Editing capabilities)

Phase 2 of the Playbooks on Mobile initiative builds on the foundational features delivered in Phase 1, bringing additional interactivity and flexibility to Mattermost Playbooks on mobile devices. The goal is to empower users to fully manage playbook runs on the go by introducing richer task interactions, the ability to initiate new runs, post status updates, and conclude runs from a phone or tablet. By expanding these core capabilities, we continue to reduce friction for field teams and incident responders who need to execute and update playbook workflows away from their desks.

Phase 2 covers the following major features on mobile:

1. Task Interactions – Enhanced task viewing and actions via a new task detail view, including the ability to skip tasks and edit task attributes (assignee, due date, slash command) directly on mobile.

2. Start a New Run – Ability to start a new playbook run from the mobile app, either from a specific channel context or via a global shortcut.

3. Post Status Update – Ability to post a playbook run status update from mobile, with support for the status update dialog, predefined update timer, and finishing the run as part of the update.

4. Finish a Run – Ability to mark a playbook run as finished on mobile, with confirmation and appropriate updates to the run’s state and related UI.

Each of these is detailed in the sections below, with clear interaction flows, UI expectations, and edge case handling.

In Phase 1, users could only check or uncheck tasks. Now, tapping a task reveals details and actions, and users can modify key task attributes.

Check Off a Task

• Users can tap the checkbox next to a task in the run details view to mark it as complete (or to uncheck a completed task). This immediate tap interaction remains from Phase 1.

• If a task is currently in a skipped state, tapping its checkbox will revert it to the unchecked (open) state instead of directly completing it.

• Skipping a task is now possible via a dedicated action (see below), which toggles the task to a distinct “Skipped” status with appropriate visual styling.
  
  
  

  Open

  

   

View Task Details

• Tapping anywhere on a task’s title or description now opens a Task Details bottom sheet. This bottom sheet provides an expanded view of the task and key interactive controls.

• The Task Details sheet displays the following:

  • Task Title & Description: The full task title and the complete description in a scrollable area (both read-only).

  • Task Actions: Prominent buttons for core task actions:

    • Check/Uncheck: An action button to check/uncheck the task. This performs the same function as tapping the checkbox in the list.

    • Skip Task: A button to mark the task as skipped. If a skipped task is later marked incomplete via the checkbox, it returns to normal state.

    • Run Command: If the task has an associated slash command, a “Run Command” button is shown. Tapping it executes the command immediately.

    • Edit task attributes: Assignee, Due date, and Slash command will be listed as menu items with the title on the left and the value on the right. Tapping on the row should open up the edit modal for each. If an attribute is not set, it should show None on the right.

Open

• The Task Details bottom sheet is read-only for title/description in this phase (users cannot edit the task title or description on mobile). They can only act on the task (complete/skip/run command) or change its attributes (assignee, due date, command) as described.

Updates to Task List

• Full-Width Checklist Container: The checklist section in the run details screen now spans the full width of the device. This allows more space for task titles and attribute chips, improving readability.

• Attribute Chips: The tap area for the interactive chips for Assignee, Due Date, and Slash Command are now at least 40px in height to ensure a comfortable touch target. (The chip itself is ~32px tall with ~4px padding above and below.) This change makes tapping these chips easier and brings visual consistency with mobile design guidelines.

  • In the task list, chips for task metadata are now interactive:

    • Assignee: Tapping the assignee chip opens a modal to change the task’s assignee.

    • Due Date: Tapping the due date chip opens a modal with a date and time picker to set or modify the due date.

    • Slash Command: Tapping the slash command chip runs the command (same as the Run Command button). Long-pressing the slash command chip opens an edit modal allowing the user to modify the command or view the full command text if truncated originally.

Open

Tap areas for different elements in a task

• Time format: We can update the time format to be more concise so that it takes less space and avoids the chips going into separate lines. The proposal is to use a short notation as below:

  • Due in 20 minutes —> Due in 20m

  • Due in 2 hours —> Due in 2h

  • Due in 10 days —> Due in 10d

  • Due in 3 months —> Due in 3mo

  • Due in 3 years —> Due in 3y

  • Due tomorrow —> Due tomorrow

  • Due yesterday —> Due yesterday

Mobile users can now initiate a new playbook run directly from the app, providing flexibility to kick off workflows without needing a desktop. The “Start a New Run” flow is accessible from two primary places in the mobile UI:

• Channel Playbook Runs List: When viewing the Playbook Runs list for a specific channel (introduced in Phase 1), a sticky “Start new run” button is available. This allows users to start a run in the context of the current channel.
  
  

  Open

  

• Global plus menu NICE TO HAVE: From the main app navigation (the global “+” plus menu on the Channels list screen), there is a new “Start New Run” option. This lets users begin a playbook run from anywhere, even if they’re not currently in a channel that has playbooks.
  
  

  Open

  

Playbook Selection

• Tapping “Start new run” (from either entry point) opens a Playbook picker screen. This screen allows the user to choose which playbook to run.

• The list of playbooks is grouped into logical sections, identical to the web experience, to help the user find the right playbook:

  • Used in This Channel: (Only shown when launching from a specific channel context.) Lists playbooks that have previously been executed or are currently active in that channel. This helps surface relevant playbooks for that channel’s context.

  • Your Playbooks: Playbooks owned by the user.

  • Other Playbooks: All remaining playbooks available to the user (e.g. playbooks the user has permission to view/run but are not in the above categories).

Open

• After selecting a playbook, the app navigates to a “New Run” details screen where the user enters information to start the run. This form includes:

  • Run Name: A text field for the run’s name (required). This field must be filled out before the run can be started. If the user attempts to proceed with it blank, an error is shown (and/or the Start button remains disabled).

  • Description: An optional text field for an initial run description or summary. This can be multi-line and left blank if not needed.

  • Channel Selection: Options to choose how to associate the run with a channel:

    • Link to an existing channel: The user can pick an existing channel to tie the run to. Selecting this might open a channel picker, allowing the user to search for and select a channel they have access to. (By default, if the flow was initiated from a channel’s context, that channel could be pre-selected here, but the user can change it if desired.)

    • Create a run channel: The user can opt to create a new channel for this run. In this case, a new channel will be created upon starting the run. The new channel’s name will default to the run name.

    • Once the user has filled in the run name (and any other optional fields) and chosen the channel option, they can tap the “Start Run” button to create the run.

• Result: Upon starting:

  • If a new channel was requested, the app creates the channel and the run simultaneously, then navigates the user into the newly created run’s details screen.

  • If an existing channel was selected, the run is created and associated with that channel, and the user is taken to the run details view in that channel.

• After creation, the run will appear in the In Progress list for that channel.

Edge Cases & Validation

• Run Name Required: Attempting to submit with no name will result in an error (e.g. red outline and message “Run name is required”).

Open

• Offline Scenario: If the user is offline or loses connectivity when attempting to start a run, the app should show an error message (e.g. “Unable to start run while offline. Check your connection and try again.”). Any input the user had entered (run name/description) should persist so they don’t have to re-type after regaining connectivity.

Mobile users can now post status updates for a playbook run, just like on the web app, ensuring stakeholders stay informed from anywhere. The “Post Update” button is available on the Run Details screen for any active run.

Open

Posting an Update – Modal Launch

• Tapping “Post Update” opens a Post Status Update modal. This modal is analogous to the webapp’s status update dialog.

• At the top of the modal, there should be text informing the user where the update will be published. This text is read-only.I

• The modal contains a multiline text input field pre-filled with the update template or the content of the last status update (matching the behavior of the web application). The text field is auto-focused so the user can start typing immediately.

• Below the message field, a “Next Update Timer” dropdown (or picker) is provided. It shows the time until the next update is due, pre-populated with the default interval configured in the playbook (e.g. 24 hours, 30 minutes, etc.). The user can tap this field to choose a different preset interval (for example, 15 min, 1 hour, 1 day, etc., as defined by the playbook’s settings). (Note: In mobile, setting a fully custom interval is not supported; users can only pick from the predefined options.)

• A “Mark run as finished” checkbox is available at the bottom of the form (mirroring the webapp functionality). If checked, submitting the update will also mark the run as finished (concluding the run immediately after posting the update).

• Empty update: If the user taps the Post button with no text in the status update, there should be an error and the field should be highlighted.
  
  

  Open

  

Submitting the Update

• When the user taps “Post”, the status update is submitted:

  • The modal closes, and a status update post is published to the channel and any other subscribed destinations (if the playbook is configured to broadcast updates to specific channels or participants, those are triggered exactly as on web).

  • If the user opted to mark the run as finished, the run is immediately transitioned to the Finished state upon posting.

When the run’s tasks are all completed—or whenever the user decides to end it—mobile users can tap Finish Run at the bottom of the Run Details screen.

A confirmation prompt will be sure to ensure the user understands what they’re doing and avoid ending a run erroneously.

Once confirmed, the run is marked as finished, an update is posted to the relevant channels, and the run is no longer displayed in the In Progress runs screen.

Open

MUST-HAVE

It is essential for all these features to work as well on Tablets and iPads.

Note: Test on iPad with Split view as well.

Open

Open

MUST-HAVE

When a run is linked in the channel(e.g., a run link posted in the channel, custom playbooks bot messages mentioned above), tapping the link should bring up the Run Details modal in the mobile app.

If the user lacks permission to view the run, show an error alert.

Open

• No Connectivity:

  • If the user attempts to view the runs list, run details, or check off a task while offline, there should be a clear error message shown to the user asking them to check their connection and trying again.
    
    

    Open