wiki:doc/UX/SupportPage

This page is to document the design of support.torproject.org


Research

This summarizes what we did for the support page with respect to the research phase of the project.

Audience: first-time Tor users, relay operators, Tor users with issues

Purpose: help install Tor Browser, resolve common questions, troubleshoot common errors

Content:

  • Overview of products*
    • Tor browser vs onion browser vs orbot/orfox
    • Other products that use tor that we know of
  • how to install tor*
    • Instructions for each OS
    • How to resolve common tor browser use errors
  • Support FAQs*
  • Get tor
  • Tor Browser manual
  • Tor glossary
  • Tor relay operator support
  • Tor onion service operator support
  • Trademark FAQ
  • Abuse FAQ
  • Legal FAQ

Note: We have a lot of existing material that we can leverage, such as Tor documentation, tor stack overflow material, information on trac tickets and wiki pages, and more. We need to decide what is helpful to users to see and not to see; sending them down a rabbit hole is not a good idea, and we should only use what is critically useful to them.

Choosing a support page model

We look at three support pages which target different users, involve the community in different levels, and require different amounts of maintenance.

Model 1: targets general users, no community involvement, high-maintenance

Twitter (https://support.twitter.com/): although this is a fair amount of work and we'd need to do it all ourselves, but this page is to help the average twitter users with the most common questions. All of the answers are short, clean official, and asks for user feedback if it was useful. They also use search results to generate new answers. (we decided to go with this model for our design).

Observations: has the ability to search, has the most common questions near the search bar, has topics for questions below, short, accessible, and helpful answers, rating system for answers (if it was/was not helpful), does not give users contact to support directly, have community input, or redirect to any other place, High maintenance

Model 2: targets software implementation and volunteer developers, minimal community involvement, medium-maintenance

Stripe (https://support.stripe.com/): this mixes official answers with links to documentation, which can be dizzying. The site is also a bit confusing, because there is a lot of information, but the key takeaway is that the support page is for the community that contributes to Stripe, rather than the end users of stripe. This is a model that support.tpo can follow (but we decided not to; see below in design decisions section).

Observations: has the ability to search, has topics below, simple layout that doesn’t require scrolling or much reading , redirects users to the support email or irc channel, official answers from the company (i.e. this), suggests related questions when they view a question, their official answers link to documentation (i.e. this).

Model 3: doesn't really target any user, community based answers only, low-maintenance

Mozilla (https://support.mozilla.org): although this would allow the broader community to answer questions that users might have and really takes pressure off the support team, this model requires users to be proactive in asking questions, waiting for answers, and they might not get what they need. (for quality control and user empathy reasons, we decided not to go with this model).

Observations: has support by product rather than by topic, has different languages of support, completely community-based questions with the contributors (i.e. this), encourages people to contribute to answers with a ranking system for contributors, quality of the answers vary dramatically, can have inaccurate information

Additional support pages:

  • Betterment: I like the layout a LOT! The search bar front and center, and a column for topics, popular questions, and contact. Their answers are all official and there are a lot of answers that are aimed to educate the user, not just troubleshoot.
  • Wordpress: the support page itself is bleh, but I like how integrated it is into the main wordpress site. I think tor support should be integrated like this.
  • Craft CMS: good mix of community and official; another example of how to leverage the community.
  • Intercom: I reallllly don’t like it, and it’s a product page rather than a support page--but it places a huge emphasis on educating users, which is something we may want to consider.

Pre-emtive design work

We have decided on:

  • using JS; we need it for search anyway, so let's use it to make other things easier too
  • simple design, since it will be a subpage of torproject.org
  • showing curated, high-quality, from-Tor answers that user can search through
  • targeting the page primarily to the new tor user
  • highlighting the answers to the most frequent issues (clock issues, AV issues, verification issues, VPN issues, proxy+tor issues)
  • allowing for "was this helpful? yes/no" feedback at the end of each answer for feedback
  • including screenshots when possible, using what's already in tor-documentation
  • no community answers; we will link to documentation, stack overflow, and irc channels but not host community answers directly
  • sort answers by popularity at first, then if a product is picked, by sort those answers by popularity.

.

You'll notice that the design of this page is quite simple, and we've aimed for simplicity. A key aspect of this design is that the support page, does not have any subpages. The topics on the left and the search bar above filter the questions in the main section, and the answers link to external sources, but that's it. We plan to have the support page as a subpage for torproject.org, and we want to avoid having subsubsubpages and subsubsubsubpages.

The layout of the website mimic's Betterment's support page, but added key features from Twitter's support page (such as the feedback mechanism for rating answers). We decided that question suggestions under the search bar and the boxes for different topics of questions were redundant if there was a column for question topics in the main part of the page.

This mockup shows the layout of the page more clearly. None of the text on the mockup is final, and is only there for illustrative purposes. No alterations to the layout were made since the sketches.

We do plan to use javascript to enable certain features--autocompleting questions when typing into the search bar, having questions be expandable and collapsable, and to make the website look cool. BUT we will ensure that nothing will break without javascript--the search bar won't autocomplete, the answers to questions will all be expanded by default, and the cool styling won't be as cool, but the functionality will remain intact.

Misc

Brain dump of things we don't want to forget.

Last modified 5 months ago Last modified on Aug 17, 2017, 9:27:43 PM

Attachments (2)

Download all attachments as: .zip