Cybersecurity Threat Intelligence Platform

senior UX/UI Designer & Product Owner

Cybersecurity Threat Intelligence Platform

Cybersecurity Threat Intelligence Platform

senior UX/UI Designer & Product Owner

UX/UI Designer & Product Owner

KEY ACCOMPLISHMENTS

KEY ACCOMPLISHMENTS

Led the end-to-end design and implementation of a custom Role-Based Access Control solution with UI-embedded business logic, resulting in $5.2M in revenue impact.

Conducted in-depth user interviews and collaborative discovery workshops to surface workflow needs and gain understanding of customer use cases.

Worked with PMs, Sales, and engineering to scope a complicated, highly technical project in 3 main phases of work to deliver value to the customer earlier.

Delivered complex business logic and a user-friendly configuration flow to simplify action permissions and data access controls for internal and cloud-based MSSP use cases.

customer discovery calls

customer discovery calls

Conducted 10 in-depth interviews with users from five key customer organizations across varied team sizes to surface pain points, synthesize common themes, and define clear business requirements.

interview insights

interview insights

Pain Points

  • The existing permissions in the default user roles were limited and no longer meeting the needs of growing security teams

  • Administrators could not restrict specific actions in the system, such as the ability to export data

  • Certain teams should only have access to certain data depending on data type or specific attributes

  • Organizations needed to group users depending on region, team, or government clearance level

Desired State

  • Administrator can configure permissions to feature areas in the platform

  • Administrator can configure permissions for specific user actions in the UI and API

  • Administrator can segment access to data based on data source

  • Administrator can segment access to data based on data type

  • Administrator can segment data for data consumers in MSSP multi-tenancy environment

product Planning & Design process

product Planning & Design process

Prioritization & Scoping

Information Architecture & Logic

Intuitive Interface Design

Prioritization & Scoping

Information Architecture & Logic

Intuitive Interface Design

Prioritization & Scoping

Once we had a good understanding of the requirements and user needs, I set up a series of meetings with key players from the product, engineering, and architecture teams to prioritize the requirements and determine relative sizing for level of effort. To guide these conversations I structured them using the MoSCoW Prioritization Framework to rank and weigh requirements.

MoSCOW prioritization framework
Determining the scope of mvp

Because the project spanned permission controls across the entire platform, it was crucial to define a viable MVP to deliver value earlier rather than pursue a waterfall approach that could take a year or more to ship. The MoSCoW exercise resulted in a prioritized list of features from the Must (P1) and Should (P2) columns and would inform the core MVP scope. The next step was to then scope the prioritized list of P1 and P2 requirements into feasible phases of development work.

Milestone 1: Administrative Action Controls

Through conversations with engineering, it became clear that API endpoint architecture would allow for relatively low level of effort for implementing permission controls for administrative actions such as managing users, system configurations, and data policies. These were also some of the most commonly requested features.

Milestone 2: Granular Action Controls

This more granular level of action controls required significant refactoring work in the API, so I scoped this portion into the 2nd phase of work. This allowed engineering more time to research the correct long-term approach and apply any learnings from the backend work done in milestone 1.

Milestone 3: Data Access Controls

This portion of the project required the most refactoring work as it entailed gating data access based on the type of data object and other attributes. In order to prevent any data leakage, this meant that data needed to be marked and segmented immediately upon ingestion. This presented data storage and performance implications that required significant collaboration between product, design, and engineering.

predictability in delivery

Through collaborative planning with product and engineering, I developed a feature roadmap that prioritized the most pressing customer needs while giving engineers a predictable framework to execute against. This alignment enabled clear stakeholder communication, set accurate customer expectations, and prevented unexpected delays in the delivery timeline.

Prioritization & Scoping

Once we had a good understanding of the requirements and user needs, I set up a series of meetings with key players from the product, engineering, and architecture teams to prioritize the requirements and determine relative sizing for level of effort. To guide these conversations I structured them using the MoSCoW Prioritization Framework to rank and weigh requirements.

MoSCOW prioritization framework
Determining the scope of mvp

Because the project spanned permission controls across the entire platform, it was crucial to define a viable MVP to deliver value earlier rather than pursue a waterfall approach that could take a year or more to ship. The MoSCoW exercise resulted in a prioritized list of features from the Must (P1) and Should (P2) columns and would inform the core MVP scope. The next step was to then scope the prioritized list of P1 and P2 requirements into feasible phases of development work.

predictability in delivery

Through collaborative planning with product and engineering, I developed a feature roadmap that prioritized the most pressing customer needs while giving engineers a predictable framework to execute against. This alignment enabled clear stakeholder communication, set accurate customer expectations, and prevented unexpected delays in the delivery timeline.

