Blog

I want to discuss accessibility because it is the most important thing for making websites. Other A List Apart articles give you innovation and insight. This article will give you homework. These are just my personal views, but they’re pretty good.

I want to start off with a couple of statements, and you will agree:

1. Designers are good people. I have never heard a designer say, “I don’t care if somebody can’t read this text”, “Not my fault if somebody can’t use this device”, or “Who cares if this is confusing?”
2. Some designs exclude people. You have seen people unable to read the text on a website or app that somebody designed. You’ve seen people unable to use a physical device that somebody has designed. You’ve seen people utterly bamboozled while trying to use a service that somebody designed.

So what?

The first question is, “Is this life-or-death stuff?” The answer is, “Yes.” In my favorite essay, This Is All There Is, Aral Balkan makes the point that pretty much everything that we design can affect life events and death events. Aral gives the example of how even a straightforward bus timetable app can affect life and death events, if we design it badly:

• somebody might miss a life event, such as their daughter’s fifth birthday party; or
• somebody might miss a death event, such as the chance to say goodbye to a dying grandmother.

The next—and frustrating—question is, “Why do some designs still exclude people?” After all, we know that:

• not everybody can see perfectly;
• not everybody can hear perfectly;
• not everybody thinks the same way; and
• not everybody moves the same way.

I think the answer is that there’s too much to recall. Consider, if you will, the wide variety of topics that A List Apart articles cover. Designers are expected to remember all of that guidance, plus all of the accessibility guidance, plus so much more. It is too much.

Recognizing accessibility issues while designing

I’d like to point toward one possible solution, starting from Jakob Nielsen’s 10 Usability Heuristics for User Interface Design. These are from the mid-1990s, and—although there’s a good chance that you, gentle reader, are a lot younger than that—please bear with me. 

Seeing as the problem is that there’s too much to recall, I want to look at heuristic № 6, “Recognition rather than Recall.” Jakob Nielsen said that for users, information required to use the design should be visible or easily retrievable when needed. I suggest we tweak that to make life easier for designers. Let’s say that the information required to produce the design should be visible or easily retrievable when needed. In other words, let’s make it easier to recognise accessibility issues while we’re designing.

How are we going to do that? I really like the book A Web for Everyone—Designing Accessible User Experiences by Sarah Horton and Whitney Quesenbery. I really like this book not only because it includes a quote from me—actually two quotes, but I don’t like to boast—but because it includes personas that are perfect for helping us to recognise accessibility issues. That’s the good news. The even better news is that these personas are available now for free on the companion website to the book What Every Engineer Should Know About Digital Accessibility, again by Sarah Horton, with David Sloan this time.

Meet your users

I’m going to introduce you to these personas now:

• Vishnu, an engineer and global citizen with low vision says, “I want to be on the same level as everyone else”, “If I can adjust my screen, I can read comfortably”, and, “Translating in my head is easier with simpler sentences.”
• Trevor, a high school student with autism, says, “I like consistent, familiar places on the web”, “When I can learn the pattern, I can find my way”, and, “Reading is hard for me”.
• Steven, a deaf graphic artist and American Sign Language speaker, says, “My only disability is that everyone doesn’t sign”, and, “Without captions, it’s meaningless to me”.
• Maria, a bilingual community health worker, says, “I love this. It’s all here … when I can find it”, “When a site is confusing, I just leave”—fair enough, Maria!—and, “When I hear and see it, health information makes more sense”.
• Lea, an editor living with fatigue and pain, says, “No one gets that this really is a disability”, “Don’t make me work so hard”—please do not bombard this lady with drop-down lists—and, “Links at the top of the page make navigation easier for me”.
• Jacob, a blind paralegal and a bit of a geek, says, “The right technology lets me do anything”, and “This makes it possible to do my job”.
• Emily, who has cerebral palsy and is living independently, says, “I want to do everything for myself”, “Simpler screens are easier screens”—hell yeah, Emily!—and, “Tell me what I need in advance”.
• Carol, a grandmother with macular degeneration which affects her sight, says, “My grandkids are dragging me into the world of technology”, “I don’t understand what the screen is saying”, and, “Why can’t the text be just a little bit larger?”

I want to throw one more persona at you now, because, well, A List Apart readers are overachievers. One of my favorite authors, Cennydd Bowles—who literally wrote the book on Future Ethics—says to create Personas Non Grata. In other words, every time we design something, we have to think about what a bad guy could do with that thing, and whom that might affect.

To actually use these personas while designing, I like what Eric Meyer and Sara Wachter-Boettcher in Design for Real Life call the Designated Dissenter: for each project that you work on, one of your teams should be responsible for asking, “Will this work for Vishnu?”, “How’s Trevor going to get on with this?”, and so on. 

Then, once you’ve used the personas to recognise the accessibility issues, you can look up the guidelines for whichever platforms you’re designing for: 

• Web Content Accessibility Guidelines (WCAG) 2.2
• Accessibility designing — Material Design 3
• Accessibility — Windows apps
• Accessibility | Apple Developer Documentation
• Check your interface for accessibility (Ubuntu)

Your mission, should you choose to accept it

