publications

rethinking text handling in GIMP /1

20 May 2012, 23:02

At the beginning of this month, most of the open source graphics applications community convened for the libre graphics meeting in Vienna, Austria. After a one‐year hiatus, the GIMP team was back in force, and so were two of its UI team members, my colleague Kate Price and yours truly. We delivered a lecture about our most recent GIMP project, which we will write up in three parts. Here is the first.

beyond the text tool

This project was the first one in our series of open internships. I had created these last year, combining mentoring, open working and getting serious interaction design work done for the GIMP project.

Dominique Schmidt worked with us on this project, which goal is to rethink everything associated with text handling in GIMP. It would have been cool to have Dominique on stage in Vienna, telling the story himself. But he had this holiday booked; to a tropical destination; and surprisingly he insisted on going. Since projects means teamwork at m+mi works, Kate and I were instead fully able to report from the trenches.

The text project is quite a wide‐ranging one and at the moment of writing it is in‑progress. So there are going to be no magic bullets, or detailed interaction design specs to be presented—yet. Certainly a wide‐ranging project demands a structured approach, else it goes nowhere. It is exactly this structure that we will use to present it here, in this and the follow‑up blogposts.

direction

Step one: compiling a vision for the project. With text—and editing, styling it—being so ubiquitous in computers, it is very easy to get stuck in nuts‑and‐bolts discussions about it. The trick is to concentrate on the big issue: what is the meaning of text in GIMP work? What we needed was a vision: ‘what is it; who is it for and where is the value?’

The vision is compiled out of quite a few elements: of course it has to align with the overall product vision of GIMP; we interviewed the GIMP developers who have worked on text; it includes the GEGL future of non‑linear working; and we held an informal user survey on the developer mailing list—plenty of users there—about the essence of working with text.

building blocks

To show how the resulting vision, worked out, let’s discuss it line‑by‑line:

• ‘Text in GIMP is always part of the composition—unless it is an annotation.’

This puts text thoroughly in its proper place; it is never the end‑goal, by itself. Also defined is a separate annotation workflow: users adding notes for themselves or for collaboration purposes. This sets us up for a small side project: annotations in GIMP.

• ‘The canvas is not a page; there is no such thing as paging in GIMP.’

I love this one. The first part was phrased by Dominique, the second by Kate. This puts clear limits on what text functionality GIMP needs: beyond paragraphs, but short of page‐related stuff. Note that ‘paging’ is a verb, it is about working with pages and managing pages.

• ‘Text is both for reading and used as graphical shapes; meta data in text—mark‑up, semantics—are not supported.’

This puts on equal footing that text is for information transport and just shapes; an excellent example where the GIMP context makes a big difference. The second part excludes any meta data based processing: e.g. auto‐layouting or auto‐image manipulation.

And now, we get to the value section:

• ‘GIMP users get: minute control over typography and the layout of text on the canvas.’

If there is one thing we learned from surveying users, it is the essence of typography: to control exactly, down to the (sub)pixel, the placement of every text glyph. This control is exerted via the typographical parameters: margins, leading, tracking, kerning, etc. GIMP needs to support the full spectrum of these and support top‑notch typographical workflows.

• ‘GIMP users get: internationalisation of text handling, for all locales supported by unicode.’

This thoroughly expands our horizon, we have to look at use of text word‐wide: many different writing systems, different writing directions. But it also sets clear limits: if it cannot be represented in unicode, it is not in scope.

• ‘GIMP users get: text remains editable forever.’

This anchors the GEGL dream in the project: no matter how many heavy graphical treatments have been applied on top of a piece of text, one can always change it and see the treated result immediately. But also included here is a deep understanding of projects and workflows. E.g. Murphy’s law: a mistake in the text is always found at the last moment. Or the fact that clients always keep changing the text, even after the delivery date.

• ‘GIMP users get: super‐fast workflow, when they are experienced.’

This reflects that GIMP is for graphics production work and the speed‑of‐use requirements that accompany that.

it’s a wrap

And there we have it. Here they are again, together as the vision statement:

• Text in GIMP is always part of the composition—unless it is an annotation;
• the canvas is not a page; there is no such thing as paging in GIMP;
• text is both for reading and used as graphical shapes; meta data in text—mark‑up, semantics—are not supported.

GIMP users get:

• minute control over typography and the layout of text on the canvas;
• internationalisation of text handling, for all locales supported by unicode;
• text remains editable forever;
• super‐fast workflow, when they are experienced.

Nice and compact, so that it can be used as a tool. But these seven simple sentences pack a punch. Just formulating them has knocked this project into shape. The goals are clear from hereon.

And on that note, I hand over to Kate, who will continue our overview of the steps we took, in part two.

Labels: GIMP, lecture, mentoring, product vision

—ps

0 comments, link‐ins, forward this posting:

GIMP redux, full GEGL ahead

22 January 2012, 17:36

Recently I have been receiving requests to clarify the GIMP UI strategy surrounding GEGL, so I thought I’d write a catch‑up blogpost about my 2010 LGM lecture. There I tackled this GIMP UI challenge: a first outline for a UI for a fully GEGLed GIMP. The thinking about this UI, and the discussions with Øyvind Kolås (the GEGL‐meister himself), have been going on for years. Its introduction will be the most profound change to GIMP in the foreseeable future.

two minutes of fame

I started off my lecture with introducing GEGL, the graph‐based image processing engine that is slowly, but surely, being integrated into GIMP. I could spend quite some time taking us through the complete GEGL graph (linked) below:

…and this is only a small one. Instead, here is the essence of it in four easy steps:

1. there are input boxes that load an existing image, or render some vector shapes or text;
2. there are chains of operation boxes that perform things like blur or change opacity of whatever gets fed into them;
3. there are composer boxes that take two inputs and put one over the other, combining them in a certain way (think layer modes: normal, dodge, multiply);
4. there are output boxes that either display the grand result on a screen, or export it to graphics file formats like png or jpeg.

so…great

Thus GEGL processes graphics by hooking up the boxes, inputs–to–output. Why does that matter? Well, because it is non‐destructive: the images in the input boxes are never modified.

If the structure of above graph is written to a file—apart from the input images, all other boxes are just snippets of XML—and a year later it is re‑opened in GIMP, then each of the operations and their parameters; each of the vector shapes or text can be freely changed. Even the input images could be swapped out for different ones. The result is a changed image composition, without any loss of quality.

It is exactly this promise of non‐destructive editing that played a big part in me joining the GIMP project years ago. I could see how that could lead to the end of some of the major workflow bottlenecks in today’s graphics software.

UI modelling

The integration of GEGL in GIMP is a disruption; it changes the rules of what one can do and how one can work. This is not a bad thing, it is a refreshing change. An interesting question is: how does the user interaction of GIMP have to change, in order to harnesses all this new power? In general there is a big urge, especially with developers, to just display the graph on the screen:

I call this the boxes and hoses model. If it looks familiar to you, it is because it has been around for decades: it is called visual programming. Which again explains why developers tend to choose this type of solution. One day a direct representation of the graph will appear in GIMP, as something extra. This is because the product vision defines GIMP as (also) being ‘a platform for programming cutting-edge image processing algorithms, by scientists and artists.‘

activity centre

To find out what the main UI in GIMP should be, we take from the product vision what the main activities are that GIMP is made for: ‘high-end photo manipulation’; ‘creating original art from images’; ‘producing icons, graphical elements of web pages and art for user interface elements.’

As a next step, it pays off to look at the nature of these activities. Users start with images or basic shapes (vectors) and apply image manipulation operations, one after another, to achieve the desired result. Users organise their work in layers and GIMP composites the result. Schematically that looks like this:

