Redesigning a security tool that teams use every day to find and remove phishing emails, making it faster and clearer without making existing users relearn it.
Email is behind more than 90% of security breaches. Incident Responder helps security teams remove phishing emails from every mailbox, but the MVP was hard to use: reports were hard to scan, responding was slow, automation logic was confusing and forms were long.
A redesign that keeps existing workflows intact: a one-step action to find and remove a threat everywhere, automation logic that reads like a sentence, and a dashboard that shows the status people check first.
Who are these people, and why do they use this?
I watched security teams use the product in their own work environment and held online sessions with others. Together with interviews with colleagues who work with customers, this became personas and journey maps of how incidents are handled today.
Which problems matter most?
I listed every difficulty users mentioned, then grouped and ranked them into pain points and usability issues. This showed where the product hurt most, and became user goals, business goals and KPIs.
Security specialists need tools that stay clear and dependable under pressure. I framed the biggest gaps as questions the whole team could work on together.
What could solve them?
I brainstormed with developers, the PM and leadership so ideas stayed feasible, then mapped user flows to give the most common jobs the shortest path.
Investigating a reported email meant typing search criteria by hand. I added an Investigate action to each reported email that pre-fills the search, so analysts find and remove every copy across mailboxes straight away.
Result: almost half the effort per investigation.
Top widgets summarise the selected period, a panel shows recent investigations, and one table lists every reported email with its scan result. I iterated until the status people check first was the first thing they see.
Competitors used dropdowns or “all/any” wording, and testers found both confusing. I replaced them with a simple toggle and and/or badges on the lines between conditions, so the logic reads like a sentence.
Result: the toggle tested well where dropdowns had confused people.
Does it really work better?
I ran 1:1 sessions and unmoderated tests on Maze and TryMyUI, then moved the tested wireframes into high-fidelity UI.
I designed the widgets on a Material-based design system, showing overall numbers next to what needs attention now, like running investigations and queued scans. After launch we tracked usage with analytics and ongoing feedback.
Result: users found it more intuitive than the MVP and competitors.
Even features that already exist deserve testing. The MVP could already investigate emails; testing it again showed us how to cut the effort almost in half.
