Everyone’s hyped up about getting a Google Wave invite. I have one and I don’t see what the fuss is about. Yes, I’ve seen the YouTube video, and yes I’ve watched the Developer Preview video too. It looks great and all, but seriously folks – it’s one complicated thing… next to email.

And this is why Google Wave isn’t about email. The same way computers aren’t (just) about calculators.

What it is is real-time collaborative messaging with historical playback. Which, granted, is very good for real-time anything. Except that real-time in human terms is highly contextual.

Because people have better things to do besides sit in front of their computers all day long, they are much better off carrying Blackberries and having push email rather than collaborative messaging. In my opinion, push email works just as well – because you don’t need to be in front of a computer to communicate with your colleagues.

Wave is also a tool. Meaning that the interface itself is not the message. In order for users to synthesize information, they have to make sense of it in a collaborative sort of way, which means paying attention to whatever is happening in that messaging window, which takes up at most 1/2 of the screen. It looks and feels like, a video player – but for messages. Think of IM on steroids, not email.

Email works because it’s mind-dumbingly easy. And because of that, nobody needs to take 3 week lessons on how to use email – and that includes your grandpa. And because it’s so atomic, it can easily be transported as a message to any other atomic messaging forms – SMS, blog post, forum post, IM chat, whatever.

Waves, on the other hand, are almost asynchronous streams – anyone can start writing content at anytime into a wave, and hope that it doesn’t make a mess of the conversation. Last I checked, people still pay attention to body language and subliminal messages, both of which are devoid in Wave but affects the way people communicate collaboratively and socially together – i.e. turn-taking and all that jazz.

Which part of a wave is atomic? You have to spend effort to calculate and decide. Then you have to find a way of “clipping” that message – and how do you make it portable? Can you cut and paste portions of your wave onto your blog? SMS? can you print it out?

Like email, most of what is published gets fixed in time. But a Wave, is a collection of content played out over time. Just like how photographs put together over time become videos. But with the added complexity of multiple sources of photographs, it becomes more and more difficult to separate and organize content in a Wave.

And that’s why Google Wave is not about email.

Sites and Articles Relevant to this Post:

• It’s Just Fancy Talk
• EasierToUnderstandThanWave

User-Centred Design – Using What Works For Me

I felt that a lot of “formal” usability methods didn’t help me much, here. I felt somewhat trapped by procedure and process, thinking about best practices for wireframes, personas, user journeys, etc. Having been exposed to too much user experience jargon, I realized that user-centered design isn’t necessarily synonymous with visual design. In fact, each stakeholder seems to have a different understanding of who the user is, even if the differences are slight.

What ended up working for me was to put down the questions I felt the users would ask (while using the interface/application) onto little bits of post-its, and looked for patterns like organizing those questions into related categories. I organized this in several ways:

“User Journey”-type Things and “Site Map”-type Things

One way of visualizing the questions was to list them out in the style of a “user journey”, which were lists of questions laid out in a temporal fashion (e.g. question A leading to question B as a user traversed deeper into the application). This helped me understand which questions to address first, and which to address later. It helped me prioritize my workflow, and make decisions on which interfaces to work on first. It was already obvious that we needed to focus on designing the homepage, but there were other pages that weren’t immediately obvious, such as a page to help users to “learn more” about the product – that page only came about after looking at the questions from the user journeys.

Another way was to group the questions that were related to one another, and label them as categories. That helped me to visualize the overall site layout, because I absolutely hate building software in the dark – and that includes building on software requirements without understanding the whys to the point I’m convinced of its business and user needs.

At this point, I hadn’t used any formal methods I had learnt from a class, website, or book. It was good that I understood who I was designing for, and I wouldn’t have been able to do this without classes, websites and books – but the formal methods were pretty useless. I just used what worked for me.

We Used Fireworks, but I can’t Recommend it to You

It’s important to note that two of us jumped onto paper and pencil and did wireframe sketches, and then designed a hi-def visual of the homepage on Fireworks (which I now really love) – only because we were three people and we couldn’t quite picture the outcome in our minds. At the same time, we needed our boss to make a decision and he has a lot of emotional attachment to the look and feel of the site, being the founder and all. So it was important to get those designs out.

I don’t think I can recommend the same process to other designers – it really depends what you’re designing for. Those fireworks designs took up several days and a lot of it was thrown out of the window as we iterated from one design to another. But I think that’s necessary in design, sometimes – because the interface is what users will end up seeing and using, again and again.

Sometimes I read articles from other designers and it all sounds really cool and makes you feel that there’s some kind of order or process in the design of an interface. But I find these things hard to use because it’s the designer that makes a difference, not the method. It’s about knowing what you know that works – a process or method can’t save you. They’re just tools.

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:

• http://gettingreal.37signals.com/ch11_Dont_Do_Dead_Documents.php
• http://code.new-bamboo.co.uk/polypage/ (a tool developed by Clearleft and New Bamboo)
• method-acting (see Bill Buxton’s Sketching User Experiences for an example a designer “being” the device)
• plasticine? feel free to add your own examples.