In short: a work (a composition) consists of layers, each with its sequence (in time) of operations. Now we got the start of a model for the UI. That list of layers we know already, as the layers dialog. The sequence of operations for the layer, we can call that the operations dialog:

disclaimer

Keep in mind that the user interaction shown in the image above, and all the ones below, is not a true mockup. It is more a diagram—with in part grotesque proportions—to show the principles of how the UI works.

We can see that the four GEGL elements are covered: The image material to start with: loaded pixels or rendered vectors; the layers that control the bulk of the compositing; the chains of operations; the output to the screen in the big image window.

Yes, the image window is the place for judging one’s work and for doing the actual work, hands‑on. The image window deserves a couple of times more screen space than any GEGL graph manipulation. Reversing this relationship (as shown earlier) is completely disregarding the nature of the activity.

back to the future

Adding an operation works as before: use a toolbox tool or invoke a menubar item. Here Gaussian blur is invoked and it appears at the top of the operations list:

Now it gets more interesting: revisiting the past. No matter if it was done five seconds or five months ago, one can recall any previous operation applied to this layer and readjust it. Here the curves for this layer are revisited. While adjusting, the output updates through the complete chain of operations, including colorise and blur:

A lot of layers dialog behaviour can be reused for the operations dialog. ‘Eye’ toggles can be used to show/hide the operations:

Drag and drop can be used to rearrange the order of operations. The result of that may turn out to be more subtle than you think. Because GEGL processes everything in 32bit floating point, it will be much harder to get the rounding and clipping artefacts you get with 8‐ or 16‑bit integer processing. Only when an operation does not commutate by nature (i.e. the order matters), then it gets interesting to experiment with the order of operations.

Of course copy and paste of operations, between layers of the same or different files works. Dragging and dropping of operations on another layer copies or moves them, a modifier key (shift or ctrl) will sort that out. And before I forget: selecting some operations in the operations dialog and invoking ‘Make macro’ would be a good, natural way to get that started.

the holy trinity

Before we continue with more GEGL user interaction, here is a pop quiz. I took this b+w photo of the brilliantly named Kloten airport and coloured part of it red:

My question is: how did I apply that red?

1. directly with a tool from the toolbox;
2. making a selection, then invoking a menu item;
3. using a layer with a layer mask.

Well, I have forgotten how I did it (it’s been a while) and you will never guess. My point is that it does not matter. All three methods listed above are a combination of an operation (apply red) and a greyscale mask, controlling where it is applied and how much. All three methods are fully equivalent, it does not matter to the software—or the viewer.

It does matter to users. Given the context, composition structure, the graphics material and the end‑goal, each user knows exactly which of the three methods she/he prefers. There is a million different use cases and only the individual user on the spot can take the right decision. It follows that each of the three methods is equally important and needs to be equally available to users. This I call the holy trinity of image manipulation.

pagan practices

However, at the moment, you quite often see the following: ‘if you want this feature, you’ll have to use it on its own, extra layer.’ This is layer abuse. I get misquoted on this so let me clarify: users never abuse layers, developers do. Here are some examples of layer abuse:

• the only way to do a non‐destructive operation is via an adjustment layer
• only one vector shape per vector layer;
• only one block of text on a text layer;
• the output of a filter plugin is always put on a new layer;
• the result of using a toolbox tool is always put on a new layer.

The problem is with ‘only,’ ‘always’ and ever more layers, whether users want them or not.

reformation

The abuse listed above is straightforward to fix. Quite a bit of it has to do with enabling users to redo or revisit the image manipulation. That is solved by the operations dialog.

Furthermore, there can be as many vector shapes and text blocks on a layer as one likes. Just show them—and stack ’em—as sub‑layer elements in the layers dialog. And when then one of these sub‑layer elements is allowed to be actual pixels, then it is clear that the whole notion of special vector/text layer can disappear:

Layer abuse has to stop. Developers should never force users to use another layer. Only users decide how many layers they want to use, purely as their own personal way to organise their work.

more blessings

So apart from that no image manipulation is exclusive to a layer, what are further implications of the dogma of the holy trinity?

paint with anything

Yep, with anything, also all the plugins that appear in the Filters menu. Also the obscure ones that you and I, and anyone on the GIMP team have never heard of. Just dip your brush in it and smear it on the canvas. Thinking of combining it with paint dynamics just blows my mind. It just takes one tool (Filter brush?) to enable this.

adjustment layers with anything

You see, I have nothing against accomplishing things with layers. It is perfect when you got a collage made out of dozens of layers and then want to apply some treatments to the whole thing. It just takes one adjustment layer with any number of operations to get that done. Again, with anything.

behind the mask

As mentioned, all three image manipulation methods consist of an operation and greyscale mask, controlling where it is applied and how much. The interaction for these masks can be analogous to that of layer masks:

This means that both the parameters of the operation and also the ‘where and how much’ can be revisited and adjusted, a second later or a year later.

in triplicate

By now you may be thinking ‘wow, every image manipulation must be possible in three different ways, does that mean that one day GIMP will contain three times more stuff than today?’ Well no. I have already mentioned two measures—Filter brush, adjustment layers with anything—that will make large strides towards fulfilling the holy trinity. And even today the trinity is partially in place at GIMP.

Take for instance composition, putting pixels on top of pixels. Sounds like the exclusive domain of the layer stack, no? Well, even today you can use toolbox tools to do the same thing: the Clone tool and its 90%‑identical cousin, the Heal tool. And the menu item to compose is called Paste. Yes, the current layers dialog interaction while pasting should go. The GIMP team is agreed on this for years. Instead paste is an operation on the current layer:

weird science

There is a fifth element to GEGL graphs, that I have been keeping under wraps in this blogpost until now: cloning. This is taking an in‑between result in the GEGL graph, anything from a simple vector to a huge sub‐tree, and ‘teleporting’ one or more clones of this result to another position in the graph:

The original and the clones can have the same or a different position on the canvas; undergo the same or completely different operations; be composited in the same or a completely different manner. The magic is of course in that when the original (the input to cloning) is updated, every clone immediately updates, with all further operations and compositing applied on top. This is going to be liberating, because of the amount of work this saves.

Let me give an example. Let’s take the scan of a snowflake and fix it up with a number of graphics operations. We clone the result 99 times and spread these over five layers to compose our snowscape. We make ever flake a different size and a different colour. Already laborious, no? And now, we decide we are not satisfied with how refined the snowflakes are. Solution: fix the original with more/less/different/updated operations, all 100 flakes will immediately show the improved refinement—in their different sizes and colours.

send in the clones

My plan for the user interaction of cloning is to make it a variant of pasting: Paste as clone. This includes doing further operations on the pasted (as clone) material, before closing off the paste (you can always revisit the paste operation and modify all of it). And as Ville Pätsi pointed out a while ago, there needs to be a way from each clone to access the original. A button or link on the Paste clone operation in the operations dialog might do the trick.

There is more tricky stuff coming up with this cloning, like cloning layers or layer groups. And to go fully meta on this: I am asking myself why chains of operations cannot be cloned and applied to different input material. But Øyvind is not up for that.

two more things

To wrap all this up I have two benchmarks that have developed out of the GEGL discussions. They are alternate manifestations of the holy trinity and they are serious tests of the direction the GIMP user interaction is taking.

First, in a future version of GIMP, if users really envision their work as one single layer—not that unusual with photographs—then they will simply be able to close the layers dialog. Their work will not be impeded in any way by this, everything is still available to them (twice, as toolbox tool and menu) with no limits in the sophistication with which they can express themselves:

