Defining interaction style helps work on multiple layers

Posted on: November 02, 2009 by: Vesa Metsätähti in:

Interaction style is something I was thinking to define back in late 90’s. Early in 2000 there was not much “leisure” type software (not counting games as they are a bit of different stuff than what we are looking for here). Software (and hardware?) for consumer digital photography — specially the one bundled — was quite awful.1 Although the idea of defining interaction style got going with tangible products and user interfaces this model was brushed up in software related projects.

The model became very important with software embedded products and services. Some of the such projects that I have worked with treated the physical side of the product as a sculpture, and design of it’s behavior as a totally different unrelated project.2

The reasons for needing a way to define interaction style was that:

  1. the way something works defines it just as much as it’s physical appearance
  2. the way something works needs to correlate with the physical appearance and other manifestations of product or service (advertisements, packaging, physical appearance, etc. give promise on what the product or service will be like, if they tell a different story or lie the customer will be extremely disappointed: “this car looks like Audi but drives like Opel”)
  3. in the future with ubiquitous computing what defines the experience is not what we use but how we use it (you might be using handset of X but control device of Y – and the X might be quite transparent: “on this car my steering wheel drives like an Audi”)

Interaction style can be defined with the relationship of controls and feedback

The range of controls in the model is from casual to conscious. Casual controls include anything that has not been specifically designed for the use (or where use is not specifically designed for being controlled by), and/ or that do not provide high, exact, motivated or sensible way to tackle the task.

In this model the feedback ranges from plain to rich. Feedback is a bit tricky to evaluate since it doesn’t not naturally fit inside such a one dimensional continuum. Rich interaction would be something like a melody instead of simple sound. Richness or plainness is relative and is found by comparing feedback to what else it could (realistically) be or what other conventions there currently are or have been.
Interaction style diagram, feedback from plain to rich vs. controls from casual to consicious
In our diagram feedback is located on the horizontal axis and controls on the vertical axis. Thus in the lower left corner we have an area where we have find plain feedback and arbitrary controls. In the upper right corner we have place for stuff with rich feedback and conscious controls. The interaction in rich feedback and conscious controls can be categorized as tool like interaction. Interaction with rich feedback and arbitrary controls can be categorized as toy like interaction.

In a sense this describes the relationship of stuff on the task layer and stuff on the presentation layer. More importantly, this is a tool for work in the task layer to define what kind of feedback the presentation layer should consider. It is up to the presentation layer to decide what the feedback actually is.

Feedback changes between primary and some secondary media

Interaction style diagram, secondary media strongest in rich-casual corner, primary media strongest in plain-consicious corner

Primary media is what you would think of as a natural output or feedback of your actions. Secondary media is something added, more artificial etc. For tool like interaction secondary feedback will give more detailed view of the matter, usually in such detail that it will be redundant for a layman. With toy like interaction the secondary media will make the natural feedback more visible, understandable or cover lack of natural feedback.

As an example four different audio tools. For all of them the primary media is sound.

Audio tools as an example of interaction style

In lower right corner we have mini stereo system. There can be a lot of controls (shiny ones) but they perhaps have little or inaccurate effect on the sound the stereo system produces. That does not really matter for the user to know the stereo system sounds good through the flashing lights it has: the secondary media. Clearly a case of toy like interaction.

In lower left corner we have portable radio. Not too many buttons and not too deep controls. For feedback to know that you are playing the correct radio station is enough (even as they tell what station you are listening to, they fail if you do not recognize it through the selection in program). Lets call this straightforward interaction.

In upper left corner we see record players of a DJ. There can be plentiful controls but the largest are the most important – by spinning the decks the DJ is in full control of how the music is played. Even as there can be a handful of feedback to help DJ in her job, the real professional trusts only her ear listening how the music sounds. Direct manipulation perhaps?

In upper right corner is an image of studio mixer. Studio has accurate control on many things and technician trusts in her ear evaluating the sound. Additionally she will get a bunch of additional feedback on sound levels etc. Tool like interaction.

There is no right combination and good usability can be found in all of them

Unlike with some diagrams there is no preferred combination. The “correct” choice depends from the context and goal. (Working with a high-end lawn mover should not feel toy like – unless that is for some reason specifically decided to be the thing that sets it apart from the rest. But even then the physical and visual world should have some sort of connection to the toy-like-ness or it will feel detached and unmotivated).

