Melissa Denby
Creating an action
The goal of this project was to help users create an action to resolve a problem — and crucially, 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 presented these ideas to the team and we iterated together, then worked closely with the visual and content designer to refine the designs further.
I also shared designs across teams and with the larger design group for critique — helping maintain consistency across the product.
​
This was also a transitional moment — 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.
03
Final designs
Once the designs were complete, I worked with the design team to hand them off to development. As the product was built, I stayed close — monitoring progress, answering questions, and working through QA to ensure the design intent was preserved in the final implementation.
04
User feedback
Because this project was a priority, it was released to Preview (Beta) first — giving us a chance to gather feedback 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.
