Because I have been doing a lot of PHP plumbing lately, I’ve been thinking a lot about implementing a web interaction framework that would make my life easier as a web developer cum interaction designer. One of things that got me thinking is the amount of complexity that’s involved in provide the right kind of feedback at the right time to the user.
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?
- 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.
- 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.
- 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.
- 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.
- 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.
