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…

Exciting News!

I’m at Interaction 14 in Amsterdam this week, so I won’t be posting regularly, but I wanted to let you know about some exciting news. It’s exciting for me, and if you enjoy reading DesignAday, I hope it is at least a little exciting for you as well. I’ve written a book.

A year ago, I presented my workshop, Sitting in the Driver’s Seat, at Interaction 13. I was contacted by, and met with, a representative from Morgan Kaufmann. During the next few months, I put together a proposal for a book that would incorporate both the workshop and the Working with Developers for Fun and Profit talk that preceded it. Eventually, a contract was signed and I began writing the book in August. Given that I was a first-time author, the publisher didn’t want me publicizing the fact until they were sure they had something they wanted to take to press.

I’ve finished writing, and the book is going into production. It is titled Bridging UX & Web Development: Better results through team integration. The first half of the book covers collaboration, process, tools, and documentation. The second half is HTML and CSS exercises intended to help designers improve existing coding skills to a point at which they can contribute to the production codebase, giving them more control over the final product.

It’s been difficult to keep this bottled up for so long. I do intend to write posts about the entire process, and of course I’ll be keeping you informed of progress from here on out. Stay tuned.

Unicorn Quest - Part 5

Dave Malouf points out three benefits for designers that can code. The most important one, and I agree whole heartedly, is control. When you can implement your own designs, you aren’t dependent on someone else’s attention to detail. You don’t have to worry about whether or not they care enough to follow the spec. You don’t have to book yourself on somebody else’s schedule to look over their shoulder and tell them how many pixels to the left an element must be moved. You aren’t limited to submitting bugs at the end of implementation in the hopes someone has time to fix all the trivial mistakes that were made simply because the developers aren’t designers. You can implement the UI correctly to begin with, and when you do see something off, you can immediately address it. The final product matches your design because you were able to shepherd it through implementation.

The other two benefits Dave lists are:

  • By knowing the technology we can tinker in it
  • Experience it instead of visualize it

He’s right on the money. The importance of serendipity during the design process shouldn’t be undervalued. When you implement your designs, you are not only tinkering with the technology, but extending the time you are able to spend thinking about, working with, and refining the UI. Design is an iterative process, and the more iterations you have, the better your end result is likely to be. Implementation provides more iterations—iterations that allow you to live with the functioning application. That is invaluable.

Dave also mentions some perceived benefits that he considers less valuable:

  1. Speaking like a developer.
  2. We can work faster.
  3. Designers need to understand technology.

I’m in agreement with Dave that, while these may be of some value, they do not require one to know how to code.

So far, Dave and I seem to be on the same page. We agree on the benefits. We have minor differences of opinion on potential drawbacks. But Dave has a big concern about how designers spend their time. I’ll address that tomorrow.

Leanings: Part 2

Yesterday, I reviewed the premise that Jeff Gothelf based his argument for Lean UX on. With that out of the way, let’s take a look at what exactly Lean UX is.

Inspired by Lean and Agile development theories, Lean UX is the practice of bringing the true nature of our work to light faster, with less emphasis on deliverables and greater focus on the actual experience being designed.

A couple things strike me right off the bat. First is the term “deliverables”. He actually means documentation. Not all documentation is delivered (to the customer), and I’ve created plenty of prototypes that were delivered to the customer, so that’s a little misleading. Second is the goal of being “faster”. I’m not going to pick on this too much, because Jeff is clear that Lean UX is intended for startups and quick-to-market product strategies. Speed is important in that context. I just point it out because it’s important to keep this in mind as we continue. Faster is not always the main goal. Faster often requires trade-offs with other goals,.

Now we come to an aspect of Lean UX that I’m completely on board with. Jeff says we can’t have solitary designers perfecting every pixel in private. We must collaborate with the entire team early and often. And while I’m in complete agreement, I don’t think this is something for Lean UX to hang its hat on. This applies to every type of design and has for years. Important? Absolutely. Unique to Lean UX? Definitely not. Moving on…

Next Jeff lays out the Lean UX process: Concept > Prototype > Validate Internally > Test Externally > Learn from User Behavior > Iterate. At first glance, this just appears to be a typical, high-level design process. What you must realize, however, is that this is the detailed process. Concept doesn’t have sub-steps in which you brainstorm on a whiteboard, formalize those sketches into wireframes, and annotate them with notes about behavior. Jeff proposes that “the initial investment in sketching is so minimal that there is no significant cost to completely rethinking the direction.” What he’s inferring is that once you have a quick whiteboard sketch, you’re ready to start creating a working prototype. Spending time revising and documenting that sketch is wasteful. That’s not to say that you go with the very first sketch—there is still iteration—but there isn’t much refinement.

In some projects, this is a perfect approach, and I’ve done just that. I’ve rapidly sketched and iterated a UI concept, showed the sketches to a developer to ensure technical feasibility, and then scanned in the sketches and hooked them together to mimic navigating through the application. I presented the prototype to the customer to get their buy-in on the approach. I chose this process because it was a non-standard method of navigating the content that I thought would be particularly suitable. The customer agreed, and I continued to flesh out the details.

In other projects, I consider a prototype to be more time consuming and wasteful than some simple documentation. If I’m designing a multi-page form using tabs, I don’t have to create a working prototype for the customer to understand how it’s going to behave. They are familiar with tabs.

What I’m most uncomfortable with in Jeff’s description is the lack of any kind of formal documentation of decisions. Sure, you can throw up a rough flow on a whiteboard and hash it out with the product owner, but what are you going to do three months down the road when another stakeholder asks a question about the flow and is pressuring the team to change it? You know you had a reason for doing it that way, but it’s gone through several revisions, and you can’t quite remember the rationale. Wouldn’t it be great if you could quickly check a wiki page or PDF to see the history of decisions that led to the current design? I don’t mind admitting that I bounce around from project to project so often that I have a hard time remembering off the top of my head what I did a few days ago, let alone months. But when a developer comes to me with a question, I have a folder within reach that will provide the context necessary to focus my thoughts.

So far, the only thing that sets Lean UX apart from plain old UX is the abandonment of documentation. I don’t see much value in that. Perhaps we’ll find something more tomorrow.