Draft 1.0.0 brand guidelines doc for updating instance & LP logo images

[ninavizz]

This issue w/in Epic #74

---

Problem

1. When the 1.0.0 release of SD goes live, the updated branding and UI will make all SecureDrop graphics on newsroom landing pages obsolete. This includes any co-branding, and all screenshots. This is a video audit of today's landing pages, as listed in the SD directory.
2. Likewise, all co-branded instances will carry outdated SecureDrop logo assets in their logo-img.
3. Until the instance owner's name can be built into the Admin UI to dynamically populate within each instance's Source UI, the logo image is also the only way for sources to be reminded of who they're submitting to—which is important. Consumer culture has trained us to be navigated by visual impressions and semiotics, more than by agentive decisions informed by having consumed, processed, and retained knowledge presented in writing. This makes the co-branding schtick important to get right, throughout the source journey.

Tangentially, the usability of today's landing pages is pretty all-over-the-place. It is most likely that lone-soldier IT folks are simply doing their best. That said, we could still offer them better guidance, as a longer-term concern.

Solution

As noted in this issue in the SD repo, draft a brief PDF to send to newsrooms in Redmine. 2-3 versions of a salutation letter are being drafted to address unique edge-case concerns.

Longer term, the instance logo and landing page branding guidelines will need to get baked into RTD, along with more general design guidance for how to structure usable and credible landing pages. Within such an endeavor, re-framing how the phase of an installation shifts from "get it going" to lifecycle things, should also be considered.

Objectives

• Optimize for lone-soldier IT folks
• Don't compete with technical upgrade needs happening in parallel, that the same person will also need to be making time for.
• No more co-branding in the logo image after the 1.0 footer goes live (woo!)
• Provide options for orgs to better identify themselves to sources through, that lack quality artwork resources.
• Speak to source user needs in being reminded about who they're submitting to; especially when a source may submit to multiple SD instances. This is why co-branding matters, it's not design polish for its own sake.
• Keep the PDF brief, not overwhelming, and clearly actionable.

[eloquence]

IMO the first priority is to create a one or two-pager PDF that covers both:

• Advice to not use the SecureDrop logo in the Source UI (thanks, new SecureDrop footer!)
• Request to use updated version of the logo on landing pages, if logo use on the landing page is desired -- and some guidelines/examples for doing so

My main goal is to make sure we can get that PDF out to news organizations by mid-August or so, to actually give folks sufficient notice, so I want to keep this as simple as possible without worrying too much about how the current docs are (dis-)organized. We can then separately scope out more carefully structured updates to docs.securedrop.org.

[ninavizz]

Ok, I updated the first comment to more clearly reflect this project's objectives, per our meeting earlier today.

• The latest PDF draft, with small tweaks made after our meeting.
• This is the GDoc where edits may be made to the text.

14 Aug Meeting Notes

Nina, Erik, Jen, Ro, Kev, attending

• Corporate tone/feel
  • Jen/Kev concerned "tone" is too corporate/dictatorial; lacks optional-ness/softness of open-source governance. Jen speaks to carefulness to always/only use term "recommend," even when the most dire of security caveats are being cited.
  • Nina defends, citing standards in branding/design... and agreeing that "corporate-y" sucks, but that clear direction is important.
    • I forgot to cite: the objective with all the branding stuff is cognitive factors wrt clearly communicating concepts of "ownership" and accountability to sources (who owns and is accountable for what in the co-branded relationship)—assuming that many will not read things like the Privacy Policy , or carefully read much of the wealth of text offered to them. It's a known user pattern that most users just don't take the time to read instructional text; and known human factors wrt how anxiety impacts behavior, make it less likely that they will if submitting in anxious circumstances. Which is not to say that I affirmatively believe users will not read things; only, that I don't believe we're doing right by sources to make un-natural behavior on their part, a dependency. Entity relationships and "who owns/does what" are important to end users w/ data-sensitive B2B2C things, which SecureDrop is. In addition to being FOSS. I don't want to penalize source users, just because consumer culture has trained us all to be lazy. Hence, the desire to take a stronger hand in co-branding stuff, than SD has historically taken with dev matters.</lecture>
    • Really not dropping the B2B2C and co-branding terms to sound like a tool. I cringe when I hear those terms, too. They're just the best language I know of, to accurately describe the entity relationships and how users think about them. My own priority in all of this, is truly the users (sources first, journalists second, admins third).
  • Erik feels that a more affirmative tone than SD has historically embraced in documentation is preferred, and that it's a careful line to walk. Cites Mozilla as a good resource to look to wrt striking the balance between how to craft standards parallel to professional design standards, but without the paternalistic necktie tone.
    • Specifically, "Do" and "Don't" are ok, but "Never do 'x'" and "Always do 'y'" are too much.
  • How to be clearly directive without being dictatorial. Creeper vibes matter.
• LP Design Reccs
  • Kev: Technical limitations for the LPs are likely why many are so sparse. This feels like you're encouraging them to use the CMS? Also, what if a Source wants to print something to take with them to a cafe or library—might this discouraged approach be endeavored to meet that need?
  • Nina: The print-to-read use case is not the primary use-case, and "visual language" can be accomplished without all the fancy/dynamic code-y things. Will note to clarify writing to speak to that. The primary use-case is that a source clicks on a link from the website, and goes to a page that feels strange to them; the logo is used, but not the branding. Which is how consumer culture has trained us to measure trust and credibility factors. Also, absent hierarchies make the "Wall of text" overwhelming, which is a barrier to entry.
  • (General discussion around design principles of landing pages, ensues)
• Priorities... ??
  • Lots of techy things need to be paid mind to with 1.0.0, not just this stuff.
  • Usability and re-design of landing pages seems to also be getting asked. That's a lot, maybe too much.
  • Content needs a lot of trimming & focus
• Next Steps
  • Ro, Kev, Erik, to spend time Thurs/Fri making edits and notes in the GDoc
  • Nina to then pick-up on Monday

^^ @redshiftzero @rocodes @zenmonkeykstop @eloquence FYI!! Let me know if I should add or edit anything in the notes, above.

[huertanix]

I took a look at the PDF draft. tbh it feels a bit long. There's some clear examples of what to do / what not to do, but the answers to "so what do I need to do" seem kind of scattered around the doc, which I worry might be too much for a lone-soldier IT person.

[ninavizz]

@huertanix Thank you for taking the time to review and provide feedback, David!

Yeah, it's been a little awkward for me not doing this in tandem with more bigger-picture RTF updates... cuz there's so much to document & step through.

Erik has been really good about continuing to impose his focus-machete on this... "Logo updates, Nina, Logo updates!" and your comment coming from the perspective of someone who's done branding work in their past life as a designer, is validating.

The observation wrt scatterd-ness is a good one, and I'll especially be mindful to reign that in when I get back to this next week. :)

[ninavizz]

Good analogous documentation...

https://mozilla.design/firefox/personality/ (soooooo pretty!)
https://mozilla.design/firefox/logos-usage/

https://www.mozilla.org/en-US/foundation/trademarks/policy/