This is the presentation I had originally planned to give at WordCamp. Several people have asked for it, so I posted it here.

1. I’m RHJR, and I’m a WP blogger. Designing the Obvious, however, is a book about web application
design principles. And I didn’t talk about blogs in it at all.
But you guys are all here to talk about blogs, so I’ve adapted things a bit, just for you WordPress
geeks. Today, I’ll follow each topic with an example of how to apply the concept to a blog.
We’ll talk about:
1) Building only what’s absolutely necessary (and how to do it)
2) Getting users up to speed quickly so they can start liking your app
3) Surface the important elements on a page
4) Handle errors

2. build only what’s absolutely necessary.
First, let’s talk about building only what’s absolutely necessary.

3. Early on, we need figure out what really needs to be built. Seems obvious, right? Well, it is, unless you
want to build something really good.
It’s easy to build everything that comes to mind. It’s easier to do that than it is to cut things out and
build only what’s absolutely necessary. But that’s what needs to be done, because a more focused app
is easier to learn and use, and easier apps lead to repeat business.
So take your wireframes (like this one) and strip things out of it until the essence of the app shines
through. What’s the core purpose of the app? What’s it do? Focus on this.
Let’s see how to do that by stripping some things out of this “fictitious” webmail app. In the book, this
is called “Interface Surgery” and there are several examples.

4. Strip out the ability to search the web.
- All browsers have this. It’s redundant to include it.

5. Strip out the Saved Search feature.
- Takes longer to save and re-run the search than it does to just type it in
- This means we can get rid of the two tabs as well. Cleaner design.

6. Move the Storage Used info to another screen. It doesn’t need to be in the main UI 100% of the time.
This is a webmail app, right? So send an email when the inbox starts to get full.
OK, see the INBOX label? It’s big and bold to tell you which mailbox you’re looking at ...

7. So get rid of the TITLE BAR for the FOLDER box. You already know from the sidebar what folder you’re
looking at.
Get rid of Apply Action dropdown. Move these actions somewhere else. (We’ll talk about those in a
moment).
Clean up the mess. Again, a simpler design.

8. Surface the command links (reply, forward, etc.)
Apply some logic to the links so they’re disabled when they can’t be used. (Heck, you’re building fewer
features now, so spend some more quality time on what’s left and make it great.)
Clean up the mess again.

9. Reminder: This was the original.

10. This is the new version. Much cleaner. Much more focused.
Not a huge dierence to us, but MASSIVE to a typical user.
Let’s talk about how this applies to a blog. Usually, blogs contain several elements: a post, a link to
another post (or two), a link to the archives ... things like that.

11. [example of this applied to a blog]
This is Sam Stephenson’s blog (and no, I have no idea who Sam Stephenson is). He stripped out almost
everything. He left out the blogroll, the category links, the list of recent posts ... heck, he left out the
post footer!
There’s no way to digg this, StumbleUpon this, trackback it, comment on it, or anything. Each page
contains exactly one post.
I love this design. Sadly, Sam has only ever written two posts.
Bloggers are a creative bunch, and I certainly am not saying everyone should do this. This is sort of
extreme. What I’m saying is to figure out what’s actually important to YOUR blog, and kill everything
else.
If you don’t need links to previous and next posts, get rid of them. If a blogroll doesn’t really help you,
ditch it. If you and your readers won’t benefit from a list of links to categories, don’t include one.

12. Sometimes a blog doesn’t even need standard blog elements. A “tumblelog” is a form of a blog that
has no titles, no footers, no categories, no trackbacks, no search, no archives ... nothing. It’s just a
long series of very stream-of-consciousness posts that are either quotes, links, images, videos, or
ideas.
Of course, the trick is to avoid removing too much. Your page still needs a page title to provide some
sort of context. Tumbelogs often lack the most basic and standard elements of a web page. So be
careful if you do this.

13. turn beginner’s into intermediates, immediately.
Now that you’ve stripped down the app so only the important stu is in it, it’s time to focus on turning
beginners into intermediates.

14. Alan Cooper - “perpetual Intermediates”
Most users are not beginners. People learn as much as they need to learn very quickly, thereby
becoming intermediates. They rarely advance to expert level.
Design for the intermediates, but MAKE SURE PEOPLE CAN BECOME INTERMEDIATES IN THE FIRST
PLACE. How? Instructive design.
Almost EVERYONE fails in the area of instructive design. They never tell users how to use the app, and
they never figure it out on their own. If you hired me tomorrow to fix your app’s design, this is the first
thing I’d look at.
That said, I did find a few examples of good instructive design work. Some of them are discussed in
the book.

15. Surface the Help info.
Inline tips from Squidoo (from Seth Godin)
- Show up on rollover
- Short, concise tips

16. Take care of the “blank slates”
Basecamp screencasts
Fill up the blank slates with useful information
- Big red link
- Screencast

17. No milestones exist.
This is what it looks like with no instructive elements. Not very helpful, eh?

18. My Yahoo!’s blank slate is filled with a preview of what your page could look like.
No, Michael Jackson isn’t on it all the time.

19. Welcome screens:
- Call out what can be done on the page
- Show it to new users
- Set it to disappear automatically after the 5th login or something
- As people get more familiar with the app, you don’t want them to keep bumping into newbie
stu.
BONUS:
- You can use this again when you have a new feature to announce, so it’s dual-purpose.