I told you in the introduction of this article that I would give you homework. You thought I was joking. So, here’s your homework: I want you to grab the personas from the Know About Accessibility website, and use them throughout every design project to help you recognise accessibility issues while you work—and reclaim design for everyone.

NOTE: This article is based on “Recognise,” my five-minute presentation from Interaction Design Association (IxDA) Dublin’s Defuse (Design for Use) event in 2025.

Every language app in your pocket inherited a teaching method built for Latin. Understanding why that happened is a more useful design lesson than anything the apps themselves will teach you.

In 1788, Prussia introduced the Abitur, a standardized national examination required for entry into universities and the civil service. To pass it, students needed to demonstrate measurable, gradable knowledge. The system needed to teach language to large classrooms, produce consistent outcomes, and do it with one teacher and thirty students. The educators responsible for designing this system reached for the only teaching template they had, one that had been used in European schools for two centuries: the method developed to teach Latin.

Latin, by 1788, was a dead language. Nobody needed to speak it. The scholars who studied it were reading Cicero and Virgil, not conducting conversations. The method built around it, memorizing grammar rules, constructing translations, analyzing written texts, reflected that reality exactly. Oral skills were irrelevant. Comprehension of written form was everything. The method was not designed to produce speakers. It was designed to produce readers of texts in a language nobody spoke.

When Prussia applied this template to French and German, living languages spoken by living people, the premise did not change. Johann Valentin Meidinger’s textbook Praktische Französische Grammatik, published in 1804, ran to 37 editions across Europe by 1857. Karl Plotz formalized the approach into what became the dominant model for teaching modern languages across Europe and eventually the United States, where it became known simply as the Prussian Method [1]. Each institution that adopted it trained teachers in it, who trained students who became teachers. The constraint that created the method, how do you grade language at scale with limited resources, became invisible inside the method itself. What remained was the assumption: language is a body of rules to be learned consciously and measured. It was a design decision dressed up, over time, as a pedagogical truth.

The observation that should have ended it

There are people in the world who cannot read or write a language and speak it fluently. There are children who hold full conversations years before they can read a single word. There are immigrants who arrive in a country knowing nothing of its language and come out, years later, speaking it naturally, not because they studied it, but because they lived inside it. Literacy and fluency are separate things produced by entirely separate mechanisms. The Grammar-Translation method, as it became known, assumed they were the same thing. That assumption was inherited from a method designed for a language nobody needed to speak, and it was wrong the moment it was applied to a language people actually used.

The evidence against it accumulated slowly. In the mid to late nineteenth century, reformers including François Gouin in France and Maximilian Berlitz in the United States argued independently that language should be taught the way it is actually acquired, through immersive exposure to real communication in the target language, not through analysis of its rules. Berlitz built an entire school network around this principle. The reformers were correct. They were also largely ignored by mainstream education systems, because the Grammar-Translation method had one decisive advantage that direct immersion did not: it could be graded.

In 1982, the linguist Stephen Krashen gave the argument its most formal articulation in what he called the Monitor Model of second language acquisition. His distinction was precise: language acquisition, the unconscious process through which children absorb their native language and through which adults succeed in immersive environments, is categorically different from language learning, the conscious study of grammar rules and vocabulary that classrooms deliver [2]. Acquisition produces fluency. Learning, at best, produces the ability to pass a test. The evidence supporting this distinction, and the observation that immersive exposure to real native-speaker communication is the mechanism that produces genuine fluency, has only grown since.

I went to Brazil without a word of Portuguese and came out speaking it. I studied French in a classroom for years and cannot hold a conversation in French today. This is not an unusual experience. It is the expected outcome, and it has been the expected outcome for as long as we have had formal language education.

The same decision, made again in a different medium

Prussian educators faced the question: How do you deliver language learning at scale, measure progress, and retain users over time? The answer it arrived at was structurally identical to the one arrived at in 1788. Duolingo gamified the grammar drill into a streak. Anki formalized the translation exercise into a spaced-repetition flashcard. Babbel organized grammar lessons into structured modules. The interfaces were new. The underlying assumption, that language is a thing you study rather than an environment you inhabit, was not.

This was not a failure of design skill. The products that emerged from these decisions are, in many respects, genuinely well-crafted. Duolingo’s retention mechanics are sophisticated. Anki’s spaced repetition is grounded in real cognitive science. They are excellent at what they actually do. The problem is what they actually do: produce measurable engagement with a proxy for language rather than the conditions that produce language itself. A streak is measurable. A vocabulary score is measurable. The moment a user walks out of an app and holds a real conversation in another language, that happens in the world, outside the product, and cannot be instrumented.

When the outcome a user needs is difficult to measure directly, the design process tends to reach for something that can be measured. The proxy becomes the goal. The interface optimizes for it. The gap between what the product delivers and what the user actually needed grows. This is not a pattern unique to language learning. It is a pattern that repeats across product categories whenever a design constraint—the need to measure, the need to scale, the need to produce a grade—gets built into a system so deeply that it stops being visible as a constraint and starts being mistaken for a truth about the problem itself.

What happens when the constraint changes

