This is a write-up primarily geared toward providing guidelines for our internal content design considerations.
It should be clear that a project is a project of the Electronic Frontier Foundation, and include a link to eff.org. Why: Branding makes it clear who the developing team is. This is helpful for our fundraising efforts as a nonprofit, as users may not know that EFF is behind a free, open source product they like!
If you're a software developer working with EFF: our design team can help you! Please send a ticket!
If you're project managing a new resource at EFF, such as an activist campaign website: Please send a ticket!
If you're not at EFF but are wondering about whether you can include a logo: No need to send a ticket or open an issue. Please check our Trademark and Brand Usage policy page.
Presently, our design parameters for banner images are that they should span the entire width (100%) and are responsive.
- EFF branding, reiterating the name of the organization and a way to head to eff.org.
- Copyright policy.
- Privacy policy, as well as additional information if the given policy for that service differs. Consult with General Counsel.
- Social media sharing: we tend to include links to share content for Facebook and Twitter. You can ask the design team for assets on these social media icons. We've created versions that are circular and square that meet accessibility constraints. We may want to customize them to match the palette of the site or service, so please submit a ticket.
Say that you've downloaded software, like one of EFF's fine browser extensions. As a new user, you may need a tour of features! Here are the components to keep in mind.
- materials to get started
- if it's an onboarding flow: highlight the most important features of the tool, and keep it to 3-5 key features you'd like people to see.
- if it's a tutorial: clear, numbered steps are important.
- screenshots
Design will ask you to provide some initial text that a user should read upon landing on the guided tour. Consider the circumstances in which the user might be reading such text. For example:
- Has the user already downloaded the tool? Perhaps you could thank them for downloading it! A good example is the extension page for Privacy Badger, when you "take the tour".
- If the user hasn't already downloaded the tool, you'll need to give them further context around what system requirements are. A good example is Surveillance Self Defense's individual guides, such as How to: Use Signal for Android. Include the download location (where someone would access the download), system requirements, version used in the guide, license, and additional reading. If appropriate, include the estimated time it would take to follow the tutorial.
Design will help you come up with some general content and expected spacing. If you're able to provide drafted content yourself, even better! Remember, the goal is to: make it easy to understand, easy to use, and easy to get started.
As you write, keep in mind learning objectives. What do you hope someone can accomplish at the end of reading this content? For a primer to learning objectives, see our piece from the Security Education Companion.
These educational materials should be broken down into simple steps. Determine the base task that you're asking people to complete, then layer on top of it. Think of your favorite educational resources, intended for non-technical beginners: how do they explain things in a simple way? How do they demonstrate how to do the thing?
Go through the process of downloading the tool anew. Imagine you're a non-technical beginner and use the tool yourself. What are the steps you need to take to download the tool? Then, imagine you're teaching someone who has never seen this tool before, and has limited exposure to these concepts, how to do this. How does that affect your writing?
Find a reader (ideally someone who doesn't work on or adjacent to tech). Adjust your writing if your test reader seems confused by any of the steps. Consider involving design at this point, as the team can help structure the content, and provide a wireframe of what your text would look like in context.
Design will likely ask for it to be as simply written as possible. If it's intended for a general audience, please test your writing's readability with a tool like HemingwayApp and aim for a 5th grade reading level.
You'll be expected to go through the normal editorial process for EFF, including abiding by the style guide, as well as activism, tech and legal review.
You'll need to demonstrate how to follow along. Screenshots will need to include alt-text. If you're not sure how to write alt-text or how alt-text is used, check out this guide from WebAim.
For tutorials and on-boarding guides, we recommend pointing out key features of the tool. What feature is someone looking for? Is there a way that the feature is found (how is it labeled by the developer, and do each of these elements have alt-text themselves?).
Additionally, captions for these screenshots can be very helpful for providing context to the image someone is looking at.
Anytime the interfaces change substantially, you'll want to plan to take new screenshots (providing captioning and providing alt-text), as well as to change the copy.