Second, in a future version of GIMP, if users are really not interested in switching operations on/off; rearranging operations or revisiting the past, then they will simply be able to close the operations dialog. Their work will not be impeded in any way by this, everything is still available to them with no limits in the sophistication with which they can express themselves:

You could even combine the two benchmarks and GIMP would still work, without a hitch.

aftermath

Directly after the lecture at the LGM, Øyvind Kolås pointed out one flaw, one thing I had not thought of: those greyscale masks, that play such a central role, are not pixmaps. They are GEGL sub‐graphs themselves. Which creates the possibility of near‐endless drill‐down: operations with greyscale masks, which contain operations with greyscale masks, which contain… et cetera.

Is that a fatal flaw? Is that going to blow up my plan to reduce the complexity of the GEGL graph to a linear list of operations? Do we just have to confront users with the whole graph? Let not kid ourselves about the complexity of that graph. In practice, I’d say that a simple GIMP file starts at ten times the number of boxes in the example at the top, quickly moving to a hundred times and then beyond.

not my problem

To developers—especially the ones that are working up to their elbows in GEGL graphs—this problem looks like one of navigating the graph and making edits. But to me it looks like another problem needs to be solved: how can users navigate their working context? Already today GIMP users are doing this navigation. Which layer, which layer mask are they editing, or is it the quick mask?

It will have to wait for another day, but when this context navigation is going to be designed, the one thing not to lose sight of is the image window. Everything evolves around it, including this navigation, and feedback of the working context has to be inside it. I certainly think we can do a better job than currently happens with the layer masks.

And when this context navigation has been designed, taking into account the holy trinity and the two benchmarks, then the operations dialog can show the simple list of operations performed in that context, in their natural order.

Labels: GIMP, GIMP redux, lecture, practical, product vision

—ps

30 comments, link‐ins, forward this posting:

the wud, on social networks

15 November 2011, 18:10

I have just just wrapped up another world usability day (WUD). The theme was Social Networks and we had a full house—workshops and lecture hall—all day. As mentioned before, I had hands‑on interaction design experience with a sprouting social network to share in my lecture. A video registration (in German) of the full lecture can be seen online and, as usual, here is also my write‑up.

structured visualisation or simply being social,
the design work at unusuals.net

unusuals is a startup in Berlin that runs the online network for advertising film professionals. At the beginning of this year they were working on their relaunch and approached m+mi works to help revamp their user interaction. We agreed on a ten man‑day consulting project, which was then implemented over a two month period.

With a modest project like this one cannot expect interaction architects to make and document detailed designs (wireframes) of a whole social network website. There is simply not enough time; practical consulting is the most effective way to shape the project. Fortunately, the unusuals were up to the task of wireframing themselves.

just getting started

The work before the work that I do at the start of a project is structuring. At unusuals I implemented the following sequence of methods and phases:

product vision

Define of what is it that we are creating; what is the end‑goal.

functionality

Create a complete overview of ‘what’s inside the box.’

user scenarios

Further work out the vision with scenarios showing typical and essential use. These are then used for…

expert evaluation

Evaluate any existing stuff: ideas; plans; designs; software; websites; competing offerings.

brainstorming

Time for creativity and generate new ideas. Starting with real life; take it through a couple of loops of fantasy; then back to earth.

design sessions

Sit down and solve the design problem at hand. From fundamental stuff like browser sizing and flexible layouts; to mid and detailed design of components like a film gallery.

This may look like a long‐winded process, only getting results at the end (the design sessions). Let’s see whether this was really the case.

panavision

We started—as is my custom—with the product vision phase: defining what the product is, its identity, what the target user groups are and where the value is. This took a couple of hours with unusuals, especially because they had to explain to me the advertising film world.

How many people does it take to make a tv commercial? Easily more than 50. All these people work in a pyramid, in a strict hierarchical system. It is also a world full of freelancers and the name of the game is getting that next job; then recruit the people who work directly below you in the pyramid, within one or two days.

keep on rolling

Two weeks before the WUD, the unusuals kindly agreed to help me prepare by spending two hours recounting the project. During that, they admitted that they did roll their eyes (a bit) when they realised they had to explain the film world to me, an outsider. They themselves have 10–20 years of experience in the business as either producer or director.

But then they also quickly realised, while explaining, that this was helping them, formulating this simplified version to an external. Also my questions helped, always pointing in the same direction: how does this film world tick. Because how it ticks is how the unusuals network should work. And it is the interaction design that defines how it works.

this header has been intentionally left blank

Now I would like to show the unusuals’ product vision to you, but it is simply too strategic. User interaction, being so directly connected to it, is that strategic. But I can share some of the keywords of the vision. unusuals is:

international

There are a hundred thousand, or two, people in this industry, worldwide.

transparent

The whole point of the network.

exclusive

For insiders only.

a ‘kitchen party’

Thinking about identity, the unusuals wanted the opposite of industry (awards) events, with its cynical networking. They wanted to have that vibe of a private party at someone’s home, full of film industry mates of course. And the best place to be at a party is… the kitchen.

just can’t get enough

Where it came to functionality, there was already a wall full of post‑its; the proverbial wish list of everything other social networks do, plus some more on top. But luckily there were some moderating factors. There was a fixed (re‑)launch date of mid‑June (real artist ship) and there was also a planning, so they knew they had to do a feature freeze way before June. Apart from that I also encouraged them to focus on the essential, because squeezing it all in would be in direct conflict with achieving great user experience.

And here I must make the unusuals a big compliment. Unlike many other companies, they were able to prioritise functionality, to decide what really mattered. And ensure that that would be designed and implemented to a high standard. They were able to draw on their experience as film makers and translate that to the software maker world.

But also they had a new basis for their decisions upon. They had their product vision. So instead of individuals fighting for their feature, they were a team checking if features were essential for reaching their common goal. The unusuals completed this method as ‘homework.’

internet‐free zone

More homework for the unusuals was writing their user scenarios. I say: six is the magic number for user scenarios. I also had an extra assignment for the unusuals: keep the technology out. No mention of social stuff like poking, liking, following; do not even mention the internet. The focus should be on users and what they are trying to achieve.

Being natural storytellers, the unusuals gave the main character of each scenario a name. Here is a swift impression of a scenario: Pablo searches for information on film‐making companies; Pablo asks his friends for some tips; Pablo looks at films to get inspired; Pablo checks the details of a film company; et cetera. Usually around ten steps like that per scenario. Only human tasks and needs.

fun fun

The unusuals said they had fun boiling an initial fifteen scenarios down to the magic number. Seeing the commonalities between two of them and merging them into one. And they learned about what mattered to users while doing this.

This method overview shows that designing good user interaction did not have to wait until the design session. It started right away, from the first step, discussing the product vision. Let’s now take a look at how those four vision keywords drove the interaction design.

up and away

Starting with international, yes it is a worldwide industry. But it is also very local. That professional is needed here and tomorrow. In real life everybody maintains a local network of contacts for that. And there is a third factor in this paradox: this industry has a penchant for exotic locations. And with that a couple of questions rise:

• What network do you tap while filming on location, far from home?
• When a professional wants to base himself in a new town, how to get started there?
• Even simpler: what do you do when all the usual suspects who can fill a position are busy next week?

The unusuals network is of course the answer. We combined the transparency that it needs to deliver with the local‐but‐international paradox to arrive at a design where one page handles many tasks:

• organic exploring, starting from this user’s own network;
• organic exploring, starting from anybody else’s network;
• organic exploring of the filmmaking market of a city, country or the world;
• recruit people, starting from this user’s own network;
• recruit people, starting from anybody else’s network;
• recruit people within a filmmaking market of a city or country.

