State-changing actions
Copilot for Security
Creating a platform template that enables skill developers to create action skills that allow users to make changes in external apps and services.
State-changing actions
State-changing actions, or a "write actions", are any actions in Copilot for Security which alter the state of internal or external entities, systems, or environments, such as changing incident statuses or quarantining machines.
This feature will provide a more cohesive and integrated user experience — users will no longer need to switch between multiple applications to perform certain tasks, which can be cumbersome and time-consuming.
PRODUCT DESIGN @ MICROSOFT
PROCESS SUMMARY
TEAM
Long term project with project ownership: I had full ownership over this project, coordinating and communicating with product managers, developers, content writers, and researchers to design the optimal solution.
Manager — Hayley Steplyk
Product Designer — Amy Zhang
Product Managers — Kosi Pierre-Louis and Harmony Mabrey
UX Researcher — Marc Dubin
FINAL MVP
One-size fits all
The main goal of this project was to create a write action template on the platform side that could accomodate most, if not all, state-changing skill use cases. The final deliverable was a flexible platform template that addressed all the parameters and scenarios that could be used by skill developers.
UI TEMPLATE
This is the general UI template for write actions from the deterministic parameter box to the final confirmation step that shows the action is done. The below scenario is when a user asks Copilot to change the status of an incident in ServiceNow.
DEFINITION KEY
PARAMETER AFFORDANCES
In the guidance for write action skill developers, we highlighted the different types of parameter affordances we are enabling them to use and include in their skills.
GOAL SETTING
Defining our goals
Our goal is to enable Copilot for Security to take state-changing actions across applications. We must ensure that state-changing actions are safe and reliable and meet our responsible AI standards.
TERMINOLOGY
First, we outlined the glossary of terms that were necessary to understand this project.
The next step was to create flow diagrams based on the possible directions we could take. Because allowing an AI product to take action in an external program is a risky action on the responsible AI front, it was important to outline all the key steps that would be necessary.
Flow diagrams
USER JOURNEY
Copilot write actions can have risky consequences. We want to optimize for user control & transparency.
PRIORITIZATION
Phased approach
Working with my PM Kosi, we developed a game plan for a phased approach to write actions. We will start with low-risk actions like appending a comment and move up towards destructive actions like deleting significant policies.
We will enable a no-AI direct skill invocation before we can technically support Copilot-guided write actions responsibly. Direct skill invocation allows users to select a skill from a drop-up menu and fill in the fields in the prompt bar before executing.
PRE-CRAWL
CRAWL
We will introduce non-destructive, low-risk comment-appending actions within Copilot for Security applicable to both first-party and third-party security products, such as Defender, Intune, Entra, ServiceNow, and Splunk. This stage will be limited to comment actions only, with no additional UX affordances. Users will be constrained to performing write actions on one item at a time.
WALK
There will be a significant expansion in the range of write actions. We'll introduce friction in the user experience to ensure actions are transparent and deliberate. Additional non-destructive actions will become available, including the ability to close incidents and assign tickets or incidents to users. Write actions will still be limited to one item at a time. In preparation for the run phase, we will explore options for write-action admin capabilities.
RUN (FUTURE)
We will implement write-action admin capabilities, allowing for oversight and management of these actions. This phase will also introduce bulk actions, enabling users to perform write actions on multiple items at once, and multi-skill actions, which will combine different operations into a single workflow. Automation features will begin to be incorporated, allowing certain write actions to be triggered based on predefined criteria.
FLY (FUTURE)
We will introduce destructive write actions, granting users the ability to create or delete entities/items, such as removing an account from a workspace. This stage will require robust safeguards and confirmation mechanisms to prevent accidental destructive actions.
PHASE 1: CRAWL
Appending comments
The design for comment appending actions was something we decided to push earlier because it was a non-destructive action. To ensure RAI standards, I created guidelines on responses to include the content of the comment, a disclaimer in the content of the comment that the comment is generated by AI, and a link to the comment in the original source (ex. ServiceNow).
CURRENTLY SHIPPED
The current shipped version of this design does not include any UI changes due to technical constraints and timelines.
FUTURE STATE
The future state includes the form template that will be used for other write action skills. This includes form fields and a deterministic submission button.
IN SERVICENOW
PHASE 2: WALK
Scenarios
For this design phase, we wanted to create a write actions template that could apply to most write actions that the skill developers of our first party, third party, and custom plugins could create. My first step was to better understand the scenarios that skill developers may create.
Design explorations
There were a few clear design directions for the explorations that emerged when I began iterating — a simple linking method, a conversational method, a step-by-step wizard, and a longer form. I explored the pros and cons of these different strategies and ranked them on how accurate and deterministic the options were.
MOST DETERMINISTIC
MOST PROBABILISTIC
Research study
Because there were disagreements internally about what the best solution was, we decided to pull in the research team. Some believed that Copilot should be a chat-first interface always, and some believed that we should innovate and put different interface-types into the Copilot responses.
I worked with Marc Dubin on our research team to test my hypothesis that users would find the AI auto-filled form to be the most easy-to-use and intuitive experience.
Prototypes used in research study.
Plan breakdown
Our research study involved 1-hour sessions testing 6 different analysts that work in cybersecurity, 3 of which are referred from our customer experience team which meant they have more experience with Copilot for Security.
3 designs (AI-auto filled form, chat with UI affordances, and pure conversation) will be shown to 6 participants (experienced and non-users of CfS), alternating which design is shown first, second, and third.
RESEARCH TESTING
The prototypes will mock the experience of closing a security incident ticket in ServiceNow from the standalone experience of Copilot for Security.
TEST SCENARIO
-
Which pattern is optimal for users in this use case? Why?
-
What are the benefits and drawbacks for each pattern for users?
-
[Form] How would a form pattern fit into the current interaction model of chat, which would be utilized in other interactions?
-
RAI: Before using the feature, what do they think will happen? What are their expectations from the capabilities of the feature? What do they think that they (the user) can do? (Principle: Set appropriate expectations)
-
How confident are participants that the output is correct? How would they verify? Would they verify? (Principle: prevent over reliance on AI)
-
RAI: When detecting errors, do users know how to correct them?
-
[Chat] Do participants realize the difference between the form and the chat including that the latter is more error prone? (if they don’t, we can prompt after they have finished the prototypes)
-
[Form] Do users understand the prefilled fields and how the superscript references associate with them?
-
RAI: Do users understand the difference between AI-generated content and actions and deterministic ones? (principles: Transparency, prevent over-reliance on AI)
-
How will they correct errors, if they find them?
QUESTIONS
Findings
During this study, I was able to define the research direction, attend research sessions, and compile results with real quotes from customers.
​
Our main finding was that all 6 of our participants preferred the AI auto-filled form, which confirmed my team's and my hypothesis.
Final templatization
Based on these research findings, I created a template for the AI auto-filled form design with guidance for skill developers. I included examples of different scenarios using the template.
REFERENCES
One important feature we wanted to introduce was reference numbers to indicate which fields were filled by AI, allowing users to go back to each reference point.
POPOVER
A popover appears when the user interacts with the reference number, allowing the user to have visibility into the source of the reference.
ERROR HANDLING
It was also important to document and design for the types of errors that users may run into and skill developers have to consider.
TAKEAWAYS
Key insights
The state-changing actions project is a long-term ongoing project with many moving parts and helped me learn how to navigate ambiguity, manage expectations between different stakeholders, and use effective and unbiased user research to back up a hypothesis.
NAVIGATING AMBIGUITY
This project was especially tough because the concept is cutting-edge and there were not many examples of write actions being taken safely and effectively in other products at the time. Because of this, it was important to consider responsible AI principles heavily, causing me to iterate more often to find the right solution.
PLANNING AND EXECUTING A RESEARCH STUDY
Conducting and planning an unbiased research study involved a lot of learning from talented researchers on my team. Through this experience, I was able to learn how to guide participants through a study and get clear and usable feedback.
MANAGING STAKEHOLDERS' EXPECTATIONS
There was more stakeholder disagreement than usual on this project, due to technical constraints of changing aspects of the Copilot platform, as well as misalignment on what we believed the best user experience was. I learned when to compromise and when to stand my ground, and how to make convincing arguments in meetings.
Congrats! You made it to the end of this page.
Hope you enjoyed coming along for the ride, and I truly appreciate you taking the time to check out my work! You can reach me at amyzh425@gmail.com — I'd love to chat with you.