4 min read

I2P For Application Developers: UX Considerations and User Testing Overview

I2P For Application Developers: UX Considerations and User Testing Overview

Provide Context for the Benefits of Your Application

If we are working within the scope of I2P, then describe the privacy features that your application provides. Describe the features that will protect your users, and match them to concise examples of threats.

UX: Create A Visual Workflow

Provide a clear relationship for users between the protections provided in the application and how they interact with the application. Consider visual cues that people look for to verify that something is working or safe. Ensure that the UX includes elements that counters configuration risks. Show your security in your UX.

Policy and Updates

Where is your source code? How do I build it from source? What is your licence? Do you handle data in your application? How is that handled? How will you disclose bugs? How do you handle software updates?

Troubleshooting

How can people communicate issues? Do you have a guide or FAQ? How can they uninstall the software?

Maintaining

Ensure that your application is properly documented for other developers and that your code and licences follow FOSS best practices. If you ever decide that you no longer want to maintain your work, someone else has the opportunity to take it on.

User Testing and Feedback

I often see posts " ready for testing!" and "please test". I am guilty of these call outs myself.

What are you testing for? Be specific, choose a task. If you can, host a session and walk people through the task.

In 2018, I received a small grant specifically for user testing for the core I2P Java software. For people who are familiar with the software, I can hear you scoffing already. The software offers so many options for configurations, assumed networking background or understanding, applications, and a glossary specific to peer to peer networks. Bandwidth testing? Firewalls? Hidden Service? Proxy/outproxy? Let's be real - these are not familiar terms. How about the idea that you are downloading a router and connecting to a network? Where to start!

Working with Ura Design , we came up with the following tasks and purposes:

Different browsers, operating systems and hardware were used.

The demographic of volunteers was varied.

A summary map of the findings was created.

Follow up questions were important to add context to the volunteers experience. What specifically did they find clear and what presented challenges? Did they feel like they wanted to use the software or did it intimidate them? Could they understand the guides and UX? Would they continue to use the software?

Choosing People to Build and Test Your Application

Consider your threat models and the different kinds of people who could use your application.

Are they familiar with privacy tools already? Are they new to navigating terms and concepts that some may be familiar with? Do they regularly use a privacy workflow ( ie Tor, PGP, Whonix, Thunderbird), or are they more casual and minimal. For instance, they might focus on messaging security so they use Signal, but do not use PGP or Tor. They use 2 Factor and rely on a browser and maybe a some add ons to provide context and protection for accessing sites only. What OS do they use?

In short, when we can, it is best to engage with as many people as possible to build and test our applications. Assumptions are not helpful to users. Giving them a voice is.

Asking For Help

Outreach messages are important. Recently the I2P MacOS maintainer left, and a new person has taken on the role. The first test build was created for Mac users.

I documented some of the ways that we could have asked for help more clearly for the future.

In the case of the Java software, there are 2 options for software: the older Java version and a new Java version. One has a separate Java install dependency for it to work, the new version has a bundled Java option that makes the download and install process much more efficient. In this case, we were looking for feedback on the bundled installer.

We are looking for people to help us verify that out new MacOS builds are going to work for the next release. The following tasks will help us ensure that the software is functioning. ( insert tasks). This will take about a half hour and anyone can participate.

Are you running MacOS version xxx or higher? We are looking for people to test the latest dmg for our Easy Installer for MacOS!

For existing I2P Participants:
Do you already have I2P installed?

Is it the full Java version or the Easy Install Version?

Include conditions for moving forward for either option.

Include instruction for how to preserve existing I2P, and uninstalling the new download.

For New New Participants:

Download the following binary and proceed through the installer and set up wizard to the I2P router console. ( Include some screenshots so that they can match terms to UX).

This is an example to demonstrate how providing context and expectation both engages and sets expectation for the volunteers. Having a specific repo or discussion hub for follow up questions provides a place to continue the conversation. It is also a place to reach out if you would like more feedback in the future.

Set Boundaries

Be specific about what your scope and goals are. This will allow you to reinforce what kinds of feedback is helpful and what is not.