No plugins allowed

It’s not as easy as hooking up messages to specific URLs, which get displayed when an action is performed. Interaction is complex, some involving multiple conditions and terms. And you can never design for everybody in mind, because there’s always an issue of context that you have to deal with. So, then what you’re actually trying to build is based on an assumption of the kind of context that is most appropriate for the task at hand.

For example, take the simple case of a password reminder. Although it’s relatively straightforward to implement a mechanism to send off a password via email, how the user  has arrived at that task is another thing altogether. A password reminder system for an online banking application would look a lot different than a social networking site. Do you send the password along with the email? Do you send a link with that takes the user to a page to reset the password? What should the messages say? How often do these password reminder tasks occur with the existing user base? How did they know how to find help?

With such a basic task, there’s already so much to consider. What more a task that involves collaboration, scheduling, persuasion, trading, payment, and communication.

The bare necessities

This is when I started to take a step back and ask myself – what are the most essential things that I need to build an effective interaction framework?

1. I mentioned feedback, so I think notification is one of them – a way to inform the user regarding the state of the application or system.
2. Then, I think there’s the element of context I mentioned earlier - technology can help with helping us understand more about what is appropriate, and also helping us in designing for what is appropriate.
3. Also, I don’t think we can ignore the interface itself - all the buttons, fields, and little components that are used to interact with the system. I think this is the main part in what we usually consider as interaction design.
4. Somewhat related to the issue of context, but I feel deserves its own section, is testing - or, evaluation. This is so that we can identify potential areas of improvement by understanding the patterns of existing user behavior.
5. Finally, because all interaction is both a function of time and space, I feel that there needs to be an element of process – some kind of journey, or set of occurences that take place one after another. Much like how stories are expressed using specific narratives, interaction is also played out between the system and user through various sequences.

There may well be more, but these have been on my mind lately – ways in which I think a framework could help in solving interaction design problems.

Design patterns and human predictability

While I think design patterns like the ones from Tidwell’s ‘Designing Interfaces’ or Welie’s pattern library are extremely useful resources for solving interaction problems, they are also somewhat limited as they don’t propose more high-level strategies for interaction design. This is simply because many of these patterns are extremely tangible, and are essentially a collection of existing interactive solutions that have been known to solve common problems in interfaces (e.g. accordions, tooltips, tag clouds, wizards, breadcrumbs, etc.)

This is where I think an interaction framework can help – by providing the necessary “glue” and language by which these patterns can coexist and integrate in a flexible, scalable, managable way.

My inspiration comes not from the hubris of Steve Jobs, nor the empathic anecdotes of Don Norman. Neither is it from the pragmatism of Cooper’s Goal-Directed Design methodology, to which I owe great thanks in sparking my journey toward interaction design. Instead, I was inspired by J2EE design patterns from my early days as a Java developer.

This is an important distinction is because all of these design patterns come to play in a systematic, structural whole. Whereas, many of the existing interaction design patterns we know of now are sort of separate and somewhat distinct from each other.

	System Architecture	Interaction Architecture
Transform, Manipulate, Guide, Communicate, Create, Translate, etc.	Bits, Bytes, Strings, Numbers, Objects, Packets, Records, Emails, Documents, Interfaces, etc.	Emotion, Feeling, Mood, Action, Behavior, Values, Words, Drawings, Opinions, Stories, Decisions, etc.

In a way, I am envisioning an interaction architect structuring an interactive system the way a system architect designs an application’s infrastructure. The system architect defines the language in which data (or manifestations of it) is transformed, manipulated, sent/received, created, etc. The interaction architect defines the language in which human attention, behavior or actions are transformed, manipulated, communicated, guided, persuaded, etc.

Some comparisons

Bill Verplank proposed an interaction framework that looks really interesting. It’s set up mostly to assist teams in designing interaction and interfaces, and has little to do with the actual nuts and bolts of a particular interaction technology. This is all fine, because as an interaction designer you don’t necessarily want to lock yourself down to any particular technology. In the same way, Cooper’s Goal-Directed Design also proposes a methodology that provides a practical framework for understanding who the target users are and designing for them. GDD also takes the approach of being technology agnostic, although Cooper mostly refers to software interfaces like desktop applications, mobile phones and websites.

However, I think there’s a growing need for a technology-focussed framework – one that sits just between the sort of team-focussed, process-driven, project methodology – and the tangible, collective, distinct set of pattern libraries I talked about earlier. I am probably thinking about web applications, but this can apply to any other technology (Air Traffic Control systems, for example).

The J2EE design pattern specification exists for Java architects to build enterprise Java applications in scalable, managable, flexible ways. In a similar vein, interation designers can establish similar frameworks for their own interactive systems – that sits between the system and the project, that can be expressed in terms that are more closely linked to the systems themselves (like interaction design patterns are), rather than wireframes, storyboards, sitemaps, affinity diagrams – stuff that’s more commonly used for communicating between people rather than communicating between systems.