Book Launch

To commemorate the launch of my book, which is now shipping from Amazon and Barnes & Noble, here is the Preface.

As tends to happen with experience, my convictions have morphed over the course of my career. As a graduate student studying interaction design at Carnegie Mellon University (CMU), I was of the opinion that designers shouldn’t need to know how to code. We should have tools that give us complete freedom to create without requiring knowledge of the technical bits that are necessary to realize our visions. Looking back at my younger self, it seems hypocritical. I had already learned the technical process of offset printing—not enough to set up and run a press, mind you, but enough to know the difference between process and spot colors, how to specify them, and how to design a brochure with only two colors to keep the cost down. I knew that I had to include an extra margin if I wanted an image to bleed off the edge of the page. As it turns out, I had to learn a lot about the production process to be an effective graphic designer. Why did I not expect to have to do the same to effectively design for the web?

I was quickly disabused of the notion once I took a job with a software development firm where I was expected to hand over HTML that developers could cut and paste into their Java server pages (JSPs). My screens may have looked fine, but the what-you-see-is-what-you-get (WYSIWYG) editor I was using generated terribly ugly code. So it was that I began down a path that resulted in the book you hold in your hands now. But it isn’t just a book about code. More important than learning how to write clean Cascading Style Sheets (CSS) is learning how to integrate with your development team.

You see, when I was first hired by that small software development firm, I was set to work on a complete, ground-up redesign of their flagship product. This was to happen in parallel with the development team rearchitecting the product. The company was young, and I was inexperienced. I was advised by another designer who had been with the company since its inception to not show my work to the developers until I had polished it to perfection. I’m sure you already sense the train wreck that was coming. Sure enough, after months of brainstorming new features and iterating over pixel-perfect screen mockups, I presented my work to the developers, only to be told, “Hey, that looks great, but our architecture assumed the same functionality and a similar interface to what we have now.” They were too far down their side of the tunnel to come back for me, so my fully designed and specified user interface (UI) was shelved. I learned a valuable lesson the hard way, and since then, I’ve worked diligently to integrate myself tightly as part of the development team. Doing so has paid great dividends, and I’d very much like to share them with you.

I’ve now been working for that same company over 13 years, during which time I’ve been able to merge my design process with that of the developers. I use many of the same tools they use for task assignment, issue tracking, version control, and documentation. Where once upon a time I would hand over my designs to the developers for implementation, I now participate in implementation, ensuring that every detail of the design is translated correctly by contributing directly to the production code base. And that brings us full circle. If you want total control of your design, from its first inspiration to the day the finished product ships (not to mention future revisions), you have to participate in the entire development process. That means you should be able to write production-ready HTML and CSS. That’s why I decided to write a book that is one part down-and-dirty code tutorial and the other part ideological process and collaboration. Both parts give practical advice, some of which you can put into action immediately, and some you can begin to plan and build toward.

One person who has the skills of a visual designer, an interaction designer, and front-end web developer is often referred to in our industry as a unicorn—a magical, mythical creature and the object of many a great hunt. If you look at natural history, you’ll find many plausible origins for the legend of the unicorn. You’ll also find a number of creatures that, while not matching our perfect envisioning of a unicorn, are nonetheless creatures with four legs and a single horn. I posit that there are actually quite a few designers in the workforce who meet the base-level description of a unicorn; they just don’t have the opportunity or direction necessary to meet their full potential. Perhaps you are one of them? My sincere hope is that this book will be the incentive that leads you to take that next pivotal step in your career.


Our proposal to bring Midwest UX to Pittsburgh is almost ready to go live. Our design lead decided to give Wix a try to build our site. I’ve been doing some editing tonight, and I’m unimpressed. For one thing, it didn’t work in Safari, but that was the least of my issues. I realize it’s probably a great tool for someone that doesn’t know how to write HTML and CSS, but I found it extremely limiting and pound-your-head-on-the-desk frustrating to use. Unless you want to be tied to the specific designs they’ve made available, you have to “customize” your elements. When you do that, they no longer share their styles with any other objects, so if you have a list of buttons that have all be customized, and you decide you want them to be a different color, you have to change each one individually. I wouldn’t be surprised if there is some feature I don’t know about that lets you define styles, but if so, it isn’t obvious.