Milestone 1: Administrative Action Controls

Through conversations with engineering, it became clear that API endpoint architecture would allow for relatively low level of effort for implementing permission controls for administrative actions such as managing users, system configurations, and data policies. These were also some of the most commonly requested features.

Milestone 2: Granular Action Controls

This more granular level of action controls required significant refactoring work in the API, so I scoped this portion into the 2nd phase of work. This allowed engineering more time to research the correct long-term approach and apply any learnings from the backend work done in milestone 1.

Milestone 3: Data Access Controls

This portion of the project required the most refactoring work as it entailed gating data access based on the type of data object and other attributes. In order to prevent any data leakage, this meant that data needed to be marked and segmented immediately upon ingestion. This presented data storage and performance implications that required significant collaboration between product, design, and engineering.

To dig in deeper, I spent time physically sitting with users to better understand their mental states while engaging with the current process and document their workflows in-context to better validate our assumptions about the business problems.

Design exercise

Rather than creating user personas defined by demographic or static attributes, I sought to apply a more dynamic framework. This approach allows you to think of a user’s attitudes and behaviors over time through 2 key lenses:

MINDSET: This lens captures traits such as attitudes about technology, attitudes about their roles and responsibilities, level of experience, or working styles.

MODE: This lens more dynamic and can shift over time. Rather than a static trait, it refers to the user's current desire or task at hand.

KEY INSIGHTS: User stories

As a user, I need the ability to view complex data from multiple sources chronologically and clearly see gaps in the process in order to take remediation steps.

As a user, I need the ability to understand the chain of logistics and responsibility for the package at each step during and after the process completes.

As a user, I need to view detailed information for each event in the process so that I can easily draft reports or emails to my counterparts.

As a user, I need the ability to view complex data from multiple sources in a relational context so I can understand how events are related.

Intuitive Interface Design

Information Architecture & Logic

Information Architecture & Logic

Applying insights from conversations with engineering, I developed business logic and an internal terminology for how our system use these concepts.

conceptual diagram
communicating the business logic

Mapping the feature’s high-level business logic provided the development team with a solid foundation for designing the supporting backend architecture. It served as a common north star to refer back to from the planning stages all the way to quality assurance testing.

consistent terminology
aligning product & engineering to the same language

Speaking the same language means turning the requirements, user needs, and technical realities into a shared vocabulary. The result was faster decision-making, fewer handoff misunderstandings, and a delivery process where PMs, designers, and engineers could confidently build the feature in the same direction.

validating scenarios
Vetting business logic in practice

To validate the underlying business logic, I conducted an extensive exercise to test the framework across core flows and edge cases; the diagram above represents roughly 10% of that work. This process led to a more robust, intentional architecture grounded in both engineering constraints and product priorities, and it also provided a detailed foundation for the QA team to develop comprehensive test coverage.

Intuitive Interface Design

After researching existing implementations of configurable role-based access controls in comparable SAAS platforms, it was clear that configurations for nearly every aspect of a complex system could easily become confusing to an administrative user.

mapping new interfaces to familiar patterns

My goal with the design was to structure the architecture of the system's interfaces into intuitive categories. To do this, I organized the information in a way that is familiar to the user by basing the structure around the existing navigation menus.

Addressing new edge cases

As with many new feature development projects, things don't always go as planned. New information discovered during the spike research or development can always impact a design. It's key to be willing to adjust the design or the technical approach (or sometimes both) to address new edge cases.

In this case, the API engineer found several instances where permissions that were conceptually distinct in the UI were actually dependent on one another due to the backend architecture. An example of this was, for permissions related to the ability to edit the Scoring policy in the system, the user would also need "Create, Edit, Delete" permissions to Sources, Attributes, and Relationships.

Applying usability heuristics

To address this, I re-designed the interaction flow to ensure the following usability principles would be applied:

  • Error Prevention: The user will understand upfront that the current action the user is attempting to take will impact other configurations.

  • User Control and Freedom: The user is given control over whether to proceed with the action.

  • Flexibility and Efficiency of Use: The user only has to click once for the system to then make the relevant updates to the impacted configurations.

  • Visibility of System Status: Micro-animations in the UI help to inform the user of the updates that have automatically been applied to the impacted configurations immediately after the action is taken.

After researching existing implementations of configurable role-based access controls in comparable SAAS platforms, it was clear that configurations for nearly every aspect of a complex system could easily become confusing to an administrative user.

Addressing new edge cases

As with many new feature development projects, things don't always go as planned. New information discovered during the spike research or development can always impact a design. It's key to be willing to adjust the design or the technical approach (or sometimes both) to address new edge cases.

