Interactions and questions

My frequent collaborator Jeremy Yuille is off at Interaction 11 in Boulder this week, where he’ll be running an activity focused on interaction design fundamentals. Over the last few months, Jeremy and I have been working on a new iPad app… which I’m not going to write about here (at least, just yet).

I do want to note down something about our process that struck me as interesting though – there was very little “visual” design involved at all.

We did almost nothing in the way of sketches and wireframes, and the only visual work I did in photoshop was a few png files for shapes that were a little harder to draw in code. There was very little documentation other than some notes taken down after meetings or recorded sketches (which, incidentally, I never referred to).

Instead, we worked almost entirely with interactions and prototypes: Jeremy would establish a scenario or use case, and we’d develop a prototype – through discussion, a “test” (usually no more than pointing at pieces of paper or a post-it on a wall) – then I’d code a quick demo to check the interaction and performance on the iPad.

Each step of the design process had two basic questions:
1) What is the desired outcome (for the user)?
2) What is an interaction that will achieve that outcome with a minimum of friction?

This approach seemed to free us from traditional design patterns and solutions (though we did use traditional patterns where appropriate to the outcome) – by sticking to the pattern of “interaction supports outcome” you stay focused on the user experience in a way that other design approaches don’t always afford.

In fact, when we didn’t ask these questions we tended to get stuck. When we asked ourselves “how will we implement groups?” (a question about a specific information structure) we spent a long time trying to solve complex implementation details. When we instead reconfigured the question: “what is the outcome we want when we use the word ‘group’?”, we discovered that “groups” weren’t actually what we needed at all – we needed a different interaction altogether.

It was very important that this was done collaboratively. We would do thinking and coding separately, but all the “design” happened through discussion – this way questions could be asked, interpreted, and designs modified on the fly. The design happened through constant rethinking and questioning.

The process was iterative – each demo that I coded was tested against the outcomes and modified – so our finished alpha is essentially just a sum of the interactions that we kept from each demo.

The interactions are the interface

So what does all this mean in terms of a design outcome? It means that the visual design of the app is nothing more than a set of interactions that facilitate specific actions. Any visual “flair” either arose from an informational requirement (user feedback – a highlighted state), or a hierarchical need (size, position, object delineation).

Now, the app that we’re working on is unusually suited to an “invisible design” – it is a visual thinking and presentation app designed to work with a variety of user generated content, and designed to keep out of the way of the content wherever possible (much, much more on this when it is ready for the public). But I do think this process could easily be applied to all sorts of product development, and it is one that I’ll be using regularly in the future.