Conventionally this would lead to up to six different web pages, each designed differently and fragmenting the experience. Shown below is how we designed it: in a natural, unified—if at first sight maybe even unspectacular—way. Starting with exploring:

Adding filtering for a certain role:

Or take as starting point the network of people one trusts, or a certain market:

What we see is user interaction shaped by working methodically; combining the product vision, user scenarios and the understanding of how users tick.

splendid isolation

unusuals being an exclusive network is a great thing. It really helps to focus while designing, creating a place where this user group will feel right at home. Which can only help to build the network. But it will also help the network to survive.

What is it that destroys social networks? It is that cool innovators—who are the gravitational force that builds a network—do not want to be seen in the company of people who they consider ‘clowns, jerks and definitely uncool.’ So they leave networks when they feel overrun by these types, adopting a new, hip hangout for themselves. As usual, this is followed by an exponentially rising tide of invites that builds this next network.

lean and mean

My conclusion is that all general networks must die. By which I mean that these networks have the same life cycle as boy bands: every couple of years there is another bunch that dominate the charts. It is just a fashion/trend cycle, driven by these cool innovators.

I believe specialised, exclusive networks have much greater staying power. By keeping out people who are definitely not insiders, reasons to leave can be kept below the threshold of the cool. This why I am happy that the unusuals followed through with keeping it exclusive:

To join unusuals you have to be invited. And to be invited you have prove your credentials. Modelled on real‐life strategies of getting past the doorman of an exclusive club, there is two ways to do it. Either ‘do you know who I am?’ or ‘people are waiting for me inside.’

you can’t touch this

What became of the kitchen party? There is no part of the unusuals site that can be identified as its tangible representation. But as the unusuals pointed out in their feedback, it is everywhere. It certainly got mentioned a hell of a lot throughout the project. That helped with finding the right form while designing and also helped with important decisions.

Having you own offbeat concept like the kitchen party really works like a conspiracy within the design and development team. It does keep everyone pushing in the right direction.

paper + clip

With the kitchen party comes the curious host, who keeps the party going by discreetly asking a question or two to participants and using that to establish new connections and interactions. Again, this is not directly tangible. Do not expect Clippy, the curious host.

Instead, it resulted in a policy: no form‐filling, beyond the bare minimum, like on the request for an invite. There is no duty for users to reveal information about themselves, only opportunities. ‘See that cool sneaker spot? Yeah, I edited that.’ You can then count on the vision of a exclusive, professional network; that users will take the opportunity to profile themselves.

talk talk

And now for some social interaction. Among all that initial functionality on post‑its there was all sorts of communication. Private messaging, group discussions, comments, following, feeds, tweeds, et cetera. Each of these looks ‘easy’ to add. In reality we underestimate the effort because they are ubiquitous, infrastructure type of functionality. We tend to forget about all the details that need to be designed and implemented for each.

Part of my job is to exactly point out these implications. And to show how much work it would be to integrate these with each other, as well as having to explain to users why all these have to exist within unusuals. For example, private messaging is covered well by good old email. No need to duplicate it. It was time for me to say: ‘Pick one. Which form of communication is the most important for your vision?’

crashing the party

Fast forward to a round of brainstorming, where the vision of transparency was combined with a look at how people communicate at a real‐life kitchen parties: two or more people conversing with each other anyone standing close enough can listen in. And anyone who has something to contribute can join the conversation.

That is how conversations were designed at unusuals. Starting with a comment to a film, or person A starting talking to person B. When someone answers it is a conversation, anyone can join to broaden it. Nice detail that there is no ownership of any given conversation, they are simply attached to all persons and content involved.

the right stuff

The best part of this is that the unusuals own this stuff. No, not like in software patents. I mean they worked it out themselves. The worst you can do when developing user interaction is blind copying: ‘facebook has a wall; so must we. They are quite successful.’ Not really much better is the ‘not invented here’ attitude. ‘facebook has a wall; that will not happen to us. We must invent something unique.’

The correct way to develop user interaction is to work through the methods outlined above, beginning with that you’ve got to have a vision. If then your design is quite similar to something already existing, then that is OK. You arrived at it independently, from your own strength.

During the unusuals development period this year, facebook changed the behaviour of its ‘wall.’ Two weeks ago I asked the unusuals what they thought when that happened. They said that they could not care less. They have their own thing, which is right for them and their users. They have their independence.

red carpet day

Further brainstorming produced premieres, of course based on the film business. It solves the problem of how a crew that worked on a film can be kept up to date of the release of said commercial. unusuals lets members schedule a premiere of a new commercial. Those closely involved with its release will do so, out of pride and/or as part of customer service. Via invitations and organic networking the crew gets to hear about the upcoming premiere.

And here the curious host principle pays off. Any member checking out the premiere has to opportunity to put himself with a simple action on the crew list of the film (yes, there is peer review to fight abuse). This action (soft‐)connects the crew: they have worked together. We see again how important content is for starting social interaction and building the network.

quattroporte

The unusuals had a dream. They asked me if the site could feel really simple. Like only needing four departments to structure the whole site. Problem was that at that time their straightforward classification of their functionality called for nine departments. So I thought about it for a short while and the answer is: yes, you can.

There is no standard recipe for achieving this simplification. Solving it is quite an intuitive design process. Full understanding of the product vision and how users tick goes into it and suddenly, it gels. The understanding that exploring the network, keeping up with social activity and users presenting themselves were the most promising categories to put top‑level. Then the functionality overview is used as a work list to check and place everything:

Top‑left is the Explore section we saw before. The Me section is all about this particular user (profile, settings, media uploaded and associated with) and the Buzz covers anything social and dynamic in time. Finally the Tools section offers room to expand. For instance managing premieres belongs there.

get the most out of it

Phew, already a long haul and it still only covers part of what we were able to achieve during this modest, ten man‑day project. So I asked myself: how come the unusuals got so much out of this? I think it is because:

1. The unusuals were fully open to process change. Introducing proper interaction design means that things cannot stay as they were before. Because unusuals is a startup it was more a case of process shaping, but still they got it without a need for heavy discussion.
2. The unusuals reached out to get a professional on board to work on their user interaction. And they were determined not to go it alone. They kept looking until they found a partner that fitted their needs; then without further ado started our project.

And here we have the acid test. Without these two, really nothing is going to happen. You cannot bolt on some usability or interaction design consulting to the side of you regular development process and expect results. For that they have to become the core of your process. Similarly, doing serious work takes experienced professionals that you trust. When both of these points are not in place, then all that is left is talk, about improving usability and having a great user experience. Read more about process integration—from last year’s WUD.

What also really helped is that at unusuals I was working directly with deciders. People who, without distractions, put their 100% in making the best product they can.

live and learn

A nice aspect of my job is that you always learn something new, it keeps things interesting. What I learned from the unusuals is that especially for startups, structuring is more than half the work—I explored that deeper in a previous blog post. They stressed that they really valued the methodical approach to the project.

The second thing I learned takes that to the next level. The unusuals insisted that the early methods—product vision, functionality, user scenarios—liberated them. They could stop talking about unusuals on other peoples terms, start with a clean sheet and express what and how they wanted to create themselves.

This really bowled me over, I had never looked at it in this way. I use the methods for information transfer and as a solid foundation of the interaction design. That these methods can work emancipating for my clients, well, I keep that in mind from now on.

the ins and outs

The final lesson learned is that a social network like this is a living thing. The growth and dynamic of the network definitely forms another channel of feedback that goes into the evolving interaction design.

