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.

Does the reward system reflect the intent?

Last week, Jared Spool wrote a “Tweetstorm” that bears repeating as one, compiled post.

Does your organization have a ‘design-centered’ DNA with the right rewards? Developers are rewarded to push out flawless code on an aggressive time schedule; not rewarded for taking the time to improve the UX. Business folks (like product managers/owners) are rewarded to get features into the product; not get perfect experiences. Who in the org is rewarded to create a great customer experience? UX people are. 

But are UX folks rewarded for something that’s in conflict with devs’ & biz folks’ rewards? Who makes the rewards? The senior execs. If an organization truly wants to be design-centered, they need to construct a reward system that puts great design above all else. 

Now, good, solid code is part of great design. Innovative features are part of great design. Devs & PMs work towards great design. But do their rewards reflect great design, or are they in conflict with the effort to get great design? A “good-enough” mentality overrides great design. Great design doesn’t say, “this is good for now. We’ll fix it later.” 

Organizations that reward great design above all else see greater returns in the long run, but have trouble competing in the short run. Rewards are built into an organization’s DNA. They are very hard to fix later. They must be gotten right from the beginning.

I admit that I’ve never really thought about it this way. It makes a lot of sense. I’ve spoken a good bit about how developers‘ concerns are vastly different from those of a designer, but I’ve generally taken that for granted and never seriously considered why they are different and whether or not the should be.

My team is currently working on solving some significant performance problems with our products. While this is largely a technical issue, it is very much a UX issue—one with many different potential causes and potential solutions. It is affected by back end architecture, front end architecture, the technology stack, the environment, the information architecture, the UI design, and the expectations, understanding, and process of our users. It’s interesting to see the difference in team dynamics when we’re all focussed on, and incentivized for, the same goal.

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.

The Birth of a Book: Part 13

The next three weekends were productive ones. Chapters 4, 5, and 6 were churned out in rapid succession. By the end of the Thanksgiving holiday, I had finished the last two chapters. That didn’t mean the book was done—far from it—but it was a major milestone, and only two weeks late of the contractual deadline. I get the feeling that the publisher was used to writers delivering late. Every time I gave my editor a status update, she thanked me  for trying so hard to stick to the schedule.

So, what was left to do? Well, a lot of the figures I included with my writing were placeholders. I wanted to create graphs that Tufte would approve of, and I wanted all of the screenshots to be sized appropriately. There was a diagram that I had only sketched out. Then there was the dedication and acknowledgements, the conclusion, a references section, a glossary, and the book cover. I was also required to provide abstracts and keywords for each of the chapters. And, of course, there were the reviews. I already had comments back on chapters 1-3 and 4 was being reviewed.

Now, one of the exercises uses the Amazon homepage as an example, so the book includes screenshots. These were the only figures that there was some question as to whether or not permission was needed. I was asked to contact Amazon about them. I contacted their customer service and was directed to send a draft to an Amazon Permissions email address. I did that and never received a response. Eventually, my editor told me that we could use them, but they would all have to include the web browser. I had cropped them all down to only show the content, so I was going to have to redo all of them from scratch.

Another exercise, which I pulled straight from my workshop, involves a layout for an address book, including contacts’ photos. For fun, I had used the fighter pilots from Star Wars: Biggs Darklighter, Jek Porkins, Dak Ralter, John “Dutch” Vander, Tiree, etc. I couldn’t have those copyrighted images in the book, of course, so I decided to acknowledge my coworkers—the developers and designers that have helped me to reach the point in my career at which I could write the book. I invited them to provide photos for my mock address book, which you’ll be able to work with in chapter 8. Those people are:

  • Rob Veltre
  • Jeff Christensen
  • Doug Fellner
  • Will Ross
  • Steven Schwab
  • Kelly Dolan
  • Joe D’Alessandro
  • Henry Burke

They’ve all been outstanding collaborators from whom I’ve learned much. Including them in the book is the least I can do to thank them for their contributions to it.

To be continued…

Read previous parts.

Flip it Around

In discussions about designers learning to code, you can bet that somebody will pose the question, “Why don’t we ever hear people arguing that developers should learn to design?” I typically cite examples of developers that have become designers. It happens more often than you may think. Stephen Caver of Happy Cog went the other way.

