Today, let’s talk a little bit about mental health. Hooray! Specifically, the many ways brains process information. I know it’s maybe not what you’re expecting in these, but I think it’s an important component of what we think about when we’re making design decisions, and I don’t want it to go left unsaid as the content design-related posts pile up around here.
It should be obvious, but I’ll start with this anyway: I’m not a doctor. So, any of the suggestions I have here are based on my work and life experience only. Your mileage (and mind) may vary. But even as I type that half-joke caveat, I think we’ve already unearthed the gem at the center of why I think this post is important. Everyone consumes and creates knowledge and ideas differently. Those could be slight differences, like thinking you’re talking about either a flipper or a turner or a scraper when someone mentions the word “spatula”. Or, there could be large gaps in understanding for people who are better at processing audio information versus written.
These are just a couple of examples, but they both speak to why we need to build our experiences for a spectrum of understanding. This includes making good decisions around taxonomies and metadata, but it also means that we need to make all of our components accessible at launch, not an afterthought to add into the v2 iteration. Additionally, we should be attracting and retaining team members who either have these considerations top-of-mind, or are at least willing to learn why they are so important.
Let’s dig a little deeper on those last two points, though, starting with accessibility. I hope everyone knows about the curb cut example, but I can summarize it quickly, if not: Initially thought to help people using wheelchairs to navigate their environments by removing barriers to crossing intersections, installing curb cuts was also helpful for people pushing strollers, delivery people hauling large loads on hand trucks, and even for people with mobility issues where stepping up or down was difficult or dangerous for them. So when we build accessibility into our products and services, we don’t know how widely those benefits will reach.
When Kat Holmes spoke to our team at Twitter, she shared a concept which has stuck with me to this day. What I took away from part of the talk was that we’re all potentially temporarily abled. We don’t know what each day can bring, but we should build for the broadest possible accessibility rather than limiting our ideas to what we consider the “norm” (I’ll talk about that naming more in a bit). Think of it this way: You may have full mobility and strength in both your arms and hands. One day, though, you might need to navigate a mobile site from your phone while holding a bag of groceries, or a child, or with one arm in a cast. We need to account for these temporary scenarios when creating items like navigation menus and thinking about button placement, as just two examples.
Now, let’s talk about our teams, and how we’re defining them and our own users. First, I want us, as an industry, to move away from the idea of a “normal” user. What even is that? Have you met anyone normal recently? I know that, at the very least, the last two-plus years have made that term basically meaningless for me. Instead, let’s talk about our users’ needs, and then frame those using a more mathematically based term, median. What do the most number of our users need? And then, how far to each side of that cluster are we building? Defining these edges becomes important because we are actively deciding not just who we are including, but also who we are willing to exclude. To quote Eric Myer, who was paraphrasing Evan Henſleigh, “When you call something an edge case, you’re really just defining the limits of what you care about.” Defining our target audience is also a de facto exercise in letting people know who we’re not building for. This is where building strongly opinionated teams comes in.
I am purposefully avoiding saying “diverse” teams. Diverse teams can still fall into a group-think mindset. And I don’t think that building teams based on physical characteristics alone is the way to go either; the definition of diversity doesn‘t start and end in the mirror. Yes, those physical factors are important, but what’s more important to me is what lived experiences these people can bring to your discussions. No doubt that how people present and how they are perceived have shaped those experiences, so they are a major factor in the perspective they can contribute. But we also need to keep in mind that no one person from a marginalized group, for instance, should be placed in a situation where they are having to explain and educate the rest of the team on what it’s like to be part of that group. That burden of education is not for them. It’s for you, and your entire team. Do the research! It’s not like all intersections show up as visual cues, either. Looking at me, for instance, you’d have no idea about the alphabet soup of acronyms and abbreviations that my brain has been saddled with. But am I supposed to be the spokesperson for everyone with an OCD diagnosis, for instance? Hell no! But I can say, “Hey, have we considered how this decision will affect people living with XYZ?” Whether you have that condition or not, we need to build teams that are fluent enough with the diverse needs of our users to ask these questions, whether or not we have team members who identify with them.
Let me be clear, though: Building more diverse teams will let you build better products. Period. The more accessible your products are, the more people who can use them. Isn’t that the point? To get as many people as possible through your onboarding flow and into the thing you’ve spent so much time, energy, and resources creating? Ideally to solve one of their problems? Every time you push to make something more accessible and as open as possible, you’re increasing the number of customers potentially available to you. And you can do that by prioritizing their needs, understanding how to expand the definition of your target audience, and putting together teams who know what questions to ask and how to advocate for everyone, everywhere. This can be as simple as having your team ask things like, “How will this work for low-vision users?” or “Is our language as inclusive as it could be?” or “Will this feature work as well for people in low-bandwidth situations?” or even “Who are we potentially harming if we launch this?” The broader the perspectives are on the teams asking and answering these questions, the better your products will be.
Face Pollution
23 February 2023
Today, let’s talk a little bit about mental health. Hooray! Specifically, the many ways brains process information. I know it’s maybe not what you’re expecting in these, but I think it’s an important component of what we think about when we’re making design decisions, and I don’t want it to go left unsaid as the content design-related posts pile up around here.
It should be obvious, but I’ll start with this anyway: I’m not a doctor. So, any of the suggestions I have here are based on my work and life experience only. Your mileage (and mind) may vary. But even as I type that half-joke caveat, I think we’ve already unearthed the gem at the center of why I think this post is important. Everyone consumes and creates knowledge and ideas differently. Those could be slight differences, like thinking you’re talking about either a flipper or a turner or a scraper when someone mentions the word “spatula”. Or, there could be large gaps in understanding for people who are better at processing audio information versus written.
These are just a couple of examples, but they both speak to why we need to build our experiences for a spectrum of understanding. This includes making good decisions around taxonomies and metadata, but it also means that we need to make all of our components accessible at launch, not an afterthought to add into the v2 iteration. Additionally, we should be attracting and retaining team members who either have these considerations top-of-mind, or are at least willing to learn why they are so important.
Let’s dig a little deeper on those last two points, though, starting with accessibility. I hope everyone knows about the curb cut example, but I can summarize it quickly, if not: Initially thought to help people using wheelchairs to navigate their environments by removing barriers to crossing intersections, installing curb cuts was also helpful for people pushing strollers, delivery people hauling large loads on hand trucks, and even for people with mobility issues where stepping up or down was difficult or dangerous for them. So when we build accessibility into our products and services, we don’t know how widely those benefits will reach.
When Kat Holmes spoke to our team at Twitter, she shared a concept which has stuck with me to this day. What I took away from part of the talk was that we’re all potentially temporarily abled. We don’t know what each day can bring, but we should build for the broadest possible accessibility rather than limiting our ideas to what we consider the “norm” (I’ll talk about that naming more in a bit). Think of it this way: You may have full mobility and strength in both your arms and hands. One day, though, you might need to navigate a mobile site from your phone while holding a bag of groceries, or a child, or with one arm in a cast. We need to account for these temporary scenarios when creating items like navigation menus and thinking about button placement, as just two examples.
Now, let’s talk about our teams, and how we’re defining them and our own users. First, I want us, as an industry, to move away from the idea of a “normal” user. What even is that? Have you met anyone normal recently? I know that, at the very least, the last two-plus years have made that term basically meaningless for me. Instead, let’s talk about our users’ needs, and then frame those using a more mathematically based term, median. What do the most number of our users need? And then, how far to each side of that cluster are we building? Defining these edges becomes important because we are actively deciding not just who we are including, but also who we are willing to exclude. To quote Eric Myer, who was paraphrasing Evan Henſleigh, “When you call something an edge case, you’re really just defining the limits of what you care about.” Defining our target audience is also a de facto exercise in letting people know who we’re not building for. This is where building strongly opinionated teams comes in.
I am purposefully avoiding saying “diverse” teams. Diverse teams can still fall into a group-think mindset. And I don’t think that building teams based on physical characteristics alone is the way to go either; the definition of diversity doesn‘t start and end in the mirror. Yes, those physical factors are important, but what’s more important to me is what lived experiences these people can bring to your discussions. No doubt that how people present and how they are perceived have shaped those experiences, so they are a major factor in the perspective they can contribute. But we also need to keep in mind that no one person from a marginalized group, for instance, should be placed in a situation where they are having to explain and educate the rest of the team on what it’s like to be part of that group. That burden of education is not for them. It’s for you, and your entire team. Do the research! It’s not like all intersections show up as visual cues, either. Looking at me, for instance, you’d have no idea about the alphabet soup of acronyms and abbreviations that my brain has been saddled with. But am I supposed to be the spokesperson for everyone with an OCD diagnosis, for instance? Hell no! But I can say, “Hey, have we considered how this decision will affect people living with XYZ?” Whether you have that condition or not, we need to build teams that are fluent enough with the diverse needs of our users to ask these questions, whether or not we have team members who identify with them.
Let me be clear, though: Building more diverse teams will let you build better products. Period. The more accessible your products are, the more people who can use them. Isn’t that the point? To get as many people as possible through your onboarding flow and into the thing you’ve spent so much time, energy, and resources creating? Ideally to solve one of their problems? Every time you push to make something more accessible and as open as possible, you’re increasing the number of customers potentially available to you. And you can do that by prioritizing their needs, understanding how to expand the definition of your target audience, and putting together teams who know what questions to ask and how to advocate for everyone, everywhere. This can be as simple as having your team ask things like, “How will this work for low-vision users?” or “Is our language as inclusive as it could be?” or “Will this feature work as well for people in low-bandwidth situations?” or even “Who are we potentially harming if we launch this?” The broader the perspectives are on the teams asking and answering these questions, the better your products will be.
See you tomorrow?