The constraint that made the Grammar-Translation method necessary in 1788 was real and rational. One teacher. Thirty students. A standardized exam. You cannot grade a conversation at scale. You can grade a translation exercise. The method was not chosen because it produced fluency. It was chosen because it produced a score.

That constraint no longer exists in the same form. Technology has made it possible to deliver immersive, real-time conversation practice to anyone with a smartphone, at a cost that continues to fall. The design problem is no longer how to make language learning gradable at scale. It is how to make the conditions of genuine language acquisition accessible to people who cannot move to another country or afford a native-speaker tutor.

The products that are now closest to solving the actual problem are not the ones that invented a new pedagogy. They are the ones that removed the access barrier to an old one. Praktika builds AI conversation partners with distinct personalities, regional dialects, and cultural context, replicating the specificity of a real native speaker rather than a generic language-learning voice. Langua clones native speaker voices so that the interaction feels like a real conversation rather than a lesson. Rosetta Stone’s foundational methodology, image association in the target language with no translation, was built on the same insight Berlitz arrived at in the nineteenth century: language is acquired through immersive exposure, not through analysis of its rules [3]. A 2025 meta-analysis of 31 studies found that AI conversation tools produced a statistically significant improvement in language learning outcomes, a result that no amount of flashcard optimization has consistently matched [4].

None of these products invented a new theory of language acquisition. They translated an existing one into something more people could reach.

The design question this leaves

The Grammar-Translation method persisted not because educators were wrong about design, but because a design decision made under a specific constraint became, over two centuries, indistinguishable from the thing itself. The constraint, how do you grade language at scale, was forgotten. The method it produced was inherited as if it were a description of how language works, passed from Prussia to Europe to America to the App Store, from the grammar drill to the streak.

Every time a design team optimizes for a metric because the actual outcome is hard to measure, they are making a version of the same decision. It is often the right decision given real constraints. The question worth asking is whether the constraint that made it necessary still exists, or whether it has simply become invisible inside the system it originally produced.

Before reaching for what can be measured, it is worth asking what the user actually needs to do, and what stopped them from doing it before. Sometimes the answer is a new solution. More often it is an old one that was always out of reach.

Early September is traditionally a quiet time at the multiplex. The last holdovers from the dog days of summer movie season—your Spider-Mans and Odysseys, as well as August risks like Coyote vs. Acme—continue to do dwindling business. Meanwhile new and skewed genre films are taking their chances in the off-season. But for everyone else outside […]

The post Oscar Season Now: Welcome to the Rest of the Year appeared first on Den of Geek.

There are many shows that are set in the past, either distant or recent, using what we know of that era to shape their stories. It can be used as a colorful background, or as a key aspect of the story due to historical events or limitations of the era. If your audience has nostalgia about it, all the better, and a great deal of nostalgia is saved for the 1970s.

The best examples don’t simply throw some bell-bottoms and carpeting onto a modern script, they make it part of their identity. From fictional families and ambitious musicians to real-life criminals and historical scandals, these shows offer very different windows into a fascinating decade.

That ’70s Show

Eric Forman and his friends navigate adolescence in Point Place, Wisconsin, beginning in 1976 and eventually reaching New Year’s Eve 1979. The sitcom uses teenage misadventures to explore the decade’s music, fashion, drugs, relationships, and generational conflicts.

The Deuce

Set primarily in 1970s New York, The Deuce follows the interconnected worlds of prostitution, organized crime, and the emerging adult industry around Times Square. Its first season begins in 1971, offering a gritty portrait of the city’s changing sexual economy.

Mindhunter

Netflix’s Mindhunter begins in 1977, following FBI agents Holden Ford and Bill Tench as they interview imprisoned murderers to develop a new approach to criminal psychology. The series blends fictionalized investigations with real serial killers and late-1970s atmosphere.

Vinyl

Vinyl drops viewers into New York’s music industry in 1973, following record executive Richie Finestra as he struggles to keep his company alive. Created by Mick Jagger, Martin Scorsese, Rich Cohen, and Terence Winter, the series captures rock’s chaotic business culture.

Daisy Jones & The Six

Daisy Jones & The Six chronicles a fictional rock band’s rise during the 1970s, following its journey from Los Angeles clubs to international stardom. The story moves through years including 1975, 1976, and 1977, immersing viewers in rock’s golden age.

Mrs. America

Mrs. America dramatizes the battle over the Equal Rights Amendment during the 1970s, focusing on conservative activist Phyllis Schlafly and the feminist movement opposing her. The miniseries turns a major political and cultural conflict into an intimate ensemble drama.

Gaslit

Gaslit revisits the Watergate scandal beginning in 1972, but approaches the familiar story through figures surrounding Richard Nixon rather than concentrating exclusively on the president. Martha Mitchell becomes central to the drama, giving the political scandal a distinctly personal perspective.

The Offer

The Offer recreates the turbulent production of The Godfather, taking viewers into 1970s Hollywood as producer Albert S. Ruddy battles studio executives, political pressure, and organized-crime concerns. The series provides a behind-the-scenes look at one of cinema’s landmark productions.

Minx

