On Myths & Mythos, Design-Wise

Caveat lectorum: My university and professional lives collide below. I'm not trying to Threshold Guradian you or anything, just a warning.

There are a lot of things about design that we (as designers) can count on:

  • Humans are readily predictable; they rarely do what they say they do.
  • The environments in which humans act and interact are readily predictable; they are easy to observe and change.
  • Humans hate being observed and changed.


Myths are stories that we rely on in times of uncertainty. They often stem from truth but in the retelling become broader in context and oddly less applicable to most situations.

They are plenty of myths in design. They tend to get tossed around in meetings by designers and non-designers alike and usually start with “I think the users will…” Thinking the users will do something is a good place to start, but the conversation usually ends there.

Here's a myth, based on 10-year-old research, we can all agree upon:

“Research shows no reliable differences in reading speed or user preferences for twelve point Times New Roman or Georgia (serif fonts), or Arial, Helvetica, or Verdana (sans serif fonts).”

—Source, usability.gov

Or can we agree upon it? Is 10-year-old research good enough to still rely upon, especially on the web? It's something I've stated, in different forms, over the years. But no one I've worked with really wants to use 12-point (equivalent) font-size and very few think Times New Roman should be allowed on the web other than ironically, like Comic Sans. Yet, research shows…

There's plenty more where that came from and I don't just mean on usability.gov.

Heuristics (rules of thumb) are myths of sorts. There are just certain ways we all go about designing that are steeped in myth.

I am not saying I never rely on design myths. I do.

I believe most design myths can be relied upon. My caution here is that they should also be questioned from time to time. Environments change. People change. And at some point it won't make sense to worry about defining a font-size or font-family.


Let's go back in time to my φίλος Aristotle. Mythos is the vehicle by which actions are carried out. Aristotle cared more about goat songs (tragedy), while we care more about workflows.

While there is still plenty of Feature-based Design™ happening in the world (hello, job security), I see a move toward Task-based design. Designers and those they work with are starting to ask: what really needs to be done? The problem that remains is the tendency to focus on what the business needs to accomplish, rather than the user/customer.

For his part, Aristotle focused so much on plot that he neglected character (or didn't think it was as important for the creation of Conflict which drives the Change and… k, another post, for another blog, for another time). Sound familiar? You work with people who know how the system should be designed and how users should, well, use it. But who actually asked the user what they think? Anyone?

If you have a UXer (hey, you could have me!) in your company, you're in a better place that you'd be without one. They can ask what the user wants, assess what the user can do, and balance that with what the business wants and can do. Done and done.

If you don't have a UXer, you are not screwed. Remember, you are working with people who know the business side of the equation. Run with it. Design around it. But early and often, get feedback from users on how the design is progressing. (And yes, it's fine to simply ask, “What do you think?”) You wouldn't implement a system without starting with Unit Testing, right? Please say, “Right.”

Beliefs Should Be Fluid

There is no right way to design. There are good ways and bad ways.

You can get a good percentage of completeness in your design just by having a decent designer who knows the design myths well. And all without talking to a single user. There are dos and don'ts in design; follow them and you'll have a decent design.

The caution here is two-fold: you won't get a great percentage of completeness without involving users, and you can't always rely on design myths to be true in every context.

Question, question, question. Question business intention. Question user goals. Question your own beliefs about design. It's important to know that you are making design decisions not out-of-hat, but that meet the needs of all aspects of the system within the correct context(s) of use. Which, on its own, is really hard to guess your way to success.

There's no need to add to the collective insanity in the world by designing without this level of attention. Things are bad enough out there. While that kind of drama may play well on stage (I'm looking at you Oedipus), it isn't good in a product or service.