Research Operations Community, ReOps+, published my article, Informed Consent: Vetting Research Software for Privacy, in the Research Operations’ Medium publication. I am a member of the ReOps+ board and they invited me to contribute this article, which discusses a study of several research platforms and how user experience researchers can be sure participants understand what is happening to their personal data. The information can help researchers protect their liability* and improve trust among your participants.
We’d like to be sure that the data about our research participants stays between us and the test participant, but are our participants fully aware of the data sharing agreements underlying their use of the testing tools? The confidentiality agreement they have with us is only part of the picture.
In this article, I’ll discuss how to ensure that your participants know how their data is collected and how it might be used or shared beyond the scope of the covered research product. I’ll focus on a mini audit of several user testing software packages that we performed based on the 10 attributes for respectful Me2B commitments that underlie the Internet Safety Lab’s ISL Safe Software Specification:
Clear data processing notice
Viable permission
Identification minimization
Data collection minimization
Private by default
Reasonable data use & sharing / Me2B deal in action
Data processing behavior complies with data subject’s permissions and preferences
“Me2B” is a flipping of the traditional shortcut, B2C or Business to Consumer, relationship and is designed to put the individual first.
“Me2T” is your relationship with the technology itself.
To understand the background let’s take a brief look at the data privacy legal landscape in the US. I’m not a lawyer, so this is really just a broad brush overview. Any legal questions should be discussed with your corporate counsel.
Data Governance
Participant data may be collected in a number of ways, such as entering numbers or text directly into forms, entering it into an account profile (if you have one) or via an aggregated profile obtained from third party data brokers. Behavioural data also may be collected from third parties or your own app use.
Those of us who collect, use and share data from our research participants are becoming subject to a greater and greater number of data protection laws. Each law has varying degrees of requirements, usually based on where the data subject lives, so you want to be sure to get your data governance policies right. And it’s fair to expect the same from usability software that collects and controls data from you and your participants.
Data Handling in Practice
Researchers collect and store data with a number of different tools that in turn use underlying technology that may also access this data. Knowing what entities might have access to data through the testing platform’s relationship with these underlying tools can help you to evaluate whether you are exposing your team or your participants to risks that come with these technologies. We like to call this the “Me2T” relationship and it is largely hidden from the user.
Lack of notice and consent to share data present significant risks.
Notice of data sharing and consent are key components of many of the data privacy laws that govern which data we can and cannot save, use or share. While the risk to the researcher is similar to those of the user testing platform, the platform also bears responsibility for ensuring that anyone participating in a test on their platform has an appropriate level of notification that the data is being collected and shared, and subsequently allow the participant control over whether they continue using it.
Data Safety Audit
Researchers collect and store data with a number of different research tools, and that creates that Me2T relationship between the individual and the technology. We created a mini audit based on our safety specification. It is not a scientific study, i.e., we didn’t do a randomised sample and it only reflects the software packages that either we use in our own research or those that we’ve documented from forums that we participate in. However, the results brought up some interesting questions. (As a note, these are all companies that I have used and am comfortable using).
Table 1: Data sharing by vendor
You’ll notice from this list that most of the software we looked at shares data with Google and other external vendors. One shared data with Facebook’s ad network and two shared with Amazon and Microsoft (including Microsoft Forms).
In Table 2, you can also see that just for these eight vendors, there are a few dozen companies or company assets that are receiving data. The ones in bold are advertising or tracking software, which often have agreements to sell the data they collect through data brokers. Many of these tools aren’t necessarily exploiting user data, but they are doorways to entities that now have some access to your participants’ data and your participants should know about that.
Table 2: Third party data vendors discovered in this study
Methodology
To do the analysis, we used a tool from Evidon called Trackermap that exposes tags that allow data sharing between entities. What you’re seeing below is a map of the underlying technologies that expose data from Google Forms and Microsoft Forms. Trackermap is a paid platform that is bundled with Evidon’s Tag Auditor product, but there are free tools, like Augustine Fou’s Page Xray, that maps server and data tracking requests.
Results
Trackermap scans for various requests by external sites. We were particularly interested in advertising (blue), analytics (red), and trackers (gold), as these are most likely to be integrated into a data broker network.
We started with Google Forms and Microsoft Forms because they are popular, free tools that don’t require a lot of expertise to set up. While we expected to see a lot of sharing within their own advertising networks, we only saw Microsoft sharing with Bing Ads. Google Forms did not share data with their advertising network.
Can the participants see this? Well, Google doesn’t require it, but researchers can add an additional description with information about the study and details for informed consent, if they choose to. Significantly, most of the form-based surveys that we reviewed didn’t actually do this.
A savvy user may see that Google has its own privacy policy at the bottom of the form. That’s one potential relationship, but the Google Forms survey we reviewed also indicated that there was another company involved, a panel recruiter called SurveySwap. This is another Me2T relationship. This means that there are a few third party technologies in play here (Google and the panel recruiter), but no reference to the consent practices for any of these underlying relationships other than Google’s privacy policy link. So maybe Google Forms doesn’t share much, but in this case, the participants in this survey are potentially exposed to data sharing by the panel company (see the Tracker Map results formSurveySwap below).
We ran a few other tests. The table below shows the number of trackers, ad networks and analytics packages for several products commonly used in user research.
Table 3: Ad networks, data trackers and analytics packages by vendor
Below are the tracker maps from live tests at the usability testing platforms that we examined, and you can see that these platforms share to both DoubleClick and Google Analytics:
The survey vendors we examined tended to have a smaller number of tracking vendors:
The third group that we looked at was panel recruiters, where we saw a lot of data sharing with entities like Facebook Ads, DoubleClick, Microsoft Marketing and Adobe Metrics:
…you should be asking yourself whether your participants are aware of these relationships and whether … [vendors] have access to the data they provide to you.
It’s important to note that panel recruiters create a relationship with the participant at the time when the participants create an account with the recruiter, usually before they sign up for your study. It’s not a relationship you control, and it is not likely that your research data is shared with the recruiter unless you use their platform to run the survey.
When you look at these results, you should be asking yourself whether your participants are aware of these relationships and whether they are aware that these entities might have access to the data they provide to you. We feel it’s a good idea to remind participants of any Me2T consent relationships that they have already entered into when they participate in your study.
What else can you do?
Product development is flawed. Often there is no consent at all when testing with potential users. What are some of the other things that you can do to ensure that you are fulfilling your role as a data collector?
Researchers should be advocating for informed consent, highlighting all of the potential recipients of the participant’s data, and referencing in the informed consent document any additional data policies underlying the usability, platform, software or panel recruitment programs that are in use. And you should make all of this part of your vendor selection process.
Software testing platforms should take a closer look at their data protection responsibilities and make a greater effort to inform participants and test creators of the data sharing policy, not just once, but every time they use your software.
…and if the 75 min read warning on LinkedIn scares you (it’s mostly charts anyway) jump to the intro and discussion to see what you really should be concerned about as digital makers. This is important information that every product designer and engineer should know.
Some interesting findings about product safety attitudes:
* When it comes to product safety, there’s a double standard among consumers for connected vs. unconnected products.
People expect product makers to be responsible for the safety of things like home goods, cars, cleaning products and the like. But they don’t have the same expectation when it comes to websites, Smart TVS and mobile apps.
* Many consumers appear unaware of the causal connection between personal and societal harms such as physical, emotional, reputational, and financial damage and the systemic loss of privacy tied to connected products and services.
Product consumers are subjecting themselves to more harms than they think when they trust digital product makers to take proper care of their personal information.
* Even though survey respondents didn’t score mobile apps as the “least safe” option—websites, smart automobiles and smart homes got that dubious honor—consumers expressed more concern about the safety of apps than the safety of other internet-connected products.
If you find that last point interesting, you will find Internet Safety Lab’s AppMicroscope educating. App Microscope displays Safety Labels for mobile applications. Currently, App Microscope contains over 1700 apps studied in the ISL 2022 K-12 EdTech safety benchmark.
In May, I was invited to speak at UX Lisbon, on Preventing Digital Harm in Online Spaces. At the main event, I presented the Internet Safety Lab’s framework for preventing digital harm in connected products. This included a discussion of the relationship technologies have with consumers. I demonstrated techniques designers should adopt to mitigate the digital harms and dark patterns that could potentially violate that relationship. You can download my presentation below.
On the first day of the event, I ran a half-day, pre-conference workshop titled “Designing Effective Search Strategies.” In this session, I introduced a new framework using observation as a powerful tool to understand site search behavior. To explore this, we broke into seven groups and worked on empathy maps, search personas and mapping the user journey. I also introduced including group personas (2 of the groups took as a hint to discover cocktail lounges in Lisbon). As a takeaway, all participants received a toolkit for crafting these artifacts and a step-by-step process to enhance product search. We got to eat yummy Portuguese snacks, too!
“Noreen … made the interesting point that if we build an accessible design we’ll also be solving many search problems.”
What a wonderful event, interesting and welcoming people and an absolutely unforgettable time!
I am available to teach your team preventing or mitigating digital harm. Or lead a workshop on how to understand user search behavior. I can lead workshops solo or with my colleagues at Information Architecture Gateway. Let me know if we can help.
In a session yesterday of the NSFCyberAmbassadors leadership training program, my breakout group were tasked with discussing a case study of a potential ethics violation in research data privacy. The Code of Conduct that we were to use to determine if a violation occurred was the Association for Computing Machinery’s (ACM).
The case study involved a research scientist who had made software to analyze three sets of participant data, including DNA records, medical records and social media posts. There was a problem with the program and the scientist wanted to be able to do a crowdsourced code review. They asked their ERB team to review whether they could release the codebase to the public to crowdsource the problem. The ERB approved the request as long as no participant data was also released or could be reidentified. The case expressed a statement that there was a risk of reidentifying data but didn’t say specifically how. Just that the request was approved.
My first impression was that the research scientist was hiding behind item 2.6 in the ACM Code of Conduct, which says to only do work within your area of competence. The way we read it, the researcher relied on the Ethics Review Board (ERB) to make the ethical determination. Since the ERB approved the study, was the researcher in the clear?
Conversation ensued about how a data analytics program that didn’t include test data could be tested, or whether it could be tested with dummy data and a sample of open social media posts/hashtags, etc. but that was actually aside from our real interest, which was the idea that technology developers, including those with less funding, but also those with fewer guardrails, may not be competent to or interested in make ethical decisions.
Someone brought up AI. People working in AI today or really any large, complex model affecting global populations, are often making decisions way outside of their area of competence. They may do well, in one or two disciplines, but understanding and unraveling the externalities of what the thing will do once it’s in the world is of lesser interest since they aren’t ethicists.
In fact, not all companies have ERBs and many big names, youknowwho, have quietly and unceremoniously disbanded their ethics teams. In a world of move fast and break things, it’s not their area of competence.
How do people locate and discover information online? Well, they type keywords into a search engine and then select items from the search results, right? This is the current mental model of how search/retrieval works for most users. But it’s not the only way people search, nor is it necessarily the most effective for the information seeker.
In this workshop, you will learn about ”Sense-making,” a search behavior that information architects, user experience (UX) and usability pros should not ignore. You will learn how individuals (and groups) plan and carry out search activities. How a searcher’s goals affect their sense-making tasks. And how accessible design and information architectures improve search performance. At the end, you you will understand how to optimize the user experience of your products and search engine results pages, so people get the information they need with less frustration.
Topics covered:
Approaches to sense-making & information seeking behavior
Searcher goals that affect sense-making tasks
How accessible design and information architecture improve search performance
Where & how to implement search-related sense-making in user personas/profiles & customer journeys
How to optimize individual search listings for findability & sense-making
Search strategies for apps, video, voice and ChatGPT
Exercises:
Individual and group search exercise
Analyze a selected web page for accessible design and search optimization
Incorporate search behavior characteristics into personas and JTBD
App, video and voice search optimization
Discussion of new and emerging forms of search experiences
Attendees will learn:
How to identify search behaviors and incorporate them in personas and JTBD tasks
How to architect & optimize different types of search experiences
How accessible design can improve search experiences for everyone
How search strategy differs for websites, apps, voice, video and emerging experiences
On May 5, 2022, I participated in the California Privacy Protection Agency’s (CPPA) stakeholder meeting, making a public statement about “dark patterns” which I urged them to redefine as “harmful patterns,” and suggested changes to their definitions of “Consent” and “Intentional Action.”
As Jared Spool says, we should be looking at the UX outcome of design decisions, not just the intent, as many designers adopt strategies or work with underlying technologies whose outcomes can be harmful to the technology user and other stakeholders. These UI patterns may not have the intent to do harm. Often the designers’ intent is to provide convenience or a useful service.
Take accessibility overlays that intend to provide a better experience for people with visual or cognitive disabilities but have the effect of overriding necessary controls. Even patterns that affect user behavior, like staying on a page longer, clicking on a link, accepting default cookie settings, etc. may be intended to provide convenience to users, but unknowingly to both the designer and the user, there are processes underlying many of these tools that share data and information about the transaction that can be harmful.
CPRA is defining what it means to consent to data collection and what an intentional user action is. It addresses “dark patterns” as an intentional deception, when often the digital harm is not intentional, yet is deep-rooted. We are hoping to make these harms clearer and provide guidelines for addressing them through our ISL Safe Software Specification.
Read more about the CPPA stakeholder meeting and my statement on behalf of the Internet Safety Labs (formerly the Me2B Alliance):