Since the final form of Olinda is out in the world, I had a dig in the archive - and the studio - this morning and found some of the physical visualisations from along the way. It was fun to look back and see a classic case of thinking through making.

I know Jack will be posting design notes in the coming weeks. For the moment, this is all about the pictures.

This isn’t physical, but it’s a good place to start: the image is from our proposal document, before any feasibility work. When that begun, we went back to the drawing board and explored other designs: Jack talked before about drawing Olinda as exploration.

Our original intention was to use bamboo ply and formica to make the radio. We’d come to sloped forward-facing surface of the model by imagining it attempting to look towards you (instead of being on a vertical plane and forcing you to crouch down). It’s a small gesture towards meeting the user half way, and its echoes remain in the final piece.

Another retained element is that the buttons and dials encourage force downwards through the radio into the shelf or table. That means you don’t have to support the radio with one hand while you push a button on its front with the other.

Wood form explorations continued, aided by Jeff Easter, who was working with us on this part of the project.

Again, you can see more mock-ups of these in Jack’s drawing post.

Here the wood now incorporates a plastic shell (as mocked-up with card).

As we got more into the communications purposes of the project, we realised that the ultimate intention was to demonstrate that a social and Web-like experience was possible in consumer electronics, and in particular DAB radio. But to show this, to people in the industry and at the BBC, Olinda would have to draw more from product processes and aesthetics.

Given the conversation needed to be about particular features and not distracted by a total change in design, this meant the form became more traditional… which in turn led away from wood which, for structural integrity and precision reasons, couldn’t give us the form we needed. It was worth seeing whether we could hang onto some wooden elements.

Meanwhile the component sizes - speakers, screens, PCBs and so on - were becoming known. There was a brief foray into vacuum formed plastic to see whether it’d give us the required shape and quality.

On the left you can see the last attempt with wood, investigating whether cabinet making techniques could give enough structural strength and quality of finish to pass muster in the product space. Not quite, is the answer, and the work consumes a lot of workshop time: it turned out to be more economic to use repeatable manufacturing techniques and poured plastic.

But the main model here is not a visualisation but part of the hardware rig used to give a good feel of the interface during software development.

There’s the same hardware rig in use.

The rig wasn’t the first instance of the final user interface: Jeff had built a Web-based simulation, so we could feel it in use, and every button press from every state (and time-out events) had been mapped on paper.

Note we hadn’t yet hit on the double dial (the outer dial scrolling through stations alphabetically, the inner learning from your habits and giving you only your most listened). It wasn’t until the Web UI prototype that a good metaphor for the dial emerged, and the idea of coarse+fine tuning (seen also in the Beolit) was one of several factors that took us there..

Finalising the manufacturing technique allowed Jack to develop the form (this is the final CAD model). As I mentioned before, Olinda wears its heart on its sleeve: the form betrays the processes that created it, the ideas beneath it, and its history. There’s no universal visual design scheme, just each interface element being allowed to tell its story. This lets people, I hope, look past the form to concepts like social networks and the Lego-like modularity.

The look of the hardware interface is its own story. Though I’ll mention, briefly, that it was through these computer models that the hardware interface came to be displayed on the end of the friends module too, so that the radio would continue to advertise its modular nature even when assembled.

And there it is. You can see the heritage - chunky controls to advertise use and invite participation; the sloping interface - and how it has developed.

I’ve chosen this image because it illustrates a design decision that emerged very late in the process, only when the weight of the final units could be felt: the placing of the aerial at the base of the main unit. Several radios have it emerging from the top, but this means brushing past the aerial can topple the device over. By having the aerial attach at the bottom, knocking it doesn’t impart enough turning moment to destabilise the radio. Discovering that happened in a real sweaty palm moment.

These photos and more can be found in the Olinda Flickr pool.

I’m pleased to be able to bring you Olinda, the social radio prototype we’ve designed and built for BBC Audio & Music.

Tristan Ferne, who commissioned Olinda and leads the BBC Radio Labs, is currently at the Futuresonic Conference, discussing what happens when you put social networks and the Web inside consumer electronics - in particular, this radio - and is giving the folks there the very first look. But for those of us not in Manchester…