Set in 1970s Los Angeles, Minx follows earnest feminist Joyce Prigger as she teams with unconventional publisher Doug Renetti to create an adult magazine aimed at women. The comedy uses the magazine business to explore changing attitudes toward sexuality and feminism.

The Serpent

The Serpent dramatizes the crimes of Charles Sobhraj across Asia’s hippie trail during 1975 and 1976. The limited series follows Sobhraj, his accomplices, and diplomat Herman Knippenberg as investigators attempt to connect a string of murders involving young Western travelers.

The Get Down

Set in New York’s South Bronx, The Get Down begins in 1977 and follows teenagers witnessing the emergence of hip-hop and disco. Baz Luhrmann’s musical drama combines fictional characters with real historical footage and recreates the city’s rapidly changing music culture.

Endeavour

Endeavour spent most of its run in the 1960s, but its seventh season deliberately crosses into the 1970s. The season opens in 1970, with young Detective Constable Morse investigating murders while Oxford experiences political tensions and social change.

A Friend of the Family

This true-crime miniseries takes place during the 1970s and dramatizes the Broberg family’s horrifying encounters with Robert Berchtold, who repeatedly kidnapped their daughter Jan. The series explores how manipulation and misplaced trust allowed the abuse to continue.

Good Girls Revolt

Good Girls Revolt begins in 1969 and continues into the early 1970s, following young female researchers at a fictional news magazine who challenge workplace discrimination. The series explores the professional inequalities that helped fuel the women’s liberation movement.

Life on Mars

In Life on Mars, modern police detective Sam Tyler wakes after an accident and finds himself apparently transported to 1973 Manchester. The series uses its strange premise to combine police procedural storytelling with a sharply contrasting vision of early-1970s policing.

The post 15 of the Best Shows Set In The 1970s appeared first on Den of Geek.

In the 1950s, many in the elite running community had begun to believe it wasn’t possible to run a mile in less than four minutes. Runners had been attempting it since the late 19th century and were beginning to draw the conclusion that the human body simply wasn’t built for the task. 

But on May 6, 1956, Roger Bannister took everyone by surprise. It was a cold, wet day in Oxford, England—conditions no one expected to lend themselves to record-setting—and yet Bannister did just that, running a mile in 3:59.4 and becoming the first person in the record books to run a mile in under four minutes. 

This shift in the benchmark had profound effects; the world now knew that the four-minute mile was possible. Bannister’s record lasted only forty-six days, when it was snatched away by Australian runner John Landy. Then a year later, three runners all beat the four-minute barrier together in the same race. Since then, over 1,400 runners have officially run a mile in under four minutes; the current record is 3:43.13, held by Moroccan athlete Hicham El Guerrouj.

We achieve far more when we believe that something is possible, and we will believe it’s possible only when we see someone else has already done it—and as with human running speed, so it is with what we believe are the hard limits for how a website needs to perform.

Establishing standards for a sustainable web

In most major industries, the key metrics of environmental performance are fairly well established, such as miles per gallon for cars or energy per square meter for homes. The tools and methods for calculating those metrics are standardized as well, which keeps everyone on the same page when doing environmental assessments. In the world of websites and apps, however, we aren’t held to any particular environmental standards, and only recently have gained the tools and methods we need to even make an environmental assessment.

The primary goal in sustainable web design is to reduce carbon emissions. However, it’s almost impossible to actually measure the amount of CO₂ produced by a web product. We can’t measure the fumes coming out of the exhaust pipes on our laptops. The emissions of our websites are far away, out of sight and out of mind, coming out of power stations burning coal and gas. We have no way to trace the electrons from a website or app back to the power station where the electricity is being generated and actually know the exact amount of greenhouse gas produced. So what do we do? 

If we can’t measure the actual carbon emissions, then we need to find what we can measure. The primary factors that could be used as indicators of carbon emissions are:

1. Data transfer 
2. Carbon intensity of electricity

Let’s take a look at how we can use these metrics to quantify the energy consumption, and in turn the carbon footprint, of the websites and web apps we create.

Data transfer

Most researchers use kilowatt-hours per gigabyte (kWh/GB) as a metric of energy efficiency when measuring the amount of data transferred over the internet when a website or application is used. This provides a great reference point for energy consumption and carbon emissions. As a rule of thumb, the more data transferred, the more energy used in the data center, telecoms networks, and end user devices.

For web pages, data transfer for a single visit can be most easily estimated by measuring the page weight, meaning the transfer size of the page in kilobytes the first time someone visits the page. It’s fairly easy to measure using the developer tools in any modern web browser. Often your web hosting account will include statistics for the total data transfer of any web application (Fig 2.1).

The nice thing about page weight as a metric is that it allows us to compare the efficiency of web pages on a level playing field without confusing the issue with constantly changing traffic volumes. 

Reducing page weight requires a large scope. By early 2020, the median page weight was 1.97 MB for setups the HTTP Archive classifies as “desktop” and 1.77 MB for “mobile,” with desktop increasing 36 percent since January 2016 and mobile page weights nearly doubling in the same period (Fig 2.2). Roughly half of this data transfer is image files, making images the single biggest source of carbon emissions on the average website. 

