I enjoyed writing the series of posts about Designing the Obvious, the guide to creating sites and applications that keep both developer and user sane.
My favorite part was reading what others thought about it in the comments. Three were randomly chosen to receive autographed copies: Aaron Hockley, Bram Pitoyo, and David Frey. I hope we get to hear more about what they think when they read the entire book.
Thanks also to the author Robert Hoekman, Jr., who supplied the books, and agreed to answer the following questions about his work. If you’re still itching for more Hoekman, he has a new book, Designing the Moment, that is full of examples of his concepts put to use.
How do you determine what is essential and what is nice-to-have?
As I touched on in Chapter 2, I take an activity-centered approach to design, which is to say that instead of focusing on a narrow range of audience types, for most projects I focus on the activity an application is meant to support. In doing this, I study the essential elements of the activity, document them, and then work to justify every item on the list.
So, as I study an activity, I create what I call an “Activity Grid”, which is basically a 3-level outline you can create in any word processing application or outlining tool (such as OmniOutliner). At the top of this document, I write a description of the activity the application will support, then I break the activity down into outline form. The first level is a simple list of tasks, which could be something like “Find photographs” in a photo-sharing application. Tasks then break down into actions, which are itemized accounts of the steps you might take to find photos, such as “Search by member” or “Search by subject”. Finally, these actions break down into operations — the lowest level of detail. Operations can be things like “Enter a search term” followed by “Click the Search button”.
When I start studying an activity, I identify the major tasks — the ones most essential for completing the specified activity. Once I have that list, I detail the actions that comprise each task. From there, I can detail exactly what operations must occur for the actions to be completed. By the time I flesh out the Operations level of the activity grid, I have a fairly detailed set of design instructions. For example, the “Enter a search term” operation tells me I need an input field in the interface, and that there will be a search feature.
Once I finish this list, I start my design work. But instead of setting the activity grid in stone, I review it throughout the project, continually re-justifying everything that made the cut to see if anything is missing, can be stripped out, or needs revision.
With all this in mind, there are many ways to determine what’s essential and what needs to hit the cutting room floor. For example, Joshua Porter’s book on social web design offers a very different approach where you identify the objects needed to complete an activity and then devise your feature list out of that list. I think it’s a smart approach and am planning to try it out soon.
You rely on use cases in your work. How to you maintain a balance so your process can simplify things instead of make things more complicated?
The use cases I write are a little different than the typical “user story” you might see in a lot of development processes. First, they’re very detailed. Instead of a single line that describes only the action the user will take, I describe each step of each action. Second, these use cases are very much an extension of the activity grid. So, I design all the screens and screen states I need to fulfill the activity grid, and then I stick them all into this Powerpoint/Keynote template I created and write the use cases in a sidebar, right alongside each wireframe. I call this a Design Description Document (DDD) — in fact, you can grab the template from my site.
This can definitely sound like a complicated process, but depending on the activity, an activity grid can be created in a matter of hours in a lot of cases, and the DDD can be done just as quickly. Instead of a long, dry technical specification, I use this DDD, which can be created and updated in extremely little time, and does a more effective job of communicating to stakeholders and developers exactly how everything should work so they can build it all out.
I’ve been using this set of solutions for a while now, and it’s proven to be very efficient for me, but I’m always looking for ways to simplify the process and get the right messages across to clients, so I could just as easily change it all tomorrow.
The real key is to be flexible. Don’t lock yourself into anything, because there’s always an improvement to be made and you don’t want to miss it by getting too focused on one way of doing things.
Do you find making your personal workflow simpler makes your products simpler?
Oh, definitely. The more I simplify my own process, the more I’m able to quickly identify areas of a design that need to be created or improved, and the more readily I can do that, the simpler the outcome. For example, by using an activity grid and a DDD, I can determine what needs to be designed and document every detail of it very quickly, which enables me to spot trouble areas or gaps in my thinking so I can revise the designs.
How do you avoid the curse of knowledge and think like a user?
Great question — and the answer is actually a little ironic.
When it comes to designing usable and enjoyable software experiences, the principles of design are simply restatements of human behavioral patterns and psychology. For example, we know from observing people use software that they tend to blame themselves for mistakes when error messages come popping up time after time, and they can end up feeling dumb, as though they’re simply incapable of understanding how to do something correctly. We certainly don’t want our users feeling dumb as a result of using our products, so all you do is restate the problem as a principle. Once you know that users blame themselves for mistakes, even when it’s not really their fault, the design principle becomes, “Prevent errors, and handle those that cannot be prevented as gracefully as possible.”
Because the role of design is to support human behavior and because the principles behind good design do exactly that, there is no “curse of knowledge”. The more you know about human behavior, the better you can design to support it — to work within those constraints.
Why did you write Designing the Moment?
I wanted to pick up where Designing the Obvious left off. The first book was about core tenets — the high-level things that are simply essential to good web application design. But beyond those principles, there are a whole lot of very specific problems that come up when you’re shoulder-deep in the details of a design, and I wanted to talk about the principles and practices that address those problems. The best way to do this was to talk about them in context — to describe specific instances where I was faced with a common (or uncommon) problem and then walk through the principles and such that I applied to solve them. So, Designing the Moment is a collection of stories from real projects where I talk about the design problem, the steps I took to start and improve the design, and the concepts I used to make each decision.
The really fun part was that I got to tell all these stories about projects I’ve actually worked on and how I got through them. Of course, that’s also the really scary part. Designing the Moment is an educational tool, sure, but on a personal level, it’s also sort of a journal of these little bits of designs I’ve done over the past year and a half or so. It never really occurred to me while writing it, but once it was released, I had this realization that I’d just put all this work into print. It’s out there to be judged by anyone who picks it up. That’s a scary idea! I’m glad I didn’t have this realization while I was writing it, else I might have panicked and scrapped the whole book.
Too late now!