For background, photos and more, check out Olinda.

Recently at Web Directions North, I introduced Snap, the syndicated next action pattern. It’s a way to get all those little interactions out of websites, and all in the same place: your newsreader. You can watch and read the presentation here.

In this post, I want to expand on those slides to introduce Snap and show it working.

What kind of ‘next actions’?

There are loads of small next actions. For example:

• Taking a new bug in a tracker, and accepting it, allocating it, completing it, or marking it as a duplicate
• For an email or weblog comment in a moderation queue, accepting or deleting it
• Clicking through and perhaps purchasing a recommended book

It’s tedious to move around the Web to do these actions. It would be better if they were all in the same place. We had this same problem with weblogs and other media, and RSS was invented to syndicate new entries to the desktop.

What I’ve previously suggested is that we need a kind of RSS for interactions–and you can see a mockup here. At the time, the concept got some attention.

Conceptually, each ‘object’ that requires interaction is a feed entry. The actions are shown as an HTML form, and using the form sends data to the website which updates that object. The feed is then updated, changing the original entry to show the new object state. The original object state is no longer visible. This requires the newsreader to allow HTML forms and respond sensibly when feed entries change.

I’ve been working together with Tom Armitage on a proof of concept (of which more in a minute), and the headline is this:

Feed entries can indeed represent interactions, and update to show new states. The user never needs to leave the newsreader.

This is the pattern I’m calling Snap. It works, and we have a demo.

Demo: Dentrassi

For the proof of concept, we created Dentrassi (Tom did the heavy lifting), a desktop todo list manager which can be run entirely through a newsreader.

Watch a screencast and transcript of Dentrassi in use.

The app demonstrates a number of ideas:

• There is an admin feed which has persistent entries. One entry includes a form, which is used to add new tasks
• New tasks appear in the inbox feed, until they are allocated to projects
• New project feeds are created dynamically: users can subscribe to a project feed from another persistent entry in the admin feed
• Every task feed entry is smart: each includes a form to show the available interactions, so tagging, task completion and editing all happen inside the newsreader
• Tasks move from feed to feed so you can focus on different lists of next actions at different times

Tasks only appear in feeds if they require actions. This means there’s a single place you look to find what to do next.

One interesting feature, not in the demo above, is the idea of the deferred task: a task can be pushed into the future by some day - a day, a week or a month - and it then disappears from the feeds, only to reappear when it’s valid again.

Dentrassi possibilities

Imagine having your todo list manager - whether it’s iCal or TaskPaper - expose a Snap interface, so you can use it entirely from your newsreader.

Tasks could then be mixed with interactions from all your other sources - like email moderation or bug tracking - and even tasks from other people in your company. Perhaps tasks from other people would be read-only, or maybe you could collaborate.

Lessons learned for Snap

We learned a lot from Dentrassi. Some points:

• Stale items: once you act on a feed entry, the entry is stale until the feed is refreshed. Problems are avoided, in Dentrassi, by giving each object a serial number which increments on updates, and refusing to accept updates from forms which don’t pass in the current serial. This isn’t great from a interaction design perspective. Instead each feed item should query the server when it’s viewed, showing a ’stale’ badge if a refresh is required. If the user is offline, an ‘unknown’ badge should be shown instead.
• Disappearing entries: an entry will often disappear from a feed once it’s actioned. It’s important that a newsreader allows the entry to vanish, and doesn’t keep its old state as a duplicate entry (GUIDs help here).
• Keeping interaction in the newsreader: when the follow-up to submitting a form is a success or failure, Dentrassi shows a badge. It would be good to have a standard way of reporting status. But sometimes the follow-up to a form is another form, and that’s tough: the interaction has to move to a website. Using Ajax inside the feed entry will help.
• Subscribing to feeds from within the newsreader: inside feed entries, new feeds URL should be prefixed with ‘feed:’ to make sure the newsreader handles them directly, instead of opening a Web browser.
• Working offline: there is currently no way to work offline. It would be good to have the newsreader cache the form data to send… although this may pose a problem if Javascript is being used.

