Allied Media Consensual Technology

From DevSummit
Jump to navigation Jump to search

How the website project began and how we got into participatory design, what consentful technology means.

When we came on, this was a big project we inherited. There's been a desire to redesign it for a couple years. Current website is 7 years old, and it's not as accessible as they wanted it to be. A lot of info was buried, a page within a page. We wanted to talk about different accessibility needs and different language needs. We got feedback from participants, and learned a lot of people were having trouble finding info on the conference on our site. People told us things they wished it did - more robust story telling arm rather than a traditional photo and narrative blog.

Aspiration helped us through the RFP process and helped us find a vendor. We emphasize getting staff buy-in for everything.

We were lucky to have a major way to get feedback through the conference. When you're thinking about a new website, it's great to first ask what is working and what's not. We also wanted to accommodate different ways people like to give feedback. We sent out a web survey, and we tried to mix it up with open ended questions, scales (1-5, etc.), multiple choice, etc. Something that might have a more yes or no answer, you may want to only give those choices, whereas something with style or design, you might want a more open-ended question.

We also did online collaborative working sessions, getting a lot of users on a Zoom call and asking open-ended questions. We had both the really technical specific info and more open-ended info, and we used a collaborative Google doc during the Zoom call. Some people were taking notes in the doc while others were talking.

For people on staff, we did an in-person conversation with Aspiration calling in.

Q: How was your response for the online survey, and did you give incentives to fill it out?

A: We are very lucky that we have an active, vocal community so we did not need to incentivize it. We blasted it out on every channel we use. We didn't want to incentivize it, because we want the people who are actively on the site and really want to give us feedback. Incentivizing might have skewed it a bit to the people that don't care as much.

We brought in web designers to lead some meetings as well. They did wire frames and proposed data architecture and invited feedback to the proposals they were suggesting.

When we got closer to page designs, we could kind of react directly.

Q: How do you amplify voices that are not used to being amplified in this process? Were you collecting demographic info and centering marginalized communities in that analysis?

A: I think as far as demographic info, typical things like age we didn't collect. More so, it was understanding the type of user that we have, because we have so many different users, and so many different uses that bring people to the site. We have our conference, our sponsored projects, our speakers. So we were more focused on the user stories in terms of what people were trying to do with the site. We did run stack during the live meetings to try to make amplify the marginalized voices. On the Zoom calls, we also encouraged people who didn't want to type in the Google doc to speak aloud, but there wasn't really a competition for air time, since it was such a collaborative doc and anyone could add their info.

We were also working on a really fast timeline. We wrote an RFP in August, we hired someone in September, and we've been working on it ever since. December 15, we're going to release the conference website and open registrations for the 2020 conference.

We already have an inclusive community that has been deliberately planned. But for other organizations, you might need to be more deliberate with including people. We had primarily POC, queer, and trans folks involved.

[Name redacted]: I used to work for an org that did participatory stakeholder engagement, and we used to make sure the goals are determined by representatives of the different stakeholder groups, so that there isn't bias in the framing to start with.

Q: How did you balance the goals you were trying to achieve with the requests that others are asking for? Also what CMS are you using?

A: We are using WordPress. We had people self-identify the user types in the beginning, and then we were able to distill them down into similar users with similar journeys. We basically asked what kind of user are you, and what do you primarily use the website for? We then found all of the potential paths people might make through the website. We used those "user stories", took them to our project leads and said, does this satisfy what your knowledge is of how people are using the website? And we also find staff also uses the website in their own ways. And you as a staff member might have totally different uses than an outside users. So that's a big part too - just reserving the questions for a certain type of user.

Q: For your information architecture, how did that play a role in how it was organized?

A: There's a section on mission, programs, sponsored projects, AMC, speakers bureau, a tools and resources section. A lot of people told us, we would love for AMP's website to share more resources and tools for people using media. A lot of this stuff was there, but it was kind of impossible to find them. There's also the conventional stuff - about, contact - and we made a separate site for AMC as well.

This came out in the research, but it was not seen as an organizational priority, so it was something we really needed to fight for to get the tools and resources section on there. We had to show pie charts and defend this need on behalf of the outside stakeholders. Internally, it was assumed that was not something that needed its own section.

We can also talk about consentful technology here a bit - there's a zine call the Consentful Tech Zine - I think that's also their URL ( It talks about how we talk about consent with our physical bodies, and we should talk the same way about our data bodies. In this zine they say "Consent is easy as FRIES" which is an acronym.

F - Freely given - no pressure, manipulation, or force to participate. Things like "join our newsletter", if you don't give us your info, this will happen to you, etc.

R- Reversible

I - Informed - eg., if someone is going to enter a sexual relationship, and someone says, I'd prefer you to use protection, but the person secretly doesn't, that's not informed consent. In a website, this means that what you're signing up for shouldn't be buried in terms and conditions in a lot of jargon

E - Enthusiastic - it shouldn't be like, I have to contribute this data to access a necessary or attractive service you're offering.

S - Specific - just because you sign up for one thing, it doesn't mean you're signing up for everything else. Like, if you sign up to get updates on AMC, it doesn't mean you want updates on all our other programs.

With consent and participatory design in general, it isn't always an organizational priority. There's not a lot of research to justify why it's important and to say why it's something an org needs to spend money on. It's really hard to trie to be the traffic conductor on that, which is the role we ended up in. It's really easy to get really fried and burned out, working against deadlines and goals. Sometimes this process makes things more difficult, but it's really important to give all the stakeholders a voice internally. And make sure you take care of yourself! We're really big on fun and self-care, because otherwise it can get pretty stressful.

We want every single user to have power in some kind of way, but often the people cutting the checks or running the organization have more power and are able to veto a process like this.

Q: I was wondering how you use data and analytics in a consentful way. Because that data can be so useful - finding out what people are searching for.

A: I guess, we are interested in how people are using the site, but we aren't interested in who they are. So we are looking at switching to Matomo as our analytics program. We are going to set it to be opt in for the tracking, and even if you do opt in, it tracks your behavior on the site, but not any demographic info.

For our purposes, we use it more for large trends. We thought about only turning on tracking during certain "count weeks" and let people know in advance when we are tracking. The thing that's an issue, is we need to report the total users for funding reports.

And we should start thinking about pushing back against those kinds of funding requirements, but for the time being we're tracking the bare minimum we need to track. We actually asked leadership what the bare minimum is we need for funding requirements, and we didn't want to track anything we don't need.

Q: I'm very curious about what were your findings about accessibility?

A: Part of what I was describing about this FRIES stuff is visible. We've put this on the designer, to push her further to make fonts more readable, to make sure that you can't scroll past a check-in point without noticing, etc. In terms of visually, we took it to the designer. And the main thing is to make sure everything was text based so that web readers will work. With our user stories, we prioritized certain things, but there are other things on the back burner. When you start talking about things like translation to other languages, there are additional costs, you have to think about how to keep it up-to-date.

Q: Are you going to have a mobile site?

A: It's going to be responsive, not a separate mobile site.