History clearly shows us that our web pages can be smaller, if only we set our minds to it. While most technologies become ever more energy efficient, including the underlying technology of the web such as data centers and transmission networks, websites themselves are a technology that becomes less efficient as time goes on.

You might be familiar with the concept of performance budgeting as a way of focusing a project team on creating faster user experiences. For example, we might specify that the website must load in a maximum of one second on a broadband connection and three seconds on a 3G connection. Much like speed limits while driving, performance budgets are upper limits rather than vague suggestions, so the goal should always be to come in under budget.

Designing for fast performance does often lead to reduced data transfer and emissions, but it isn’t always the case. Web performance is often more about the subjective perception of load times than it is about the true efficiency of the underlying system, whereas page weight and transfer size are more objective measures and more reliable benchmarks for sustainable web design. 

We can set a page weight budget in reference to a benchmark of industry averages, using data from sources like HTTP Archive. We can also benchmark page weight against competitors or the old version of the website we’re replacing. For example, we might set a maximum page weight budget as equal to our most efficient competitor, or we could set the benchmark lower to guarantee we are best in class. 

If we want to take it to the next level, then we could also start looking at the transfer size of our web pages for repeat visitors. Although page weight for the first time someone visits is the easiest thing to measure, and easy to compare on a like-for-like basis, we can learn even more if we start looking at transfer size in other scenarios too. For example, visitors who load the same page multiple times will likely have a high percentage of the files cached in their browser, meaning they don’t need to transfer all of the files on subsequent visits. Likewise, a visitor who navigates to new pages on the same website will likely not need to load the full page each time, as some global assets from areas like the header and footer may already be cached in their browser. Measuring transfer size at this next level of detail can help us learn even more about how we can optimize efficiency for users who regularly visit our pages, and enable us to set page weight budgets for additional scenarios beyond the first visit.

Page weight budgets are easy to track throughout a design and development process. Although they don’t actually tell us carbon emission and energy consumption analytics directly, they give us a clear indication of efficiency relative to other websites. And as transfer size is an effective analog for energy consumption, we can actually use it to estimate energy consumption too.

In summary, reduced data transfer translates to energy efficiency, a key factor to reducing carbon emissions of web products. The more efficient our products, the less electricity they use, and the less fossil fuels need to be burned to produce the electricity to power them. But as we’ll see next, since all web products demand some power, it’s important to consider the source of that electricity, too.

Carbon intensity of electricity

Regardless of energy efficiency, the level of pollution caused by digital products depends on the carbon intensity of the energy being used to power them. Carbon intensity is a term used to define the grams of CO₂ produced for every kilowatt-hour of electricity (gCO₂/kWh). This varies widely, with renewable energy sources and nuclear having an extremely low carbon intensity of less than 10 gCO₂/kWh (even when factoring in their construction); whereas fossil fuels have very high carbon intensity of approximately 200–400 gCO₂/kWh. 

Most electricity comes from national or state grids, where energy from a variety of different sources is mixed together with varying levels of carbon intensity. The distributed nature of the internet means that a single user of a website or app might be using energy from multiple different grids simultaneously; a website user in Paris uses electricity from the French national grid to power their home internet and devices, but the website’s data center could be in Dallas, USA, pulling electricity from the Texas grid, while the telecoms networks use energy from everywhere between Dallas and Paris.

We don’t have control over the full energy supply of web services, but we do have some control over where we host our projects. With a data center using a significant proportion of the energy of any website, locating the data center in an area with low carbon energy will tangibly reduce its carbon emissions. Danish startup Tomorrow reports and maps this user-contributed data, and a glance at their map shows how, for example, choosing a data center in France will have significantly lower carbon emissions than a data center in the Netherlands (Fig 2.3).

That said, we don’t want to locate our servers too far away from our users; it takes energy to transmit data through the telecom’s networks, and the further the data travels, the more energy is consumed. Just like food miles, we can think of the distance from the data center to the website’s core user base as “megabyte miles”—and we want it to be as small as possible.

Using the distance itself as a benchmark, we can use website analytics to identify the country, state, or even city where our core user group is located and measure the distance from that location to the data center used by our hosting company. This will be a somewhat fuzzy metric as we don’t know the precise center of mass of our users or the exact location of a data center, but we can at least get a rough idea. 

For example, if a website is hosted in London but the primary user base is on the West Coast of the USA, then we could look up the distance from London to San Francisco, which is 5,300 miles. That’s a long way! We can see that hosting it somewhere in North America, ideally on the West Coast, would significantly reduce the distance and thus the energy used to transmit the data. In addition, locating our servers closer to our visitors helps reduce latency and delivers better user experience, so it’s a win-win.

Converting it back to carbon emissions

If we combine carbon intensity with a calculation for energy consumption, we can calculate the carbon emissions of our websites and apps. A tool my team created does this by measuring the data transfer over the wire when loading a web page, calculating the amount of electricity associated, and then converting that into a figure for CO₂ (Fig 2.4). It also factors in whether or not the web hosting is powered by renewable energy.

If you want to take it to the next level and tailor the data more accurately to the unique aspects of your project, the Energy and Emissions Worksheet accompanying this book shows you how.