A couple of years ago at Happy Cog, I transitioned from my position as a designer to a developer full-time. Up to that point, I had been a hybrid designer and developer, splitting my time between the two responsibilities. The truth is that it was a long-overdue transition. My passion lies in the development side of the spectrum, so I am glad to be in a role where I get to express that passion full-time.

Stephen’s post on the Happy Cog blog is titled Why Developers Need to Learn Design. He details four reasons:

  1. Empathize for improved teamwork
  2. Adapt for a responsive web
  3. Understand design to understand the user
  4. Enjoy your work more

Much of what he says parallels my own reasons for designers learning to code. Everything he says meshes well with my thoughts on working with developers.

This Week in Design

We lost one of the greats: Massimo Vignelli.
Massimo Vignelli, Visionary Designer Who Untangled the Subway, Dies at 83 – The New York Times
Michael Bierut’s tribute at Design Observer
The Vignelli Canon

Bearded’s Kickstarter campaign for What Comes Next is the Future, a documentary about the web got funded. Congrats to my fellow Pittsburghers!

Device Lab is a really nifty idea.

Reeder 2 for Mac is now available.

Slides from my IxDA Grand Rapids talk are up on Speaker Deck, and the video can be found here.

Let the Book Tour Begin

This coming Thursday, May 22nd, I’ve been invited to speak at IxDa Grand Rapids. This will be the very first talk I’ll be giving based on my soon to be published book, Bridging UX and Web Development. It is also the first I’ve been invited to speak outside of my own IxDA group here in Pittsburgh, so I’m quite grateful to my good friend Grant Carmichael and his cohorts, Samuel Bowles and Jonah Bailey, for the opportunity. They have a really strong organization going in Grand Rapids—a model that other IxDA local groups can learn a lot from. They’re inspiring my own plans for furthering our Pittsburgh design community.

Now that I’ve written a 200 page book, I have way more content than I could ever hope to include in a 30 to 40 minute talk. There is so much information I want to share, and I don’t mind telling you that I’m having a hard time pairing it down. For this talk, I’ve decided to focus first on designer-developer relationships, and second, on the first two phases of my collaboration lifecycle: requirements analysis and design. I think this combination of soft skills and practical design methods will give a good preview of what readers will find in Part I of the book, which just so happens to sport the same title as my talk: Working with Developers for Fun and Profit.

They have the event posted on Meetup. Oh, and for the folks at home, they’re going to be streaming the event online. I’m quite looking forward to it.

If you are interested in having me speak to your company or organization, please get in touch.

Some Things of Interest

I’m happy when people find my posts interesting or useful, especially when they take the time to share them with others. Here are a few things that have piqued my interest this week.

Have you been listening to 99% Invisible? You should be. Meet Roman Mars.

I’ve been looking for a good Thunderbolt dock ever since I got my iMac. They’ve been slow in coming, paltry on ports, and expensive. This one just might fit the bill.

I’ve written a book about working with developers, but I’m not the only one talking about it. Jonah Bailey of Mutually Human just presented on the topic at GLSEC Monday. If you missed that, he’s speaking again at self.conference at the end of the month.

I’ve always enjoyed DTDT discussions. Heck, I collect design definitions and diagrams. This self promotional piece from Smart Design will fit nicely into my Design Issues course introduction.

Have you seen the debate between Dan Klyn and Matt Nish-Lapidus hosted by IxDA Grand Rapids? Architecture & Interactions is two intelligent guys saying really smart things about the way they approach and understand design.

The Birth of a Book: Part 2

Read Part 1

So, several days after Interaction 13, I received a “short book” proposal form. The Acquisitions Editor was on the fence as to what format the book should be. I was given the options of a “short, concise book” to be marketed as a hands-on, practical guide, or a “short format project”. They sounded like the same thing to me, but it turned out that the former would be around 200 pages, while the latter would be 120-140. That’s the difference between a typical book from Rosenfeld Media and one from A Book Apart.

Having never written a book before, I really didn’t have any idea how to estimate the number of pages it would be. We decided to shoot for 200. At the same time, I suggested including information from my talk, Working with Developers for Fun and Profit, making the book a blend of practical, professional insight and tangible, technical instruction. So, I started putting together my proposal, which was quite a bit of work in and of itself. It took me just under four months to complete, though I admit I wasn’t dedicating much time to it.

To be continued…