What the work moved
The 80% approval rate and support ticket signal are outcomes I can attribute directly to design decisions. The MTTR reduction is a product-level outcome; my triage and fix-flow redesign contributed to it alongside engineering changes.
The product, the team, my role
Core Application Security is OpenText's enterprise AppSec platform. It scans applications across SAST, DAST, MAST, and SCA, surfaces every vulnerability it finds, and helps teams remediate.
Aviator is OpenText's AI assistant, the company's equivalent of Microsoft Copilot, integrated across multiple products. My mandate was to bring Aviator into Core Application Security for the first time, designing how AI-generated fix suggestions, prioritisation signals, and confidence data would surface inside a product whose users had never seen any of it before.
I owned the human-facing layer end-to-end: every screen a developer or security manager sees, touches, and makes a decision on. The engineering team owned the LLM configuration, the confidence-score algorithm, and the code-commit handoff after an approval. I came in at the greenfield stage with no existing AI design to inherit or improve.
My role on this project
- Greenfield AI UX. Designed the entire human-facing layer of Aviator's integration into Core AppSec from scratch, no prior AI design to build on.
- Triage and prioritisation flow. Designed how AI-surfaced severity signals and business priority flags are presented alongside the existing Critical / High / Medium / Low categorisation.
- Fix suggestion and approval flow. Designed how Aviator's suggested fixes are displayed, including the confidence score, situational warnings, and the single-step approval that commits the fix to code.
- Dual-persona experience. Designed separate views for individual developers (one app, granular detail) and security managers (multiple apps, cascade workflow).
- Usability testing. Ran informal validation sessions including sessions with actual enterprise power users prior to launch.
Hundreds of findings. No fix guidance for what comes next.
Before Aviator, a scan would return anywhere from two hundred to several thousand vulnerabilities, already ranked by severity (Critical, High, Medium, Low) and flagged by business priority. Teams knew what was urgent. What they did not have was any guidance on how to fix it.
For recurring or policy-matched vulnerabilities, pre-built fix templates could be applied automatically. For anything new or complex, the workflow was entirely manual: the security manager would assign the finding to a developer, the developer would research the issue, write a fix, commit it, and wait for the next scan to confirm whether it worked. If it did not, the cycle started again.
The severity ranking told teams what mattered. It did not tell them what to do about it. For novel vulnerabilities, every fix decision required expertise that not every developer had, and time that no team could consistently spare. The queue grew faster than teams could clear it.
The ranking told teams what was urgent. The gap was that nothing told them how to fix anything they had not seen before.
What made this genuinely hard
Designing AI into an established enterprise security product, for expert users with no tolerance for noise, in a context where a wrong fix has real consequences. That combination shaped every decision.
Expert users with zero tolerance for AI noise
Developers and security engineers are technical, opinionated, and quick to distrust a tool that wastes their time. A suggestion that turns out to be wrong is not just unhelpful; it damages the credibility of the entire AI layer. The design had to earn trust before it could ask for action.
The model is capable, but not infallible
Aviator's LLM produces a confidence score for each fix suggestion. Engineering owns that score; I could not change the underlying model. My job was to design how that uncertainty is communicated to users honestly, so they could make a calibrated decision rather than blindly approve or blindly ignore.
Two personas with opposite contexts
A developer owns one application and needs granular, actionable detail. A security manager oversees multiple applications and needs a high-level view with the ability to cascade. The same AI signals needed to work for both without building a separate product for each.
Native to an established enterprise platform
Core Application Security is a mature product with an existing visual system, information architecture, and engineering conventions. The AI layer had to feel native, not bolted on, and had to ship within existing technical patterns.
High stakes if a fix goes wrong
An approved AI fix gets committed to production code. A bad fix could introduce new vulnerabilities or break a build. The approval flow had to communicate the weight of that decision without being so friction-heavy that users abandoned the AI entirely.
The decisions that defined the design
The central question I kept returning to was not how to display AI suggestions. It was how to help users know how much to trust any given suggestion. Those are different problems, and the second one is the one that actually mattered.
Key design decisions
How to represent confidence
The severity categorisation of Critical, High, Medium, and Low already existed and was not changing. The question was what to add alongside it to communicate the AI's confidence in a specific fix suggestion. A percentage score was chosen over colour bands or descriptive labels because it preserved the full signal from engineering without abstracting it.
What to do with low-confidence suggestions
The instinctive response to a low confidence score is to hide the suggestion or grey it out. We explored both. Both created the same problem: users lose the AI's input on the hardest cases, which is exactly when they need it most.
How much friction on the approval
The highest-stakes moment in the design: once a user approves a fix, the AI commits code to their codebase. Too little friction and users click through without understanding what they are approving. Too much friction and the AI becomes more work than the manual workflow it replaced.
Developer vs. manager view
The same AI signals needed to serve two very different jobs. Developers need granular detail on one application. Managers need a cross-application summary they can act on or cascade to the right developer with enough context attached.
Validation
We ran informal usability sessions, including sessions with power users who were actual enterprise customers. The confidence score and situational warnings were tested directly.
The non-obvious finding that shaped the final design: low confidence did not cause users to skip or dismiss suggestions. It caused them to engage more carefully. Users increased their scrutiny proportionally to their uncertainty, which is exactly the behaviour good AI UX should produce. We validated the approval flow the same way, confirming that context-before-commitment worked better than friction-before-commitment.
An AI layer that earns its place in the workflow
The solution is a layered experience that meets users at each stage of the vulnerability workflow, removing the parts that did not require human judgment while keeping humans appropriately in control of the parts that did.
AI-powered triage on arrival
When a scan completes, findings arrive with Aviator's fix guidance layered on top of the existing severity ranking. The detail page for each finding now carries an Aviator explanation of why the vulnerability exists and what its likely impact is, sitting right where users make their first triage decision.
Auto-fix for known issues
For recurring or policy-matched vulnerabilities, Aviator applies the fix automatically with no user action required. The finding is marked as resolved with a clear audit trail, removing the lowest-judgment work from the queue entirely.
Suggested fixes with a confidence score
For new or complex issues, Aviator surfaces a suggested fix inline on the finding detail page. The confidence percentage appears directly next to the suggestion, not buried in metadata or translated into a label. Where confidence is low, a situational warning appears: a visible, honest signal that invites scrutiny rather than discouraging action.
Single-step approval, automated commit
Once a user has reviewed the suggestion and confidence signal, a single approval triggers the fix commit to the codebase: no handoff, no ticket, no second screen. The finding is marked as pending verification until the next scan confirms. If the rescan still shows the issue, it returns to the queue for manual review.
Dual-persona views
Developers see granular detail: one application, all findings, full fix context. Security managers see a cross-application view with AI-prioritised summaries they can cascade to the right developer, with enough context attached that the assignment does not create a second question-and-answer cycle.
Screens have been abstracted and data anonymised to respect OpenText confidentiality. The design patterns described above (confidence score placement, situational warnings, the approval flow) are shown in reconstructed form. The thinking behind each decision is intact.
What the users actually taught me
Trust is calibrated, not binary
Users do not decide to trust the AI or not trust it wholesale. They make a judgment call on each suggestion based on available signals. The confidence score gave them something to calibrate against, which is why low-confidence suggestions produced more careful engagement rather than avoidance.
Fix guidance is the hidden job
The product's original problem framing was about detecting vulnerabilities. The real user pain was knowing how to fix the ones they had never seen before. Aviator's fix guidance addressed a gap that no amount of triage-display polish would have touched.
Expert users need transparency, not simplification
Every instinct in AI UX is to abstract and simplify. For this audience of developers and security engineers, that instinct was wrong. They wanted the raw signal (a percentage, not a label) and the full reasoning. Simplifying for them felt condescending and reduced trust.
Honesty about uncertainty compounds trust
Showing when the AI was uncertain, and why, increased the credibility of the suggestions it was confident about. Hiding uncertainty would have done the opposite: one visibly wrong confident suggestion would have undermined the entire layer. Honest signals compound trust over time.
What I carry forward
Design for model fallibility, not model perfection
The confidence score and situational warnings worked because they were honest about what the model did not know. Transparency about uncertainty builds more durable trust than false confidence, and expert users notice when something is being hidden.
Introducing AI to an existing product is a trust design problem
The AI layer had to earn its place by proving its value at the margins first: auto-fixing the easy cases, surfacing signals, suggesting fixes on complex ones while keeping humans in control. Gradual trust-building through demonstrated reliability is how AI gets adopted in enterprise contexts.
Instrument the confidence threshold earlier. The confidence score worked, but we never learned where the natural threshold was. At what percentage did users reliably slow down and scrutinise more carefully? That data would have let us tune the situational warning trigger from a judgment call into something evidence-based. I would push for instrumentation on confidence-score interactions from day one of the beta.
I would also invest earlier in the dual-persona divergence. The manager's cascade workflow (assigning findings to the right developer with enough context attached) was underspecified in the first version. Users found workarounds. That is a signal I would treat as a first-class design problem earlier rather than a follow-on iteration.
The confidence score helped developers decide how carefully to look at a fix, not whether to look at it. That was the non-obvious outcome that told us the design was working.