With the ability to calculate carbon emissions for our projects, we could actually take a page weight budget one step further and set carbon budgets as well. CO₂ is not a metric commonly used in web projects; we’re more familiar with kilobytes and megabytes, and can fairly easily look at design options and files to assess how big they are. Translating that into carbon adds a layer of abstraction that isn’t as intuitive—but carbon budgets do focus our minds on the primary thing we’re trying to reduce, and support the core objective of sustainable web design: reducing carbon emissions.

Browser Energy

Data transfer might be the simplest and most complete analog for energy consumption in our digital projects, but by giving us one number to represent the energy used in the data center, the telecoms networks, and the end user’s devices, it can’t offer us insights into the efficiency in any specific part of the system.

One part of the system we can look at in more detail is the energy used by end users’ devices. As front-end web technologies become more advanced, the computational load is increasingly moving from the data center to users’ devices, whether they be phones, tablets, laptops, desktops, or even smart TVs. Modern web browsers allow us to implement more complex styling and animation on the fly using CSS and JavaScript. Furthermore, JavaScript libraries such as Angular and React allow us to create applications where the “thinking” work is done partly or entirely in the browser. 

All of these advances are exciting and open up new possibilities for what the web can do to serve society and create positive experiences. However, more computation in the user’s web browser means more energy used by their devices. This has implications not just environmentally, but also for user experience and inclusivity. Applications that put a heavy processing load on the user’s device can inadvertently exclude users with older, slower devices and cause batteries on phones and laptops to drain faster. Furthermore, if we build web applications that require the user to have up-to-date, powerful devices, people throw away old devices much more frequently. This isn’t just bad for the environment, but it puts a disproportionate financial burden on the poorest in society.

In part because the tools are limited, and partly because there are so many different models of devices, it’s difficult to measure website energy consumption on end users’ devices. One tool we do currently have is the Energy Impact monitor inside the developer console of the Safari browser (Fig 2.5).

You know when you load a website and your computer’s cooling fans start spinning so frantically you think it might actually take off? That’s essentially what this tool is measuring. 

It shows us the percentage of CPU used and the duration of CPU usage when loading the web page, and uses these figures to generate an energy impact rating. It doesn’t give us precise data for the amount of electricity used in kilowatts, but the information it does provide can be used to benchmark how efficiently your websites use energy and set targets for improvement.

Antiracist economist Kim Crayton says that “intention without strategy is chaos.” We’ve discussed how our biases, assumptions, and inattention toward marginalized and vulnerable groups lead to dangerous and unethical tech—but what, specifically, do we need to do to fix it? The intention to make our tech safer is not enough; we need a strategy.

This chapter will equip you with that plan of action. It covers how to integrate safety principles into your design work in order to create tech that’s safe, how to convince your stakeholders that this work is necessary, and how to respond to the critique that what we actually need is more diversity. (Spoiler: we do, but diversity alone is not the antidote to fixing unethical, unsafe tech.)

The process for inclusive safety

When you are designing for safety, your goals are to:

• identify ways your product can be used for abuse,
• design ways to prevent the abuse, and
• provide support for vulnerable users to reclaim power and control.

The Process for Inclusive Safety is a tool to help you reach those goals (Fig 5.1). It’s a methodology I created in 2018 to capture the various techniques I was using when designing products with safety in mind. Whether you are creating an entirely new product or adding to an existing feature, the Process can help you make your product safe and inclusive. The Process includes five general areas of action:

• Conducting research
• Creating archetypes
• Brainstorming problems
• Designing solutions
• Testing for safety

The Process is meant to be flexible—it won’t make sense for teams to implement every step in some situations. Use the parts that are relevant to your unique work and context; this is meant to be something you can insert into your existing design practice.

And once you use it, if you have an idea for making it better or simply want to provide context of how it helped your team, please get in touch with me. It’s a living document that I hope will continue to be a useful and realistic tool that technologists can use in their day-to-day work.

If you’re working on a product specifically for a vulnerable group or survivors of some form of trauma, such as an app for survivors of domestic violence, sexual assault, or drug addiction, be sure to read Chapter 7, which covers that situation explicitly and should be handled a bit differently. The guidelines here are for prioritizing safety when designing a more general product that will have a wide user base (which, we already know from statistics, will include certain groups that should be protected from harm). Chapter 7 is focused on products that are specifically for vulnerable groups and people who have experienced trauma.

Step 1: Conduct research

Design research should include a broad analysis of how your tech might be weaponized for abuse as well as specific insights into the experiences of survivors and perpetrators of that type of abuse. At this stage, you and your team will investigate issues of interpersonal harm and abuse, and explore any other safety, security, or inclusivity issues that might be a concern for your product or service, like data security, racist algorithms, and harassment.

Broad research

Your project should begin with broad, general research into similar products and issues around safety and ethical concerns that have already been reported. For example, a team building a smart home device would do well to understand the multitude of ways that existing smart home devices have been used as tools of abuse. If your product will involve AI, seek to understand the potentials for racism and other issues that have been reported in existing AI products. Nearly all types of technology have some kind of potential or actual harm that’s been reported on in the news or written about by academics. Google Scholar is a useful tool for finding these studies.

