Inconsistent design was costing HackerOne customer trust. I authored the design principles that unified the product and gave every team a shared bar for quality.
Design Principles is the standard I authored to unify a product that had drifted into five different design languages. As Head of Product Design I led the audit, wrote the principles, and turned them into something every team could actually use. It is the case study of raising the quality bar across an organization, not just on one screen.
The problem
HackerOne's product had grown feature by feature and team by team, and it showed. The same action behaved differently depending on where you found it, the vocabulary shifted from screen to screen, and there was no shared definition of "good." For a security product, where trust is the entire proposition, that inconsistency was quietly expensive.
Problem · the same product, five different ways
Before · inconsistent
After · one bar
The same action looked different on every screen
One pattern, used everywhere
Three words for one thing: report, finding, submission
One shared vocabulary
Icons that meant different things in different places
An icon means one thing, always
Every team had its own bar for quality, so the product felt like five products. For a security tool, that inconsistency reads as carelessness, and carelessness costs trust.
Research & discovery
I made the drift impossible to argue with before proposing a fix.
Research · naming the drift
01
Product-wide UI audit
Catalogued every pattern, button, and flow to see the drift in one place.
02
Cognitive-load analysis
Found where screens asked users to hold too much at once.
03
Journey mapping
Traced the real paths through the product, not the org chart.
04
Accessibility audits
Held every pattern to a real, measurable bar.
Before writing a single principle, I made the inconsistency undeniable, so the case for fixing it was evidence, not taste.
The principles
I distilled the fix into four principles. Each one is memorable, and each one is paired with the concrete questions that make it usable in a real design review.
The deliverable · four principles, each with the questions to ask
01
Make it delightful
Protecting the internet doesn't have to be a boring task.
Ask yourself
›Are we using plain, approachable language?
›Are we motivating users to finish the task?
›Are we helping users when they get lost?
02
Speed & efficiency matter
Efficiency is a user reaching their goal fast.
Ask yourself
›Can the user reach their goal faster?
›Can they do it in fewer steps?
›Is the page structured for the task at hand?
03
Reveal information in layers
The right information at the right time.
Ask yourself
›What is the one thing the user needs first?
›Are too many actions competing at the same level?
04
Strive for consistency
Reuse, reduce, recycle. Lower the cognitive load.
Ask yourself
›Can people predict what an action does anywhere?
›Is the terminology uniform across the product?
›Does an icon always mean the same thing?
Principles are useless as posters. Each one ships with the questions a designer, PM, or engineer can actually hold a screen against.
Impact: a shared bar
Principles only matter if people use them. So I built them to be applied, not admired.
Impact · from principles to a shared bar
Design review · does it pass?
✓Is it delightful, not a chore?
✓Can the user get there faster?
✓Is information revealed in layers?
✓Is it consistent with everything else?
The principles stopped being my opinion and became the team's checklist. Any designer, PM, or engineer could hold a screen to the same standard, in any review.
Reflection
The lesson that shaped how I lead design since: consistency is not a constraint on creativity, it is what lets a team move fast without the product falling apart. A shared bar turns a hundred individual judgment calls into one aligned product.
Explore · the principle cards
Each principle shipped as a card with its illustration and the questions to ask. Tap any to open it full-size, then arrow through the set.