Create/Publish SD "Brand Use Guidelines"

[ninavizz]

Problem

When folks need to grab a SecureDrop logo "to use it somewhere" they need a brief, quick resource to guide them in how to use different pieces of artwork—including:

• How different unique artworks (logo files) work together or apart in different use contexts, to express the SecureDrop brand;
  • Placement of SD brand visual assets among non-SecureDrop branded visual assets;
  • Requirements to suit trust/usability in product use vs requirements to suit generalized brand awareness;
  • Use in of SD brand elements in different reproduction contexts (digital vs analog), correct size variances, and use of negative/positive space;
  • Dos/Donts
• How typography is used to express the SecureDrop brand;
  • Short answer: no Franchise font outside use of the word "SecureDrop" in allcaps, and in the product which type families we u and how that can/could carry-over into slide decks, swag, brochures, etc
  • Dos/Donts
• How color is used to express the SecureDrop brand;
  • Guidance on RGB vs Pantone vs CMYK
  • Guidance on different repro processes to expect in different use-need situations, and how to navigate
  • Dos/Donts

Trademark Use Guidelines typically cover the name and licensing particulars, and they also typically exist as a separate document—because otherwise, designers and developers get dragged-into all the legal crap, and forget to to prioritize simple aesthetic rules. The latter, is what a BUG is for.

A rant from the SD Brand In Use wiki page I threw together:

Historically, designers and artists have never bothered with licensing, whereas open-source projects with elaborate code architectures, derivations and dependencies, need to. Derivative pieces of code often require a far greater effort to prove and test, than small tweaks to artwork. Artists much more simply either don't want their stuff messed with, or don't care; and if we don't care, we also just don't want to deal with the hassle of disambiguating creative commons or other licensing particulars.

If we do care, just either credit or pay us. Don't paint either of our preferences with a bunch of big fancy words that digital-rights champions care about, passionately, yet never asked professional creatives if we wanted. Professional creatives not only did not ask for Creative Commons, but CC's evangelism has created a perception of creative work as anyone-can-do-it dabblings; not the craft of full-time professionals with decades-old professional codes Larry Lessig couldn't have been bothered with. Professional photo-journalists have felt the brunt of this, harder than anybody—and FPF being a non-profit to support adversarial journalism, I'd like to see get on board with the push-back against CC's extension to SecureDrop creative assets.

While the axis of Creative Commons get it right (profit, attribution, derivation) the broader concept of a licensing system just isn't how creatives work. Furthermore, "derivation" is far more complicated across media in creative work—how to credit photographs of performance art, who "owns" the underlying IP so compensation can be equitable from sales of those photographs, etc—than in code. And yet, SecureDrop is an OSS project, created by one of the Creative Commons authors. /leSigh

It is expected that the user journey will begin with "My organization needs to use the SD brand." From there, they need to reference a BUG to generate ideas and to guide solutions. Once they have some solutions in mind, then they should check a Trademark Guideline to ensure compliance. Those processes need to be sequential, not in-parallel, or details will get missed and the goals with both artifacts will be lost. Which is just a reality of how the human brain works. As such: Please keep this project a lawyer-free zone.

From the SD Brand In Use wiki page I threw together:

Supporting end-user trust in legitimate instances of our product, is our primary goal; not protecting a public corporation's dumb thing. Users don't see licenses, they see strange combinations of elements that do or don't make sense as credible to them. This guide needs to clearly document how to do that right, and for people who've already decided they want do that right.

Of note, as EFF demonstrates, a Brand Use & Trademark Policy document, is very, very different from a Brand Use Guidelines doc.

IMHO more appropriate BUGs to base SecureDrop's off of, are Mozilla's, Firefox's, Slack's. BUG developed by designers, for practical use. Seriously: Lawyer-Free Zone!

Solution

1. A concrete audience needs to be decided, for whom a generalized "Brand Use Guide" should suit. Tentative prioritization following discussions with David, and my own experience working on different touchpoints across the SD brand experience.

2. Tailor a BUG to suit the designated audience. EG: Spotify's BUG needs to be as detailed as it is, because many different creative agencies draw from it every day to co-brand creatively-rich commercial experiences for musicians. No OSS project has those needs. Mozilla and EFF's BUGs are good examples of super-general stupid-simple BUGs. SD's needs to be super-general and stupid-simple.

3. Subordinate/Descendant Guides that a BUG may link-out to should include:

   3a. Landing Page design guide. This is so badly needed. Should be published, separately; and it should first target design-inept lone-soldier IT folks that will feel helpless not being able to use Bootstrap or other frameworks requiring JS; while second, targeting editors or writers. Most news orgs do not have product UX contributors.

   3b. Trademark and licensing guide. Seriously, please do not get bogged-down in trademark and licensing stuff. That reflects developer and lawyer priorities, and the aesthetic particulars get lost when that happens—which most developers won't "see," because aesthetic particulars are not a developer spidey-sense trigger.

Context

David began a Brand Use Guidelines doc some time ago. The trademark lawyer consulted in that effort, suggested Spotify's BUG for developers.

Lawyers need to keep-out of the BUG, as it is created to suit the needs of designers and developers. Project managers, or team-of-one designers and developers will then reference the Trademark Policy guide, to ensure they're solutions that are tailored from a BUG, are compliant.

The Trademark Use guide, is what gets written by the lawyers to suit accountability needs; and lawyer author types should base it off the guidelines set-forth for creative needs, in the BUG. Spotify's BUG was also created to fulfill a very different set of both business and creative needs, and imho is total overkill for what SD needs. Mozilla's and EFF's, conversely, fulfill more of what I expect are SD's needs.

[ninavizz]

Of note for this project: In 2022, an updated design system was created for SecureDrop... effectively "baking-in" decisions made for the SDW over the preceding 3yrs, and decisions made in shaping the new SI design system.

Colors were reconciled between the QT client UIs and the web UIs, and the more muted CMYK-spectrum hues were depreciated in favor of brighter, higher-contrast and more digitally-native RGB values.

In the "SD Brand In Use" schpeel I put together, I somewhat conflated the 2019 created "Tee Shirt Palette," with the 2022 palette, in specifying desired color values for the SD lockups. Another challenge, is that all files downloadable from GitHub, today, are RGB; so when automatically converted to CMYK by vendor machines, they flatten and mute and look awful.

The artwork currently used in the Web UIs from 2018-2021, is shown in the top image, below. A version showing color-correct values of the 2019 palette, is shown in the lower-right. In the lower-left, is shown a version using the color-correct values for the 2022 palette. It's my hope that the one in the lower-left is used for 2.3.0, but the top one might remain.

In any event: for the Brand Use Guide, one version should get standardized to (duh), and new artwork created to align with it—including color-corrected CYMK conversions.

If help is sought with color correcting new CYMK files to match the RGB values, I'm happy to lend a hand there, as I did print design for many years before pivoting to UX. If not, a tip: you'll get the best results by experimenting with Photoshop's color ramps for conversions, and picking the closest one as a starting-point. Yes, use the proprietary BS software, as it has the patents to do the best job out the gate.