Good design and usability can be found from each category. (The straight forward portable radio is actually the most stylish one of the example devices). The important thing is to know what part of the product or service will fall in to which quadrant and communicate it.

Sometimes thinking of one quadrant is forced on every part of a product. But not everything has to behave similarly — it is more important to behave appropriately than “logically”. In a health care device the examination process can be direct manipulation or perhaps tool like interaction (depending on the application of course). Selecting a current patient from database should however be straightforward and not forced to work like direct manipulation for example.

Now how does this relate with the 4 layers for design?

The interaction model is useful tool for:

  • generating designs — trying out how the product or service would be like if executed in another quadrant for example
  • validating design — evaluating if the design fits in the defined interaction style
  • communication — it is easier to get the design right if different professionals have common terminology for this kind of abstract stuff

Interaction style is useful tool for presentation, task and service layers
Much of the documentation related to design work is directed at the infrastructure layer. Interaction style is something that is useful as a mental tool for the designer and as a communication method for other designers. It will be less likely useful as documentation for implementation.

Footnotes aka. Excel turns to a bad toy when added with “fancy GUI” etc.

1 The software bundled with cameras (and most early digital boom image editing and organizing software to that matter) was tool like interaction stuff that did not really relate to photography. To make them look more humane they were added with bloated graphics and some times more “advanced” functions were hidden somewhere, resulting in sorry toy like interaction coupled with bad usability.

2 The products or services were thought usually through models (like Peter McGrorys 4 dimensions of product identification) that were then forcibly applied to statue like design objects — with some vague brand value on background and physical features that were designed in the end (and value, behavior happening magically somewhere between).

But you CAN do research for stuff that does not exist yet

Posted on: October 28, 2009 by: Vesa Metsätähti in:

In a project the client was a proud business man. Inventor of many fine things. He knew the technology of his product through theories and experience. Now it was time to take a leap and have the product make sense for ordinary people: those who did not understand or care to understand how well designed the details were in the technology. The invention worked, and the task was to craft it in to acceptable and desirable product that would matter to the user. (A very common brief — this is what all designers usually do, no matter of the discipline).

Because of the technological invention the client thought that he would have right answers for every other question as well. (This is not uncommon either). You have to respect experience of someone who has been in business for long time, but what surprised me was the claim that: “it is not possible to do research for a 1st generation product”. (And in this case the invention had been in similar use before).

Sure thing, the surveys and research work does not give you all the right answers but they give you good inspiration and requirements to get started. (Just as well as there are business requirements etc. that you need to consider).

To illustrate how to do some work with users (current or potential…), I used this good old diagram to describe what stuff matters when designing a product or service:

task, tool, user, context, environment In the core of product or service design is the task.

If you know at least one of these layers you can start doing some research to find out how related activities and goals could be supported. If there is a strategic decision to have a service for mothers of 3 children (user), you can find out what goals there are to support and what practical problems there are to be solved. You can find more about the contexts and environments these people act in. The more strategic decisions there are affecting these layers, the more focused the research will be. In most cases the target for design is the tool, but in my opinion it could just as well be the task, supporting business decisions defining target group, context and environment for service etc.

Another use for that sphere of layers is to illustrate how some very good solutions turn out to be very poor when copied in to another product, service, or situation.

Think about, lets say an online store that sells just about everything from clothes and fragrances, to home electronics and vehicles. This store does not have shops of its own, but it provides the online shop service for other vendors through a unified web service. The product descriptions and presentations are actually tailored to present the product in the vendor’s own service. From there they are copied to the unified store.

task, tool, user, context, environment - general and specialized stores Specialized store and general store have common environment and user, but task, tool and context are different.

Amazon screenshot Small vs. large televisions at Amazon. At least they have the ratings and size in the product title. Amazon is not about such lists either, because it already has reliable reputation and products are well connected with each other.

Transition from a specialized vendor store to unified general store actually changes much. What remains the same are the user and the environment (computer, web browser). If you are in a TV store a big headline like “this is the best price to quality ratio we have to offer” makes sense. The same headline in general store does not tell much (as you might just as well be looking for knee pads).

In a general store this might get solved through very unified presentation. Amazon does offer TVs through the same tool — description and comments on a web page — as it does sell DVDs for example. It is hard to tell from the picture which TV is small and which is large. They do have ratings however, unlike fruugo who relies even more on a bit meaningless image of a product. In addition you can narrow search by color — relevant with clothes but not TV-sets.