One point to look further at is how to improve newsreader support for this usage. Maybe there could be a Snap profile for Atom, in the same way podcasting is supported by enclosures? If forms were ‘enclosed’ in feed entries, they could be shown separated from the main body - more like a dialog box - and it would be clearer how to use them. This was the look that seemed to make most sense in Dentrassi. In my original mock-up, which just used the straight HTML, the forms look confusing.

Other possibilities

I’ve mentioned a number of possibilities for Snap in general:

• Mixing together multiple ‘next action’ feeds from different sources
• Having several feeds representing different states of a process, for example different Snap feeds for the different states of a bug in a tracker
• Desktop applications exposing a Snap interface, for local use. And using the location of the feed request to show full feeds or read-only feeds, for collaboration
• Having multiple people work on the same applications, each using a different mix of feeds

These are rather abstract, so here are some systems that use these patterns:

• Multi-player turn-based games, like Risk, or Scrabulous
• An editorial work-flow for a CMS, where each article goes through a number of states, dealt with by journalists, subeditors, editors and other sign-off parties. The documents could be links to the Web, or included as enclosures. A persistent item would allow the upload of new documents
• Similarly, an HR system. Employees would use a website or persistent feed item to submit a form, and then track its process using a single feed. The HR team would have an interactive version of the feed
• iPhoto exposing a Snap feed of all untagged photos, to encourage me to categorise them
• A blog feed which has all posts, and a comments feed which only shows comments from posts the reader is following. A reader follows and unfollows posts by using a persistent entry in the comments feed
• The Facebook activity steam, except each entry carries with is contextual interactions: see more/less of this type of item; add this person as a friend; join this group; enlarge this photo; add a comment
• Feed pipes, slim applications which take a single object through a number of steps in different applications. For example, the same feed entry could represent an untagged photo in iPhoto, then the same photo uploaded to Flickr, which then becomes an object which can be commented on
• A feed of ‘travellers you might know’ from Dopplr, each having a form to either share trips or ignore for a month

Snap as part of the Web

RSS/Atom is simple human interface to website content. A REST API is a simple machine interface to website functionality. Jabber/XMPP is gaining attention for being a machine interface to website events. Snap sits in this same constellation: Snap is a simple human interface to common actions, on a website or desktop application.

All of these are ways for websites to get blurry edges and mingle into one another. They offer ways for website to be recombinant, so that each can build on the functionality of others. They also offer ways for websites and applications to be more humane–to let us build around the tasks and experiences of people, rather than the features list of an individual website.

Snap isn’t a technology. Snap is an interaction pattern which works right now, and I’m convinced makes the experience of using websites better. I’m hoping you’ll give it a try.

Next action!

So, what’s next?

Go read Tom’s post on Snap, about building the proof of concept and the interaction design learnings that came out of it–in particular how the big tick is useful for hitting flow states. That’s first.

Second, if you have a web app, it’d be great to see Snap happening. Feel free to drop a mail if you want to bounce ideas around (and I’m sure Tom would be happy to speak with you about it too).

Thanks

Thanks again to Tom Armitage, WDN08 for giving me the opportunity to think about this, and Ben Hammersley for hosting the session which led to this, way back in 2004. (Also…)

A couple of months back I visited Tom and Durrell at Luckybite to discuss some of the Olinda development. During our conversation, Durrell described one of his favourite portable radios, the Bang & Olufsen Beolit 600. I bought one.

The range was produced between 1971 and 1981 and aside from its elegance and good audio quality, the detailing is very deft.

Tuning with magnets

The chassis is constructed from aluminium strips, holding plastic shells front and back. The controls for the radio are spread out along the front and back edges of the top face. On the back edge are buttons for band selection and two sliders for volume and tone. The entire front edge is a horizontal tuning slider.

The slider can be grabbed and pushed quickly up and down the length for coarse tuning. To tune precisely the two small kinked wheels are rolled under the thumb to give fine control. The remarkable detail is in how the selected frequency is indicated:

Two very small steel bearings sit in covered grooves in the aluminium chassis, one for each tuning band. The tuning slider conceals a magnet, which drags the bearings along the scale inside their grooves (the aluminium is of course unaffected by the magnetism). The position of the bearings corresponds to markings on the surface of the radio which indicates the frequency the radio is tuned to.

It’s a really nice example of celebrating functionality. There is no functional need for the bearings. The additional cost to develop and manufacture can’t possibly have made financial sense. Why not use an arrow? But tuning is what radios do, and something which articulates this most familiar function so poetically just had to be done.

I love how the furthest bearing twitches along more slowly than the closer one.

Construction

Structurally the radio is a square of four lengths of extruded and cut aluminium, with the front and back plastic shells tucked in. What’s exciting is that taking the radio apart isn’t work: there are no machine screws or self-tappers.

The base plate of the radio can slide. Sliding it a little way first unlocks the back shell. Removing the back allows the base to slide more, which releases the more rarely removed front shell. All this is achieved with a clever system of grooves and nooks.

Coming off first, the back shell gives access to the battery. The front shell reveals something else.

The repair manual

Inside the front shell, there is a little envelope. Inside the envelope there is a piece of folded paper.

Screen printed on the paper are all the instructions for repairing the radio. There is an abstracted circuit diagram and also an image of the actual PCB. The radio contains its own data sheet, physically!

I’ve cut these last two images together to show that the PCB and the print in the diagram are to scale (the screens were probably made from the same drawing).

One of Olinda’s jobs is to communicate the potential for hardware APIs. Matt discussed this in detail in his post on widgets.

Olinda is expandable and modular. For this to be effective, the core services of the central unit really have to be accessible from it’s periphery. We don’t mean superficial expansion or extension of lineout (like adding a speaker), but actually change the nature of the object, to grow from it’s core. There is an obvious predecessor in consumer electronics in hi-fi separates, although it is limited in that the turntable cannot affect the services available through the interface, on the amplifier. The extensions for Olinda will be able to make the radio a new object with each addition (In our case main and social do this).

Part of this project is to discuss modularity. (While designing the physical radio itself is a large part of the work, the larger project is about communicating the core ideas.) The connector is effectively a serial connection between the main unit and the extensions (plus a few extras). This could have manifested as a serial cable with two sockets on each unit, much as they appear on old printers and the like. Although traditional connections and cables have historical precedent, they do not sufficiently raise modularity.

We were clear early that the mechanism for connection should be visible, rather than discreet. It should go out of its way to invite extension (Matt discusses these ideas with reference to the Levittown Homes in his talk, The Experience Stack). One should see how it extends and the connection be mechanically explicit. The use of the mechanism, the act of extending should feel really satisfying too. For the reasons described above the serial cable fails.

Connector developments

Each module needs to include a surface which connects to the previous. Software and power aside, the implication should be that the units are infinitely extensible. To begin with we examined the possibility of a mechanical connection, something with toggle clamps or vertical stacking.

Kiyoshi Seike’s book on Japanese joinery includes some beautiful imagery, above.

In some early work we experimented with connections in wood. As the process progressed and more influences on the form of the radio emerged, we chose to explore a system of magnets and studs. This delivered the most satisfying feeling and the building brick aesthetic taps nicely into the familiar heritage of Lego.

This idea came out of both Apple’s MagSafe power connector, and a previous project on RFID which touched on using magnets for tactile feedback to make reading RFIDs more like pressing a button

So in the final model, the entire end surfaces of the modules are positive and negative connectors.

These two images show the progression of the studs, looking for a good fit and a good feel. These models also explore how the magnets are to be included.

There are eight electrical connections between the modules. These are a line of sprung copper domes, held against copper blanks on the opposite face by the force of the magnets.

Above is the most recent and final connectors prototype before machining, and the image following gives an impression of the final form.

Much of the early work in this process was produced with the help of Jeff Easter, thanks Jeff!

Last week, Tristan Ferne who leads the R&D team in BBC Audio & Music Interactive gave a talk at Radio at the Edge (written up in Radio Today). As a part of his talk he discussed progress on Olinda.

