Category Archives: Interaction Patterns

Grids, Blocks, Behaviors and Attributes

Occasionally I work on projects that I know will turn out horribly.

This usually doesn’t slow me down, since I’m pretty confident I can turn it into something very cool.

Case in point, the shuffling block site I’m working on now. The projected behavior of the site reads like a list of UX no-no’s.

There’s a grid that doesn’t expand, despite the number of objects within, just starts scrolling downward.

The grid is filled with boxes of various sizes, interaction with the boxes makes them either grow larger, or link to other grids. No visible difference in boxes, just random behavior.

The grid re-shuffles every time a box is opened or closed, in a random order, like the system playing Tetris. Things that were there, are now over there.

Oh, but some boxes don’t move, and some boxes only have one size, and some boxes need to be marked so that on every shuffle, they get preferential treatment.

And somewhere in all of this is content.

If it turns out good, I’ll post a link. If it’s a magnificent failure, I’ll post a link.

If my worst fears come true and it’s sort of ordinary, you won’t hear another peep about it.


Core Concepts of the Ruthless Monk

The Ruthless Monk is my general approach to site conceptualization. Here is my general overview of the tenets of hitting something Monk Style.

The user’s current position is considered the center of the site. Wherever the user is, they are in the right place. Bring content to them, don’t use your navigation as advertisement. This only makes the user feel they are in the wrong place, and all other places are better.

Items that are of more relevance are closer to user. This means, stop carrying navigation and global elements around the site. If the user chooses a path, their focus is on that topic or action. Leave shit behind when it’s not needed.

The degree to which items are presented and the visual and cognitive impact they will have. Not everything can be cranked to 11. A simple visual inspection of every screen should reveal the top 2-3 actions you want a user to take. These are the items with the loudest volume, the rest need to be turned down.

Discreet modal shifts within a current space. I call these ‘Flips’ they are nothing more than div layers that contain a complete and concise task. They are called when needed, and should adapt to user position and mindset.

Story Shaping
Arranging user opportunities through a story metaphor. If I asked you to tell me about your new camera, it’s unlikely you would organize your thoughts in the same manner as a camera maker’s site. Think about how a conversation evolves, how people will interrupt at moments of interest and change the course of the discussion. This is real time Story Shaping.

Content will always beget an action. If it doesn’t provoke action, it is likely useless. Also, ask yourself what questions a user would have based on a piece of content. That is likely to inform your choice of actions you provide, and think ACTION, don’t always think movement.

If it doesn’t add something, remove it. Be ruthless in your dislike for every object on the screen. Strong, single and simple actions will always beat complex, wishy-washy activities. At some point, everyone is a uni-tasker… realize the power in this.


Mobile. It’s kind of a bitch.

(Although, designing for a platform like iPhone makes it much better).

But here’s what I found to be the biggest problem : Sticking to a single concept

I work for a company that specializes in moving and manipulating large amounts of unique data. My gig is making sure that data is usable, understandable, and mashed up in a manner that end users find valuable.

So, I design products. Some people call them apps, some call them services, I consider them products. They are tangible things that people interact with, and get improved based on that interaction. They’re long term, not a feeble microsite.

Anyways, it seemed like a no-brainer to start moving some of these products to a mobile platform, as one of my main pushes this year is in the saving, sharing and moving of information off a primary site and onto where users feel they need to keep it.

In starting, I uncovered a continuum in design rationale…

On one end is the Encumbered Complexity. Things that are too large, too forked, too unwieldily to be useful on a mobile device. (Unfortunately, most of our primary products fit in this category).

On the other end is Useless Minutiae. Information and features that could be moved to a mobile device, and usually upon first glance, seem like a great idea, but are too detailed to be useful, or replace a real-world activity that doesn’t benefit from being digitized. (Usually, the ideas seem great because my company controls or manages all the data, and no one else could create this product).

So, I’m working in the sweet spot between the two of them, following three pure and simple approaches :


Mobile is one part of a larger experience, and should act in conjunction with other devices and products that are not mobile.


Any mobile product must provide useful content and features that have reason to be mobile… and “because we can” is not a reason.


Kick the Andrew “Ruthless Monk” Method up a notch. One thing at a time, a single Item=Response metaphor. Even more so than the internet, mobile is a conversation, and one that must be streamlined.

I’m showing off the first of 3 Automotive-based mobile products this month at our annual user conference in Savannah. I’ll share them once I’ve done the dog-and-pony.

You are looking at it the wrong way.

Stop trying to dismiss the task in order to create something different. Instead, transform the ordinary into something remarkable.


I give loaded pistols to chimpanzees… sometimes they hit a target, sometimes they shoot their toes off.

Object, Action + Method

I was talking with a friend about car configurators, which is a topic I spend a lot of time on.

He was discussing this idea about inline config, having a small window open at specific times and ask the user to add or select an option.

In essence, a very good idea, I have several prototype screens for this sort of thing.

The problem became that the designers were struggling to figure out how the window operated, how it minimized, how the user re-activated it, and so on.

Here’s the root of the problem : They devised a Method that did not support the Object or the Action.

The super-duper Tigerstripe Approach tells us every task-based design problem has three main components. In this case they were The Car (The Object), letting users do partial configs (The Action) and the small floating window (The Method).

When one starts with a method, as many people like to do (“Dude, what if it just popped up there randomly!”), problems usually arrive.

Similar problems arise when a site-based method or set of rules is used inflexibly for all manner of data display or user interaction.

Here’s a tip, go in the right order :
Q: What are we talking about?
A: The Object

Q: What is the user response we want to promote?
A: The Action

Q: What is the best way for the user to interact with the system?
A: The Method

Save yourself some grief, there’s a reason UX is a different discipline that UI.

Forget the URL, Nab the Keyword!

Saw this today : Japan: URL’s Are Totally Out

Apparently, rather than advertise a URL, many ads in Japan are presenting a few choice keywords to search on.

With a decent URL harder and harder to find, and the rise of metadata, it makes a lot of sense.

It also makes sense if the use of the search can perpetuate a positive and high ranking for the right destination. Built-in rankings, baby!

It opens the question tho, with the highly competitive keyword mongering that corporations are involved in, would this work in the US?