From Score to Score Plan

A short-form UX consulting engagement with SecurityScorecard — redesigning the invited-vendor experience to reframe a passive security grade into an active remediation workflow.

Challenge

Invited vendors arrived in a product built for their assessors — a judgment with no path forward.

Role

UX Consultant

Approach

Designed Score Plan as the primary artifact — a remediation campaign with projected score recovery per issue.

Outcome

Concept proposal demonstrating a category shift from passive scoring to active remediation workflow.

Thesis

A security score is a judgment. The vendor on the receiving end of a bad one — invited by a customer to fix it — doesn't need a better view of how bad things are. They need a path forward. Redesigning for that user means starting from their motivation, not the scorecard owner's.

The Brief

SecurityScorecard provided platform access and a specific scenario: a vendor for GE has been invited to the platform because their security score is an F and GE wants them to fix it. Redesign the experience of being that invited vendor — understanding the context of the request, navigating the score, and improving it — and produce visual designs for a representative subset of the redesigned flows.

Five days. A platform I’d never used before. Technical delays on account access ate into the first day. No real users to interview, no existing research to draw from, no customer data.

The work is grounded in pattern recognition and domain expertise rather than validated research. It’s included here because the problem framing and the core concept are genuine — and because the direction it points toward maps onto how the category has actually evolved.

Discovery Under Constraints

I couldn’t do real user research on a five-day timeline with a platform I’d just been handed. What I could do was use the product as the user I was designing for: log in, trigger the invite flow, and experience what a vendor with an F score actually encounters when they arrive.

The finding wasn’t subtle. SecurityScorecard had built a deeply featured platform, but the architecture was organized around the scorecard owner — the enterprise customer running assessments on their vendors. The vendor arrives through an invite, sees a grade on their own organization, and then faces a product designed for someone evaluating others. Every view, every data hierarchy, every action path was oriented toward the wrong person.

Pseudo persona diagram showing vendor motivations, tasks, and outcomes — the gap between what the invited vendor needs and what the platform provides — Vendor persona — motivations, tasks, and outcomes for the invited user. The product was built for the assessor, not the assessed.

The second problem was structural. The platform treated “vendor user” as a single role. In practice, the vendor side involves at least two distinct modes of engagement: the executive who wants to understand what’s happening at a high level — the grade, the trend, the most exposed areas — and the practitioner who needs to work through issues methodically, prioritize them, track their resolution. Those are different jobs. The product gave both of them the same interface optimized for neither.

Insight

SecurityScorecard was built for the organization running assessments on vendors. The invited vendor arrived through a side door into a product designed for their assessor — every view, every data hierarchy, every action path oriented toward the wrong person.

Hypothesis

If the vendor's experience started with a remediation workflow rather than a score breakdown, the platform would have something to offer them — turning a passive judgment into an active project the vendor could own and show progress on.

Decision

Designed the Score Plan as the primary entry point — a structured remediation campaign with projected score recovery per issue — making the vendor's workflow the surface rather than a buried feature inside a scorecard-owner product.

The Core Problem

An F score is a judgment. Being invited by GE to fix it is a political situation as much as a technical one. The vendor isn’t browsing. They’re accountable to a customer, under pressure from their own leadership, and looking for what to do — not a more detailed view of how bad things already are.

The existing product answered the wrong question. It showed the score and its components in exhaustive detail. What it didn’t provide was a path: here’s what you can fix, here’s what it would change your score to, here’s how you track whether you’re making progress.

Key views audit — Scorecard, Issues, Compliance, and History views, each designed from the scorecard-owner perspective — Key view inventory — four views, each rich with data, none designed around the vendor's immediate question: what do I do next?

The Score Plan

The central concept I proposed was the Score Plan: a structured remediation campaign that turns a passive security grade into an active workflow.

The existing product had something like this buried in the experience — a form-based list of findings. My redesign treated it as the primary artifact for the invited vendor. The difference was in how it was structured:

Dashboard-first score view. The vendor’s landing experience shows overall grade with a per-category breakdown, each category displaying both its current contribution and the projected improvement available through remediation. The question “how bad is it?” and “what’s worth fixing first?” are answered on the same surface.

Plan generation flow. Two entry points: Generate Plan, which proposes a prioritized campaign based on impact and effort, and Create Own Plan, for vendors who already know what they need to address. Both lead to the same artifact — the vendor owns the plan regardless of how they entered it.

Impact-visible prioritization. Each issue in the plan shows projected score recovery alongside remediation effort. A vendor under pressure from a customer doesn’t just want the most critical issues — they want the ones where effort converts most efficiently to visible score improvement.

Workflow-driven progress tracking. Issues move through states — Active, In Progress, Resolved, Decayed — as a kanban-style workflow rather than a static list. This reflects how remediation actually works: it’s a campaign over weeks, not a single session. The existing product treated it as a list of findings. The Score Plan treats it as a project.

Score Plan generation flow — from current F grade to a proposed improvement plan with projected score recovery and remediation effort per issue — Score Plan generation — current grade, proposed prioritization, and projected score improvement visible before committing to the plan.

Score Plan tracking view showing issues organized by Active, In Progress, Resolved, and Decayed states with a timeline and progress visualization — Score Plan in progress — issues tracked through workflow states, with timeline and plan management tools for a campaign that runs over time.

Proposed visual design for the Score Plan view — projected score B 85, active issues panel, score plan timeline, and plan management controls — Visual design comp — projected score, issue panels, timeline, and plan lifecycle controls. The F-to-B arc visible in a single view.

Constraints and Tradeoffs

Five days with technical access delays meant no time for user research, usability testing, or iteration. The personas and mental models were informed by a decade in enterprise security — pattern recognition rather than validated findings.

The presentation ran 30 minutes and covered the full process. It generated questions about aesthetic choices and interaction behavior that a static mock couldn’t answer — transitions, how kanban states would behave at scale with hundreds of issues, the experience of the score improving in real time. Those are legitimate questions and the right ones to ask. What the static format could demonstrate was information architecture, workflow logic, and the core conceptual shift from score-as-judgment to score-as-roadmap.

Whether the Score Plan concept was kept and used after the process ended is speculative. The pattern — turning passive compliance data into an active improvement workflow — has precedent in how platforms like AuditBoard and OneTrust have evolved, and in work I later did at ActZero on Security Posture Assessments. The idea that vendors need a path, not just a grade, holds across the space.

Outcome

The engagement ran four weeks total, including presentation and follow-up. The presentation covered the full process — discovery, problem framing, Score Plan concept, and visual comps — and generated substantive questions about interaction behavior and edge cases a static mock couldn’t resolve. Those are the right questions.

The Score Plan concept itself has proven directionally accurate. The pattern of turning a passive compliance or risk grade into an active, workflow-driven improvement campaign is now standard in platforms like AuditBoard and OneTrust. The specific mechanic — impact-visible prioritization, kanban-style state tracking, projected score recovery — anticipates how SecurityScorecard’s own vendor workflow features have evolved. The work is included here as an example of applied product thinking under a constrained timeline, in a domain where the underlying problem structure was already familiar.