Intigriti connects ethical hackers with organizations looking to find vulnerabilities before they can be exploited. As a bug bounty platform, trust is everything. Researchers need to discover programs and submit findings without friction. Organizations need to manage reports, assess risk, and reward researchers fairly.
I joined in 2016 as the first UI/UX Designer, through Monkeyshot. No design function, no design system, no established UX practices. Just an early proof of concept and a product that needed to work for two very different audiences at once.
That early foundation supported Intigriti's growth into one of Europe's leading bug bounty platforms.
Two Audiences. One Platform. No Room for Ambiguity.
Designing Intigriti meant balancing the needs of two fundamentally different user groups within a single platform.
Security researchers needed to:
- Discover relevant programs
- Understand scope and eligibility requirements
- Submit vulnerability reports efficiently
- Track communication and bounty payouts
Organizations needed to:
- Manage incoming reports
- Assess and prioritize vulnerabilities
- Collaborate internally
- Maintain productive relationships with researchers
Each audience had different goals, workflows, and mental models. The challenge was creating a platform that felt intuitive and efficient for both sides without sacrificing clarity or trust.
Getting the information architecture wrong would create friction for researchers, organizations, or both.
Before There Was a Product, Someone Had to Build One.
The initial focus was validating the business model and supporting early customer acquisition.
Working closely with the founders and engineering team, I designed the core platform experience from the ground up, including both sides of the marketplace:
- Researcher onboarding and program discovery
- Vulnerability submission flows
- Company dashboards
- Report triage workflows
- Initial design patterns and UI foundations
At this stage, speed and usability were more important than visual refinement. The goal was to prove the concept, support early customers, and establish product-market fit.
Real Usage Revealed What the MVP Couldn't.
As the platform matured, the proof of concept started showing its limits.
The product worked, but the workflows were becoming harder to scale. Researchers were using the platform to discover more programs, submit more reports, and manage more communication. Enterprise customers were handling larger volumes of submissions across multiple programs and internal stakeholders.
The first version had helped validate the business. Now the product needed to support real operational complexity.
Before proposing solutions, I focused on understanding where users experienced the most friction.
The Redesign Was Guided by Data and Customer Feedback.
To identify the highest-impact opportunities, I combined multiple sources of insight:
- Product usage signals around high-traffic and high-friction workflows
- Customer workshops with enterprise clients
- Feedback from customer-facing teams
- Stakeholder interviews with founders, sales, and engineering
- Opportunity mapping based on user impact and implementation effort
This helped avoid redesigning the platform based on opinion alone.
The goal was to understand which problems kept coming back, which workflows mattered most to the business, and where design could create the most leverage.
Three Problems Kept Coming Back.
Across the usage signals, workshops, and customer feedback, three problem areas kept coming back.
- Reporting Workflows Lacked Clarity: Vulnerability reports contained large amounts of information, multiple timelines, and complex status transitions. Users often struggled to understand the current state of a report and what would happen next.
- Communication Was Buried: Once a report was submitted, communication between researchers and organizations became the primary activity. Comments and collaboration were visually deprioritized despite being central to the workflow.
- Navigation Did Not Reflect User Behavior: Organizations had to move between multiple disconnected sections to manage their programs. The platform structure reflected the underlying system architecture rather than how security teams actually worked.
Those themes became the filter for the redesign.
Instead of redesigning the platform screen by screen, I mapped the recurring problems onto the workflows where they created the most friction: program discovery, navigation, dashboards, report detail, status management, and program lifecycle states.
I Turned the Patterns Into Workflow Redesigns.
Researchers Shouldn't Have to Hunt for Programs.
Customer feedback showed that researchers needed to scan programs faster, compare requirements more easily, and understand whether a program was relevant before opening the detail page.
I redesigned program browsing around clearer hierarchy, stronger visual scanning, and overview cards that made scope, eligibility, and next actions easier to understand.
The new experience allowed researchers to quickly evaluate programs, understand requirements, and take action without unnecessary friction.
The Platform Was Structured for Engineers, Not Users.
Usage patterns and customer conversations showed that enterprise users were switching between programs and reports throughout the day.
I redesigned navigation around a persistent sidebar, improved search, and suggestions that made it easier to move between programs, reports, and ongoing activity.
This reduced navigation complexity and made it easier for users to move between programs, reports, and ongoing activities.
Security Teams Were Managing Risk Across Five Screens. I Made It One.
Workshops with security teams showed that report management was less about reading one report at a time and more about maintaining situational awareness across many active submissions.
I consolidated key information into a unified dashboard that surfaced active submissions, severity levels, status updates, and ownership information.
The redesign helped teams focus on prioritization and decision-making instead of navigation.
The Most Used Screen in the Product Was the Hardest to Read.
The report detail page was the most complex and business-critical screen in the platform.
Security teams used it to review vulnerabilities, communicate with researchers, assess severity, track history, manage payouts, and update statuses.
Feedback showed that users were losing context between status, communication, severity, and next actions.
I reorganized the page around the triage workflow itself, bringing communication, status information, and next actions closer together.
The result was a clearer experience that supported faster and more confident decision-making.
Status Management Was Trying to Solve Two Problems at Once. One Didn't Exist.
Customer workshops surfaced a recurring problem in how companies managed vulnerability reports after triage.
The platform supported both public and internal statuses, but most customers already used tools like Jira for internal remediation. Maintaining a second status system created unnecessary complexity.
I simplified the experience around the status that mattered most and made the available next actions explicit. This reduced workflow complexity and aligned the product more closely with how customers actually worked.
10,000 Researchers. 100 Clients. One Design Foundation.
By September 2020, Intigriti had grown into one of Europe's leading bug bounty platforms.
- 10,000+ active security researchers
- 100+ enterprise customers
- Clients included Telenet, Brussels Airlines, and Tomorrowland
- One of the leading bug bounty platforms in Europe by 2020
The design language, information architecture, and core workflows established during those four years became the foundation that supported Intigriti through its most important growth phase.
The platform evolved from an early proof of concept into a scalable product capable of serving both sides of a complex security marketplace while maintaining trust, clarity, and operational efficiency.