Interaction08: Dan Brown and Jared Spool

Concept Models by Dan Brown

[I missed Dan’s introduction and story-telling. The room is packed.]

Let’s start talking about Concept Models with a mock assignment of building an expense report. He shows some hideous screenshot of an expense report and talks about our desire to make things better. You might have requirements and personas; now what do you do?

Someone shouts, “What’s the big idea?” It’s an expense report, there is no big idea. You’ve got a stack of requirements on your desk, you’ve got personas; what do you do now?

You could:

– do a flowchart. But the problem is that flowcharts preserve that screen-based approach to applications

– start wireframes; just sketch different ideas. (He shows an example of his wireframes with annotations.)

– brainstorm; all stand up at a whiteboard and sketch up. The problem here is that many of us don’t have people to collaborate with. Also, you might not fully understand the problem and its underlying concepts.

Underlying concepts? What are you talking about? Let’s go back to the requirements. I circle the interesting nouns. What do you do with this information? Well, you can create what I call a concept model (he displays a bunch of nouns–concepts–linked together). Circles connected by lines.

Dan’s showing a few example concept modules. The most interesting is a Flickr concept model, which takes a central theme (a user takes a photo of a subject) and builds on it.

[While I’m sure this was interesting to loads of people, I switched sessions mid-stream.]

Intuitive Designs by Jared Spool

Jared is showing some examples of bad designs by showing connection settings dialog. He showed negative examples from Google and Skype, amusingly saying that “you can tell Google employs Ph.D.s because you have to be one to understand their software” and “Skype was designed by high school drop-outs”.

He showed an example from Yahoo! Messenger which has very verbose descriptions in their connection settings area. He’s showing that they explain to normal users when they might consider using certain options (as compared to Google and Skype which are very geeky and require advanced knowledge to even understand the help). Jared shows how many of the Yahoo! screens have similarly excellent information.

AOL Instant Messenger one-ups Yahoo! with an “Auto Configure” button that automatically figures it all out, which is of course the best option, if it works. It’s what we call a wizard, which does things for us without having to train us. The wizard brings target knowledge down to current knowledge, whereas Yahoo! brought current knowledge up to target knowledge.

I now want to apply this to intuitive design. A design is intuitive when current knowledge equals target knowledge: the user already knows what to do. Or, the Knowledge Gap is very small. The user doesn’t perceive that they are learning.

I’ll offer an example from this hotel. I pick up the phone. What’s the first digit I’m supposed to press: 9. Everyone knows this. Well, let’s check. Jared shows examples from three examples.

Hotel 1 and Hotel 2 are both nine. But at another hotel, it’s 8. What idiot would make it 8? Don’t they know it’s non-intuitive? Who thought of that? That person should be sacked. And, if you’re suffering from some sort of emergency, you have to dial 8-911. Whose idea was that? What happens when you dial 911? Does it ring someone’s room? “Oh honey, just leave it be, they’ve been calling all night.”

This notion of what’s intuitive has to do with the knowledge we bring. 9 is no more special than 8. It was originally chosen because it was the one number after 0 you couldn’t dial by accident on a rotary phone. It’s been around since the 50’s. What’s amazing is that we all know to dial 9, and we know when not to dial 9. We know this instinctively.

There are two types of knowledge:
– tool knowledge–knowledge specific to one particular tool
– domain knowledge–knowledge about a particular domain that is portable across domains

[Jared is a very entertaining and engaging speaker; I was laughing almost non-stop since entering the room; sorry, I didn’t capture most of the jokes.]

Jared is deconstructing the EPA.gov website. My laptop is shaking from all the laughter. His points are actually pretty general: he’s showing how a simple bit of information about what school someone should attend is very difficult to clean from a poorly designed webpage and information. It’s a very thought-provoking exercise, including such points as:

– a long table with headers that scroll off the page and is therefore hard to read
– domain terms that aren’t defined that lead to confusion. For example, a column said “Handles Hazardous Waste” and he wondered, “Why would you want to attend a school that handles hazardous waste?” He drilled into the page and we only got more confused. It turns out that the school has staff that are trained to handle hazardous waste, etc. There’s a lot more negative examples I didn’t get–he moves fast.

It’s a business decision as to whether it makes sense to invest in intuitive design. Some techniques:

– Field studies (users in the mist): get users current knowledge
– Usability studies: test out target knowledge against current knowledge and the gap
– Personas: who users are and what their goals are, great for communicating to engineering team
– Patterns: package up the target knowledge and how to design for the gaps

What makes a design intuitive?
– Intuitive is personal to the user, based on their current knowledge and the required target knowledge
– Intuitive happens when the gap is minimized
– Just because something seems intuitive to you doesn’t mean it will seem intuitive to your user because of your knowledge and experience; you have to get to know your users

We have a newsletter: UIEtips (free) and we have a website too (www.uie.com). We have vritual seminars, and conferences and reports.