FOSSA
ISSUES V.2
FOSSA is an SCA (software composition analysis) platform that scans customer software to find instances of borrowed code (open source packages), identify security vulnerabilities or licensing issues resulting from those packages, and removing them before their code is pushed to a live product. A key product value is identifying issues and providing issue remediation options and support for our customers.
Situation
Data insights showed less than 5% engagement with FOSSA’s issue remediation feature by key enterprise accounts. This was a clear signal to our sales and product teams that the issue workflow was broken and that these customer accounts were at risk for churning in approaching quarters.
Task
Understand customer goals and pain-points to redesign the issue workflow with a focus on increased engagement, stronger data clarity, and decreased customer churn.
Action
My design team partnered with our product and engineering teams to design, develop, and launch a scalable framework to manage large issues counts, clarify issue context, and streamline user communications and actions; with a goal of beta-testing an updated version with our churn risk customers well before their contractual deadlines.
Result
Qualitative customer feedback was very positive, we achieved an 8.7% decrease in security issue counts, and 23.7% engagement with new issue filtering component.
Kickoff ▶️
Key progress indicators that guided our design efforts:
+100% engagement with issue actions (resolve, export)
20% of issue page visitors engage with issue filters (new feature)
-10% issue active issue count on new code revisions (demonstrates new issue system is decreasing issue counts overall)
-50% churn associated with issue resolution (need strong collaboration with sales and account reps)
Early Insights 🧭
Inadequate tools to find important issues
Red issue color system makes all issues hard to differentiate importance
Issue types and workflows are different across legal, security, and developer personas
Actions are vague, scary, and unused (what does this do? – signals customer churn)
Discovery 🔭
Interviewed post-sales (customer success and support) and product managers (weekly customer calls) to extract major themes
Reviewed internal tools (Gong, fullstory, Zendesk) discussions associated with issues
Researched competitors for patterns in issues
Mapped customer journey with design and product to highlight critical moments and pain points for users
Reframing the Problem 📐
Only some issues matter
Open source software posture and protocol vary by customer and use case across issues and the policies that generate them.
Resolve action is too broad
Users need to manage issues based on a variety of use cases: zero day event, high severity + actionable, false positive, low severity, no fix.
Issue discovery and removal are done by different users
“Finders” (Lawyers, Security Developers) need to interact with “Fixers” (Software Developers).
Enterprise use cases need support
Large orgs + lots of issue = load and management problems.
Redesign ✍️
Separate issue list and detail into separate views to optimize the workflow
We used an email inbox mental model to discover, prioritize, and organize issues for our “finder” personas
Show more
Highlight the appropriate data to communicate an issue’s shape and relevance with optimized issue rows and data table.
Control more
Bring unmanageable issue counts to a prioritized and actionable list with filters.
Do more
Organize issues based on you and your team’s needs and workflows with contextual actions.
Actions are a team sport
Collaboration between “finder” (lawyer/security) and “doer” (developer) gets better with optimized views for their part of the process.
Highlight critical data, provide immediate actions, and provide a data deep dive for our “fixer” persona
Prioritized and organization
All high-level, critical data is immediately available on the overview tab, with additional data context, relationships, and references close by.
Package details
View package-related data and relationships to understand this issue’s origin.
Smart suggestions
Take immediate action and understand the context of those actions.
Left: vulnerability base metrics help developers determine if they’re code is vulnerable
Right: affected project list helps lawyers and security devs know the affect of the issue and if more teams/devs need to be contacted
Organizing content
Reducing visual noise while organizing and prioritizing data by personas.
Ignore action
Problem
Too many issues cause decision paralysis.
Goal
Provide issue management tools to organize issues by user need and bring down their issue count.
Research
Data: less than 0.36% engagement with resolve action during the issue workflow.
Customer interviews: Security Developers (persona: devsec) say not all issues are actionable:
No current fix.
Dependency's depth doesn’t allow easy access.
No available resources to invest.
Competitive analysis: other tools like Snyk provide more flexibility and granularity to address this grey area of the workflow.
Hypothesis
If we provide additional actions that address a “pause” in workflow, which can be triggered by external events (fix published in NIST, new code revision) or user determined time interval, than users can manage non-actionable issues and decrease their overall active issue count.
Opportunity
Create an Ignore action with more user defined flexibility for timing, availability of a fix, new revision, or escalation of severity.
Outcome
Still building, pushed 1 quarter.
Note: this could have an outsized benefit for customers and may have been a better tradeoff functionality versus a full redesign.
Ignore issue action button and dropdown menu
Launch & Impact
Qualitative: customer feedback was very positive
-8.7% on active security issues
23.7% engagement with new issue filtering component