Magicicada tredecassini cicada
Magicicada tredecassini

I’m finishing my 17th year making money doing the web.

The 17th year is significant for me because I grew up around the 17 year cicadas. As a kid I remember finding what’s called Brood IV — the black and orange Magicicada cassinii — around our backyard, their molted shells covering our fence and trees. I was 8 years old. Their grandchildren emerged from the ground in early summer last year.

Cicadas evolved the 17 year cycle as a way to throw off predators. The annual cicadas come out in force knowing they will be eaten by birds more often than successfully mating. 17 year cicadas, they sit there, buried in the Midwest soil, waiting out generations of predators before coming out in force to bewildered predators.

17 years in this industry. I’ve evolved myself, from a kid with a copy of HomeSite and HTML knowledge to a user experience such-and-such armed with new tools, a lot of experience, and a secret memory of how I got here.

I don’t have any tattoos. I wonder how, as a Gen X’er, I’ve managed to never get inked, especially given how many tattoos cover my friends. But I’ve thought about getting one of a Magicicada cassinii. A symbol of making it this far. Of maybe, this year, climbing out of the dirt to unleash the cacophony.

But what happens in year 18? I don’t know. Evolution, change, it’s part of the way things are. And should be.

A blogger recently fretted about the “sameness” of the web (yet again) and how machines would replace design (yet again). A lot of people read it, shared it, loved the message. But I saw a sameness there. A fear of what happens when evolution stops.

Meanwhile, another blogger fretted that things change too fast, that the rules of building websites are moving at such a speed that maybe it would be good to pause the “innovation.” That blogger was derided, rightly, for that belief. But I saw a sameness there. A fear of what happens of not being able to evolve fast enough.

The Magicicada cassinii evolved a solution to a very real problem — they needed to live to fight another day. There are many ways to solve this problem in nature. You can dump your offspring out in one big cloud and hope a few of them survive. You can choose a defense mechanism, like poison, or a stinger. You can also choose to move up the food chain, requiring more energy to sustain yourself and your population, but you’ll be damned if a bird’s gonna eat you.

The cicada chose a different defense mechanism. Time.

But time is what we lack with the internet. Things are evolving, fast, crazily, and we cannot keep up.

But the websites I designed and built in 1999? They’re still there, on someone’s server. They live on.

Like a cicada, I made it here, 17 years on. Unlike a cicada, I didn’t bury myself. I fought to stay alive amid so many predators, bad bosses, bad companies, bad ideas.

So, like an orange eyed, black bodied Cassini, I’m here. And now the new questions happen. What now? where to next?

I don’t know. But I don’t want to bury myself. I want to make my noise and keep on going. I want to keep annoying everyone with my drone. I will not stop. Not now. Not ever.


People argue about the boundaries between subfields. Is this the domain of UX? Content Strategy? Is it really IA? Does this problem belong to a front-end developer or a designer? Can a usability person do design? Should a developer know CSS? Should a designer know PHP?

We all want to stake out our territories. We want to know where the edges are, for a variety of reasons. Is this my job? Do I own this space? How much do I need to know?

Maybe in a huge organization it’s easier to claim vast swaths of territory for a single specialty. Maybe not, because people do seem to keep arguing.

In a small organization, the roles blur, because they have to: we add to our stated roles because the work still needs to get done. I’ve been the Webmaster and bounced in a single day between strategy and debugging, writing promotional copy and writing code, planning an email campaign and cleaning up the mailing list for the campaign. It’s probably too much for one person, but you do what you can with what you have.

There’s another way to approach the problem of confusing boundaries. Recognize that the world itself is blurry, overlapped, and nuanced. Discover and embrace your curiosity.

When I was in college I never settled on a minor[1]I knew my major going in: I was going to be a famous novelist, so I was an English major with an emphasis in creative writing. If I hadn’t had an overarching love for writing, I don’t … Continue reading because everything was interesting. My alma mater had lists of required subjects, and I ranged across them all without ever finding a single thread to tie them together: philosophy, geology, psychology, astronomy, history. My favorite moments were always places where the fields crossed.

Twenty years later, I’m working at the college I should have gone to. There’s no majors or minors here, just the idea of an area of emphasis that sometimes appears in retrospect: how did my studies connect? And most classes cover different fields held together with a theme. Once I knew what it was, I knew its ethos matched mine.

