Security Configuration

BigFix’s First Live Compliance Dashboard — UX Case Study

Enterprise SaaS · HCL Software BigFix WebUI · Resolve Sole UX Designer Stage 1 of 6

<aside> 🌐

300,000

endpoints at scale

</aside>

<aside> ⚡

<3s / <20s

Landing / Detail page SLA

</aside>

<aside> 🧠

key structural decisions

</aside>

<aside> 🪩

Stage 1 of 6

roadmap foundation

</aside>

<aside> 💡

The Real Story Before this product existed, BigFix had no live compliance view. A Security Admin who wanted to know their compliance posture had to navigate to each device, each device group, and each check individually — with no aggregated view, no filtering, no way to act without switching tools. Security Configuration changes that. Stage 1 is the first real-time compliance dashboard in BigFix’s history.

</aside>

THE PROBLEM

Security teams were flying blind.

BigFix had a compliance tool — Web Reports. But it wasn’t built for how modern compliance teams work. There was no single place to see posture. No filtering. No path from identifying a failing check to fixing it without switching systems entirely.

	What didn’t exist	Real consequence	What Security compliance solves
1	No live compliance overview	Admins opened each device, device group, and check individually. No aggregated environment-wide view existed anywhere in BigFix.	Real-time landing page with KPI cards
2	No filtering capability	Admins managing specific regions or device groups had to cross-reference separate reports. No scoping capability inside the tool.	Global filter: 4 dimensions, multi-block OR logic
3	No saved or default views	Every session started from scratch. Manual filter reapplication before any actual work could begin — every time.	Saved views with default auto-load
4	No path from failure to action	Admins had to leave the tool and switch to a separate system to act on compliance failures.	Deploy directly from Security Checks grid
5	No per-checklist compliance detail	Web Reports showed surface-level data. No OS segmentation, no device-level breakdown, no check-level investigation.	Single Checklist View: 5 charts + Security Checks grid

👥 Personas

Three personas. Every layout decision validated against all three.

I used these as a validation lens throughout, not just a reference document. For every layout decision, which persona does this serve, at what moment, and does it work for all three without one compromising another?

🔵 Security / Compliance Admin — Primary user · Defines and enforces policies
🟢 IT Operations Admin — Manages device health · Executes enforcement
🟣 Master Operator — Full platform admin · Sets org-wide defaults

<aside> 💡

Persona-driven layout decisions Two of the most structural layout decisions came directly from persona analysis. The landing page leads with KPI cards before the checklist grid — because the Master Operator needs environment-wide counts before making any selection. The Security Checks grid has its own independent filter — because the IT Ops Admin works at grid level, not page level. These weren’t aesthetic choices. They were persona-driven.

</aside>