On Myths & Mythos, Design-Wise
My university and professional lives collide below. Fair 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).”
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 that site. 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, in this case, goat songs while we care more about workflows.
While there is still plenty of Feature-based Design happening in the world (read: job security) more and more and more 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.
For his part, Aristotle focused so much on plot that he neglected (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) character. Sound familiar? You work with people who know how the system should be designed and how users should, well, use it. But who asked the user what they think?
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. Perfect. 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 one 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 do.
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 be good on stage (I’m looking at you Oedipus), it isn’t good in a web application.