Most of the design and conceptual work for the radio is finished now. We are dealing with the remaining technicalities of bringing the radio into the world. To aid Tristan’s presentation we drew up some slides outlining how we expect the core functionality to work when the radio manifests.

Social module

This animated sequence shows how the social module is expected to work. The radio begins tuned to BBC Radio 2. A light corresponding to Matt’s radio lights up on the social module. When the lit button is pressed, the top screen reveals Matt is listening to Radio 6 Music, which is selected and the radio retunes to that station.

Tuning

This detail shows how the list management will work. The radio has a dual rotary dial for tuning between the different DAB stations. The outer dial cycles through the full list of all the stations the radio has successfully scanned for. The inner dial filters the list down and cycles through the top five most listened to stations. We’ll write more on why we’ve made these choices when the radio is finished.

Earlier this year we hosted a workshop for Timo Arnall’s Touch project. This was a continuation of the brief I set my students late last year, to design an icon or series of icons to communicate the use of RFID technology publicly. The students who took on the work wholeheartedly delivered some early results which I summarised here.

This next stage of the project involved developing the original responses to the brief into a small number of icons to be tested, by Nokia, with a pool of 25 participants to discover their responses. Eventually these icons could end up in use on RFID-enabled surfaces, such as mobile phones, gates, and tills.

Timo and I spent an intense day working with Alex Jarvis and Mark Williams. The intention for the day was to leave us with a series of images which could be used to test responses. The images needed consistency and fairly conservative limits were placed on what should be produced. Timo’s post on the workshop includes a good list of references and detailed outline of the requirements for the day.

I’m going to discuss two of the paths I was most involved with. The first is around how the imagery and icons can represent fields we imagine are present in RFID technology.

Four sketches exploring the presence of an RFID field

The following four sketches are initial ideas designed to explore how representation of fields can help imply the potential use of RFID. The images will evolve into the worked-up icons to be tested by Nokia, so the explorations are based around mobile phones.

I’m not talking about what is actually happening with the electromagnetic field induction and so forth. These explorations are about building on the idea of what might be happening and seeing what imagery can emerge to support communication.

The first sketch uses the pattern of the field to represent that information is being transferred.

The two sketches below imply the completion of the communication by repeating the shape or symbol in the mind or face of the target. The sketch on the left uses the edge of the field (made of triangles) to indicate that data is being carried.

I like this final of the four sketches, below, which attempts to deal with two objects exchanging an idea. It is really over complex and looks a bit illuminati, but I’d love to explore this all more and see where it leads.

Simplifying and working-up the sketches into icons

For the purposes of our testing, these sketches were attempting too much too early so we remained focused on more abstract imagery and how that might be integrated into the icons we had developed so far. The sketch below uses the texture of the field to show the communication.

Retaining the mingling fields, these sketches became icons. Both of the results below imply interference and the meeting of fields, but they are also burdened by seeming atomic, or planet sized and a annoyingly (but perhaps appropriately) like credit card logos. Although I really like the imagery that emerges, I’m not sure how much it is doing to help think about what is actually happening.

Representing purchasing via RFID, as icons

While the first path was for icons simply to represent RFID being available, the second path was specifically about the development of icons to show RFID used for making a purchase (’purchase’ is one of the several RFID verbs from the original brief).

There is something odd about using RFID tags. They leave you feeling uncertain, and distanced from the exchange or instruction. When passing an automated mechanical (pre-RFID) ticket barrier, or using a coin operated machine, the time the machines take to respond feels closely related to the mechanism required to trigger it. Because RFID is so invisible, any timings or response feels arbitrary. When turning a key in a lock, this actually releases the door. When waving an RFID keyfob at reader pad, one is setting off a hidden computational process which will eventually lead to a mechanical unlocking of the door.

Given the secretive nature of RFID, our approach to download icons that emerged was based on the next image, originally commissioned from me by Matt for a talk a couple of years ago. It struck me as very like using an RFID enabled phone. The phone has a secret system for pressing secret buttons that you yourself can’t push.

