UX Case Study - Psiphon iOS Browser
This case study is expanded upon periodically
Introduction
Overview
Psiphon is a free and open source censorship-circumvention tool for Windows and Android, which provides open access to the Internet for millions of users around the world with a special focus on serving users in countries with a poor record of securing freedom of expression and access to information.
Challenge
The team at Psiphon partnered up with ASL19’s arabic outreach team to help them develop an iOS Psiphon Browser from scratch that would be geared towards arabic-speaking users and Iranians suffering from Internet shut-downs and internet filtering. For this project, we set out to develop the first iOS version of Psiphon and offer support for iOS 10 and iOS11 devices (iPhone SE to iPhone 8Plus, as well as iPad Pro 9.7 and iPad Pro 12.9).
Role
UX Designer, Researcher, Arabic outreach
Timeline
15 weeks
Team
A UX team of one, with the punctual help of my colleague A., an Arabic outreach expert.
Approach & Techniques
- Value proposition mapping
- Requirements gathering
- Stakeholders interview
- Task Analysis
- Journey mapping
- User stories
- Personas
- Competitive and comparative analysis
- Info architecture / card sort
- Feature prioritization
- Interactive prototype testing
- In-person usability study / over the shoulder user interviews
- Remote usability studies
- Accessibility evaluation
- Heuristic evaluation
- Analytics review
- Design Language System
Took Kit
- Adobe XD
- Invision
- Balsamiq
- UserTesting
- UsabilityHub
- Google Analytics
- Google Forms
- Adobe Illustrator
The Process
1. Product Definition
- Quick overview / briefing
- Stakeholder interviews
- Context research
- Requirements gathering
- Kick-off meeting (which leads us into the next phase)
Deliverables
- Design brief (living document)
2. Research: Discovery
- Data gathering: from previous studies (about internet shutdowns in the target countries, previously gathered data sets, arabic emails sent to the feedback inbox, arabic comments on social media, arabic content about psiphon)
- Surveys
- In-depth interviews with the development and outreach teams to gather their experience working directly with our users.
- Competitive and comparative analysis
3. Analysis: Exploration
- Task analysis
- Persona building
- Journey line mapping
- User stories
- Info architecture / card sort
- Feature prioritization
Deliverables
- Presentation of findings to key stakeholders, including the dev team.
- Refined requirement list and prioritized list of features
4. Design
- Sketching
- Design brief
- Wireframes (iterative, in conversation with the Psiphon team)
- Interactive prototype
Deliverables
- Wireframes (iterative, reviewed with the development team)
- Interactive high-fidelity prototype
- Design specification, assets handed over to dev team
Validation
Pre-launch:
- In-person usability study / over the shoulder user interviews
- Remote usability studies
- Accessibility evaluation
- Heuristic evaluation
Post-launch:
- Analytics
- Feedback forms
- In-person user interviews at Internet Freedom Festival 2017.
Deliverables
- Usability reports (pre-launch + post-launch conclusions)
Let’s take a look at the process we established to tackle the project at hand.
1. Product Definition Phase
During the first phase, I focused on the various contexts that have brought this project into existence.
We started off with a meeting with the project manager who quickly briefed A. and me on the project Psiphon wanted to develop and with which they required our assistance.
Then, we went off to meet the Psiphon team at their offices. I interviewed the key stakeholders including the founders of Psiphon Inc and key members of their development and operations teams to gather insights about business and development goals.
I then focused on the internal and socio-political contexts that called for a solution like the Psiphon iOS Browser. I first tried to understand why a browser version of Psiphon, specifically, and why not a fully-fledged iOS version of the proxy ?
Why an iOS Browser?Psiphon has already existed as a standalone application for Windows and for Android for many years and offers proxy and VPN-like features that tunnels all device traffic through the Psiphon network. That means that once Psiphon is running in the background, any connection to the internet coming from the device is secured by Psiphon’s system. Unfortunately, at the time of the project, despite a pressing need for an iOS version and because of specific limitations in the iOS SDK that were not scheduled to be updated before 2018, it was impossible to develop an iOS version that mimicked the exact functionalities of its Android counterpart. An efficient work-around however, was to develop a browser whose traffic is protected by Psiphon. While any other traffic coming from the device’s other applications would not be protected, at least filtered and censored information could be reached through the Psiphon iOS Browser on iOS devices.
Socio-Political ContextAfter some preliminary research, A. and I determined that the reasons for which the internet was most likely to be censored in arabic-speaking countries were:
- Preventing cheating amongst highschool and college students during national exams.
- Controlling dissent and dismantling protests
- Filtering political information - filtered topics varied depending on geopolitical conflicts in the region and on the entity doing the filtering (e.g.: Saudi Arabia filtered general critiques of the SA Saud Dynasty, but also censored information about Iran, Hezbollah, etc…)
We organized a kick-off meeting with the project manager, the developer team, the operations team and the executives so we could present our plan for the next 15 weeks and have it approved by all stakeholders. To make sure we were all on the same page, I presented a design brief to keep track of deliverables, timelines, process, etc. I also prepared a value proposition map to make sure we all agreed on the pain points we were trying to solve, and the features the browser would have, we populated it further throughout the meeting. Finally, I presented a preliminary list of functional requirements that the development team edited and approved, and a list of our 3 main goals for the project.
Once the kick-off meeting was over, we were ready to get rolling!
Our goals in developing this application were three-fold:
- Make a version of Psiphon available to iOS users for the first time, addressing a need that had become pressing.
- Launch the application prior to the 2017 Iranian presidential elections, in anticipation of a surge in censorship attempts in Iran.
- Expand Psiphon’s reach to users in arabic-speaking countries, especially those most at risk of Internet shut-downs and government censorship. To that end, during this first phase of the project, my colleague A. and I determined it would be best to focus on researching and reaching audiences in Tunisia, Syria, Yemen, Saudi-Arabia, Lebanon, Iraq, UAE, Egypt, and Jordan as well as growing and strengthening Psiphon’s existing user base in Iran.
I gathered the following list of functional requirements that we approved together:
- Clear, informative and engaging onboarding
- Safari-style web browser interface and functions, must feel very intuitive and native.
- Search function
- Ability to save and manage bookmarks
- Ability to manage tabs
- Online / Offline / Connecting proxy status indicator: Psiphon must communicate to the user what the connection status is at all times.
- Ability to choose a server region and change it as needed
- Front page automatically set to Psiphon-Today, a Psiphon-run newsite
- Settings
- Ability to set the language of the application
- Ability to select a default search engine
- Ability to turn on and off in-app notifications
- Ability to disable connection timeouts especially for regions where connectivity is poor.
- Ability to configure an upstream proxy
- Ability to configure HTTP headers
- Ability to configure various security and privacy settings (We will need to define this requirement more granularly later on)
- Feedback form: Ability to submit a feedback form to the Psiphon support inbox at any time.
- Ability to submit a troubleshooting report and data analytics report if the user wishes
- FAQ: The system must allow the user to browse through an FAQ collection regardless of Psiphon’s connection status (online, offline, connecting).
- Terms of Use and Privacy Policy available offline
- Premium subscription: The system must allow the user to purchase a premium subscription if they so choose. The premium subscription will remove ads or improve speed. This requirement will have to be discussed further later in the management and operations teams are not sure whether a subscription model will be an effective funding solution or not yet. We will take this financing issue into account in our UX research as we learn to understand our users and their needs.
Challenges
This project posed a very interesting set of multifaceted challenges, some of which shaped our entire approach to research and design.
1. Inclusive design et testing within a sensitive context
First, it was fundamental to acknowledge that while my colleague A. and I are both from the countries for which we were designing and have lived most of our lives there, we were building Psiphon from the comfort of our offices in Canada, where internet filtering and Internet shutdowns are not a reality. We also had to acknowledge that Psiphon is an application built in Canada by a group of Canadian academics and software developers who are men in the same age bracket.
This meant that to be truly user-centric and mindful of inclusivity in design, which was the philosophy at the heart of my process, I needed to include the user in our design and process as much as possible. However, since Psiphon was banned in some of the countries we were targeting and aroused suspicion in the others, I had to take into account this sensitive context.
So before I could ask “What do we test?” and “What do the results tell us?”, I had to ask if it was possible to test with real users for this initial launch, and if it were, then the question became how to find target users who could test the designs without putting them at risk. Because we were developing an iOS application, it was not convenient to securely send an image of the application to a small trusted group of users, since 1) it may not be safe enough in some cases, 2) testers would have to pay for a developer account with Apple before they could install the prototype, and 3) testing would be skewed because we would then only target very tech-savvy users and their entourage.
We could test remotely with interactive online prototypes some basic user flows, but we were more eager to learn about the user experience in-situ, i.e. within the context of throttled internet speeds, frequently dropped connections, etc.
Once the first version of the application was ready, I opted to do over-the-shoulder interviews with target users from the region who were currently visiting or living in Canada but still had strong ties to the middle east.
In the earlier phases of the research, I opted for surveys, gathering as much data as possible from analytics, previous studies, arabic feedback Psiphon had received to their support email but had not been able to read. I also interviewed members of the operations and content creation teams to gather their observations and second-hand accounts of user needs and user behaviors.
2. Bridging cultures - cross-cultural design thinking
3. Building trust with MENA users
By monitoring Arabic social media comments about Psiphon, I learned that many users in the Middle East and in North Africa were suspicious of Psiphon because the organization had received funding from the US State Department and various other US-based sources. The organization and the technology it developed was perceived by a large portion of the non-civil society MENA demographic as an agent of counter-intelligence masquerading as an Internet Freedom organism.
It was clear that in order to reach users in the region, Psiphon had to build trust with its potential user base and adopt a policy of transparency. I therefore advocated for further transparency in Psiphon’s communications with their user base. I also noted that it would be helpful to communicate more clearly who is behind Psiphon, to humanize the team and the organization. It would also be helpful to explain in accessible terms the philosophy of open source projects, a concept that may not be widespread nor well understood in some of the cultures we were targeting.
As a first solution, we opted to create an FAQ and information page that explained Psiphon’s data policy in detail and in simplified terms. We also recommended the creation of a page about the open source nature of Psiphon and what that meant in terms of safety, funding, etc. Even though this may not have been a complete solution, it was a step in the right direction. The FAQ page was accessible directly from the app. I also included an About section in the app that demystified Psiphon’s team and internal functioning.