Consumer Data Standards: Consent Flow
UX & CX design, research design, project management & leadership
Pen and paper
Facebook Ad Manager
A quick rundown of my work
I led the Consent Flow team, which was tasked with investigating core consent pathways for the Consumer Data Right, including consent flows for joint banking accounts and cross-sector consent.
Our design research focused on problems and solutions surrounding the giving of informed consent, including UI and UX improvements to an existing prototype. We worked to surface issues that potentially excluded vulnerable and underrepresented consumers while maximising transparency, accessibility, and user agency.
I determined the direction of our work, managed our team's workflow, and collaborated/communicated with the other team leads and our client's design lead. As the principal designer, I created the core prototypes and research session guides, then wrote up our findings and recommendations in the final research report.
What is consent?
For this project, we referred to the in-depth work done by Greater Than Experience on consent patterns, particularly their work on Data Trust By Design. We're also building on the GDPR's definition of consent, which requires consent to be:
- freely given
In addition, our consent flows needed to be transparent, accessible, credible, and trustworthy.
Project priorities and challenges
We were brought on to this project for phase 2 of the CX research; phase 1 had been completed several months prior. We studied the phase 1 reports and, together with the client, identified gaps in the previous research (mostly to do with accessibility and participant diversity) and set priorities for research questions: what questions were most important to explore? The fundamental question was: what does consent look like to people, especially to people who come from marginalised groups or disadvantaged backgrounds? What factors influenced the giving of consent, and how might we enable consent?
From the start of this project, it was clear that completing the work in time would be a major challenge: we had 8 weeks to conduct 2 rounds of user research (with a minimum of 10 participants per round), create and refine prototypes for each round, and finish up our deliverables, which included final prototypes and presentation-ready final reports. In addition, we had several major milestones to meet throughout those 8 weeks, which left us with very little room for delay.
The timeline demanded incredibly fast turnarounds, sometimes within 24 hours. To adapt to this, we simplified our processes to prioritise speed. I was solely responsible for design, which let me respond to new information and turn around drafts very quickly.
Iterating in response to new data
Each user research round ran over a week, with the week after reserved for revising prototypes and presenting them at an all-hands meeting towards the end of the week (usually on a Thursday or Friday). Because this didn't leave us a lot of time to do analysis, convert analyses to recommendations, then action the recommendations in our prototypes, we actually began working on prototype revisions while user research was ongoing. The drawbacks to this approach (we might start designing a component, then have to revert to an old design) were outweighed by how it allowed us to adapt to new information in a natural, near-seamless way.
For example, user feedback during the first round completely changed the complexion of one major component of the consent flows (joint account consent). Responding to this feedback early allowed us to build out several different versions of this component with enough lead time to trial a completely new version for the second user research round.
The Consumer Data Right is going to make an impact on all Australians, so it was crucial to consider the needs and usage patterns of all Australians. Having a set of participants that came close to representing the incredible diversity within the Australian population was very important to us.
What we were looking for
We wanted diversity across the whole spectrum of identities, including:
- sexual orientation
- age group
- location (state)
- location type (metro, rural/regional, etc)
- disability status
- ethnolinguistic identity, experience as an immigrant
- socioeconomic circumstances, experience of financial hardship
For people coming from traditionally underrepresented groups or with backgrounds of marginalisation, we didn't want "tokens" -- the one marginalised person for a certain identity, who would then bear the burden of being the sole representative of that identity. So we made a deliberate effort to recruit widely and to have (for example) several different experiences of disability represented within our group of participants.
How we recruited
As with all of our processes, we kept participant recruitment KISS-simple. We set up a simple screener survey to gather demographic data, including the characteristics listed above, and data about other characteristics like entrepreneurship experience, comfort levels with new technology, and joint ownership of utility or financial accounts. This screener survey was a Google Form that fed directly into a Google Sheet that had important characteristics highlighted, allowing us to quickly identify suitable research participants.
Advertising the screener survey was also kept simple: we ran Facebook ad campaigns targeted at certain demographics (mostly tech- and entrepreneur-adjacent characteristics) throughout Australia.
Our participant set ended up very diverse, with participants coming from all walks of life and experiences, living not only in metropolitan areas but in regional areas as well. We had a good mix of participants from states outside NSW and VIC, which addressed significant demographic gaps in the project. This allowed us to obtain data from perspectives that are often underrepresented in user research (especially within the tech and innovation space).
We built our prototypes by referring to the user flows that had been tested in phase 1 of the research project, as well as design frameworks provided to us by Data61. These frameworks were basically skeleton design systems with ready-made components for interactions surrounding consent, with an atomic design hierarchy, eg "I consent" buttons (atoms) embedded in an "I consent"/"I don't consent" module (molecules) which was in turn used for various design patterns (organisms).
I built the prototypes using Adobe XD, then exported them for use through the native Share functionality in Adobe XD. I also exported the graphic files to InVision and connected the screens and hotspots through the InVision web interface. The screens were first laid out as rough sketches on paper, then digitised into basic diagrams in Miro, then finally rendered as screens. We were less concerned with visual UI when making these prototypes, so their visual design is very bare-bones, just a little above wireframe level. Our priority was to ensure that all the crucial interactions and screens were in place so that the prototypes would act just like a "real" app would as a user progressed through the consent flow.
We conducted two rounds of research sessions, with prototypes being updated in between the rounds based on data from the first research session. These sessions were a mix of user testing and in-depth interviews with participants; I trained the UX researcher facilitating these sessions in how to go deeper when asking questions about our focus areas and priorities, and I also put together an in-depth discussion guide.
The discussion guide consisted of:
- a runsheet for the research session (1-2 hours), including detailed notes for each prototype screen
- guidelines for interaction with research participants, including additional questions and areas of focus for participants who had certain characteristics (eg experience of financial difficulty, held joint accounts)
- technical guidelines for running the research session and setting up prototypes, video recording equipment, etc
For the second research round, the client requested us to conduct face-to-face sessions with participants from a remote, small town. Our UX researcher traveled to Yeppoon, QLD and I managed her workflow and provided direction remotely.
Overall, I'm very satisfied that our research sessions surfaced new insights, especially surrounding issues faced by people with disabilities, people living in remote areas, people experiencing financial difficulty, and people belonging to marginalised identities. We shared these insights and our resulting recommendations with the other teams working on this project in between the research session rounds, so we could all benefit from new data when revising prototypes for the second round of research.
You can read more about our methodology, findings, and recommendations in the final research report which forms part of the July 2019 working draft of the Consumer Data Standards.
A particular focal point of our recommendations was building trust in safety, increasing accessibility and enabling user agency, particularly for users belonging to marginalised groups.
Our final deliverables also included polished prototypes of the three consent flows we tested, videos and transcripts of our research sessions, and detailed documentation about our research methodology and our participant demographic data.
My key takeaways
Flexibility, as always, is key. Especially for our research sessions, my team benefited from our KISS-simple, responsive approach.
We also benefited from both UI and UX design being done by one person (myself) since UX principles could be very quickly implemented in the UI. And these fast implementations mattered: for instance, a small change in a button significantly increased the trust level for some of our research sessions.
I'm very proud of the diversity of our research participants. Many of our research insights and recommendations couldn't have happened if we hadn't pushed hard to ensure we interviewed multiple disabled people, immigrants, queer and non-cis people, and people who had experienced financial hardship.
Consent is such a vital component of all our interactions and yet, given the ubiquity of tech that ignores privacy issues and the rights of people to control their own data, it's not easy to implement. Respecting and enabling consent is often not the default for technologies we use everyday. There is so much room for more research and analysis, particularly with scenarios involving joint accounts and the possibility for abuse of data rights within that context. I'm glad that our recommendations helped open the doors to that conversation even further.