The Interaction Design Process

By now we have an understanding of the real complexity associated with Interaction Design. So what's a typical process. In the next few slides you'll see the steps that a designer will go through during a project. They're drawn as being discrete steps, but in reality they often blur into each other, happen out of order, backtrack, repeat and so on. It's not as tidy as I've made it appear. And this is a good thing - because all that messiness helps us not miss some subtlety in the problem we're solving.

But that said, lets look at the steps. First up we have the research tasks. User research informs us of our users needs, and their skills and limits. The technical briefing makes sure we design something we can build. The domain research is where we make sure we know about the business and legal frameworks we're stepping into.

Only once we have some grasp of these can we start to define the problem we're trying to solve. The problem definition is a technology neutral description of what it is the system we're designing is meant to achieve. At this point it could be implemented by chiselling runes into stone obelisks for all we care - implementation has no place here. It's just about what outcome we want in the world once this magical new system is in place. Having got this we can then start to think about what abilities the system will need in order to be able to achieve this end. I call this the Capability Definition. Again, this should be technology neutral. It should consist of a list of capabilities such as "assign people to work on specific projects", or "send an invoice to customer".

Now we're ready to start thinking about the kind of solutions we might create - the conceptual design. This is where we start to think about technologies - but only at a high level. We'll consider whether to use a desktop computer or a handheld, but we won't worry about whether it's a desktop application, a web application or what platforms it'll run on. That's too detailed. We will agonise over the mental models our future users are familiar with and generate a coherent model that is logically consistent with their pre-existing understanding, and of course with itself! This is where we make sure the solution fits people, so we won't later end up forcing people to fit the technology.