Many of the verbs we are examining, like purchase, download or open, communicate really well through hands. The idea of representing RFID behaviours through images of hands emerging from phones performing actions has a great deal of potential. Part of the strength of the following images comes from the familiarity of the mobile phone as an icon–it side-steps some of the problems faced in attempting to represent an RFID directly.

The following sketches deal with purchase between two phones.

Below are the two final icons that will go for testing. There is some ambiguity about whether coins are being taken or given, and I’m pleased that we managed to get something this unusual and bizarre into the testing process.

Alex submitted a poster for his degree work, representing all the material for testing from the workshop:

The intention is to continue iterations and build upon this work once the material has been tested (along with other icons). As another direction, I’d like to take these icons and make them situated, perhaps for particular malls or particular interfaces, integrating with the physical environment and language of specific machines.

Here’s a question: is ‘zune’ - as in the Microsoft Zune - pronounced, in the UK, zoon (as in the US ‘tune’) or zyoon (as in the UK ‘tune’)?

I was thinking today that the ideas behind Web 2.0 are equally applicable to consumer electronics, and it got me wondering: by taking the ideas of Generation C and products, what simple changes would I make to the Zune portable mp3 player?

I’d break it down into the basic Gen C expectations of community, connected devices, and co-creation.

Community. What if the Zune synchronised with a desktop application like iTunes crossed with Flickr crossed with mix tapes? It’d take the best of the Web’s curatorial culture and let people create, share and gift playlists, with facilities for illustration and story-telling (actually, Amazon Listmania goes some way in this direction for books). This would be an application focused on the social cradle-to-grave experience hooks of music, rather than just the momentary commercial transaction like the iTunes Music Store.

Connected. The Zune should include an open, documented hardware API–a couple of copper contacts that act as the transmit/receive of a serial connection, sending out events and exposing a control interface to the player. What would it be used for? Who knows… but personally I’d spend a weekend building a cradle that, whenever the Zune was dropped into it, would immediately begin playing shuffled music and projecting the title on the ceiling. Simple and the kind of thing I’d use daily, but not the kind of thing anyone would bother mass producing. The secondary market around the iPod dock connector is a big part of its popularity, and this is a way Microsoft could challenge that with a much larger, grass roots amateur developer community.

Co-creative. Owners should be involved in the form design of their Zune. While Apple keep development around the dock connector closed, they’re open with the precise proportions of each iPod. This is incredibly useful. In the development of our Metal Phone project, we had to build a 3d model of the internals of the Nokia 5140i (requiring digital callipers and much time) in order to create the casting mold for it. A provided 3d file would have been much appreciated. With the Zune, Microsoft should go one step further: the plastic shells should be interchangeable, with press studs underneath so as to accept covers made from materials like Tyvek and fabric too.

These are first steps–minimal interventions in the functionality, ports and industrial design to make a Generation C product. I just wanted to see what I could come up with, if I was challenged to think of limited changes using this particular approach.

The reason I was thinking about this was because I went to an event this morning at the Microsoft London offices (titled The Online Opportunity – What Makes a Successful Web 2.0 Start-Up?) and it didn’t feel appropriate to ask the question I’d been planning to, about whether Microsoft saw consumer electronics evolving in a similar way as the Web, and what they’d be doing to support it.

As it turned out, the event was aimed at start-ups much larger and more developed than what I regularly consider to be start-ups, and I didn’t find it addressed the ideas of Web 2.0 at all. But Steve Ballmer - their CEO - spoke, and it was a privilege to see him in action– he’s a smart, highly informed and witty speaker. I have no great love or dislike for Microsoft, but much respect for Ballmer based on today. He handled an open Q&A with grace and aplomb, and made impeccable use of framing in language (he repeatedly used words like ‘instance’ and ‘inherit’ that come from an object oriented programming world, making business strategy easily understandable by developers). It was great to listen and learn.

Jeremy Keith has a comprehensive write-up (including my idea for umbrellas with tanning lamps in them). And thank you Ryan Carson for the kind invitation to attend.

Drawing hybrids and inbreds

We are around half way through the development of Olinda, the digital radio prototype we’re building for the BBC. Most of my efforts over the weeks since Matt’s post have been focused on how the object should behave and physically manifest. 

