Report a Suspected Phishing Message
Design an incident report that helps an employee preserve useful evidence, take safe immediate steps, and reach the security team quickly.
The brief
Understand the problem
Background
A suspicious message may arrive by email, text, or chat. People often delete it, forward it unsafely, or abandon a long security form, especially when they have already clicked or entered information and fear blame.
User context
Tomas receives a payroll email asking him to sign in through an unfamiliar link. He opens the page before noticing the address is wrong, but he closes it without knowing whether his session or device is at risk.
Product problem
Employees need a low-friction way to report what happened honestly while responders need original message details, exposure level, and a reliable way to coordinate next steps.
Objective
Create a reporting and handoff flow for one suspected phishing message, including the state where the reporter clicked a link.
What to design
Define the experience
Required experience
- Start a report from a message or security entry point
- Describe actions already taken without blame
- Preserve the original message and relevant technical evidence
- Receive immediate steps and track security-team acknowledgement
Screens and states
- Report start
- Exposure assessment
- Evidence review
- Incident handoff
Core user flow
Follow the critical path
- 01
Tomas chooses report suspicious email from the message menu
- 02
He confirms that he opened the link but did not enter a password
- 03
The report securely includes headers, sender, link destination, and message content
- 04
The service gives approved device and account steps while notifying security
- 05
Tomas sees acknowledgement, case ownership, and when to expect an update
Product rules
Requirements and constraints
Requirements
- Support email, text, chat, voice, and QR-code report origins
- Ask about clicks, downloads, credentials, payments, and device behavior in plain language
- Preserve evidence without requiring the reporter to reopen a dangerous link
- Tailor immediate steps to the reported exposure while keeping emergency contact visible
- Show receipt, case owner, and any organization-wide action already taken
Constraints
- The interface cannot guarantee that a message is malicious or harmless
- Security evidence may contain sensitive personal or company information
- An employee may be reporting from a device that should no longer be trusted
Reality check
States worth considering
Finish line
What to deliver
- Four responsive screens covering low-blame reporting, clicked-link guidance, and incident acknowledgement
Optional direction
Visual resources
Use these as a starting constraint if you want one. They are not part of the required solution.
Theory to review
UX principles for this brief
Use these as decision lenses, then validate the design with the people and context in the brief.