I never had a minor, and I never planned on being a web developer. I had a series of experiences that let me explore and combine things I cared about. I wanted to express myself in public, so I learned how to make web pages. When I got a job making web pages, I realized I cared about clean code; I wanted to understand how to make sustainable useful design; I wanted to build things that real people could use to make their own lives better.

There wasn’t a plan, and more than that, it didn’t matter to me when something crossed an invisible boundary. If I had to learn how to do usability testing, I was going to learn it. If making something better meant picking up design theory or Drupal, I’d do that, too.

Even now, on a team with some more defined roles, we find that problems cross over our specialties. Is a user’s ticket a problem in CSS or JS? A simple text edit? A glitch, and on whose end? A “simple” question turns into a discussion across our whole team of usability, information architecture, language, marketing…or even what the college itself is or should be. The work continues to cross disciplines.

When you find yourself trying to draw a line between what is your discipline and what is their discipline, I hope you will pause to appreciate and enjoy the blurring instead. Celebrate that you’ve found something interesting to explore together.


1 I knew my major going in: I was going to be a famous novelist, so I was an English major with an emphasis in creative writing. If I hadn’t had an overarching love for writing, I don’t know what I would’ve done.

Documenting the core

We document specifications to describe how individual interactions on a page work. Above that, we document components (some folks call them molecules), so that reusable elements across sites are described and developed consistently. Above that, we have wireframes of pages or sets of pages, showing the combination of interactions and molecules and content. We document entire subsites or sites with these.

And above that? What’s more abstract and at the same time more critical to get right than the wireframes?

I’ve heard them called both “design heuristics” and “design principles” – the principles and trade-offs that we, as a designer, or a group of designers, or an organization, make to accomplish goals. They both define the values of a specific project, and at a higher level define our values as designers. I prefer the term principles.

The set of design principles I use for most of my work are based around the following topics:

  • Learnability – make sure that my users can learn how to use the system.
  • Efficiency – make sure the user can move through the system as efficiently as possible.
  • Managed Complexity – make complex situations clearer, or at least manageable.
  • Autonomy – ensure that I’m allowing the user to move freely, control their progress, and not get stopped by process decisions.
  • Messaging – ensure that the system communicates everything from error messages to informational situations
  • Accessibility – ensure that the widest possible audience can use what I’ve built.
  • Semantic Structure – make it written as close the semantic HTML as it can be, it uses progressive enhancement, it follows good coding practices like DRY, etc.

Of all the things I document, these are the most important.

I document them even when I’m not asked to.

It’s not enough to know that I wireframed the purchase process for, say, purchasing stock. I can make wireframes for the purchase process. I can even make personas and scenarios. But if I don’t document that this design is intended to be used by new investors (and therefore needs to be highly learnable) or that this is intended to be used by internal employees who trade stocks all day (and therefore do not need nearly as much instruction but desperately need the system to be efficient for data entry), I haven’t captured the core of the interaction.

When I was a young pup in UX, my mentors required me to document the principles I was using to justify the design decisions I was making. It forced me to communicate the trade-offs I was making, and made them much easier to discuss with my peers. “Is it appropriate to trade off learnability for efficiency in this situation?” we would ask. “This design manages complexity well, but forces the user to follow a specific path. What if we did [suggestion here] to return to them some of their autonomy?”

Times have changed, and I find myself in fewer conversations with my peers about our work. When we are talking, we’re often — like everyone else — easily caught up in the components and layout and behavior of a page. We’re not talking about the principles behind the decisions as much anymore.

When I’m outside the office, and I talk about principles and heuristics, I find many organizations don’t have any documented at all.

I’m worried. I fret that between the push for Agile development and Lean UX and other built-it-faster techniques we’ve neglected to teach and communicate the basics. I fear we too-often count on folks new to our field to implicitly learn the “rules” without explicitly explaining things like Fitt’s Law.

So between rants and raves on other topics, I’m going to dedicate some of my time on The Interconnected talking about the principles and decisions that shape my work, and examples of the same.

If you have questions or topics you want to see me cover, ping me at @kirabug on Twitter. Or if you have great examples you want to share, come write for us.