[EPIC] Source UI Co-Branding

[ninavizz]

Problem

It's not clear when submitting to a SD instance, who a Source is submitting to. Too many "well, we're assuming they..." variables exist to reasonably invalidate that hypothesis.

Co-branding is a design problem. It's not rocket science, but it is always a design problem that vendors and service providers need to solve for, in B2B2C software ecosystems (what SecureDrop is). This is a known problem often solved for elegantly, in for-profit products.

As a maturing product, this design problem has not yet been solved for in a UX effort with SecureDrop. Existing solutions are piecemeal and out of step with established UX best practices. For Source users who often come into SD cold, yet most likely have their expectations shaped by a history with more polished for-profit software ecosystems, this is problematic.

Background & Flagged Issues To Date

In today's Source UI, the identification of an instance's host is not in any way governed or designed for. Most of the Source's Experience is based on expectations and assumption on the part of the training and development teams. None of it has been validated via UxR, and none of the assumptions that informed today's live solution(s) were informed by existing known best practices for B2B2C co-branding—which is not a familiar or common "problem" in the FOSS space. B2B is common in the FOSS space, but not B2B2C.

1. This concern was first raised by @heartsucker and Eileen from SimplySecure, here. It was discussed in 07Mar2019's UX Meeting with Eileen from SimplySecure as our guest.
2. Customizing the logo from the default SD ship-with logo is not identified in the Installer checklist when setting up an instance.
   • Noted as solution opportunity in SD Repo Issue #4619
3. There is no governance or guidance around how to customize the logo-img. Guidance, at a minimum, should be offered—and is a easy to put together.
   • Also cited in SD Repo Issue #4619
4. The instance-host org is not dynamically inserted into the Source UI, nor is there a place in the Admin UI for an org to identify themselves in such dynamic insertions.
   • Noted as solution opportunity in SD Repo Issue: —tbd, but it's there—
5. Landing Pages are not governed nor templatized, and only light best-practice suggestions from the training team are made—no actual info-architecture or design suggestions made. For many reasons, this is not good and goes against known B2B2C best practices.
   • Noted as solution opportunity in SD Repo Issue: —tbd, but Nina did explos in 2017—
   • Source Journey to be discussed/dissected in Sept Offsite... can address more, there.

Key Touchpoints

• Source UI
  • Logo-img
  • Footer
  • UI text, throughout the experience
  • Submission Confirmation Page
• Instance host landing pages
• Instance host "Contact Us" pages
• SD Directory

[ninavizz]

@eloquence See 2nd paragraph, above. Not sure if you properly saw this ticket when I filed it; but the second paragraph above, is the background on why the "service vs tool" bit from our convo earlier today about how newsrooms speak to their SecureDrops, is a priority to address in future RTD LP best practice additions.

[ninavizz]

Standards completed, yet to compose documentation to publish in RTD—which is being tracked in #79