Arbor web solutions

We bring beautiful, accessible websites to life.
(That includes yours.)

Making Intent Visible

Published on May 25, 2014 in Design


  • design process
  • apple

Reading Daring Fireball this morning, I came across a fascinating article by John R. Moran entitled "Design Is About Intent". In it, Moran argues that what separates Apple from other technology companies is its ability to do design, which he describes as "answer[ing] the question 'How should it be?'". In its place, he argues, many companies choose one of the "Three Design Evasions" instead: sticking with the status quo, copying what others have done without much thought, or foisting the problem out onto the end user in the form of configuration over actual choice.

I found this take refreshing and well-reasoned. I've long been a fan of the Steve Jobs quote that design is "not just what it looks like and feels like. Design is how it works." This article goes farther, though - design is not just how it works, design is deciding how it works and offering up that singular vision as your product. Design is sweating the small stuff, not because you want to make it look better or be more attractive, but because every piece of the experience is there for a reason. Every piece matters.

I see this kind of stuff in my work every day. There are so many websites out there where "design" is how it looks and what technology it uses - look at the spread of parallax, even for things that have nothing to do with motion. (Moran also points out that good ideas tend to swiftly move "to the tools and techniques stage - the 'how', instead of the 'what'," becoming step-by-step processes with varying degrees of success.) There are so many decisions that go into a website, and nearly all of them are utterly transparent to the end user - unless your user is a web dev too, people are insulated from the challenges of cross-browser support or even the differences between different versions of the same browser.

So how do we make these decisions available to other designers? Writing blog posts is great, and post-mortems presented to the public can be incredibly informative, but I wonder if it wouldn't make sense to follow in the proud tradition of humans.txt. Why not make a semi-standardized text file that lists out the assumptions and decisions that went into a site? What browsers were chosen for official support, and why, and how those changes were implemented; what behind-the-scenes technologies the developers chose to use, and why. It would be nice to look at a site (as a developer) and see that it was built with PHP because it had to be put out in a rush and there was legacy code to support. Or, conversely, that the developers took great pains to write fully-modernized, thoroughly-tested PHP code - that they "knew what they were doing" when they made the choices they did.

All of this doesn't mean much until developers start picking up on it, and none of that can happen without having an actual document to point people to. These are just my early thoughts on the topic, but it's definitely something I'll be thinking about.

Image by John R. Moran