In literature (and generally, other forms of storytelling media), there exists a set of tools called the “implied author” and the “implied reader”. These concepts exist in the narrow space between the fourth wall and the pages of the book – that is, though they are not in the story, they are still contained within the pages of the book. They are stand-ins for the real people, whose characteristics can only be inferred from the manner in which the story is conveyed.

An example may help. In ancient near-eastern cultures, it was common for writers to write as if they were a famous historical figure. I actually encountered this topic first when studying apocryphal Gospels, but I think Homer provides a less touchy example. Modern scholars attribute the Iliad and the Odyssey to him, but there were many more ancient works that were written in his name and style.

In these works, there is a clear division between the real and implied authors. The implied author was Homer, the legendary poet who wrote about the battle of Troy and the journey of Odysseus back to his home. However, it was someone else who actually put the pen (quill? stylus?) to the page (scroll? tablet?) to create these other stories. In a way, this was part of the fiction itself – it’s a little bit like if I released a manuscript for a story of an autonomous truck leaving a country boy, written in Shakespeare’s iambic pentameter with his name on it.

Similarly, these authors (and all authors) wrote their stories for a particular audience in mind. We can infer a few basic things just being familiar with the basic context the stories were written in. For example, the implied reader was someone who read (or more likely spoke) Koine Greek and was contemporary to the authors, based on the language the stories were written in and the casual mention of now-obsolete technologies. This stands in stark contrast to the high school students scratching their heads over wine-dark seas today.

So what’s engineering got to do with it?

What’s engineering, but a secondhand emotion?

I think that in the same way, there are implied engineers and implied users.

As engineers, we’re probably more familiar with the latter. We consider operators, users, user stories, and the like frequently. Almost always, these are hypothetical or even fictional individuals who we invent to stand-in for end users.

What about the former? What do we know about the inventions of a single person, especially those given little thought? First and foremost, they contain bias. There is some baked-in information that the creator’s perspective imparts on their design. In this context, there’s often basic assumptions about user knowledge and rationality that we don’t realize we’re making, and this leads to things like the Software QA in a bar joke.

I spent two years working in post-release testing at an autonomous vehicle company operating on public roads. It took me longer to onboard than to learn that rationality is a frequently incorrect assumption. In that context, assuming people would act rationality would have gotten someone killed. Under the Obligation of an Engineer, I would suggest that being agents of natural selection runs contrary to the duties to respect, humanity, and the public good.

This is where actual user testing comes in. That’s why that organization was doing public road testing: data could be gathered, but they still maintained human intervention capabilities.

But maybe you’re not making cars, autonomous or otherwise. What are you making, an app? It’s probably an app, or maybe a website. Why should you care about good UI? Friction.

When’s the last time you used a website from a sizable, successful company that felt bad to use? With the notable outlier of one bookstore-turned-cloud-computing behemoth, it’s probably been a while. (GitLab just got a notable UI upgrade, and it feels so smooth.) The best UI enables great growth, but the worst UI is the bathwater that the baby gets thrown out with.

Would you use TikTok if it had the same interface as Amazon?

The Other Side of the Coin

So that’s the implied user, what about the titular implied engineer?

Well, what do your designs say about you? You’re probably not pretending to be Homer, but are you expecting literacy in a language less than 10% of the population reads? For the mechanical engineers out there, do you consider tool clearances when you’re designing something for humans instead of CAM? Ask a technician, and they’re sure to have a story of something like a weld joint with two thou of clearance.

One of my favorite examples of good UI is a car – or at least the ones I’m familiar with driving, which are a decade or two old. Every control mechanism is carefully thought out to be reachable by the appropriate appendage. Gas pedals are narrow, while it’s much easier to find and slam on the wider brake pedal. The steering wheel being circular makes it a position-agnostic control, allowing the user to reposition hands without having to think about it, maintaining control and attentiveness. Similarly, the “stalks” behind the wheel are positioned carefully to be reachable from common hand positions, and provide feedback you can see and feel. Sometimes, I want to put my turn signal on just to feel that nice “chunk” when the lever pops into position.

Yes, I know waxing poetic about the tactile feedback on a turn signal qualifies me as “having a thing for cars”, but in my defense, the idea of driving cars is widely romanticized in American culture. Songs are written about fast cars and nice trucks, commercials use it as a way to communicate a sense of freedom and control. And part of what enables that romanticization is engineers who use their own products. Over the course of years, every bit of friction, every hesitation in what should be intuitive, every unsatisfying feel and sound got smoothed out.

That’s one of the easiest solutions to make good products: use what you make. That inherently tightens the feedback loop in a way nothing else can. You know what I mean if you’ve ever dealt with a poorly-written bug report or helped a user troubleshoot software: communication is an inefficient process, and completely unable to replace firsthand experience.

Unfortunately, few of us have the opportunity to oversee the lifecycle of entire product lines as incremental improvements are made by engineers who are also the users, especially without getting chewed out by Linus Torvalds for breaking userspace. That makes it all the more important that we get it right sooner. More than that, though, we are a single perspective. If a tech-savvy engineer can use your app, does that mean it’s intuitive for those who are less tech-savvy? It’s entirely possible that you’ve come to an internal deal that you’ll put up with navigating layers of menus to avoid messy refactoring.

However, that’s not helpful for anyone who’s not you. Again, that’s why end-user testing and feedback are important, but that requires having a functional prototype. In the same vein as making a bugfix in production being more expensive than catching it while defining requirements, it’s better to consider other perspectives sooner. And if that sounds expensive, you should look up what happens if you run afoul of the Americans with Disabilities Act.

Who are you missing?

I’d be remiss if I didn’t point out that every single design I’ve mentioned so far is designed without a particular user in mind: people who are disabled.

There’s a few cases where the product categorically doesn’t align with a disability, such as cars and the blind. Without the sense of vision, the task of communicating information about a vehicle’s surroundings with the required speed and granularity is such a monumental task that it’s considered more feasible to teach the cars to drive.

On the other hand, the population of people who are disabled is so diverse that there’s almost certainly some subset that could potentially use a design. Sticking with cars, anybody who’s mobility-impaired is almost certainly also unable to drive a car with its stock controls. Without getting into the nightmare of medical insurance, I will say modifications are generally expensive.

Maybe you’re not sold yet. You should be though – odds are, we’re discussing your future.

Between injuries that impart disabilities and side effects of just getting old, most people will be disabled at some point in their life. It could be something as mundane as a torn ACL or a broken leg, both of which would prevent someone from driving. It could also be a symptom of getting old – how well can your app be used when someone has bad vision or poor motor control?

Are you okay with having to take a couple months off of using your design? Are you okay with having to hang it up permanently one day just because you got too old? How would that impact your ability to get places, have gainful employment, or broadly live a “normal” life?

You miss who’s missing

In the vein of easy solutions, I’ve got another: ask someone. Seek out voices that aren’t your own. I would never have considered accessibility as much if I didn’t have a partner who was passionate about it because she works in disability healthcare.

It’s well known that diversity of perspectives can have a positive impact on a company’s future, and I think it’s specifically because of the ways a different voice can illuminate things from a new angle. A new perspective can be a new solution, or it can prevent a problem nobody else saw coming.

Who doesn’t have a voice at the table? What could you do to find someone with that new perspective?

Your Implied Engineer

Take a new look at your work. Forget what you know about it and ask yourself who designed it. Hopefully, your answer is honest and positive, but I’ve definitely seen some household appliances that seemed to be designed for alien anatomy.

What about your interface, is that intuitive? Are you handing out excessively long floating point numbers, or IDs that are gibberish? How hard would it be to round a few digits off, or make IDs shorter with identifying information so they can be more human-readable? (Have you ever tried finding a 64-digit UUID in a list of hundreds or thousands of them? I have. Not fun.)

Take a step back sometime and make sure you’re making something for humans. And if you are, consider making something for more humans.