Specific research: Survivors

When possible and appropriate, include direct research (surveys and interviews) with people who are experts in the forms of harm you have uncovered. Ideally, you’ll want to interview advocates working in the space of your research first so that you have a more solid understanding of the topic and are better equipped to not retraumatize survivors. If you’ve uncovered possible domestic violence issues, for example, the experts you’ll want to speak with are survivors themselves, as well as workers at domestic violence hotlines, shelters, other related nonprofits, and lawyers.

Especially when interviewing survivors of any kind of trauma, it is important to pay people for their knowledge and lived experiences. Don’t ask survivors to share their trauma for free, as this is exploitative. While some survivors may not want to be paid, you should always make the offer in the initial ask. An alternative to payment is to donate to an organization working against the type of violence that the interviewee experienced. We’ll talk more about how to appropriately interview survivors in Chapter 6.

Specific research: Abusers

It’s unlikely that teams aiming to design for safety will be able to interview self-proclaimed abusers or people who have broken laws around things like hacking. Don’t make this a goal; rather, try to get at this angle in your general research. Aim to understand how abusers or bad actors weaponize technology to use against others, how they cover their tracks, and how they explain or rationalize the abuse.

Step 2: Create archetypes

Once you’ve finished conducting your research, use your insights to create abuser and survivor archetypes. Archetypes are not personas, as they’re not based on real people that you interviewed and surveyed. Instead, they’re based on your research into likely safety issues, much like when we design for accessibility: we don’t need to have found a group of blind or low-vision users in our interview pool to create a design that’s inclusive of them. Instead, we base those designs on existing research into what this group needs. Personas typically represent real users and include many details, while archetypes are broader and can be more generalized.

The abuser archetype is someone who will look at the product as a tool to perform harm (Fig 5.2). They may be trying to harm someone they don’t know through surveillance or anonymous harassment, or they may be trying to control, monitor, abuse, or torment someone they know personally.

The survivor archetype is someone who is being abused with the product. There are various situations to consider in terms of the archetype’s understanding of the abuse and how to put an end to it: Do they need proof of abuse they already suspect is happening, or are they unaware they’ve been targeted in the first place and need to be alerted (Fig 5.3)?

You may want to make multiple survivor archetypes to capture a range of different experiences. They may know that the abuse is happening but not be able to stop it, like when an abuser locks them out of IoT devices; or they know it’s happening but don’t know how, such as when a stalker keeps figuring out their location (Fig 5.4). Include as many of these scenarios as you need to in your survivor archetype. You’ll use these later on when you design solutions to help your survivor archetypes achieve their goals of preventing and ending abuse.

It may be useful for you to create persona-like artifacts for your archetypes, such as the three examples shown. Instead of focusing on the demographic information we often see in personas, focus on their goals. The goals of the abuser will be to carry out the specific abuse you’ve identified, while the goals of the survivor will be to prevent abuse, understand that abuse is happening, make ongoing abuse stop, or regain control over the technology that’s being used for abuse. Later, you’ll brainstorm how to prevent the abuser’s goals and assist the survivor’s goals.

And while the “abuser/survivor” model fits most cases, it doesn’t fit all, so modify it as you need to. For example, if you uncovered an issue with security, such as the ability for someone to hack into a home camera system and talk to children, the malicious hacker would get the abuser archetype and the child’s parents would get survivor archetype.

Step 3: Brainstorm problems

After creating archetypes, brainstorm novel abuse cases and safety issues. “Novel” means things not found in your research; you’re trying to identify completely new safety issues that are unique to your product or service. The goal with this step is to exhaust every effort of identifying harms your product could cause. You aren’t worrying about how to prevent the harm yet—that comes in the next step.

How could your product be used for any kind of abuse, outside of what you’ve already identified in your research? I recommend setting aside at least a few hours with your team for this process.

If you’re looking for somewhere to start, try doing a Black Mirror brainstorm. This exercise is based on the show Black Mirror, which features stories about the dark possibilities of technology. Try to figure out how your product would be used in an episode of the show—the most wild, awful, out-of-control ways it could be used for harm. When I’ve led Black Mirror brainstorms, participants usually end up having a good deal of fun (which I think is great—it’s okay to have fun when designing for safety!). I recommend time-boxing a Black Mirror brainstorm to half an hour, and then dialing it back and using the rest of the time thinking of more realistic forms of harm.

After you’ve identified as many opportunities for abuse as possible, you may still not feel confident that you’ve uncovered every potential form of harm. A healthy amount of anxiety is normal when you’re doing this kind of work. It’s common for teams designing for safety to worry, “Have we really identified every possible harm? What if we’ve missed something?” If you’ve spent at least four hours coming up with ways your product could be used for harm and have run out of ideas, go to the next step.

It’s impossible to guarantee you’ve thought of everything; instead of aiming for 100 percent assurance, recognize that you’ve taken this time and have done the best you can, and commit to continuing to prioritize safety in the future. Once your product is released, your users may identify new issues that you missed; aim to receive that feedback graciously and course-correct quickly.