This post discusses some early drawing processes. We use drawing to surface and test many ideas easily and early. These drawing processes are also used to reach unexpected forms, and to examine why an object should look like it does.

About three weeks ago I met with Matt Ward from Goldsmiths. Ward has developed a drawing process which he works through to explore and interrogate ideas. Here we used it to develop ideas around products. His position for understanding how a product can manifest begins with a framework that includes how objects respond to anticipated contexts and tasks, in situations within a culture of consumption. He sketched this for me, and I’ve included it below. I like that it includes the designer, in a ‘context of production’. 

Ward’s approach is this. Begin by taking an existing radio, and draw it at the centre of a page. From here, choose four contexts or situations for development, like ‘in the kitchen’ or ‘listening to the football’. Write these labels in the four corners of the page surrounding the original sketch of the radio. Then evolve the form in the centre towards imagined new forms in response to the four situations.

The point here is to get away from the original form as far as possible, and to make many drawings. Below there are radios that are - more and less literally - in the contexts of decorating, the bathroom, kitchens and shop shelves.

Sometimes this leads to very strange things.

Critically, the purpose for such an exercise is not to draw good products but to begin evolving forms outside of an expected mold. As soon as a form emerges which catches, it is redrawn on a separate page, and bred between other sketches to develop new hybrids.

One is being selective in this process, but it is surprising how little control there is over what you expect to emerge, forcing issues with the sketches rarely yields anything satisfying. But this is not a storming, random process. It is very methodical, as a process of deconstruction. It is using drawing as thinking, which is its power.

What emerges is the discovery of what it is about that original radio that persists, in spite of the violent evolution. The drawings are really about ways of housing these commonalities, so you start thinking in terms of materials very quickly. The other thing that happens is you see particular twists. For example a kitchen radio should have legs, in order to sweep crumbs out from underneath it.

Making and drawing

In parallel to these processes, we have been in the workshop making objects from which to derive further drawings. This process started by thinking out a critical aspect of the form, in this case the connection between the two separate Olinda modules.

Once things start to get made, materials start to influence drawings and further made experiments. As the pieces of wood were cut, the shapes started to yield new directions and the wooden blocks emerged as a combinatorial way of interrogating traditional and less likely forms.

These are then fed back into the drawing and imagined interfaces are penned onto surfaces.

Some of the drawings begin to imply unlikely material qualities. The social module here looks like it’s been knitted from wool. The drawing is from a little over a week ago, and is based on a model used to investigate certain materials and assembly.

When Olinda is an object, it will be a product of unusual influences. It is unlikely that in this project such radical deviations from expected form will be appropriate. But these processes have made it possible to interrogate the assumptions embedded in the form of products. Objects like Olinda respond to forces from many territories, but the reasoning around that is a separate discussion.

Since the central point of my experience stack presentation was somewhat obscured because of my playing with the structure, I thought I’d have another bash at it here. Setting an idea up like this feels unnecessarily dogmatic, but frameworks are only meant to be rocket boosters to the actual design so it doesn’t feel too constraining. Anyhow. You can read the original presentation in addition to this article.

Five layers

The experience stack is a way of thinking about the different levels at which experience design operates. Experience design can be thought of as…

• branding;
• service design;
• product design;
• interaction design;
• human factors.

Just as with the OSI seven layer model of computer networking, these layers can be thought of in a tiered stack… but not reducible to one another. It is not possible to express the experience of discovery, in the service layer, to the cognitive components in the human factors layer, for example.

Let’s go into these, from the bottom up, and look at the contribution to experience from each.

Human factors

Human factors covers physicality and cognition. Cognition I’ve covered in the Mind Hacks-derived presentation, Assumptions, Attention and Affordances: it means we have to know how people pay attention and the limits on it; the impact of the workings of visual perception, and how things like arrows, shading and visual change are more important than we realise; and how to take advantage of all of this. I would include peripheral vision and tactile feedback in this.