Working with the unusuals was a blast. I am proud of what we achieved in such a short time. Normally this would be the point where I say: check it out, unusuals.net. But the chance is high that you are not in the advertising film business. So you won’t get in. But that is actually a good thing.

Labels: lecture, practical, product vision, startups

—ps

0 comments, link‐ins, forward this posting:

12 interaction tips for startups

10 October 2011, 14:03

Over the last year or two, we at m+mi works have seen a remarkable increase in projects with local startup companies. For us this is tangible proof of the alleged trend that Berlin is the location for your next startup. I can see the driving forces behind it though. Having set up shop myself in Berlin, I can only confirm the advantages and benefits of doing so.

Comparing our experience of working with startups with that of many years of working with clients great and small, I have noticed commonalities and some differences, and have digested these below. If you are running a startup that is working on a product that has user interaction, check out these tips.

1. do you really want to?

Do you really want your product—application, mobile app, website or online service—to be compelling and elegant to use? I have to ask, because a lot of folks I talk to say they want this, but in reality very few take the necessary steps to make it happen.

Starting with the right mindset (is the value in features or in user experience?); followed by finding the right people to design your user interaction and putting them in charge; then, when it is crunch‐time, standing by your user experience goals, instead of declaring them ‘nice to have.’ This is just a selection of what it takes.

If you are wavering at this point—or think you can cleverly bypass one of these steps—then you might as well stop reading, with the certainty that your product will never have a great user experience. Maybe you can make it regardless (‘if no competitor bothers, then…’). However, if you know that your success depends on your user experience, then read on.

2. you have a rare opportunity

At startups we regularly find the kind of environment that is conductive to the design of great user interaction. Working directly with the top decision makers; a lack of conservative and reactionary forces; genuine believe in the product; relentless focus on product inovation; a ‘can do’ mentality; knowing that only the best survive.

Add to this a product idea that must be innovative (‘me too’ or ‘feature parity’ equals death) and you can see why it can be exhilarating for us at m+mi works to work with startups.

My message to startups: you owe it to yourself to make use of all this energy. Unlike most other companies, you have the opportunity to produce something truly innovative, with user interaction that sets new standards. Grab it.

3. yet another development company

In some regards a startup is not that special. It is simply a software development company, which is governed by the same ‘laws of nature’ as any other software company. It is not that working at a startup gives a divine shot of inspiration and ability to developers, visual designers and product people for creating user interaction, is it?

The laws of nature dictate that if you want your product’s user interaction to be a hit and drive the growth of your company—instead of impeding it—then you need to involve specialists. No, the creative guy with photoshop is not it.

Similarly, going around friends, family and neighbours, asking them ‘here, try this’ or ‘whaddaya think?’ is not a usability test. Have an introductory talk with a usability specialist to find out what goes into testing of your user interaction. I am sure you will find it worth your while.

4. if you take UI seriously, budget for it

You are determined to take the necessary steps to give your product the user interaction it deserves. I think the following truism will not surprise you: you get what you pay for. Interaction architects are quite thin on the ground; we are usually busy; and we work at the top of the software development pyramid.

If you want a permanent interaction architect on your team, you are looking at making him or her a partner, with the equity share that goes with it. A person with the right ability—and experience—will know that user interaction is the one and only embodiment of the product, and will only accept a position where the accountability comes with the necessary authority: a ‘C’ position (CUIO?). As the startup grows, more junior interaction designers can be added. But the first one has to be a leader.

Involving external user interaction experts does take a healthy budget. The good news is that if you are familiar with the day rate of a good freelance developer, you will not be knocked out by what interaction firms charge. Bonus tip: the kind of visual designers or front‑end developers who say that they also do interaction design as part of their job, will be exactly the ones who can’t.

5. to save money, you can work more

An important asset of a startup is to compensate a lack of time, money, expertise or personnel by just working more, a lot more. I have used this fact to make a project with one startup happen. It turned out to be very successful and enjoyable. However, there are some hard limits to this approach.

Certain talents and skills need to be available at the startup to be able to take over a good chunk of the menial design and specification work. This is not always the case and it will have to be ascertained before a project starts if sharing the design work is feasible. Then, there is simply no substitute for expertise. Scaling back the involvement of experts simply scales back the depth with which the interaction challenges are met. You get what you pay for.

6. you got to have a vision

Creating good user interaction does not consist of applying some ‘divine’ rules, library patterns or platform guidelines. Also simply copying something that you like from another site or app does not get you anywhere. Designing interaction means creating the embodiment of your product and to help you with that, the interaction architect needs to know what it is.

A product vision is your short, sharp statement of what your product is. It answers three questions: what is the identity of your product; what are the core user groups; where is the end‑user value? The first thing we do in a project is to moderate a session where we help you to draw up your vision statement. Once done, it will be the fundamental basis for answering any interaction design question, our pact for the rest of the project.

If you fail to get your product vision together, then I am afraid your product is doomed. Examples of failing visions are:

• identities solely defined in a derivative way (‘like twitter with music, really’);
• user groups that are impossibly broad (‘everyone’) or schizophrenic (‘for baristas and nuclear scientists, yes’);
• only being able to offer features, when value is asked for.

But not to worry, it is rare for a vision to fail. And when it happens, it tends to be at big corp.

7. zealots, infidels and you

So you got your vision and—as I know startups—you are constantly ‘selling’ it to anybody who wants to listen; including yourself, to keep the faith. But wait, who is actually ‘buying’ it? Well, ultimately only those who invest in it. Either with capital (money, machines, bandwidth, etc.) or with a slice of their life (partners, working ‘for nothing’ for a while). Besides them, there are two more groups.

First there is the huge group of total outsiders to your startup. Talking to them is, at best, a form of market research. From experience I say: because they are not part of creating the future, they are a most reactionary force (‘micro‐blogging in 140 characters? no way’). The magic trick is to stick to your vision, but in the meanwhile filter the occasional nugget of gold out of this stream of feedback.

The second group are those—internal and external—who work with you on realising your vision, creating the future together with you. Are these people cynics, because they refuse to invest in your vision and want to be paid directly for their goods and services? I say: no, these people are very valuable as objective collaborators. Don’t take it as a rejection of your vision, they work with it every day. But without roze‐tinted glasses and no IPO on their mind, they are in a better position to see—and tell you in plain language—the reality of implementing your vision. Make use of their professionalism.

8. you have to build an organisation

Here is something I learned, the hard way: startups have, by nature, no track record of their capability to really develop and ship software. Yes, this is also true if one or two grizzled veterans head up the development. The first reason for this is that the organisation has to establish itself: procedures, communication, support systems, information flow, etc. The second reason is that it takes quite a while to find out if everyone on board is really up to the job.

As a startup you really have to take this into account. It starts with working on that organisation. Yes, even if there is only one developer. There is still information flow; bug tracking; an interaction design to be communicated; perhaps content or a visual design to merge. The one person responsible and accountable for building a software developing and shipping organisation is the CEO, and no one else.

Another way of taking all this into account is to plan with the overhead, delays and other surprises that are caused by both reasons above. With all that agile and iterative development that is in fashion at the moment, ask yourself what the dependencies are if one or two people are not able to deliver. I have seen processes like that completely unravel, with ugly knock‑on effects.

9. structuring is more than half the work

For any project interaction architects do, structuring the design process and implementing our methods is the backbone of our work. The feedback I get indicates that when working with startups, the value of this reaches the next level. I see two reasons for this.

First there is the factor of order. True, for just about any company we work with, our structure and methods supersedes a mostly haphazard and random UI creation process. With established companies, this comes in the form of process change. But with startups this coincides with the organisation building discussed above, and the clean‑cut structure that gets established is much appreciated.