Sure, it makes it easy to add transitions, shadows, rounded corners, and to lay out a page, but you can have it. I’ll take my trusty text editor and a CSS file.

Midwest UX 2014 & Me

Last week, I took my annual vacation to a log cabin down in wild, wonderful Wes Virginia. During that time, I was completely off the grid. There’s still no cell phone signal in the valley, and we don’t have a land line. Nor do we have cable or any type of internet connection. We can pick up a few radio and television stations via antenna. So, of course, everything happened last week.

Most notably for me, registration opened for Midwest UX 2014, and as part of that, they announced my full-day workshop, titled Bridging UX & Web Development. Yes, it’s named after my book and will be based on it. I’ll be leading the workshop on Thursday, October 23rd. We’ll work from 9:00 am to noon, break for lunch, resume at 2:00 and finish at 5:00. Here’s the really cool part: it’s only $200. I know! Don’t miss this opportunity to improve your CSS chops and learn how to contribute to your team’s production codebase.

Documenting State

As I continue to refine my employment of OOCSS, I’m also improving the process by which I architect and document the UI. Until now, I’ve waited until implementation to think about the state classes I need and how they will be used. They have only been documented as comments in the HTML. States would be specified, but without any instruction as to how to enact them.

In the past two weeks, I’ve been working on a very detailed UI behavior specification for a complicated form (complicated behind the scenes to make it clear for the user). I figured out the various UI states that I plan to control with CSS and included state classes in my specification document. Now, I not only explain the behavior that is to occur, but provide the state class that can be added or removed to enact it. This is a significant step in improving collaboration with my development team on the CSS architecture. It also forces me to think more strategically about how I intend to implement the front end.

Three Things You Should Know This Week

  1. Midwest UX published their call for speaker proposals on April 1st—no foolin’! The conference will be held in Indianapolis, October 23-25. They’re looking for 30 and 45 minute talks, as well as full and half-day workshops. The submission deadline is June 1st. Get on it.
  2. Macaw, a new web design tool that works like a graphics program but writes semantic HTML and clean CSS, went on sale Monday. You can try it for free.
  3. Unicorn Institute announced today that they are accepting applications for full-time UX educators (aka Unicorn Wranglers). I’d apply myself if it weren’t for the fact that I would have to move to Tennessee. Nothing against the state, mind you—I’m just very happy where I’m living now.

Review: Sass for Web Designers

I’ve been reluctant to dip my toes into the waters of CSS preprocessors. I don’t like the idea of having to compile my CSS for it to render, of having non-standard compliant code in my files, of introducing a new standard that none of the developers will know anything about. Of come up with all kinds of reasons not to even try Less or Sass. Dan Cederholm felt much the same way. Then he dove in head first and ended up writing a book about it.

Sass for Web Designers is another great, little book from A Book Apart. I’m a big fan of Dan’s previous book, CSS for Web Designers, so when I saw his name on this one, I figure I ought to give it a shot. At just under 100 pages, I figured that even if I decided it wasn’t for me, I wouldn’t have to sink much time into it. I wasn’t disappointed, and I’m now itching to put it to use.

There is a lot to love about Sass, but the two main advantages to my mind are variables and mixins. Variables allow you to, for example, define a color once, give it a name (the variable), and then use it in multiple rulesets by name, rather than having to repeat the hex value. If you need to change it, change the variable’s value, and all references to it will be updated. Mixins basically do the same, except with chunks of CSS, rather than a single value. Define your drop shadow with all the various vendor prefixes and give it a name. Then you can use that name in any ruleset.

That’s just scratching the surface. If you are Sass-curious, I recommend Sass for Web Designers.


