What counts as “viable” for a Minimally Viable Product?

On July 5, Meta (parent company of Facebook and Instagram) launched Threads, designed to be a competitor to Twitter.

And in some respects, it was a hugely successful launch. For example, it hit 100 million sign-ups in just five days.  

But in some other respects, it was much less successful. For this newsletter, I will set aside both Threads’ personal data collection and how users can’t delete their account without also deleting their Instagram account. Instead, I will focus specifically on issues of accessibility. 

And to do that, I want to take an inclusive language look at a concept that is common in tech: the Minimum Viable Product, or MVP.

 
 

What is a Minimum Viable Product? The idea is that instead of endlessly perfecting an app or platform or product before launching, you release it early. In its MVP form, with just enough functionality for early customers to start using it and then give feedback on what additional features would be useful, how they’d like to see it fleshed out, etc.

So let’s look at the scenario invoked by the semantic frame of an MVP: a generic user receives an imperfect but usable product, uses it, and by using it, sees ways it could be expanded and improved.

Seems reasonable, right? And a good way to develop software that doesn’t go too far down the wrong path, software that can be tweaked to better meet user needs.

Problem is, for many companies developing software and MVPs, the generic user in this scenario is abled. 

The MVP is developed as if everyone using it is abled. 

And accessibility is forgotten about or assumed to be a “bonus feature” that can be added later, like other tweaks and improvements to make the product more robust.

(Note that Elon Musk fired the entire Twitter accessibility team, so there are also scenarios where accessibility support is considered entirely optional and cost-effective to cut.)

For Threads, the biggest accessibility issues upon launch were:

1) no user-generated Alt-text for images;

2) no video captioning;

3) contrast issues in both light and dark modes.

In addition, there were no easily findable accessibility tools and no accessibility statement.

Many people with vision impairments need alt-text to understand what’s happening in images and require high contrast between text and background in order to read. And people with hearing impairments usually need captions to access video content; captions are also useful for neurodivergent users.

Without these accessibility tools, and others, many disabled users were unable to access the Threads content available to their abled counterparts.

 

Photo credit: Joshua Hoehne via Unsplash

 

This use of “Minimum Viable Product” for a software platform that is inaccessible to many violates several of my principles of inclusive language. 

It doesn’t draw people in. (Instead, it marginalizes disabled people.)

It doesn’t prevent erasure. (Instead, it erases several types of disabled people.)

It doesn’t recognize pain points. (Instead, it ignores how frequent, and how painful, inaccessible websites, products, and platforms can be.)

And, from my perspective, most importantly, it doesn’t reflect reality.

In particular, I see two linguistic distortions taking place with this use of Minimum Viable Product. (I talk about these distortions more in Chapter 2 of my book.)

1. Masking language

Masking language is used by a dominant group to mask a social reality. It sets up the dominant group and the status quo as neutral, normal, and natural. The way it always has been, and the way it should continue to be. But what it often masks is that things are just fine for only some of the people. The experience of the dominant group is usually not the experience for everyone.

Here, the use of “viable” masks that when a product isn’t made to be accessible from the get-go, then it is, in fact, not viable for a whole chunk of the population. In this case, it’s a subset of disabled people. 

 

Infographic from ahrefs.com.

 

2. Softening language


Softening language is a distortion that presents problematic behavior as appropriate and acceptable. 

In this case of a Minimum Viable Product, it presents the product as above a threshold of viability.

But when something simply isn’t accessible to a significant portion of the population, shouldn’t it be considered below the threshold of viability? As in, not actually viable? 

Remember, the scenario of a minimum viable product is that it’s a bare bones product that is good enough to let users check it out and give feedback. 

But what if your product isn’t viable for a whole set of disabled users because it lacks accessibility tools? Can it still be considered an MVP?

My answer is: no, it cannot.

I’ve seen this with products that aren’t viable, aren’t accessible, for reasons other than disability. For example,

When something is called a Minimum Viable Product, a company is suggesting that it is viable for everybody. 

But in the case of Threads, its launch product was viable only for abled people. And for the other products, they were only truly viable for lighter-skinned people.

When you’ve got a product that is supposed to be for everybody, it’s important to do inclusion-oriented UX work to assess and meet different kinds of user needs.

And inclusive language — here, clear and precise terminology that actually reflects reality — can help point the way. 

Copyright 2023 © Worthwhile Research & Consulting

ArticlesSuzanne Wertheim