Simplifying Threat Detection in High-Risk Environments
Company
Bluebeam
Role
Senior Designer
Timeline
4 weeks
Released
July 2025
The tool
Bluebeam Revu is a PDF-based collaboration and markup tool designed for the architecture, engineering, and construction (AEC) industry. It helps users create, edit, annotate, and share project documents.
The business need
Enterprise customers need threat detection to meet strict IT security requirements, making it essential for Bluebeam to offer a built-in service that checked the compliance box while keeping collaboration seamless.
The challenge
How might we introduce security measures to meet business needs without overwhelming users or creating unnecessary friction?
Currently, Bluebeam lacks a dedicated threat detection mechanism, leaving users vulnerable to cybersecurity risks—particularly malicious PDF files that can serve as attack vectors. With Bluebeam handling a large volume of file uploads, there is a potential security gap that could compromise users’ data and trust.
Adding automated threat detection helps:
Protect users from malicious files without disrupting their workflows (hopefully)
Ensure compliance with enterprise security standards (SOC 2, ISO/IEC 27001).
Increase trust in Bluebeam as a secure collaboration platform.
Finding the goldilocks zone
This project was a balancing act: tip too far into interruption and users get annoyed, lean too far into silence and they miss the danger. The sweet spot? Just enough interruption to catch their attention, not enough to get in their way.
The goal was not just to flag danger—but to do so with grace, clarity, and minimal disruption.
And also…
How do you warn users about malicious files without turning into antivirus software?
How could we design an experience that delivers critical threat intel without alarmism or cognitive overload? And how can this process dovetail with existing UI, under tight engineering constraints, for a July release?
Once I got the basic questions answered and planned my timelines, I started by mapping one of the fundamental concepts of this experience…
To quarantine or not to quarantine…that is the question.
Insight 🧠
Sharing this with stakeholders helped us align on scope. An admin UI that allowed admins to review dangerous files was too much to take on for this project.
Insight 🧠
Clarity over explicit blocking—users cannot be locked out from their own content.
To reduce friction, flagged files will remain available to users, even if detected as malicious. This approach ensures:
Users are not blocked from accessing critical files due to false positives or security restrictions.
A clear warning system informs users of potential threats, allowing them to make an informed decision before opening or sharing the file.
Admins or IT teams may (eventually) have control over restrictions, but default behavior should prioritize awareness over strict access denial.
Mapping out all of the existing UI’s gave me some ideas…
New Idea 💡
Represent a warning about the malicious file on the file management screen.
New Idea 💡
We could add some sort of warning upon opening the file itself, mimicking the conventions set forth by companies like Google.
Insight
Threat detection is not a one-time process—it continues beyond the initial file upload.
This is because:
New threats emerge over time, and files that initially seemed safe may later be identified as malicious.
PDFs and other documents can contain dynamic content, such as links, embedded objects, or scripts, which may be altered post-upload without modifying the file itself.
Threat intelligence databases are constantly updated, so periodic rescans ensure Bluebeam catches new risks as they are discovered.
To handle this, the system periodically polls files at different intervals:
Frequent scans in the first few days after upload.
Gradually decreasing frequency over time as file reputation stabilizes.
Insight
If we limit telling users that the file is good, we can prevent mistrust when the file is bad.
This leaves two options of for informing users of danger:
non-interruptive
interruptive
Non-interruptive presents a warning on the file itself and allows users to open it with no interruption.
Interruptive stops the user with a warning modal, forcing them to confirm that they want to open the file.
Two thoughts to define this..
We shouldn’t interrupt…
We are not Norton antivirus scanner
Engineers had another view…
Mark expressed that there could be a malicious payload in the file itself that is initiated upon opening. If we aren't crystal clear about the danger on the exterior of the file, we are basically doing the file scanning for nothing. I don't feel like we're going to be able to give users a comprehensive enough warning on the exterior of the file to give them enough information to decision on it.