Second factor is clarification. Working with a startup on their product vision; followed by compiling the functionality overview; then some user scenarios to represent typical use; it forces to make concrete what was only there on a subconscious level, or in a state of constant flux. Startups realise that this clarification work we do is a first and necessary step towards shipping an actual product.

10. you will have to manage

As you are building your startup, you are in a rapid process of transitioning from doing everything yourself to hiring professionals—internal and external—to handle all kinds of competences: product, interaction, visual design, development, testing, usability, sales, legal etc. Here is one that is sometimes overlooked: project management.

When you have picked the right people, they bring their skills and industry experience; they structure their work and act with authority—within their competence area; they know what it takes to get it done. But you will have to put them all together. Project management does not just happen by osmosis.

Building that organisation; realistic planning; keeping everybody on‑planning; dealing with contingencies; QA; multi‐platform issues; alpha, beta and rollout phases: you will have to manage it, or have a professional do it for you.

11. ‘real artists ship’

The proof of the pudding is in shipping it. Well, you know what I mean. A product does not exist until it is out on the market. And I mean shipping, not promised, announced or private beta. Now, a quest for perfection gets you nowhere. Question is: how much are you willing to give up to get it shipped?

My point is that you should not be staring at a feature list to find out the minimum you can bare to ship. Instead, think of minimum coherent user experience. If you got to be embarrassed when you ship your first version, let it be caused mostly by ‘missing’ features, instead of ‘good enough’ user interaction.

If you want your‐product‑v1.0 to have an impact and form a basis to grow, then its embodiment, the user interaction, should be designed, not an afterthought. So start small, that helps with getting it out; have the essence of your product designed and then ship it.

12. beware of strangers bearing gifts

There is quite a bit of support out there for your startup. University programmes, incubators, venture partners, business angels, subsidy from city, province, country and the EU. Perversely, some of this support comes with a serious helping of red tape. This can reach a point where the founders of a startup do not have the autonomy to act like executives and entrepreneurs.

I’d swear that the point of a startup is to innovate like no ‘normal’ company can. No naysayers playing it safe, no bureaucracy, no controlling. It means selling the vision to investors, then doing whatever it takes to ship it. And failing fast if the vision or its development is unrealistic.

Startups that live in a bubble, protected from harsh reality by a checks‐and‐balances bureaucracy, end up being humdrum R&D departments. They miss the urgency and agility that enable startups to ship great, innovative products, with great user interaction.

what type of interaction?

And that’s it for now. Maybe you expected something else, like tips about sign‑up forms, touchscreen finger grids, widget toolkits, the merits of toolbars. Actually, the twelve factors discussed above are a couple of magnitudes greater in impact where it comes to user interaction. Some of them are elephants in just about any software company’s rooms. Now what you need to do, is to return to tip one and ask yourself: do I really want to?

Labels: architects, fundamental, practical, product vision, startups

—ps

1 comments, link‐ins, forward this posting:

the rise and fall of mobile empires

31 January 2011, 22:40

And now for part two of my world usability day lecture. Part one was all about the three‐point plan for the proper integration of interaction design and usability into development projects:

1. work with a vision;
2. process integration;
3. organisational integration.

Today we will use these three as a framework to make sense of the shock waves that are currently going through the mobile devices world.

money talks

We have all seen these waves, in charts like these:

source: asymco, android’s pursuit of the biggest losers

They show that Apple is already eating almost half of mobile manufacturers cake (EBIT is ‘earnings before interest and taxation’). Or this chart, where we can see the trends:

source: asymco, can android change the distribution of profit among phone vendors?

We see Nokia in steady decline; Samsung wobbling; Motorola back from the dead; Sony Ericsson disappearing; LG decimated; RIM growing a bit; HTC shrinking a little and Apple pushing all of them around. It is no coincidence that both charts start in 2007.

Remember that value forms one‐third of a product vision? Perceived value is also what people pay for:

source: asymco, making it up in volume?

What we see happening from left to right is commoditi­sation. Working chipsets are a commodity. Software that does not crash is a commodity. Plastic casing that disintegrates after exactly two years and a day is a commodity. Software features are a commodity. Yes, it is hard, nagging work to produce these and cursed are those products who do not meet minimum expectations. But there is no value in them.

analysis walks

Back to making sense of this all. What follows now is a swirling mix of first‐hand experience, first‐ and second‐hand stories from esteemed colleagues, and general internet insight and gossip. Shaken, then stirred, to protect the innocent.

Now, let’s use the three‐point plan to evaluate the rise and fall of of some mobile empires.

Siemens

1. I have no idea whether Siemens mobile had a product vision or not. Not that it mattered because…
2. …it was the kind of place where interaction designers were involved late in the project and their hastily made specifications landed in a drawer. You see, in that phase of the process, they had other priorities.
3. ‘Absorbed by the system’ is how a front‐line professional once described what happened there to interaction design. Siemens is a prime example of an engineering organisation and the engineers that were promoted to managers were not planning on spoiling the fun.

And by colluding to keep their jobs fun, by marginalising whole dimensions that cannot be understood in engineering terms, the engineers found themselves out of a job one day, when Siemens mobile completely folded.

Nokia

1. Nokia built its empire during the 90s on segmentation, on recognising that different target groups need different phones. That is at least one‐third of a vision being in place. But quite a bit more visionary was recognising early on that good UI would be a deciding factor, so they invested heavily in it. As a result, up to around 2003, ‘the next one was going to be a Nokia.’
2. This was because of what is in many ways an exemplary process. The UI specification gets written first, by interaction designers. This spec is what gets build and it forms the basis for functional testing. The implemen­tation better be exactly to spec and the spec better be completely thought through, without holes. Anything needs changing? You’ll have to talk to the interaction designer first.
3. So where is the catch? Well, about five years ago things started to change. A culture of taking decisions by consensus took over. Interaction designers started taking the path of least resistance and pandering to the whims of product managers. Design by committee and a clear erosion of the authority of the interaction designer is the result.

This was compounded by the fact that Dilbert came to Nokia—the original Helsingin Sanomat article is a must‐read on the ‘morally corrupting effect of bureaucracies.’ Innovation means taking risk and Nokia is unable and unwilling to do it. This combined with a design by committee culture explains why Nokia is not capable of producing anything like an iPhone.

Apple

1. There is certainly no lack of vision at Apple. Time and again, they see the ‘next big thing’ and create products—if not whole markets—out of it. And they make very hard choices about what to design in—at all levels: chips; hardware; software; user interaction—and what not, according to the vision.
2. Obviously, things are first designed, then built at Apple. They have sworn off usability testing years ago, because it means tapping into a most reactionary force: users. I guess it also helps maintaining the (in)famous secrecy. It does mean we sometimes see Apple missing the target when they make another great (conceptual) jump: antenna­gate; iPod shuffle without buttons; rearrange­ments in iTunes. But they are not too proud to correct themselves, while keeping moving forward.
3. From Steve Jobs downward, it is clear that user experience is everything. If it does not contribute towards that overarching goal, development and engineering ain’t worth a dime. There are some fantastic stories around about how it is enforced that the software matches the interaction design. Yes, the tiniest detail done ‘the developer way’ can derail a user experience. Although Apple is an organisation with tens of thousands of employees, they strive to make teams work like small start‑ups. This avoids death by bureaucracy.

This is the way to quake whole industries and be highly profitable at the same time. It means discontinuing your best selling product (iPod mini) because you know that the future will be different (the nano). It means getting the experience right, before being feature‐complete. It means ‘good enough’ is not good enough, when it comes to user experience.