20. [example of this applied to a blog]
This is a rather well-known blog that breaks the same rule that most other blogs break.
It doesn’t make it obvious that headings are links. Almost all of the links on this page black and
underlined. But the links to the permanent post page are green and have no underline. Oh, and the
link directly to post comments is ... um, purple. You know, so it doesn’t match anything else on the
page. Four dierent link styles on the same page.
So how does someone new to this page get to become an intermediate user of this blog?
Yup. He has to guess.

21. [example of this applied to a blog]
And in the tooting my own horn category, this is my blog.
Notice that every link on the page is orange. The only exception is the notification area at the top, but I
underlined that one to make it clear that it’s a link, so it’s OK. ;)

22. surface important elements.
To further help users understand how to use your app, and so they continue enjoying your app ...
surface the important elements on each screen.

23. Seth Godin’s banana principle:
- Put up clear signposts on a site and people will follow them, just like a monkey follows a trail of
bananas.

24. What’s this page about?
- There is a point to it, but who can tell what it is?

25. Add some links. Color makes things stand out. But not enough.
We want to turn these 3 links into giant, clear bananas.

26. Surface the main points of this page - the three hot spots.

27. Get rid of the instructions at the end of the text, and you’re done!
Much clearer. Now the monkeys can follow the bananas.

28. [example of this applied to a blog]
What’s the major call-to-action on this page? What is it that the folks at WordPress want me to do
when I land on this page for the first time?
Hint: Download WordPress!
Where’s the link? In the header, of course! (Kidding.)
What pops out the most on this page? The word “Welcome” and the screenshot on the right. Neither of
these things are clickable. And the word “Welcome” doesn’t mean anything to a user. It doesn’t help
them, doesn’t get them started, doesn’t provide context, doesn’t do, well, anything.

29. [example of this applied to a blog]
Any idea what’s on Apple’s mind today?
There are over 30 links on the Apple.com homepage. Which one do you think they want you to click?
OK, so these aren’t blogs, but you get the idea. If you write a blog post promoting something on
another area of your site, for example, include a link, and make it big and obvious.

30. prevent errors with poka-yoke.
(POH-kah YOH-keh)
Once they start using the app, make sure they can use it without feeling like idiots by making mistakes
all the time. This one of the best ways to improve your app. If people never make mistakes in your
app, they’re going to feel really smart. That’s a good thing, and it’s something most companies never
achieve.
From Lean manufacturing processes, this is Japanese for “error-proofing”
The best way to handle an error is to prevent it from happening in the first place.
Two types: Prevention and detection
Some examples ...

31. Popcorn button = prevention device.

32. “Did you mean?”
Great idea. Helps users fix their typos and helps them correct words they don’t know how to spell.
This is a detection device.

33. Google Suggest
Blurs the line between prevention and detection by helping you choose a good search term.
- Doesn’t work well for people who stare at their keyboards while typing, though.
- Also, people tend to rely on the suggestions rather than their own search terms, which may have
been better.
- If using this, use it for lookup actions (like looking up someone’s phone number), not for searches

34. Undo systems = fantastic.
- Get rid of JS alerts/confirmations (because they suck and no one reads them)
- Clear visual notification that you can Undo
This should be in every web app where you can delete or seriously aect data. (Right now, it’s not even
in every Google app, so we’ve got a ways to go.)
This introduces “forgiveness” into your app. People can play around without being terrified of breaking
things.

35. Anyone signed up for ODEO?
This shot doesn’t do it justice, but these fields are HUGE. And it doesn’t really help anything. They
didn’t do anything to make the form more usable, they just filled up the page.
Imagine this at 800x600 (for people with bad vision). Four fields, and two of them would be below the
fold.

36. RememberTheMilk
Inline validation = prevention AND detection.
- Detects errors immediately and notifies you
- Prevents users from hitting Submit before the form is correct.
- Should still be able to hit Submit (accessibility reasons, disabled JS), but this alleviates most of the
issues people have with forms. And they really appreciate it.
This one is good, but not quite perfect. Tells you there’s an error as soon as you hit the field, before
you have a chance to enter anything.

37. OurProperty.co.uk
Much better. Also includes inline tips.
Let’s take a closer look at the decisions for your form design.

38. Typical form.
Thinking back over what we’ve talked about so far, what can we do to make it better?
(Take suggestions.)

39. - Add instructive text
- Display checkmarks when fields are correct.
- Show errors inline.
- Show them next to the field.
- Show them AFTER the field loses focus
- Disable the I’m Done button
You can make these really big - it helps. Here’s an example:

40. Eventful.com - large errors = easy to see
MOST users can complete this form correctly before hitting SUBMIT
- Good for users
- Can translate to less bandwidth for you, because you’ll only get ONE server call

41. Completed form = I’m Done button lights up and you’re good to go.
Sadly, I couldn’t find an example of good error-handling on a blog. Typically, the only place this
would apply is when a user is adding a comment to a post, and when I went through all the blogs I
read normally, I didn’t find any that used inline error messaging like this.
Obviously, the moral of the story is that you should do add this to your blog. And since WP is open
source, you can hack around it and make that work. And since I’ll be spending Monday with the dev
team, I may just try to talk them into building this functionality into WordPress. :)

42. Questions?

43. Check out the blog at www.rhjr.net for continuous reality checks on application design.
I’ll be around, so feel free to come talk to me about your apps and ask questions and such. Enjoy the
rest of WordCamp!