Wireframes Aren’t the Only Thing

I’m at the start of a new phase of our development, and we’re at the point where we need to generate ideas for our interfaces. I’ve observed that wireframes aren’t always well-received by people who don’t understand them – clients who think they need more color, developers who want to code over it, etc. If the only resolution we have to this problem is educating the public, I think we’re in for a very long ride.

This might be because wireframes aren’t obvious enough to people.

You heard that right – if people are misunderstanding your wireframes for a finished product, or your sketches for a placeholder for a WYSIWYG dev tool like Visual Basic – there’s clearly something inappropriate about the tool’s use.

I believe some of us take wireframes for granted, such that we see no other way of implementing a product. While wireframes work well for some designers, I sometimes think they take up time and that there might be better, faster, more efficient ways to build software.

Also, wireframes aren’t great for super-dynamic AJAX-heavy interactions. And they aren’t great if you want to break out of the 2D mode, and work with more dimensions (how do wireframe a keypress, or an animation, or audio?).

I remember the first time I used tons of wireframes on a project, and ended up realizing that we wasted all that time building hi-fidelity prototypes just because I felt it was the right way to design an application. Time was wasted testing the prototype because we didn’t get THAT much insight out of it, simply because it was so blatantly obvious – we should have just tried it on ourselves before testing it on other users.

I’m probably stepping on some UX no-go zones – aren’t we supposed to test apps on real users, and not ourselves? Well, I think there are some things which are so blatantly obvious you needn’t waste the users’ time to fix or test. Testing via paper prototypes a la Carolyn Snyder isn’t always going to save you time. There are much faster ways to get it done, if you think through it a little.

I’m not advocating against wireframes. I’m just advocating against getting locked down on a specific method – against “methoditis” – you know, when you start believing that one method is better than another just because.

Basically, you might want to re-think wireframes if they:

  • confuse the people you’re communicating to
  • take up time when something else can be so much faster
  • cut down too many trees

Here are some examples or ideas of doing without wireframes:

Review: Inamo Restaurant, Soho

Immersive Interactions

This isn’t technically a food review, since it was part of a London IA “Field Trip” excursion organized by @AliceNWondrlnd. The main attraction of the restaurant was the interactive tables from which you could order your meal from. There are no waiters coming to take your order. They sit you down at a table, and each table has a “session”, during which you can order drinks, desserts, food, play games, change the table “wallpapers”, spy at the kitchen, track your order amount, and some other interesting stuff.

Customizable Table

Interactive Tables

The tables are given an immersive environment via overhead projectors and a trackpad on the bottom right corner of the table. Despite the excitement, the table was not a touch sensitive surface – we had to use the trackpad just as you would a mouse to navigate the “hand cursor” to interact with the system. I actually think it would be hard to design a system like Microsoft Surface, as we were resting our palms and arms on the surface of the table and not wanting the computer to pick those gestures up as interactions.

A small menu slides out, showing icons that indicate “drinks”, “food”, “table”, “entertainment” and “service” (I’m assuming all this, because the icons were not annotated with text or mouseover help). Each item leads to other sub-menu items, and they’re fairly easy to navigate.

A Drink that has my Name

Making an Order (Remotely)

When you make an order, you select an item from the menu and it appears on your order list. When you’re done with the order list, you hit confirm and wait for the food to be served by a waiter – it sort of just comes “automatically”. There is no interaction between you or waiters between any of the orders unless you specifically call for them.

This is quite a novel experience, but some people were afraid that they might have submitted the wrong order. A waiter assured us that it is possible to revert an order even after it has been confirmed, which is a good thing – but I think the interface could’ve been improved to cater for this – a waiter actually confirmed that this problem happens very frequently.

Placing an order was way too easy, which meant that the bill just kept going up. It was a bit like Amazon’s 1-click system – and it wasn’t obvious at first how to remove items from your order list (you needed to hit the minus sign next to your item in the order list).

Circle of Order