Step 4: Design solutions

At this point, you should have a list of ways your product can be used for harm as well as survivor and abuser archetypes describing opposing user goals. The next step is to identify ways to design against the identified abuser’s goals and to support the survivor’s goals. This step is a good one to insert alongside existing parts of your design process where you’re proposing solutions for the various problems your research uncovered.

Some questions to ask yourself to help prevent harm and support your archetypes include:

• Can you design your product in such a way that the identified harm cannot happen in the first place? If not, what roadblocks can you put up to prevent the harm from happening?
• How can you make the victim aware that abuse is happening through your product?
• How can you help the victim understand what they need to do to make the problem stop?
• Can you identify any types of user activity that would indicate some form of harm or abuse? Could your product help the user access support?

In some products, it’s possible to proactively recognize that harm is happening. For example, a pregnancy app might be modified to allow the user to report that they were the victim of an assault, which could trigger an offer to receive resources for local and national organizations. This sort of proactiveness is not always possible, but it’s worth taking a half hour to discuss if any type of user activity would indicate some form of harm or abuse, and how your product could assist the user in receiving help in a safe manner.

That said, use caution: you don’t want to do anything that could put a user in harm’s way if their devices are being monitored. If you do offer some kind of proactive help, always make it voluntary, and think through other safety issues, such as the need to keep the user in-app in case an abuser is checking their search history. We’ll walk through a good example of this in the next chapter.

Step 5: Test for safety

The final step is to test your prototypes from the point of view of your archetypes: the person who wants to weaponize the product for harm and the victim of the harm who needs to regain control over the technology. Just like any other kind of product testing, at this point you’ll aim to rigorously test out your safety solutions so that you can identify gaps and correct them, validate that your designs will help keep your users safe, and feel more confident releasing your product into the world.

Ideally, safety testing happens along with usability testing. If you’re at a company that doesn’t do usability testing, you might be able to use safety testing to cleverly perform both; a user who goes through your design attempting to weaponize the product against someone else can also be encouraged to point out interactions or other elements of the design that don’t make sense to them.

You’ll want to conduct safety testing on either your final prototype or the actual product if it’s already been released. There’s nothing wrong with testing an existing product that wasn’t designed with safety goals in mind from the onset—“retrofitting” it for safety is a good thing to do.

Remember that testing for safety involves testing from the perspective of both an abuser and a survivor, though it may not make sense for you to do both. Alternatively, if you made multiple survivor archetypes to capture multiple scenarios, you’ll want to test from the perspective of each one.

As with other sorts of usability testing, you as the designer are most likely too close to the product and its design by this point to be a valuable tester; you know the product too well. Instead of doing it yourself, set up testing as you would with other usability testing: find someone who is not familiar with the product and its design, set the scene, give them a task, encourage them to think out loud, and observe how they attempt to complete it.

Abuser testing

The goal of this testing is to understand how easy it is for someone to weaponize your product for harm. Unlike with usability testing, you want to make it impossible, or at least difficult, for them to achieve their goal. Reference the goals in the abuser archetype you created earlier, and use your product in an attempt to achieve them.

For example, for a fitness app with GPS-enabled location features, we can imagine that the abuser archetype would have the goal of figuring out where his ex-girlfriend now lives. With this goal in mind, you’d try everything possible to figure out the location of another user who has their privacy settings enabled. You might try to see her running routes, view any available information on her profile, view anything available about her location (which she has set to private), and investigate the profiles of any other users somehow connected with her account, such as her followers.

If by the end of this you’ve managed to uncover some of her location data, despite her having set her profile to private, you know now that your product enables stalking. Your next step is to go back to step 4 and figure out how to prevent this from happening. You may need to repeat the process of designing solutions and testing them more than once.

Survivor testing

Survivor testing involves identifying how to give information and power to the survivor. It might not always make sense based on the product or context. Thwarting the attempt of an abuser archetype to stalk someone also satisfies the goal of the survivor archetype to not be stalked, so separate testing wouldn’t be needed from the survivor’s perspective.

However, there are cases where it makes sense. For example, for a smart thermostat, a survivor archetype’s goals would be to understand who or what is making the temperature change when they aren’t doing it themselves. You could test this by looking for the thermostat’s history log and checking for usernames, actions, and times; if you couldn’t find that information, you would have more work to do in step 4.

Another goal might be regaining control of the thermostat once the survivor realizes the abuser is remotely changing its settings. Your test would involve attempting to figure out how to do this: are there instructions that explain how to remove another user and change the password, and are they easy to find? This might again reveal that more work is needed to make it clear to the user how they can regain control of the device or account.

Stress testing

To make your product more inclusive and compassionate, consider adding stress testing. This concept comes from Design for Real Life by Eric Meyer and Sara Wachter-Boettcher. The authors pointed out that personas typically center people who are having a good day—but real users are often anxious, stressed out, having a bad day, or even experiencing tragedy. These are called “stress cases,” and testing your products for users in stress-case situations can help you identify places where your design lacks compassion. Design for Real Life has more details about what it looks like to incorporate stress cases into your design as well as many other great tactics for compassionate design.