I’m visiting my parents, and my father has been volunteering his time as a math tutor to second graders in New York State. New York utilizes the common core for their curriculum. He showed me some of their homework; one of the questions reads:
“Write a number bond to show the whole and two parts.”
I had no idea what a number bond was; when he started tutoring, my father didn’t either. We looked it up. Wikipedia told us that “In mathematics education at primary school level, a number bond (sometimes alternatively called an addition fact) is a simple addition sum which has become so familiar that a child can recognise it and complete it almost instantly, with recall as automatic as that of an entry from a multiplication table in multiplication.”
It also described that “The term ‘number bond’ is sometimes derided as a piece of unnecessary new mathematical jargon, adding an element of pointless abstraction or incomprehensibility for those not familiar with it (such as children’s parents) to a subject even as simple as primary school addition.”
I’ll avoid discussing the politics of the common core; instead, I wanted to talk about the presence of domain-specific jargon in a product, service, or interaction. Language is one of the biggest “tells” we have to understand how empathetic a designed solution is – how much care the designers took to relate to the people that would be using that solution. Early guidelines for usability in software encouraged the “match between system and real world”, indicating that “The system should speak the user’s language, with words, phrases and concepts familiar to the user, rather than system-oriented terms.” Newer theory related to successful service design describes the continuity of experience a person has with a system over time, and language becomes one of the main pillars driving consistency through that experience.
If you think of this language use on a spectrum, tax-documents from the IRS live on one side, while most consumer products lives on the other. The 1040 form from the IRS uses language like “SEP, SIMPLE, and Qualified Plans”, “Domestic production activities deduction”, and “Residential energy credits.” These phrases are meaningless to most users of the 1040 form – they are extremely close (or even identical) to the language of the actual tax code. Compare this with the iPhone’s “Camera Roll” and “Photo Albums.” There’s obviously no roll of film in your iPhone, but the allusion to a physical artifact creates a mental shortcut for people who are taking pictures. The software designer could have used language like “Files”, “Folders”, and “Bitmaps”; instead, they choose language that is aligned with how most people think about cameras and photography.
In Blackboard’s software, we’ve fallen prey to the same poor practice. For example, one of the features in our product is called “adaptive release” – the ability for teachers to make content available to students over time and based on interactions students have with the product. The phrase “adaptive release” is a technical descriptor and is meaningful to people who buy Blackboard’s software. It’s not implicitly meaningful to the people that use Blackboard’s software. Yet it’s actually in our product, indicating that we’ve prioritized one set of stakeholders (purchasers) over another (users).
The common core assignment I described above suffers from the same backwards prioritization. The language indicates that some third party was prioritized over the recognition needs of students and teachers. The third party could have been an administrator concerned about how the material would appear to a review board (“We need to make sure we can check the assessment box next to ‘number bonds’, so be sure to include those words in the questions”) or a highly analytical content author (“The proper phrase is ‘number bonds’, and education should be precise and proper”). My guess is it’s even less intentional – I’m willing to bet the author of this content also authored a lot more content, and as they were working quickly to complete their work, the focus in their mind’s eye was on completing their job – not on the learner.
If you stop and think about what a second grade math student knows, feels, and thinks, you’ll likely try to remember what you thought when you were in second grade. But one of the central ideas in a user-centered, empathetic design approach is to recognize that “the user is not like me.” To find out what a second grade math student feels, you need to spend time with them, get to know them, and form a world-view that is similar to theirs. That includes objective measures – what they know, or how child development occurs – and subjective qualities, too, like their socioeconomic or cultural background.
This is the approach we collectively need to embrace in our software, in our content, and in our policies. An empathetic approach is a continuous consideration of “how will this feel to the person who is using it?” It means we need to first identify who the most important person to empathize with is (the state? the administration? the teacher? the student?) and then utilize language – and other design elements – to create a meaningful connection with that person.
As a thought-exercise, try to rewrite the question above using language that is meaningful to a second-grade student in upstate New York. This student is growing up in an economically impoverished area, with only one parent at home, with three or four brothers and sisters, in a culture that doesn’t necessarily embrace academics or schooling. You might need to actually go spend time in that community to really form this mental model, because these contextual clues matter; they aren’t irrelevant. This is the empathetic design approach.