Physicality is about understanding two things: First what I’ll call body thinking (where physical movement affects our emotions), and second, the physical and physical context of the interaction: how does one stand to approach an object, like a radio; how do its movements and shape indicate the possibilities and constraints of interaction. See for example our material explorations in wood and have a look at the identical and complementary shapes photo: that construct would be perfect as a replacement for the Bluetooth pairing process, because it shows clearly and two (and only two) objects are supposed to join together. Or also read about how to make objects ‘disappear’.

Interaction

The interaction layer includes many of the ideas in The Hills Are Alive with the Sound of Interaction Design and From Pixels to Plastic: it takes common interaction patterns like play and sociality (see social software), and positive and negative emotions and drives, and uses them appropriately.

In the Experience Stack presentation, I discussed the different ways in which games start… learning from successful interaction patterns and applying them to the product at hand is definitely part of this layer. (For example, seeing that we enjoy observation can lead to product feature ideas.)

Knowing how people will adapt their product - applying customisation - and showing how that is possible is also, to an extent, part of the interaction layer.

It’s about making the interaction not just something to be learned from the manual, but part of a pleasant, intuitive, engaging experience–and the best way to do that is to learn from other experiences.

Product

In the middle of the stack is how people experience their products–not while directly interacting with them, but nor in the more distant, less controllable way of brand. Products should be firmly identified: a product which has a sentence to identify it and a target audience can also have goals and metrics to tell when it’s performing well, and will be better understood by its team, and its host organisation. Customers will be able to tell other people about it, and develop a personal understanding of the product and how it will behave.

Metaphorically, a product should be ’shelf-demonstrable’–able to be understood simply from a first look, even if that understanding growth in breadth and richness in the future.

The point of this layer of the stack is two-fold. It says that the best way to have a good product experience is simply to have a good product. But it also says that predictability and a common understanding of the product as a discrete thing is important (it is for this reason that I’ve said previously that products are people too).

Note that this doesn’t mean that a product must only do one thing, because people are capable of seeing very abstract bundles of behaviours as ‘things’… but if a product does two things, the conception of what it’s truly about may need to change. And adaptive design points out that products have fuzzy edges that change at different speeds, but that’s just something to incorporate into the overall understanding of what a product is, and design for accordingly.

Also in this layer are firm identifications of the other actors and situations. Who will be using this product? In what situations? Considering archetypal people and situations can help target product features.

Service

Experience hooks (more) are those moments you remember in your story of your life with a product: how you meet, how you show your product off to friends, how you clean it. When I’ve discussed this before, I’ve referred to unboxing as a key moment in the product life-cycle.

Designing for these moments in the product-as-service is the service design layer of experience, and lets us associate brand ideals with product features. For example, certain experience hooks can be made a feature of–especially social, or particularly easy, for example.

Brand

The experience of the product is cloaked in messages, direct and indirect, which set up mental understandings of the product. A person then uses these models for implicature–the understanding of a product beyond its explicit communication.

It’s rare the brand - this high-level experience - can be seen as separable from the product itself, but Volkwagen’s Night Driving commercial and the site They’re Beautiful by Jackson Fish Market both create experiences beyond the product. These brand experiences affect the use of the product itself because the different layers of the experience stack are indistinguishable in people’s mind, and even weakly associated still bleed into one another.

Consideration of the brand influences what design and feature decisions are made at every other layer in the stack.

Rationale and approaches

Central here is the Generation C trend (people form communities; expect to be connected socially and electronically; Gen C are comfortable with complexity and want control; they are creation and expect co-creation), and their demands. And then ideas like social software and adaptive design point in the direction of a more holistic kind of design. Experience design is what bundles this all together, as it implies that all aspects of the product experience (from every part of the stack) are considered as one by the user, customer, or viewer… and if the experience is awful, they feel awful.

Approaches come out of using the stack–looking for experience hooks and considering the context or situation can help generate ideas. Using the brand as a guiding principle can help select features. Running through the interactions with the product and making sure they’re aligned with emotions and behaviours that are enjoyed or avoided also helps. These are all very direct uses of the experience stack.

More generally, it has to be realised that experience is very badly understood by observation: the designer has to take part. I can sum this up: Nothing is easier than believing we understand experiences we’ve never had (source).