Design principles

Last modified:

How we design at Bugcrowd.

Bugcrowd branding

Last modified:

Users first

Last modified:

**tl;dr:** “what does the user need?”

Our primary consideration is always our users. We guide design decisions by finding out what our users want to do, and then structure the product so they can carry out the task as efficiently as possible.

Clear communication

Last modified:

Landing on a page, a user should have a clear understanding of what is required of them.

Similarly, a page’s instruction, data, and process(es) should be scannable, and its hierarchy easily determinable.

Overall, our interactions with our application should:

  • Speak to users with a single voice that is consistent, and familiar to hacker culture and the security industry;
  • Be comfortable to use and navigate, with confidence that words and actions carry consistent meanings and operations.


Last modified:

Our visual style is clean and understated, to allow our users to leverage their brand or individual identity.

Everything in the interface should serve a specific purpose --- expose, and collectively iron out the cruft.

Our product reflects the Bugcrowd brand while optimizing for frequently-used and simple tasks. Utilize friction for complex and dangerous flows.


Last modified:

Embrace common platform patterns and conventions.

Our interface should feel familiar and predictable to users. Similar tasks should be represented in similar ways.

Interface elements should act in a standard way whenever they appear. Where possible, we follow conventions and patterns from the host operating system, allowing users to better understand and predict how the product will behave.


Last modified:

Eliminate ambiguity.

Users trust us with their security, time, and money; we should be clear and transparent about what’s needed and why.

Eliminate ambiguity. Provide international inclusion; aim for a readability of “Lower secondary education” or below.

Write copy that is accessible to all users; everyone at all levels of experience should feel like they know how to use the product.


Last modified:

Accessibility benefits everyone.

Our software should avoid excluding users based on their abilities --- whether physical, sensory, cognitive, or otherwise --- as best as possible.

Our provisions consider the permanent, temporary, and situational accessibility needs of users.

For more information see § Accessibility.

Cared for and maintained

Last modified:

Build with pride, and maintain with care.

We are ultimately responsible for the user experience.

Be humble

Last modified:

Be friendly and approachable to voices of our users

We’re building this to empower the development of good experiences with our product.

But we’re building this to scale, and thus not just for either ‘designers’ or ‘developers’, or any other single group of people.

Be conscious of this responsibility: consider the implications of decisions across the designs system, and how they affect its usage.

Most of all: be friendly and approachable to our users, whether fellow colleague or direct user.