Rarely is there the opportunity to completely redesign a product’s UI, even when it is desperately in need of a redesign. Rather than completely ignoring the need, find ways to move the ball forward. For example, I’m currently adding a new capability to a product sporting the same UI it had in 2006 with HTML that dates back to 2001. Rather than implementing the new features with frames and table-based layout, I’m proposing some changes that will allow new screens to be implemented with modern CSS while leaving existing screens untouched.

Pointing Fingers

I’m really digging the improvements in the latest incarnation of Safari’s Web Inspector. Here’s another supremely useful feature.

When you select an element, all of the browser dev tools list all of the rulesets that apply to that element. The list them in order of precedence, and they indicate which declarations are being overridden. So, whenever I’m trying to figure out why a style isn’t being applied, that’s the first thing I check. It’s easy enough to find the ruleset that is taking precedence. However, the ruleset may have multiple selectors, and they could be long, complicated ones. It can be a challenge to figure out which selector is the culprit. That’s no longer a problem in the Web Inspector.

As you can see in the screenshot, all of the selectors in that big block are gray except the one, little “p”. That’s the selector that is applying padding to the element that I have selected.

I owe somebody at Apple a beer.

Who Would I Hire?

I’m not hiring. I wish I were, but that’s another post. The discussion I mentioned yesterday got me thinking. If I were hiring, who would I hire, and what would I expect of them?

I’ll break it into two “what if” situations. First, what if I could hire a senior designer?

If I were given the go-ahead by my company to hire a senior designer, I would ideally want someone with a masters degree in Interaction Design or an equivalent discipline, but several years of work experience with quality work products and obvious familiarity with a good design process would be acceptable without the degree.

Ideally, I would want a designer trained in graphic design. It would be difficult to hire a single person without visual design skills, as I wouldn’t necessarily have anyone to collaborate with them on the visual design other than myself, and part of the point of hiring another designer would be to get work done that I don’t have the time for.

Ideally, I would want a designer with basic understanding of HTML and CSS. If they didn’t have this, I would be very clear that their hiring would come with the expectation that they aggressively learn it. I’ve created a tight integration between myself and the developers that I believe is important to extend to any future hires.

What if I could only hire a junior designer?

In that case, I would likely weight my selection heavily towards someone with strong visual design and production skills. Again, willingness to learn both the interaction design process and HTML and CSS production would be necessary. The visual design skills would allow them to immediately take over a lot of my production work, freeing me to design for more projects at once. Over time, I could train them up to become another unicorn like myself.

Okay, since this is all pie in the sky, I’ll throw in a third “what if”. What if I could hire both a senior and junior designer? In that case, I’d want to make sure that the senior designer had strong interaction design skills and process first and foremost. I would again weight the junior designer towards visual design. I would expect both to be willing to learn to code. As the team grows, I would worry less about having all three skill sets in one person, strategizing to balance the skill sets between the team members. What I wouldn’t do is hire a visual designer to just do visual design, an interaction designer to just do interaction design, and a front end developer to just do HTML and CSS.

It all comes back to Jared Spool’s statement:

“Coding and designing are collections of skills. What we’ve learned is teams with a better distribution of skills, not segmented by roles, produce better results.”

Designer’s Toolbelt: New Rule

Whether I’m troubleshooting a bug in Safari or testing cross-browser compatibility in Firefox, the developer tools like Firebug and Safari’s Web Inspector are invaluable. I’ll often work up an entire solution directly in the browser and then apply it to my source code. There is one absent function, however, that trips me up frequently.

I could add as many attributes to a selector as I liked, and I could add a class to an element, but I couldn’t add a new selector. I either had to write an inline style on the element, which is only going to affect that one element, or write a rule in my stylesheet and reload the page, losing whatever manipulation I’d done in the inspector. I’ve wasted a lot of time doing this.

The new version of Safari’s Web Inspector added a New Rule button in the Styles pane.

Select an element and press the button. If the element has a class on it, you’ll be given a new selector with that class. If it doesn’t have a class, you’ll get the element itself. But you aren’t stuck with that. You can edit it to be whatever you want. This provides an enormous amount of flexibility and makes the Web Inspector an indispensable tool (if you didn’t consider it to be so already).