Back to cases
  • Product Design
  • UX Research
  • Prototype

Chrome extension — Initial ideation

Concept work for a free browser extension that turns a page's invisible layer — scripts, trackers, cookies and data connections — into something anyone can read.

2

Versions designed

5.0

Rated stars today

+5000

Active users today

The Challenge

This project began as one of the ideas prioritized after the ideation workshop: giving users a way to understand a page's security and privacy posture without needing a security background. It evolved into a free browser extension that turns an otherwise invisible layer of a web page — scripts, trackers, cookies, and data connections — into something anyone can read. Beyond the utility itself, it served as a low-friction way to put the company's expertise in front of a wider audience.

My Role

I was the designer responsible for the extension's initial concept, from brief to handoff. I ran the reference research, mapped the personas with the team, sketched the product's full lifecycle (installation, contextual help and uninstall), designed the end-to-end user flow, and explored interface formats until reaching the V1 approved in co-creation sessions. I then iterated into V2 based on stakeholder input on data hierarchy, built the extension's style guide, and aligned scope with engineering.

Part 01

Research

Design brief

  • User insight: show which scripts and trackers run on a page — hosts, domains, geographic destination of data — plus deeper security signals like input read access and data transfer risk.
  • User action: let users block or allow specific behaviors (e.g. third-party scripts reading password fields), with geographic blocking as a stretch goal pending technical feasibility.
  • Brand exposure: surface CTAs pointing to the company's enterprise product.
  • Platform scope: Chrome first.

References

Personas

  • The Curious: has some idea of security, still learning, curious user, early adopter, hard to prospect.
  • The Auditor: more advanced in security, advanced user, uses tools like Ghostery, can get curious about our products.
  • The Customer: our customer, knows at least one of our products, can get interested in acquiring another one.
The three personas guiding the extension's content and language decisions.

Part 02

From sketch to flow

Early sketches explored more than the core feature — they mapped the extension's full lifecycle: onboarding messaging that immediately addresses privacy trust ("we don't use your data"), contextual help, and even an uninstall flow with a feedback survey to capture why users left. The full user flow was then mapped end-to-end, branching from installation through each report type, down to the uninstall path — ensuring the extension had a considered experience at every exit point, not just the happy path.

  • Sketches: the initial sketches were related to install/uninstall screens and the input pop-over.
Extension installation welcome message and help details.
Uninstall process and feedback form.

Userflow

End-to-end flow: install, open the extension, browse each report and uninstall.

Part 03

Design process

Exploring the format

Variations for the first version of the Chrome extension:

Version 01

The v1 was approved after some co-creation meetings:

Style guide

Version 02

Changes were guided by stakeholder input on which data mattered most to users, prioritized as: scripts > vulnerabilities > data transfers > data assets > trackers.

  • Data Assets card was added: surfacing exactly which data (email, password, etc.) was being read or transferred, and where it was going.
  • Trackers gained category tags: trackers aren't always recognizable by name alone, so grouping them into categories (e.g. advertising, analytics) made their purpose clear at a glance.
Mockup of the extension applied on a real website, simulating the browser experience.

Learnings

  • The install/uninstall flow and inline input pop-over were scoped out early after alignment with engineering — useful reminder that not every sketched idea needs to survive to production.
  • An early interaction (inline tooltip on password fields) shipped in v1 but generated negative feedback and was removed in v2 — validated the value of testing smaller interactions before treating them as core to the experience.
  • Ownership of the project later moved to the marketing team as product priorities shifted. The interaction model and structure from this phase carried through into the version live today, which is rated 5.0 stars with 5000+ active users.