In this case, the API engineer found several instances where permissions that were conceptually distinct in the UI were actually dependent on one another due to the backend architecture. An example of this was, for permissions related to the ability to edit the Scoring policy in the system, the user would also need "Create, Edit, Delete" permissions to Sources, Attributes, and Relationships.

Applying usability heuristics

To address this, I re-designed the interaction flow to ensure the following usability principles would be applied:

  • Error Prevention: The user will understand upfront that the current action the user is attempting to take will impact other configurations.

  • User Control and Freedom: The user is given control over whether to proceed with the action.

  • Flexibility and Efficiency of Use: The user only has to click once for the system to then make the relevant updates to the impacted configurations.

  • Visibility of System Status: Micro-animations in the UI help to inform the user of the updates that have automatically been applied to the impacted configurations immediately after the action is taken.

mapping new interfaces to familiar patterns

My goal with the design was to structure the architecture of the system's interfaces into intuitive categories. To do this, I organized the information in a way that is familiar to the user by basing the structure around the existing navigation menus.

Intuitive Interface Design

Key Outcomes

Key Outcomes

MVP Shipped on Schedule

As a result of intentional planning and execution, MVP was delivered on schedule and met 80% of the core P1 requirements. Customer feedback was positive and further validated design and scoping decisions.

Expanded Customer Base and Growth Potential

This feature increased customer retention from the previous year by 40% and unlocked access to new customer bases in the market due to better coverage of use cases for government customers and large MSSP data providers.

New Revenue Impact

Generating $5.2M in revenue impact within its first year of implementation, this feature helped to position the business as a leader in user experience and complex data authorization best practices.

Expanded Customer Base and Growth Potential

This feature increased customer retention from the previous year by 40% and unlocked access to new customer bases in the market due to better coverage of use cases for government customers and large MSSP data providers.

New Revenue Impact

Generating $5.2M in revenue impact within its first year of implementation, this feature helped to position the business as a leader in user experience and complex data authorization best practices.

MVP Shipped on Schedule

As a result of intentional planning and execution, MVP was delivered on schedule and met 80% of the core P1 requirements. Customer feedback was positive and further validated design and scoping decisions.

Expanded Customer Base and Growth Potential

This feature increased customer retention from the previous year by 40% and unlocked access to new customer bases in the market due to better coverage of use cases for government customers and large MSSP data providers.

New Revenue Impact

Generating $5.2M in revenue impact within its first year of implementation, this feature helped to position the business as a leader in user experience and complex data authorization best practices.

location

Washington, DC or remote

Contact details

bellajones.uxdesign@gmail.com

678-480-1766

location

Washington, DC or remote

Contact details

bellajones.uxdesign@gmail.com

678-480-1766

location

Washington, DC or remote

Contact details

bellajones.uxdesign@gmail.com

678-480-1766

Prioritization & Scoping

Once we had a good understanding of the requirements and user needs, I set up a series of meetings with key players from the product, engineering, and architecture teams to prioritize the requirements and determine relative sizing for level of effort. To guide these conversations I structured them using the MoSCoW Prioritization Framework to rank and weigh requirements.

MoSCOW prioritization framework
Determining the scope of mvp

Because the project spanned permission controls across the entire platform, it was crucial to define a viable MVP to deliver value earlier rather than pursue a waterfall approach that could take a year or more to ship. The MoSCoW exercise resulted in a prioritized list of features from the Must (P1) and Should (P2) columns and would inform the core MVP scope. The next step was to then scope the prioritized list of P1 and P2 requirements into feasible phases of development work.

predictability in delivery

Through collaborative planning with product and engineering, I developed a feature roadmap that prioritized the most pressing customer needs while giving engineers a predictable framework to execute against. This alignment enabled clear stakeholder communication, set accurate customer expectations, and prevented unexpected delays in the delivery timeline.

Milestone 1: Administrative Action Controls

Through conversations with engineering, it became clear that API endpoint architecture would allow for relatively low level of effort for implementing permission controls for administrative actions such as managing users, system configurations, and data policies. These were also some of the most commonly requested features.

Milestone 2: Granular Action Controls

This more granular level of action controls required significant refactoring work in the API, so I scoped this portion into the 2nd phase of work. This allowed engineering more time to research the correct long-term approach and apply any learnings from the backend work done in milestone 1.

Milestone 3: Data Access Controls

This portion of the project required the most refactoring work as it entailed gating data access based on the type of data object and other attributes. In order to prevent any data leakage, this meant that data needed to be marked and segmented immediately upon ingestion. This presented data storage and performance implications that required significant collaboration between product, design, and engineering.