Or: How Assumptions Can Ruin Your Project...
It was a Sunday in early August. I was sitting at home playing with my dog and talking on the phone when I heard furiously loud squeaking from the other room. Alarmed, I rushed into the other room to investigate.
There is a moment of dread that every resident of New York City feels when they think there are mice inside their apartment...
Instead, I found four juvenile starlings at my window with their mouths open, making high pitched squeak-noises and tearing at my window screen. Here are some pictures I took of them (I know the pictures are not great quality - these guys wouldn't stay still!):
These birds were probably about three months old, since they are brown and gray, compared with the black iridescent color we associate with starlings. They probably had just learned to fly and were independent for the first time.
Starlings are also known to mimic. Not just imitating other bird's sounds, but other animals as well. What I think happened was that these young birds, who had just left their nest to fend for themselves, decided to try and convince me that they belonged inside a building by pretending to be rodents! They thought that if they sounded like an animal that lives inside, like a house mouse or even a city rat, I would open my window and give them food!
I would, first of all, like to make clear: I DO NOT HAVE A RAT OR MOUSE PROBLEM. But New York City, including my neighborhood in Upper Manhattan, is known for its ongoing, indeed iconic, battle with the local rodent population. (Our Mayor even appointed a Rat Czar!) That being said, I found these starlings' tactics amusing.
If you take a step back from the absurdity of the situation, you will find that there is some solid logic behind their strategy. The birds probably heard rodents as they scurried in and out of buildings, searching for food. They might have also noted how easy it was for the rodents to enter buildings, and concluded they were welcome inside. They also might have seen people eating food though a window. Putting all of these observations together, it must have seemed reasonable that if the starlings acted like they belonged, they too would be invited in and given access to human food.
The problem with their logic is that starlings have no knowledge of how humans view mice and rats as pests, nor of the arsenic-laced bait and glue traps we set. Starlings also don't realize how cautious rodents are around us, how they hug the walls and corners so they won't be exposed, how they wait until we've left before raiding our cupboards. These birds made assumption after assumption until the assumptions accumulated into comically misguided and honestly dangerous actions. What if, instead of my puzzled face, they had been confronted by a cat or a can of pesticide? No matter what they had observed or how clever the baby starlings thought themselves, the rodent and human perspectives are key here.
My encounter with the starlings reminds me of another issue that I'm very familiar with: developers who think that they can build applications in a vacuum, without trying to understand the user's point of view. They assume that they innately understand how the user will use the technology and what the most helpful features should be. Additionally, many of them don't understand, nor take the time to learn, nor prioritize accessibility in their app or website, only satisfying any accessibility requirements as an afterthought. They end up leaning hard on assumptions about how things and people should work to fill in the gaps. Without input from users and data from target demographics to ground them and help them see from other needed perspectives, they might be as lost as those birds outside my window--with equal potential for disastrous results.
I've spent many days throughout my career as a software developer consulting with big firms in fintech and advocating for more cross-department communication and knowledge sharing. When one siloed team makes decisions and/or changes without getting input from others, the downstream effects are always frustrating and may be damaging to the flow of the project. A single team only has a partial view of the system and their expectations of how other parts work may not match reality. A contract needs to be in place, to facilitate smooth implementation of changes. Moreover, the person or people in charge of the project need to understand how all the pieces and groups fit together. If they don't know by heart, they should definitely know which people to ask. Another issue is not fully thinking through a feature's use case and how it might impact the user's experience and even collide with other requirements. Such shortsightedness, if not fixed immediately, has been the death knell to many a project. Before developing starts, project leaders need to understand how the feature might be used, collect information about what need the feature would fulfill for the user, and explore how the feature fits into the larger framework of the application.
There is a saying from the community I grew up in: A worm in horseradish knows nothing sweeter. (Original Yiddish: A vorem in khreyn kent gornisht zisser.) Although eating horseradish is so bitter and sharp that your eyes water, your tongue goes numb and you sneeze out all the mucus from your body, to this worm it is the pinnacle of sweetness. If your environment is saturated by a standard, you are going to have an incredibly hard time imagining alternatives. If you're used to the way your body/mind works and see that same type of "normal" body/mind mirrored around you, you're not going to know how people with other types of bodies and minds interact with the world around them and how they relate to technology. You might not know how your target audience or user might approach your app, without a serious reality check from their point of view.
Well then, what can you do to not fall into the assumption trap?
The first thing you can do is that at the start of your project, gather information on your possible users and how they might use your app. Do a deep dive into their point of view and work closely with representatives of the target user or user advocates for their valuable input. Once you have a mock up or plan for the user interface and workflow, explore how your users might traverse the interface and where the pitfalls might be. Test regularly and constantly reevaluate your use cases. Invite feedback and share knowledge of the system and its guiding principles across different levels and teams of the app.
Another important step you can and should take is to start your project with accessibility already in mind. Creating an accessible project means that more people with different perspectives will be able to use and enjoy your final product. It's also good design policy. Tacking on an accessible overlay with a line of javascript usually doesn't suffice, so you should get yourself informed. Keep up to date with the latest W3C accessibility guidelines on the Web Accessibility Initiative (WAI) website here. Both CWAG.org and WebAIM have good resources on tips and training for accessible design. Deque's axe DevTools is an extension to run automated accessibility testing for web apps. Lastly, interacting with local disability communities can give you insight into the accessibility people need, based on their own lived experiences. Finding an a11y (an abbreviation for "accessibility") event in your area is fairly easy. I attend the A11yNYC meetup every month in downtown NYC. The people I meet there are accessibility advocates and engineers, and everyone is extremely knowledgable. They also have a great list of videos from their previous talks on Youtube here. It's well worth checking out.
Again, don't be a baby starling, do the research. Your projects will be all the better for it.
Featured Image Caption: Courtesy of flickr user goingslo
Comments