Fruugo screenshot Product presentation in fruugo www-store rely on picture, but the picture does not necessarily describe the product well. Filtering TVs by color is nice touch.

That is why we need to know eventually (earlier rather than later) what is on the task layer and what is on the service layer.

Infrastructure layer, maybe the toughest to work with but really critical?

Posted on: October 18, 2009 by: Vesa Metsätähti in:

In his excellent book How Designers Think, Bryan Lawson writes about design by drawing:1

If the designer is no longer a craftsman actually making the object, then he or she must instead communicate instructions to those who will make it. Primarily and traditionally the drawing has been the most popular way of giving such instructions. In such a process the client no longer buys the finished article but rather is delivered of a design, again usually primarily described through drawings. Such drawings are generally known as ‘presentation drawings’ as opposed to the ‘production drawings’ done for the purposes of construction.

However, in the context of this book, an even more important drawing is the ‘design drawing’. Such a drawing is done by the designer not to communicate with others but rather as part of the very thinking process itself which we call design.

Although Lawson’s book is quite architecture orientated the contents apply well to all design. Thinking of layers of design the ‘design by drawing’ applies best to presentation layer. ‘Drawings’ to communicate ideas exist for other layers too, but for the task and infrastructure layers, the drawings are not design drawings, but rather production drawings. Documentation for someone implementing such a system.

Not having adequate tools to think about the task layer and implementation layer design can be a problem. Rapid prototyping and other methods of trying the design are good. And a coder working with the implementation layer can be seen as a craftsman producing the final product (or production tool) in many cases.

But not all products or services are implemented by a coder. Even in high tech products or self services, the implementation layer involves thinking about and designing processes, organization, roles, etc. in low tech service the whole experience is conveyed through them. Thus designing a service that doesn’t have the rhythm of events, like a graphical interface, is very hard as there is no established way to make a ‘production drawing’ or ‘presentation drawing’ let alone ‘design drawing’ of it.

We need better ways, tools to prototype and think, present and document the service for implementation.

1 How Designers Think, The Design Process Demystified Fourth edition, Bryan Lawson, Page 26

Layers and design traditions are not the same thing

Posted on: October 15, 2009 by: Vesa Metsätähti in:

Competence in Graphical design does not equal a presentation layer. First of all, presentation can be just as much about words, sounds, surfaces, forms, etc. as it is about graphics. In addition working with any of these can overlap to the task layer and should work hand in hand with it. Even as a graphical designer can feel more at home working with presentation layer stuff her skills and thinking can be used on other layers as well.

Same goes with the infrastructure layer. Its not 100% coding and coding is not 100% infrastructure. The infrastructure layer is also about managing people, building processes, etc.

Even as competences overlap layers it is important that work done for one layer does not provide design for others as a byproduct:

  • How a metal worker bends the sheets in a stove factory should not dictate how the cook prepares food at home
  • The way that program designing graphical elements names the button files should not define how the classes are built
  • Ease of coding should not dictate how the scheduling process flows
  • How a shopping process is designed should not dictate how your business is run

Layes and expertiese: copy writing usually presentation or task, infra stuff cant solve busines problems

Neglecting one (or three…) layers will effectively force decisions on one layer to produce unmotivated design for another. Some this is requested intentionally or unintentionally by a client (“could you not make the new logo for us as a by product of coding the web pages?”) trying to get something cheaper or not understanding what the problem actually is. Some expertise is so complicated to buy that something easier is bought with a glimpse of hope that the root problem is somehow solved as well.

Some times it is about a boss who might not understand what he is managing or sales man who does not understand what he is selling.

And that is why we have the layers in the first place.

Presentation layer is not the only layer that communicates with the user

Posted on: October 11, 2009 by: Vesa Metsätähti in:

Way back I remember my boss requesting me to work only with the presentation layer. “That is the only way you communicate with the user anyways”, was his rationalization.

I still think he was wrong. Not only was he wrong claiming that design and documentation should be focused purely on the presentation, but in my experience the task layer can be just as crucial for communicating with the user as the presentation layer.

Amongst other things what stuff looks like sets expectations on how they work. After interacting with a product or service for awhile the task layer either claims those promises and even exceeds expectations … or leads to disappointment. (Not that the users would care for any layers though).

Following diagrams of Service Management and Marketing: A Customer Relationship Management Approach by Christian Grönroos the layers could be divided like this:

Adaptation from Grönroos: presentation and task layers fully visible to users, infrastructure layer is kind of visible, stuff from there on invisible