Interactive Tables

In between waiting for the food to arrive, the table “entertains” you by giving you the option of playing one of two games (battleship and those picture puzzles where you have to move blocks around). You can also change the “tablecloth”, which was quite a nice touch as that made the whole experience so immersive. You could also view the live “kitchen cam”, and see what the chefs are up to. I didn’t find the “entertainment” options too distracting that I ended up not talking to the others. And to be honest, our discussions weren’t always focused on the experience of the interactions, despite being user experience geeks and all.

"Table"-paper

Overall experience

Interestingly, the waiters didn’t take long when we used the interface to “call” them. Service was fairly prompt and cheerful, so no complaints there. My only rant was that my set meal was a bit small – I ordered the cod set meal, and it was not enough for my large appetite. Despite this, the food tasted really good but you really end up paying for the overall experience, really.

The table “session” stops once you hit the “call for bill” button. Once that’s pressed, you can no longer order anymore items (unless you call the waiter), nor can you check the total of your order – which was a shame because we had wanted to pay separately. Thankfully, they were able to provide us with a seat-by-seat breakdown of the damages.

Not Even a Glass of Water?

The trackpad was okay except when I accidentally placed a small bowl of miso soup on it, and the undersides of the bowl had some sauce so it make my trackpad sticky. One person mentioned her left-handed accessibility issue.

It’s not the only restaurant in the world to integrate interactive order systems. I’ve frequented Sakae Sushi when I used to live in Kuala Lumpur, and they use a more conventional mouse and screen setup. But obviously Inamo wins hands down for sheer experience, food and otherwise.
All Chocolate, They Say

Review: Visual Thinking for Design by Colin Ware

Visual Thinking for Design (Morgan Kaufmann Series in Interactive Technologies)

I was one of the lucky winners of this book from Morgan Kaufmann after I donated some money to the IxDA fundraising initiative. After turning in my MSc Project dissertation, I finally had some time to catch a breath. You’d think that reading a book on Visual Thinking would be the last thing on my mind after losing weeks of sleep to writing… I’m surprised myself.

Anyway, at a glance, this book is about understanding how we as humans interpret and interact with objects and environments visually. It’s written mostly from a psychologist’s perspective, and provides useful references to the theory and science of visual perception, cognition, attention, etc.

Colin starts off talking about how the eye and brain processes and perceives visual stimuli, and each chapter concludes with a set of design recommendations. He gradually works upwards the abstraction layer, dealing with topics like color and shapes, the relationship between visual and verbal processing, the process of “seeing” or “thinking” by sketching, leading up towards how we perceive meaning in a visual world.

I felt that I understood the subject matter a little better because I learned about cognitive science during the HCI course, so readers who are new to psychology may initially find it slightly alienating. I also feel that designers who are looking for design ideas may not find this book as an inspirational resource. I see this as reference material – something you pull out to make sure you’re doing things right, like getting more substantial evidence to support design ideas in problem solving.

It’s also a fairly easy book to read. Despite references to psychology terms like V1, V2 and top-down/bottom-up, the author succeeds in explaining things in simple language, and provides good examples of how the science of visual perception is linked to visual design.

The best parts of the book lie towards the end, and I think that the early chapters act as building blocks that support the overall perspective summarized in the last few chapters. The gist of it is that our mind, eye and body works together to look for patterns in the world, and that understanding how this takes place can aid designers in helping users to make sense of things more clearly and easily.

The implications on p. 172 are a key takeaway:

  1. to support the pattern-finding capability of the brain; that is, to turn information structures into patterns
  2. to optimize the cognitive process as a nested set of activities
  3. to take the economics of cognition into account, considering the cost of learning new tools and ways of seeing
  4. to think about attention at many levels and design for the cognitive thread.

(The word ‘cognition’ refers to the “process of thought”, i.e. thinking.)

In summary, this book is worth an investment. It’s one of those resources I will occasionally refer to for clear, evidence-based recommendations for visual design.