Just Say No To Unicorns

code and design

Just say no to unicorns!

I don't want to rehash the nitty-gritty details of the fiery "Should designers code?" brouhaha because it's mostly irrelevant, marginally an issue of semantics, and entirely the wrong question. Some designers code and others don’t — the world of design is so large there is room for a veritable rainbow of designers. I do, however, want to talk about the danger of reifying designers-who-code as chimeras and the corollary that the act of coding is a magical, mystical, unattainable endeavor.

If you've ever seen a concept map diagramming the territory of user experience (Dan Saffer, Jesse James Garret, et al.) then you know the purview of design is, to put it mildly, nebulous. And while it's true that neither Dan nor Jesse's graph includes code, Jesse explicitly states his model is incomplete and doesn't include development practices while Dan's could potentially include code in several areas of overlapping disciplines. Either way, it's not difficult to imagine how these diagrams could and would include code.

Dan Saffer's concept map of UX

And why wouldn't it? Code — loosely and intentionally defined as writing software for the purpose of learning, prototyping, creating art, or working professionally — is a tool for thinking and exploration. It's a way of understanding the system by using the system to build the system on any number of micro and macro levels. As Jennifer Tidwell points out, there are "enduring concepts behind software creation" that transcend any given language, environment, or ecosystem. It doesn't matter where you start or what your focus, code is a way of encountering, understanding, and interacting with these concepts.

The world of journalism is grappling with the same questions when it comes to the role of code, and while journalists and designers share similar rhetoric, efforts are underway at journalism schools to teach students everything from statistics to interaction design to programming. The intent isn't to transform journalists into a legion of expert programmers, but to teach and create a baseline of digital literacy. As Robert Hernandez puts it:

"I do agree that not all journalists need to learn and master coding in JavaScript, Python, or Ruby. But they should know that it is not magic and, to be successful in their modern careers, they need to be able to communicate and work alongside different experts, including programmers. They need to be, at a minimum, digitally literate."

Those required courses in journalism school are there for a reason

To me this feels like the right framing of the issue. By acknowledging that not everyone will or should code professionally while simultaneously demystifying the mechanisms underlying the primary communication platform of the 21st century, code becomes contextualized and approachable. Most of us aren't professional writers either, but it's widely accepted that practicing the art of writing is a Good Thing because it helps you think and communicate ideas. Just like the art of coding.

Designers — say no to unicorns.

Design Is ...


The word design is everything and nothing. We think of design as not just the product's appearance: it's what the product is and how it works. The design and the product are inseparable.

Sir Jonathan Ive

Most people make the mistake of thinking design is what it looks like. People think it's this veneer — that the designers are handed this box and told, 'Make it look good!' That's not what we think design is. It's not just what it looks like and feels like. Design is how it works.

Steve Jobs

Apple's design philosophy is nothing if not direct and concise, which I'm guessing is one of the (many) reasons their level of focus and execution is so incredibly high. As we begin building out the design practice at SimpleReach I've been thinking a lot about design leadership, ways to foster understanding and purpose across divisions, and approaches to creating a strong design culture. Nothing worth sharing right now, but tidbits from my research will likely wind up here.

Happeh Canada Day

design and icon

Happeh Canada Day, eh.

Bower + Sass = Bones

design and interface

Bones - a set of Sass mixins and functions to kick off any project.

The front-end tooling landscape has exploded recently and I'm totally excited about everything that's happening. If you haven't had a chance to check it out a good place to start is Addi Osmani's deck from his 2013 FOWA keynote, "Automating Frond-end Workflow".

I've been using task runners and package managers for a while, but hadn't thought about using something like Bower to create reusable Sass modules until I came across Stefan Baumgartner's article, "Create manageable Sass Components". It's a nice alternative to Git's submodules (which have bit me in the ass on more than one occasion), with the added benefit of managing versions and dependencies.

When it comes to Sass there's a base set of functions and mixins I rely on heavily — if I don't have them handy it's almost like I can't think. While I enjoy frameworks such as Bourbon and Susy and learn a lot from their approach to architecting Sass, I find them too monolithic for my needs.

So I took the ideas in Stefan's article and published my first Bower package, Bones. It's a very lightweight set of functions, mixins, and placeholder extends that I rely on for every project, whether it's a web app, marketing site, or pet project. I've already switched this site over to Bones and it's made my life oh-so-much-easier. I'll continue to update it as needed, but if you are doing any amount of heavy lifting with Sass, consider using Bower to create reusable Sass components. You won't look back.

The Great Crab Massacre

cycling, maryland, and travel

before crab


before crab

After is fueled by the intersection of mishaps, happenstance, books, curiousity, and beer.

New York, NY