Samsung

1. Instead of vision, we can speak here of an anti‐vision. By releasing a stream of products superficially equal to an iconic competitor product, Samsung tries to reduce it to a commodity. Then the battle can be taken to familiar ground: features; alliances; marketing; fulfilling every operator whim; rebates (for operators, that is). Any notion of value and its relationship with user experience does not necessarily play a role in all this.
2. The good news at Samsung is that interaction specification goes before implementation. The bad news is that the process can be described as one that would befit the Vatican. By which I mean that the task of specifying itself is more important than the designing—i.e. solving the problem—and that Machiavellian forces use the process to further causes that have nothing to do with user interaction.
3. Samsung has a knack of having three teams working on the same user interaction. How can that work? Which team is supposed to have the accountability and authority? No, that is not compensated by any of the teams not knowing about the other two. A design team is not there to generate some cool ideas, for other folks to pick and mix. A design team is there to take charge of the interaction, all the way to the point it ships.

I guess one can play for time—for a long time—like that. Asian conglomerates must have that down to an art form. Oh wait, what happened to LG and Sony Ericsson?

modulo 3

Apart from sharing what I observed and learned in the mobile world for the last fourteen years, part two of my lecture also served to illustrate the three‐point plan from part one. Closing the circle, I am convinced that empires can be built on the proper integration of interaction design and usability. That is not exclusive to Apple or Steve Jobs, but it does take an insight, focus and a culture that is exceptional in today’s high‑tech world. And the empires that neglect interaction design and usability, those are doomed.

ps: as I finish writing this posting the latest numbers are in. The beat goes on…

Labels: lecture, mobile, practical, product vision

—ps

1 comments, link‐ins, forward this posting:

the rise of proper integration

23 November 2010, 00:51

This year’s world usability day in Berlin marks my return to blogging. The hiatus was triggered by google’s deprecation of my publishing method, which had some knock‑on effects, both organisational and in publishing discipline.

Our usability day was bigger and better visited than ever. As a long‐time co‑organiser, sponsor and speaker, I think that’s cool. My lecture built a bridge between the theme of the day—mobile communication—and the new meet the expert sessions. The latter offered executives a chance to meet senior usability or interaction design experts to discuss about strategic, big‐picture issues.

My lecture was titled ‘the proper integration of interaction design and usability, or, the rise and fall of mobile empires’ and this is how it went.

first things first

To anchor the meaning of my lecture, I started off with my definitions of both usability and interaction design.

usability

both the measure of how usable something is and the profession where experts approach user interaction in an empirical way: surveying, observing, performing exercises with users. I always say: usability means getting the facts on the table.

Asking users what they prefer is not usability. That is market research territory. Usability is about measuring how users tick and if interaction works.

interaction design

both the complete plan of how the interaction works and the profession where experts create user interaction by shaping it in broad strokes; by innovating; integrating every single detail into the overall plan. Interaction design is about creating the future by making innovation jumps forward.

My complex relationship with the word design is known. It is not about making it pretty, design is solving the problem. It is about structure and how the interaction ticks. Elegance is defined in the mathematical sense, of how a solution covers all with a minimum of complexity.

Also note my old acid test for when we have slipped out of interaction design and into visual design. The baggage that comes with the word ‘design’ makes that I rather call myself an interaction architect. That also reflects much better the role of being the one who integrates the overall interaction plan.

separated at birth

Interaction design and usability are two distinctly different professions. Now you may think that I am painting this too much as a black and white issue. Is there not a huge grey‐zone between the extremes, where usability experts also design and designers also avidly test? Well, I only found out about the dichotomy because it is so pronounced. The grey‐zone, where professionals seriously combine both, is much smaller than one would expect.

trouble in paradise

With these definitions out of the way, I moved on to state how troubled I am by the way usability is deployed today. If companies want to get a serious return on investment in usability, they should understand that:

• It is not enough to commission some usability tests, when they are performed late in the project and there is no chance anymore to sort out the UI. I have too many frustrated usability colleagues who perform tests for the same clients, same products, version after version, only to find the same usability errors.
• It is not enough to employ usability specialists, when they are kept at bay by the rest of the software development organisation, who label their recommendations as ‘optional enhancements.’ I have experienced enough developers who were wildly enthusiastic about usability help, only to start overruling when it came to taking action on the results.
• It is not enough to have a usability department, when it is undersized for the development capacity of the company; when other departments manoeuvre to keep it catching up with the situation; when there is no interaction design competence in the whole company to solve the problems at hand.

The same can be said for interaction design:

• It is not enough to commission a UI redesign, when it is received as a collection of nice and flashy ‘ideas,’ when there is no follow‐through by designers during implementation. Which means with every next step, every decision, the design further crumbles to dust.
• It is not enough to employ interaction designers, when they have to work in fireman mode: to review and correct whatever happens to be already developed at the moment; when technical architectures and hardware are ‘already fixed’ from the start; when developers reserve the right to decide which corners can be cut in the design.
• It is not enough to have a design department, when their designs end up in drawers; when they do not lead the development of the UI; when there is no usability competence in the whole company to provide a foundation for the design work.

So there we were, at the end of a successful world usability day, and I had to spread this doom and gloom. Could I maybe offer any hope, instead? Yes I could, in the form of a three‐point plan for the proper integration of interaction design and usability into development projects.

1. work with a vision

Interaction design and usability work is not performed in a vacuum. It is not implementing, and testing against, some kind of general list of guidelines. Actually, interaction design and usability start where the UI guidelines end.

When designing interaction, we are creating the (generally) sole tangible incarnation of a piece of software with a certain identity, for a certain target group, delivering the reason why one actually would invest in using the software: value. In parallel, usability recruits participants from the target group, for instance to test if the software reflects the identity and if the value is delivered or hampered by the interaction.

It comes as no surprise (to those who know me) that identity + target group + value make a product vision. In order to put a bit more practice—mobile practice—into my talk, I then showed how a product vision is made for a fictive example.

everywhere you go, you always take…

Starting from the situation where a product manager comes in and says ‘we are going to build a weather widget,’ I demonstrated how by interviewing the persons who are driving the innovation, they can be coaxed to deliver something much clearer:

‘The weather widget is an always‐available, quick forecast of the weather for one location. It allows hi‑tech seekers and lifestyle junkies to plan ahead for the next 4–8 hours, while on the move.’

There is plenty in there for identity and value, what’s in it and what not, to design from. The user segments—‘hi‑tech seekers and lifestyle junkies,’ mobile is full of that—are used for usability recruiting and come with a lot of defined market data, like the use of mobile data.

everybody is scarce

While demonstrating this I hit the point where for target group you get the standard answer: ‘everybody.’ In my experience, there is one type of software that really is for ‘everybody,’ and that is infrastructure.

Software that provides infrastructure is easy to spot: it is so boring, that nobody is interested in talking about it or working on it. Literally, I have seen it make people run away. My own main experience here is the openPrinting project my firm is working on: pure infrastructure. So is call handling on a mobile phone. Duh, no? Should just work, no? My point exactly.

As soon as software is not coma‐inducing boring, it is no longer for ‘everybody.’ Yes, even the weather. In this mobile example the user segments of the phones that the widget is made for set a much narrower target group, which means the interaction design can be much more optimised.

all together

Working with a product vision is a form of insurance against moving targets and endless discussions. It is also a form of integration, where the goals of the project are firmly implanted as the root of the whole interaction design process.

2. process integration

Let us look at the timeline of a development project, it starts at the left and ends at the right:

Now let us say that the project decides to involve interaction design at the point where the orange marker is:

I say: sure you can do that at that point, as long as you understand the following two points:

1. Up to this point, you haven’t done nothing for your user interaction. Sure, also in my experience developers—and if you got them visual designers—can come up with exiting nuggets of interaction innovation, but it has to be clear that the job of making the whole interaction work starts at this point.
2. Having started at his point, it cannot be that things—like technical architectures and visual layouts—that heavily impact interaction design are ‘done.’ These are significantly formed in symbiosis with the interaction design.

Yes, you are right: that orange marker is better placed a lot earlier in the project.

Now, let us take the same project and instead of interaction design, involve usability at the point where the green marker is:

Par for the course, I say. But there are two more points:

1. Yes, ‘you haven’t done nothing’ until this late in the project.
2. The test will get the facts on the table. Knowing the industry standard for chances of surviving a usability test, I have to ask you: what did you think you were going to do now, in so little time?

Practically speaking, creating interaction starts a lot earlier than building it and it only ends when the last bug is fixed and the software ships:

As you can see from the color coding the overall interaction project is interaction design territory. Following through, keeping the interaction concept together as time pressure and compromises start eating into it is a prerequisite for success.

A serious deployment of usability looks like this:

Detailing each wave by number:

1. Initial research of how the target group users tick. This provides a grounding for the interaction design.
2. Test of initial, rough interaction design. The most important thing about this test is that one is fully prepared and capable to throw everything away and start anew, when the results tell one to do so. Testing on paper is good for that.
3. Test of the much more solid interaction design. Medium level stuff can still be turned around when the test says so. Still testing on paper.
4. Interaction design has been working with development for a while, a software prototype can be tested in a more high‐fidelity test.
5. This is just as ‘late’ as in the single test example. In this case, we are really just testing last niggly issues; icons and graphics that have been produced by now; final wording of texts in the UI.

At the end of each wave, usability and interaction design work together to analyse the results and splice the outcome into the foundation of any further interaction design work.

all change

Introducing usability and interaction design means process change. It is the only way to morph a technical software code producing machine into one that delivers products.

3. organisational integration

This process change must be accompanied by a redistribution of authority. And here lies the rub:

• Product managers know exactly that the interaction of the software is the one and only embodiment of the product. With mobiles, it is the remaining one once the product has been bought and the spell of hardware design dissipates. Product managers don’t find it funny to lose control over this embodiment.
• The development manager simply has to get it done. So (s)he does not find it funny that the definition of done has become so clear and explicit, e.g. in a UI specification. The room to fudge, to declare it done no matter how primitive the implementation, is gone.
• My experience with developers is all over the place. A good deal of them find it a pleasure to work on UI at a whole new level, to have exactly clear what needs to be build and to get on with the engineering. Others don’t find it funny that playtime is over. That—although there is room to do proof‐of‐concepts and contribute nuggets of innovation—as soon as it comes to production of user interaction, there is no more improvisation involved.
• Visual designers don’t find it funny that ‘design’ gets extended into dimensions that they are really not comfortable with, that layouts come pre‐structured and that text has to be in un‑cool, readable sizes.

This triggers standard tactics from all of the above in order to keep their fun going just a little longer:

• ‘these folks work subordinate to me in this organisation’
• ‘well, it is only advice’
• ‘we decide on that together’
• ‘I am doing the development, so who is going to stop me?’

But I say you cannot have it both ways. You cannot ask usability and interaction design people to deliver what is unreachable for you—make the user interaction work—and in the meantime sideline them so everything stays as in the ‘good old days.’

irresponsibility

Being made responsible for something, like usability, is almost a poisoned chalice. Responsibility comes with all of the workload and none of the freedom to execute. What is missing in today’s practice of usability and interaction design is the complementary pair of accountability and authority.

The accountability—one’s neck being on the line—comes naturally to interaction designers. To make that user interaction represent the product and that it all works for users and that it is feasible to build: who else is going to do the job? It is about time that the authority—the final say in what is being built—gets respected, as part of the deal for taking on that accountability.

And let’s not chicken out on usability, although it is empirical in nature. Usability folks should be accountable for getting the relevant and correct facts on the table. By doing this they earn the authority to report the fact that software is working or not, for users. Let’s stop calling it advice and consulting.

great balls of fire

Nobody is going to give up their slice of fun just like that. It takes organisational reform to make this work. This diagram shows how accountability and authority should be implemented. The ‘boss’ stands for the person who has the authority to sign off all the funds that pay for the software production:

Below the ‘boss’ we find, left–to–right, product management; development; interaction design and usability, all at the same level. Each of these can be a single person or a hierarchy that culminates at this point. Each of these can be in‑house or outsourced. All four are accountable to the ‘boss’ and the ‘boss’ lends each the authority to get their job done.

The only variant of this structure that I can think off, is when there is no ‘boss.’ This is the case with open source: the maintainers are the top of the development tree. It is also the case with start‑ups and other partnership situations. What we then have is a flat‐top hierarchy, with clear accountability and authority as before:

It also shows what kind of partners you need in this type of set‑up. ‘Boss‐type’ decisions will have to be made a consensus or committee type of way, in open source that will involve even more persons as shown here. The worst that can happen here is that one of these four gets elevated to the ‘boss’ position, but still keeps her/his original role. Conflict of interest is then pre‐programmed.

capital punishment

So am I here on a prima donna ‘designer’ power trip? No. I think that ‘having your head chopped off’ when the design cannot reasonably be built, when it does not embody the product or when it is unusable really focusses the mind and stops ego trips.

Over the last years I have come to the conclusion that interaction design thrives with tension, i.e. when the conditions are tough. When for product, development and usability heads—even better, for the ‘boss’—only the best is good enough. I once was leading a top‐secret project to design the ‘easy, intuitive phone of the future.’ My team thought immediately of paring back the ungodly number of features of mobile phones by a factor of three. But that would have been too easy. I saw there and then that greatness would come from designing for (almost) the whole feature set and deliver on ‘easy and intuitive.’

So yeah, challenges, tough requirements, great tension are fine with me, as long as I have the authority to solve all of that as I see fit, to create and roll out the best user interaction I can.

So what happens when push comes to shove? When someone insists the interaction design has to be changed and the interaction designer has reconsidered everything and knows this is the best solution. I say only three things can happen:

1. the ‘boss’ supports the interaction designer and it gets built and rolled out exactly as designed;
2. the ‘boss’ fires the interaction designer;
3. the interaction designer resigns.

Anything else, e.g. a horrible compromise to keep the peace, is unacceptable and should trigger scenario number 3.

1 + 2 + 3 = ∞

So there we have it, the three‐point plan for the proper integration of interaction design and usability into development projects:

1. work with a vision;
2. process integration;
3. organisational integration.

Can interaction design and usability experts in any way encourage the reform needed to achieve this proper integration? Yes we can, by stopping being happy with just any kind of work that comes our way. By saying no to:

• working on a project that cannot be coaxed into formulating a product vision;
• a late, first usability test and suggest instead that the same money be spent for testing at the beginning of the next project;
• designing interaction as a layer over a ‘done’ piece of software;
• working in situations where the ‘boss’ thinks interaction design and usability are ‘nice to have’;
• jobs at companies where interaction design and usability are down on the org chart;
• being just responsible.

We better spend our energy and our capital—the stuff it takes to create great user interaction—at places where we can see that one, two or even three steps can be taken in the direction of proper integration. And deliver there, to enable the next step.

And on that note I end part one of my wud lecture coverage. Read on for the rise and fall of mobile empires.

Labels: fundamental, lecture, mobile, product vision

—ps

0 comments, link‐ins, forward this posting: