Games, chairs, knowledge bases, and the principles of elegant design

Before I became a technical writer, I wrote about tabletop games, a gig that involved explaining rules systems that could be very complex to an audience with a wide range of expertise. Later, I even worked on some games directly, including designing a monster called the Clockwork Vivisector for the Pathfinder RPG. One thing that always attracted me to understanding and designing rules systems was the concept of elegant design. It’s a concept that can inform and improve your technical writing, even if you’re not editing the latest Dungeons & Dragons book.

Invisible elegance

So, what is elegant design? We could probably argue about this all day, but let’s start with this: design that accomplishes the designer’s intent with the least possible complexity. The most elegant designs are completely transparent – the designer’s intent is achieved with no effort or even thought on the part of the user.

My favorite example of elegant design is the shrinking field of American football. It’s a design so elegant, I suspect the game’s earliest rule-makers didn’t even recognize it. Typically, when a team takes their turn on offense, they start back in their own half of the field, with the better part of 100 yards to gain in order to score a touchdown. They have almost the entire field in front of them. That means the defensive team has a huge area to cover. You could have players sprinting 20, 40, 60 yards down the field while some are going to make plays only a few feet from the quarterback. It’s difficult to defend an area so large.

But as the offense progresses up the field, the distance between the line of scrimmage (where each play begins) and the end zone shrinks. The defense has a smaller and smaller area to cover, because the boundaries of play are limited by the back of the end zone. As the field “shrinks,” the defense ostensibly has an easier time of it. There’s no rule in the NFL rulebook that explains, “As the offense gets further up the field, the game gets more difficult for them.” That just happens as a side effect of the natural course of play. In fact, the finite boundary of the end zone was almost certainly created for practical reasons (imagine stadium construction costs if the field of play was infinite). Design so elegant it was accidental!

If you’d like a more purposeful example, let’s talk about office chairs. I have two. One I bought this year. It has adjustable arms, height, back angle, and a lumbar bolster. With enough fiddling and tweaking, I’ve got it just about perfect.

My other chair is from the 1970s. It’s a big swoop of fiberglass that looks something like a melting scoop of ice cream turned upside-down. It’s mounted to a simple metal base that rolls and rotates. The fiberglass is covered in a slightly grungy orange fabric that makes it immediately clear what decade it’s from. Nothing is adjustable. Nothing. And yet, it’s the perfect chair. Comfortable for lounging or for sitting attentively for a Zoom meeting or long stretches of typing knowledge base articles. No back pain, no posture problems. I never think about this chair. I just sit in it.

The work of elegant design

While most elegant designs strive for simplicity, that doesn’t mean elegant design is easy. Often, a lot of work happens behind the scenes to make design feel elegant to the end user. For instance, imagine that you’re building out an internal knowledge base to help with new employee onboarding. You want new hires to read certain introductory articles first before they gain access to the full knowledge base.

You could write a list of the articles, with links to each article. Then, send the list to department heads and make sure they email the list to all their new hires. When someone completes the required readings, they check in with their department head, who approves the checklist and sends them a new link with access to the full knowledge base.

That would work. Mostly. But it’s a lot of work for everyone, and there are a lot of moving parts.

(Incidentally, this is another advantage of elegant design – things with lots of moving parts are prone to breaking down. What are the chances my new adjustable desk chair will still be functional in 50 years?)

How could we design this process in a more elegant way? We’ll probably have to do more work up front, but it will be worth it in the long run. If your knowledge base software is able to automatically segregate users into different reader groups (it really ought to, if it doesn’t), you can sift new hires into the Newbies group, present them with a custom front page that shows only the required intro articles, then reassign them to a reader group with more access once they’ve clicked through and read all the articles.

To do this, you’ll probably have to work with your dev/ops team and possibly your knowledge base provider’s tech help. Depending on the complexity of your knowledge base, this could be quite involved. But the end result will be a process with very few moving parts, and that happens with virtually no effort on anyone’s part. It’s also flexible and easy to update. Need to add some new material to the required reading? Just update the custom front page, instead of emailing a new list of articles to all the department heads.

Of course, if your knowledge base platform has a built-in required reading function, that means all the up-front work has already been handled by their dev team. Sounds pretty elegant to me. Using available tools to streamline processes can be an important part of elegant design.

How to move toward elegant design

There’s an infinite number of potential design scenarios you might have to deal with, so we really can’t formulate specific rules about creating elegant design. Instead, it’s helpful to think about the underlying principles that lead us naturally toward elegant design.

Remember our definition: design that accomplishes the designer’s intent with the least possible complexity. The first step as a designer is to understand your intent. We can’t plan our route until we know where we’re going!

As a tech writer, of course your intent is to impart information as clearly as possible. But for a given project, your intent will be more specific. This could be based on audience – are they only developers, or a mix of devs and people from the sales team? Or it might be driven by a specific desired outcome. An infosec best practices guide might have the intent, “Keep people from using ‘password’ as their password,” or it might be, “Make sure our company maintains its SOC 2 certification.”

If you find your intent is too complicated, or in conflict with itself (“My audience is the dev/ops team, but also end users?”), it might be helpful to break that project down into sub-tasks, each with their own design intent.

The next step is to incentivize the outcome you want. This requires empathy for your users and understanding what they need in different emotional states, whether they're learning something new or troubleshooting under pressure. (Ryan Macklin discusses this concept of empathy advocacy in documentation design on The Not-Boring Tech Writer podcast.)

Instead of a framework of rules and roadblocks, elegant design often starts by simply putting the thing the end user wants where they can see it. This is a particularly useful approach with knowledge base design, where you can adjust search results or limit article access based on reader groups in ways that make it easy for users to find the information they want.

Finally, consider the overhead required of a given design. Elegant design might require work, but it should always require the least possible amount of ongoing work. For instance, a thorough system of article tags can be very elegant for the reader, who can easily sort articles by topic. But maintaining a tag system when articles are updated or added takes a lot of work, and if that work doesn’t get done, the whole system falls apart.

Don’t make it too simple

There’s a Zen to elegant design. At its best, design works effortlessly, and your design ideas seem both sublime and inevitable. Simplicity is a key part of elegant design, but it isn’t the end goal. It’s entirely possible to over-simplify things that need some complexity. I’ll leave you with an example from the world of tabletop games.

In its current edition, Dungeons & Dragons has a system for making attack rolls that’s been simplified gradually over the years and editions. You roll a 20-sided die, add the result to your character’s attack bonus, and compare it to the monster’s armor class. There are two mathematical operations, and the whole process is intuitive. It’s an improvement over some of the systems from the past that were less than elegant.

I don’t think it can be further simplified, however, without losing something essential. Indeed, many indie games have abstracted combat significantly. But they have a different design intent from D&D, whose intent must include, in some way, “Be recognizable as Dungeons & Dragons.” The unpredictable roll of a D20, the gradual increase in your character’s abilities as you level up: these are crucial to the game’s identity.

Approach your technical writing and knowledge base architecture with this in mind: to simplify, but only until you can easily find what’s essential.