Simplicity Rules

It’s been nearly three years that a little group called Portland Web Innovators has been meeting. At the end of 2007 I highlighted a few meetings, but 2008 was such a great year, I felt it deserved a full chronicle.

Check out my 2008 Web Innovators year in review to see what this group I co-founded has been up to.

How do you decide what features to include in a new product? The simple answer is to reduce to only the essentials. That’s a lot of what I write about here, so there are many methods, such as the 60 second deadline.

Portland-based site Shizzow has a set of rules that it uses to determine whether a new feature will be added. I had a chance to sit down for a Webmonkey Q&A with one of the founders, who shared the list with me.

1. Simplicity
2. Community
3. Trust

If a new feature does not match all of those criteria, it doesn’t get added. This has helped a small team, all with other fulltime jobs, create a cool site with a feature-set that’s “just enough.”

Yes, I’m delighted that simplicity is one of their core requirements, but the balance of the list is what really makes it work. Rather than adding something to Shizzow just because it’s cool, the team needs to apply the feature to their ground rules.

A simple list like Shizzow’s can help you make good choices, avoid feature creep, and create a better, simpler product.

[Photo by Duncan Cumming]

It’s late in the evening and you’ve been working so hard you forgot to eat dinner. By now you’re tired and really don’t feel like cooking. Is your favorite restaurant open? If you’re naive, you check out their website, but you probably already know that’s a useless endeavor.

Except in rare circumstances, restaurants don’t have much of an offline-online connection. If they did, you’d be able to see the menu, learn about wait times, and maybe even get your order in before going down in person.

There has yet to be much to force restaurants to innovate online. One brick and mortar industry that had no choice but to change is the bookstore.

In 2009, Amazon will celebrate its fifteenth year and in that time it has changed the habits of many a book shopper. You can browse just about any book ever, look inside many, search inside some, and then buy it for 30% less than if you drove on down to your local store. It’s incredibly convenient.

Of course, you can’t physically turn the pages or feel the weight of the book. And you can’t have it now. There are many things a real bookstore has going for it, which is why I often go.

Recently I was searching for a few specific titles and wanted to share a tiny way that my hometown store, Powell’s, is embracing the offline-online connection.

When viewing a book listing, such as this one for Designing the Obvious, a table shows which locations I can find the book in stock. I could go down to their technical bookstore, one of my favorite places to go anyway, and grab one of the two copies of that book.

Powell’s has an online presence that allows me to be an offline customer.

When I wasn’t able to find a particular book at Powell’s, I grabbed my iPhone and was happy to see that Borders has a similar system. It doesn’t tell me the number of books in each location, but does list whether or not it is there. Or, well, whether it is “likely” there, phrasing that doesn’t inspire much confidence. At least I knew which Borders to head to and I did find the book there.

The physical bookstores that stick around are going to embrace this offline-online connection. It will become easy to shop both online and in person. And hopefully it won’t just the big guys that will do it, but the small bookstore that really is around the corner.

Similar concepts will expand to other areas. It may take awhile for restaurants to get there, but eventually they’ll have to. And finally, after a long work day, you’ll be able to reserve yourself a table, order an appetizer, and walk down the street to your online eatery.

If you want to make a simple website, or have a simple product, you need to become well-versed in letting the good in and keeping the bad out. You can’t do everything and you can’t have every feature someone could possibly want.

You are a curator, and Jason Fried has a great talk (15 minute video) about what a curator does:

“Think of yourself as a curator. You want to be a curator. You have to decide what comes in and what goes out. Curator’s job is to say no. Curator takes an entire universe of options to decide whether or not something makes it into a museum.”

The hard part, I think, is how to decide what is essential and what is not. When I need help with that, I turn to a couple of the concepts from Designing the Obvious:

• The Unnecessary Test
• 60 Second Deadlines

How do you decide what belongs in your museum?

There’s a hidden radio concept design that’s been making the rounds. My friend Nathan sent it my way and said it reminded him of the unopenable mint container.

The radio’s volume is controlled by pulling up the lid, showing more speaker. It is tuned by twisting the entire lid. Once you know this, it’s wonderfully simple. Do you think it would be obvious to the first time user? Does that matter?

Starting yesterday my daily routine with DuVinci has changed drastically. During (an extremely busy) July I phased out the work for BestPlaces that I have been doing in some capacity since 2001. It’s time for me to focus on something new.

I want to help others create on the Web. There are designers with great skills who want to learn to program. And there are bright business owners who can’t execute on their ideas. I believe anyone can learn to program. I’m looking forward to proving that.

Right now you can see my first steps at Webmonkey. I’ve written for the site since 2000, but now I’m joining as a contributor on the Monkeybites blog and writing about a tutorial per week.

The move from BestPlaces is tough. I believe in the aim of the site and the people behind it. In fact, I’ll be helping them out a bit here and there.

I’m excited about my next steps and look forward to hearing your ideas. Many thanks to those who’ve already given me such wonderful advice. I hope to receive more of it soon.

Sticky note pic by striatic

I hate doing the same stuff over and over. Since I’m a technical guy, I often create ways to make myself more efficient. Outside of work, this looks fairly mundane: stuff like buying only one type of sock, so I never have to search for a pair.

Michael Lopp writes about the geek phenomenon of being efficient in Saving Seconds. It begins as a rant against the mouse, but really gets somewhere when he writes about creating a new email message:

“There are two types of people. The ones who waited for me to say Go to compose a new mail and the ones who read ‘compose a new mail message’ and pressed the three keys that are necessary, from anywhere in the OS, to fire up a new compose window.”

I think Web people bring this desire to be efficient into our work, mostly for the better. Finding and eliminating repetition is an excellent way to streamline your product. Why make a user click twice if once will do? (Lopp might also say, why make a user click at all?)

Of course, everything in moderation. One can certainly be overcome when constantly striving to be most efficient:

Paying attention to productivity is a slippery slope. The system efficiency addiction associated with saving time can become so compelling that your process begins to control more of your time than your product.

Sound familiar to anyone?

There were some great comments on the unopenable mint container post. I wanted to share a few of them.

Most people agreed that once someone learns the trick, the container is simple. Brent Logan downplayed the effort needed to learn how to use the mint tin, then came up with some great additional reasons why the time spent learning is worth it:

I’d say opening this mint container IS simple, because once you know how to do it (and it can be documented in just two simple pictures), you can open it:

• one handed
• without looking
• with ease

Justin Thiele liked the mint tin, but wouldn’t call it simple:

What if Microsoft Word decided on a new way to copy text? No more Command C (Ctrl C for you PCs). Instead copy would be F1. F1 is simpler, only requires pressing one button, no keyboard dexterity required, and much easier to say to somebody. But now the process of remembering that Microsoft Word uses F1 and every other program uses Command C, becomes more involved. If other programs begin to take these same liberties then complexity abounds.

It sounds like Justin is worried about consistency, which I think plays a large part in simplicity. Certainly being consistent within a context (such as your own website) is important. But there’s also consistency between contexts, such as your website and my website. If you underline links and I underline everything except links, one of us will probably be confusing people. And if there are enough people making changes like this, we may all begin to confuse people.

A few weeks ago I bought some mints at Powell’s bookstore before a meeting. I didn’t want my breath to stink. As I was walking to the appointment, I struggled to get at the mints. It turned out this container required me to read the directions.

See the unopenable mint container in action in this video:

Since I discovered the secret, I’ve been pretty taken with the mint container’s simplicity. Still, I think back to my struggle in downtown Portland. It was not intuitive to open that container.

The fourth law of simplicity states:

“Knowledge makes everything simpler.”

What do you think? Does needing to read the directions eliminate the chance for it to be simple?

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!