Melissa Denby
Creating an action
The goal of this project was to help users create an action to resolve a problem — and to test it before saving. These actions matter because they help users solve recurring incidents faster, reducing impact on their customers and business.
"I spend a lot of time answering, 'How can we do this better the next time?'"
01
Identify persona
I started by meeting with the team — designers, developers, managers, and the project manager — to align on the problem and build a shared understanding before jumping into design.
Persona: Orion, the Site Reliability Engineer (SRE). We mapped his wants, needs, pain points, and goals.
Problem: Orion needs to resolve repeated, known incidents on his application quickly — so he can spend his time on more challenging problems and building new features with his team.
02
Wireframe ideas
I created several wireframe flows exploring how Orion could create and test an action before saving it.
I shared my ideas with the team during our regular design meeting and we iterated together, revising until all the details were correct. I also shared the designs across teams and with the larger design group for critique — helping maintain consistency across the product.
During this time — the product was moving between design systems, migrating to the IBM Carbon Design System, so I worked with the team to think through how the design could flex for both the current and future system, while collaborating with other teams to establish shared patterns.
Scenario 1: catalog
Users can create a new action from the action catalogue. During this process they have options to create different kinds of actions, some that require parameters to run (like a password), and then to test the action before saving it for use on an issue.
Scroll through the flow or click the image if you'd like a larger view of the slides.
Scenario 2: issue
Once the action is created, and tested it appears as an option during an issue. Orion can enter parameters, and choose where (the agent) to run the action to resolve the issue.
Scroll through the flow or click the image if you'd like a larger view of the slides.
03
Final designs
Once the we agreed on the details, I worked to refine the designs with a visual designer, and a content person along with working with the development team to implement the designs to fidelity. This meant thinking through empty states, error states, and variations for different parameters while considering the modal patterns being implemented across Instana.
Scenario 1: catalog
These are examples of the final screens--the modals for testing and adding different kinds of parameters – including various states.
Scroll through the flow or click the image if you'd like a larger view of the slides.
Scenario 2: issue
This is the same scenario as in the wireframes, starting from an issue, and the user can input parameters so the action runs to resolve the issue.
Scroll through the flow or click the image if you'd like a larger view of the slides.
04
User feedback
This project was a priority, and was created quickly so it could be used as a foundation for the next projects that were build on it's foundation. Tt was released to Preview (Beta) first — and allowed us to gather feedback and adjust as we moved forward and before the full launch.
I met with several internal SREs and external customers to hear how the experience was working. Usage data was also captured in Amplitude. That feedback directly informed the next iteration and shaped future projects.
