on interaction architecture

the world needs more fonts, honestly

noreply@blogger.com (Anonymous) — Sat, 24 Jun 2017 16:30:00 +0000

‘Can you name one problem which type design (not engineering) solved and which is not predominantly aesthetic?’ Now that caught my attention on twitter. It appeared in a thread that started off with some saucy quotes: ‘the problems have already been solved’ and ‘the function of new typefaces is largely aesthetic.’

It piqued my interest because I have worked on the interaction design of a couple of font design applications. Besides that I have spent a lot of time investigating the general nature of design.

making a splash

So I jumped in and joined the twitter discussion. After a false start (oh, the joys of social media) the heart of the matter came to light: ‘It is about problems that typefaces solve, not about the problems of typeface design practice, i.e. the categories of reasons why to draw.’ So I addressed it there, have been thinking about it quite a bit more since then, and now I am going to address it better.

Let’s start with a smooth aikido move to get this discussion positioned where it belongs. When a font is to be used by many (i.e. more than 100) people, then it is a product. The type designer is the product designer; the design process is the act of product realisation. The process starts with a product definition; methodical research and design follows. Eventually a set of design drawings is created, to be engineered into shippable fonts.

This insight rebases the discussion. It is a product issue, not a design issue. Asking what problems type design can solve today, is asking: are there any product definitions left that aim to bring useful, valuable font solutions to users?

Well, allow me to make some suggestions.

think big, really big

If you write using Latin script, then it seems that you have 100.000 fonts to choose from. If you write in another script, you are suddenly scraping the barrel; 100 usable fonts is then super luxurious. Does this impact just some tiny minorities? Well, here is a handy list: writing scripts sorted by usage. If I skip Latin and add up the populations that actively use the next ten scripts, then I end up with 3.41 billion people.

The ten scripts are: Chinese, Arabic, Devanagari, Bengali‐Assamese, Cyrillic, Kana, Javanese, Hangul, Telugu and Tamil. Right after these on the list there is a group of six modestly used scripts (Gujarati, Kannada, Burmese, Malayalam, Thai and Sundanese) that nonetheless serve another 205 million people.

Here is my suggestion: Want to do something useful? Pick a popular Latin font (family), say from the top‐1000 in use, and pick one of the big‑10/modest‑6 scripts listed above. Your product definition is to design a font in that script that goes together seamlessly with the Latin font. That does not mean that your new font has to play second fiddle to the Latin one; just that they get along famously.

I can tell you from experience that it is very rewarding to design something this relevant; with the knowledge that tens, if not hundreds, of million of people are waiting out there for the results. Of the 3.615 billion people mentioned above, a good chunk owns a smartphone or will own one soon—you cannot stop commodity Android. It’s their access to the internet. They inform and express themselves using text. They need fonts.

fit for purpose

Read a book on typography and one discovers that non‐philistine typesetting starts with using proper numbers (oldstyle vs. lining, &c.), small caps, and so on. Now check 10 random fonts on the device you use to read this post. Do they contain a full set of numbers and small caps? It is going to be hit and miss. Personally, I am still waiting for oldstyle numbers for my favourite Swiss sans.

While typesetting got more efficient (hot lead, to photo, to digital), typography support got thrown overboard. Today, typography is banned to the graveyard called OpenType features. Yes I know, OT features UI is a world of hurt, but someday someone is going to do something about it (if that is you, ping me). Meanwhile, it is 2017 and fonts that just support the skimpiest of Latin glyph set feel very ‘ms‑dos’ to me; primitive, with a touch of nostalgia, but surely past due date.

So my second suggestion is to start doubling down on OpenType features. Go through the top‐1000 list of fonts and start extending them to make them useful, and valuable, for typographers. I realise there are some barriers of entry, like intellectual property and access to source files (so that they can be extended). Maybe you can pitch the company that owns them and get the gig. A straightforward case is open source fonts, you can get started right now.

fit for authors

Bold and italic are not just a good idea, they are (by default) the way to express certain conventions in text, e.g. emphasis, or denote publication titles. The defaults of html & css are an example of how enshrined this is. A week ago I was trying to select some typefaces for a new website, and it was an uphill struggle, littered with missing italic and/or bold font variants.

My third suggestion: there are plenty of holes in the top‐1000 fonts where it comes to bold and italics. Your product definition is to fill some of these, where you think it matters most. Designing a bold for someone else’s regular can be a drag. But italics can be worthwhile design work, because they start with a clean sheet and a different skeleton than the regulars. I suspect the amount of true‐design work involved is the reason italics got skipped in the first place.

Speaking of, here is a bonus product definition: real italics to be used seamlessly with that famous Swiss sans—to replace them obliques. Again a clean‐sheet project which solves a typographer’s problem. And an ambitious, high‐profile one too. You can call it Helvetalics, if you like.

fit for a new medium

Last year I was involved in an internet‐of‐things project. After a methodical start, it became immediately clear that for our combination of display (size, resolution), use (viewing distance, information density) and goals (not end up being cheap junk slapped together by engineers) we needed a font to make it work. Yes work; life or death.

New media to display text, with new properties—and new contexts for old ones—pop up regularly. These events naturally trigger product definitions for fonts to make new media work.

aesthetics, schm’sthetics

In this blog post I have not gone into aesthetics, because I didn’t need to. All I have done is look beyond the glyph shapes and spot ocean‐sized holes in the font product landscape. Just following up on my first suggestion will keep the global type designing community busy for decades with work that is 100% non‐frivolous. Suddenly today’s ‘glut’ of type designers looks like it could use some serious reinforcement troops.

A business coach once told me: ‘this design work you do is political, isn’t it?’ She meant that my design clearly impacts society and that my design decision make the world better, or worse. That starts with the decision ‘what project do I work on?’

If you get to decide the product definitions at your font shack, then your work is political.

Your choice of scripts is political; how many of 3.615+ billion people are you gonna throw under the bus?
Your choice of OT features is political; a font for typographers, or only for simple business administration?
Your choice of including a bold and italic is political; is your font going to be a drop‐in solution for those who just want to communicate?
Your choice of targeting new display media is political; are you going to leave their new users out in the cold?

If you scour the font landscape, looking for pockets of user‐felt hurt (‘what, XYZ simply doesn’t exist?’) and then do something about it by creating, or updating, a font product, then your work is political, useful and valuable. And I salute you.

bicycle, node, network, design

noreply@blogger.com (Anonymous) — Wed, 14 Sep 2016 08:25:00 +0000

This Monday ignite berlin took place and I did a fun, five minute, pecha kucha talk that also contained some systems analysis and a design insight. For a full transcript, read on.

ring ring

There are two things that you need to know about me. The first is that I am dutch and the second is that I am becoming a sentimental old fool. I combine the two when I do cycling holidays in Holland:

my partner Carmen leads the way

For this we use the fietsroutenetwerk, the bicycle route network of the Netherlands. This was designed for recreational cycling in the countryside. It was rolled out between 2003 and 2012. The network is point‐to‑point:

Between two neighbouring nodes there is complete signage—with no gaps—to get you from one to the other. And this in both directions. Here are some of these signs:

sources: fietsen op de fiets, het groene woud, gps.nl

The implicit promise is that these are nice routes. That means: away from cars as much as possible. And scenic—through fields, heath and forrest.

Using the nodes, local networks have been designed and built:

These networks are purely infrastructural; there is no preconception of what is ‘proper’ or ‘typical’ usage. They accommodate routes of any shape and any length.

At every node, one finds a local map, with the network:

source: wikimedia commons

It can be used for planning, reference and simply reassurance. Besides that, there are old‑fashioned maps and plenty of apps and websites for planning and sharing of routes.

The local networks were knitted together to form a national network:

Looking at this map I see interesting differences in patterns and densities. I don’t think this only reflects the geography, but also the character of the locals; what they consider proper cycling infrastructure and scenic routes.

The network was not always nation-wide. It was rolled out over a period of nine years, one local network at the time. I still remember crossing a province border and (screech!) there was no more network. It was back to old‑fashioned map reading and finding the third street on the left.

not invented here

I was shocked to find out that the Dutch did not invent this network system. We have to go back to the 1980s, north‐east Belgium: all the coal mines are closing. Mining engineer Hugo Bollen proposes to create a recreational cycling network, in order to initiate economic regeneration of the region. Here’s Hugo:

source: toerisme limburg

He designed the network rules explained in this blog post. The Belgians actually had to build(!) all of the cycling infrastructure, so it took them to 1995 to open the first local network. It now brings in 16.5 million Euro a year to the region.

how many?

I got curious about the total number of network nodes in Holland. I could not find this number on the internet. The net is really quite short on stats and data of the cycling network. So I needed to find out by myself. What I did was take one of my maps—

And I counted all the nodes—there were 309. I multiplied this with the number of maps that cover all of Holland. Then I took 75% of that number to deal with map overlaps and my own over‐enthusiasm. The result: I estimate that the dutch network consists of 9270 nodes.

in awe

The reason I got curious about that number is that every time I use the network, I am impressed by a real‐genius design decision (and I don’t get to say that very often). It makes all the difference, when using the network in anger.

All these nearly‐ten thousand nodes are identified by a two‑digit number. Not the four (or more future‐proof, five) one would expect. All the nodes are simply numbered 1 through 99, and then they start at one again. And shorter is much better:

source: recreatieschap westfriesland

Two digits is much faster to read and write down. It is easier to memorise, short‐term. It is instant to compare and confirm. Remember, most of these actions are performed while riding a bike at a nice cruising speed.

but…

Pushing through this two‑digit design must have been asking for trouble. Most of us can just imagine the bike‐shedding: ‘what if cyclists really need to be able to uniquely identify a node in the whole nation?’ Or: ‘will cyclists get confused by these repeating numbers?’

This older cycling signpost system has a five‑digit identification number:

source: dirk de baan

This number takes several steps to process. Two‑digit numbers are humane numbers. They exploit that way‐finding is a very local activity—although one can cover 130km a day on a bike.

whatchamacallit?

Wrapping up, the cycling network is a distributed network:

source: j4n

All nodes are equal and so are all routes. Cyclist route themselves. In that way the network works quite like… the internet.

We could call it the democratic network, because it treats everyone as equals. Or we could call it the liberal network (that would be very dutch). Or—in a post‐modern way—we could call it the atomised network.

I simply call it the bicycle route network of the Netherlands.

designing interaction for creative pros /4

noreply@blogger.com (Anonymous) — Mon, 30 May 2016 18:08:00 +0000

This is the fourth and final part of my LGM 2015 lecture. Part one urged to make a clear choice: is the software you’re making is for creative professionals, or not? Part two was all about the rally car and the need for speed. Part three showed the need to support the free and measured working modes of masters.

Today’s topic is how to be good in creative‐pro interaction. We start by revisiting the cars of part two.

party like it’s…

It is no coincidence that I showed you a 1991 family car and a 1991 rally car:

source: netcarshow.com and imgbuddy.com

I did that because our world—that of software for creative pros—is largely stuck in that era. And just like 1991 king‐of‑the‑hill cars (even factory‐mint examples found in a time capsule), this software is no longer competitive.

yes, it’s pants! source: charliepants.com

It is my observation that in this field there is an abundance of opportunities to do better. If one just starts scratching the surface, on a product, workflow, or interaction level, then today’s software simply starts to crumble.

testing, testing, one two

For instance, while doing research for the Metapolator project, I asked some users to show me how they work with the font design tools of today. They showed me the glyph range, the central place to organise their work and get started:

They also showed me the curve editor, where the detailed work on each glyph is done:

Both of them need the whole screen. In a short amount of time I saw a lot of switching between the both of them. I sensed wasted time and broken flows. I also saw tiny, slow handles in the editor. And I thought: this cannot be it.

They also showed me, in another program, designing in context:

I immediately sensed this was a big deal. I saw that they had pushed the envelope—however, not broken through to the other side.

Besides that, I observed that editing was done in outline mode (see the ‘y’, above), but evaluation is of solid black glyphs. Again I sensed broken flows, because of switching between making and evaluating. And I thought: this cannot be it.

Frank sez…

Enough of that; let’s zoom out from my field report, to the big issue at hand. To paraphrase Zappa:

‘How it has always been’ may not be quite dead, but it sure smells funny.

The question is: how did we get to this situation? Let me dig through my experience to find some of the causes.

First of all we can observe that each piece of creative‐pro software is a vertical market product; i.e. it is not used by the general population; only by certain masters. That means we are in armpit of usability territory. Rereading that blog post, I see I was already knee‐deep into this topic: ‘its development is driven by reacting to what users ask for (features!) and fear of changing “like it has always been” through innovation.’

go on, have another cake

The mechanism is clear: users and software makers, living in very different worlds, have a real hard time communicating. Where they manage, they are having the wrong conversation: ‘gimme more features!’ —‘OK, if that makes you happy.’

What is happening today is that users are discussing software made yesterday. They are not able to communicate that their needs are so lousily addressed. Instead, they want some more cherries on top and this cements the position of this outdated software.

Constantly, users are telling software makers, implicitly and explicitly, ‘add plenty of candy, but don’t change a thing.’

This has been going on for decades—lost decades.

bond of pain

A second cause that I want to highlight is that both users and software makers have worked for years to get on the inside and it has been a really painful experience for all of them. This unites them against change.

Thus users have been fighting several frustrating years to get ‘into’ software that was not designed (for them; armpit of usability, remember), but instead made on terms favourable to the software makers.

Software makers spent year after year trying to make something useful. Lacking any form of user research, the whole process has been an exasperating stab‐in‐the‐dark marathon.

Thus a variant of the Stockholm syndrome spooks both parties. They are scarred‐for‐life victims of the general dynamic of the pro‑software industry. But now that they have gotten this far, their instinct is to sustain it.

the point

Two decades of experience shows that there is a way out of this misery; to become competitive (again). There is no incremental way to get there; you’ll have to snap out of it. What is called for is innovation—of your product, workflow, your interaction. A way that unlocks results is:

user research
Experienced researchers cut straight past the wants and get the user needs on the table. (Obligatory health & safety notice: market research has nothing to do with user research; it is not even a little bit useful in this context.)
design‐driven innovation
When user needs are clear (see point 1), then a designer can tell you any minute of the project—first to last—what part of ‘how it has always been’ is begging to be replaced, and which part is the solid foundation to build upon. Designer careers are built on getting this right, every time.

Skip either point—or doing it only in a superficial, or non-consequential, way—and I’ll guarantee you’ll stay stuck in 1991. Making it happen requires action:

Software‐makers: enthusiastically seek out user researchers and designers and start to sail by them. Stop considering adding features a good thing, stop being a captive of ‘how it has always been’ and trust the accomplished.

picture show

To illustrate all this, let’s look at some of my designs for Metapolator. To be able to solve these problems of contemporary font design tools that I mentioned above, I had to snap out of the old way.

First of all, I pushed designing in context a lot further, by introducing in‑specimen editing:

Every glyph you see above is directly editable, eliminating switching between overview and editing. The size that the glyphs are displayed in can be adjusted any given moment, whatever suits the evaluate/edit balance.

‘OK, that’s great’ you say, ‘but every once in a while one needs a glyph range to do some gardening.’ To address that, I used a handy trick: the glyph range is just another specimen:

Everybody in the Metapolator team thought I was crazy, but I was dead set on eliminating outline mode. I sensed there was chance to do that here, because the focus moves from working at the edge of the glyph—the high‐contrast black–white transition—to the center line within:

Then there was the matter of offering users generous handles that are fast to grab and use. After brainstorming with Simon Egli, the design shown above was born: put them ‘on sticks’ outside, so that they do not impede visual evaluation of the glyph.

pep talk

In closing: to be good in creative‐pro interaction, I encourage you to—

Do not ask how the past can guide you. Ask yourself what you can do to guide your software for creative pros into the 21st century.

punters vs. society, an illustrated guide

noreply@blogger.com (Anonymous) — Mon, 15 Feb 2016 11:01:00 +0000

Recently I wrote about how all users act like selfish punters when you talk to them. And that only user research delivers insight into their diversity and needs, looking at them as a society. I will illustrate that in this blog post.

brownie snaps

Below, we see the users of a product—e.g. a piece of software, an (internet) service, a device:

All users are different. Above we see the diversity of this user society depicted in two dimensions; no two are in the same spot. In reality this spread happens in dozens of dimensions. Even for very specialised user groups like ‘font designers for indochinese languages,’ there is plenty of diversity in many dimensions.

We all act like selfish punters; you, me, everyone. And when we are individually engaged in talk about a product, we will offer self‐centred opinions on what matters most and self-serving feature requests, i.e. our wants:

The dynamic we see illustrated above is very common in the software industry. You will find it in 99% of—

custom software projects for companies, NGOs or the government, during requirements gathering;
small and medium‐sized software companies where the boss, sales, support and/or consultants talk to customers and users;
any kind of user forum, online or otherwise;
take (a variant of) the second point above and combine it with the third, that’s F/LOSS, all of it;
anywhere where market research is deployed.

write write, scribble scribble

It is also very common in the software industry to earnestly administrate user wants:

Common forms of this are—

lists of use cases;
use cases in sheep’s clothing: user stories;
bug trackers; not necessarily as an enhancement or a feature request, it may be dressed up as a bug, or a usability problem;
feature roadmaps;
a lingering pressure, guilt, or fear in the minds of those in charge—boss, product manager, or maintainer;
a consensus among (part of) the crew: ‘people keep asking for XYZ, we could hack something basic in a couple of days’ (yeah sure).

Now we can compare this administration of wants to the user society:

We see that at best, wants are good at describing the fringe of the society, but 80% of them are downright far‑out and esoteric.

Since wants are so overwhelmingly used in the industry to drive products and projects, there is overwhelming evidence that this leads to awful results. It is completely normal that a majority of time and talent is spent on adding far‑out and esoteric features that are instant bloat.

And thus everybody loses: makers, users and financial backers.

doing it right

Now we are going to stop flirting with disaster.

User research avoids all what has been described up to now in this post. The focus is on—

finding out what users need;
quality and depth of these findings;
understanding the mechanisms at play.

Instead of listening to everbody and their dog, researchers accompany a selection of representative participants on a ‘journey‘ through the pertaining activity, while constantly picking their brain:

Above, we see depicted that when users still insist on pushing their wants (i.e. go far out), researchers reel them in by questioning; peeling away layers of rationalisation in order to understand the underlying needs.

These needs are not exotic, they are basic human needs (e.g. control, overview, feedback, organisation, a stable environment, a simple rule book) that form the center of the picture—and are central to making it work for users.

Researchers and designers collaborate on constructing a model—an understanding—of the user society. The centre of the picture is where one finds the commonalities in the (analysed) research material:

This is the heart of the matter. It is surrounded by the diversity in needs as found by the research. Note that there is a hard edge to this model: what is outside is certainly out of scope.

The qualitative aspect of research (e.g. taking into account the tone of voice or facial expression when something is stated) makes a world of difference. It is this richness of information that makes user research so effective. We see above that some outliers have been ignored in the user model. This is done with full confidence, based on the research.

core, non‑core

Now we can compare the needs‐based user model to the user society:

The coverage of the model works out so well, that it is difficult to see the actual users. This is especially true for the heart of the matter. Note that some users at the very fringe of society may feel left out; they are covered a little bit or not at all.

In a design‐driven approach, the needs‐based user model is used to decide which features to add (cover the diversity, but nothing beyond the edge) and where to focus design and development effort (on the heart of the matter).

A/B testing

Zooming out, we now can compare the two approaches:

When compared to the results of user research, the bog standard, wildly popular method of listening to users and their wants—

fails to record the heart of the matter;
fails to record the diversity of user needs;
is a list of disparate wishes, instead of a coherent, nuanced insight;
highlights the fringe, the far‑out, the esoteric;
gets you completely the wrong picture.

postscript

This past semester I discussed all this with my students at the BTK design school. To get the point across about the dangers of talking to users, I asked them ‘do you remember these creatures in mythology that always give you the wrong answer, so that you get lost?’

‘Yeah’, they said, ‘they are called trolls.’

war and peace—the 5th column

noreply@blogger.com (Anonymous) — Fri, 21 Aug 2015 08:22:00 +0000

Building out the war and peace series, this second instalment focusses on acts of sabotage performed by users against… users. For those in a hurry, there is a short, sharp summary at the end.

cuckoo

Last week my friend Jan‑C. Borchardt tweeted:

‘Stop saying »the user« and referring to them as »he«. Thanks!’

To which I replied:

‘“They”; it is always a group, a diverse group.

‘But I agree, someone talking about “the user” is a tell‐tale sign that they are part of the problem, not the solution.’

All that points at a dichotomy that I meant to blog about for a long time. You see, part one of the war and peace series looked at all four parties involved—product makers, users, developers and designers—as separate silos. The logical follow‑up is to look at hybrid actors: the user‐developer, the product maker‐developer, et cetera.

While working to provide a theoretical underpinning to 20+ years of observation of performance in practice of these hybrid actors, I noticed that for all user‐XYZ hybrids, the user component has not much in common with the users of said product. In general, individual users are in conflict with the user group they are part of.

That merits its own blog post, and here we are.

spy vs. spy

First we got to get away from calling this ‘user versus users.’ The naming of the two needs to be much more dissimilar, both to get the point across and so that you don’t have to read the rest of this post with a magnifying glass, just to be sure which one I am talking about.

During the last months I have been working with the concept of inhabitants vs. their city. The inhabitants stand for individual users, each pursuing their personal interests. All of them are united in the city they have chosen to live in—think photoshop city, gmail city, etc. Each city stands for a bustling, diverse user group.

inner city blues

With this inhabitants & city model, it becomes easier to illustrate the mechanisms of conflict. Let’s start off with a real‐life example.

Over the next years, Berlin needs to build tens of thousands units of affordable housing to alleviate a rising shortage. Because the tens of thousands that annually move to Berlin are (predominantly) looking for its bubbly, relaxed, urban lifestyle, building tower blocks on the edge of town (the modernist dream), or rows of cookie‐cutter houses in suburbia (the anglo‐saxon dream) won’t solve anything.

What is needed is development of affordable housing in the large urban area of Berlin. A solid majority of the population of Berlin agrees with this. Under one condition: no new buildings in their backyard. And thus almost nothing affordable gets built.

What can we learn from this? Naturally reactionary inhabitants take angry action to hinder the development that their city really needs. I am sure this rings a bell for many a product maker.

yee‑haw!

The second example is completely fictional. A small posse of inhabitants forms and petitions the city to build something for their (quite) special interest: a line‐dancing facility. At first they demand that the city pays for everything and performs all the work. When this falls on deaf ears, the posse organises a kickstarter where about 150 backers chip in to secure the financing of the building work.

Being petitioned again, the city asks where this line‐dancing facility could be located. The posse responds that in one of the nicest neighbourhoods there is a empty piece of grassland. The most accessible part of it would be a good location for the facility and its parking lot.

The city responds that this empty grassland host events and community activities on about 100 days a year, many of which are visited by folks from all over the city. And all other days of the year the grassland serves the neighbourhood, simply by being empty and semi‐wild nature; providing a breather between all the dense and busy urbanisation, and a playground for kids.

repeat after me: yee‑haw!

This angers the line‐dancing posse. They belittle the events and activities, and don’t know anyone who partakes in them. The events can be moved elsewhere. The land just sits there, being empty, and is up for grabs. Here they are with a sack of money and a great idea, so let’s get a move on.

The city then mentions one of its satellite towns, reachable by an expressway. At its edge, there is plenty of open space for expansion. It would be good to talk to the mayor of that town. The posse is now furious. Their line‐dancing facility, which would make such a fine feature for the heart of the city, being relegated to being an appendix of a peripheral module? Impossible!

What can we learn from this? Inhabitants will loudly push their special‐interest ideas, oblivious to the negative impact on their city. Again this must also ring a bell for many product makers.

leaving the city

Now that the inhabitants & city model has helped us to find these mechanisms, I must admit there are also some disadvantages to it. First, cities do not scale up or down like user groups do. I have worked on projects ranging from a handful of users (hamlet) to 100 million (large country). And yes, the mechanisms hold over this range.

Second, I suspect that many, especially those of a technological persuasion, will take the difference between inhabitants and their city to be that the former are the people, and the latter the physical manifestation, especially buildings and infrastructure.

no escape

Thus we move on for a second time, picking a more generic route, but one with attitude. For individual users I have picked the term punter. If that smacks to you as clientèle that is highly opinionated, with a rather parochial view of their environs, then you got my point.

Now you may think ‘is he picking on certain people?’ No, on the contrary: we all are punters, for everything we use: software, devices, websites, services—hell, all products. You, me, everyone. We are all just waffling in a self‐centred way.

There is no single exception to the punter principle, even for people whose job is centred on getting beyond the punter talk and to the heart of the matter. It is simply a force of nature. The moment we touch, or talk about, a product we use, we are a punter.

greater good

For the user group I have picked the term society. This works both as a bustling, diverse populace and as a club of people with common interests (the photoshop society, gmail society, product‑XYZ society). Some of you, especially when active in F/LOSS, will say ‘is not community the perfect term here?’ It would be, if it wasn’t already squatted.

After almost a decade in F/LOSS I can say that in practice, ‘community’ boils down to a pub full of punters (i.e. chats, mailing lists and forums). In those pubs you will hear punters yapping about their pet feature (line dancing) and loudly resisting structural change in their backyard. What you won’t hear is a civilised, big‐picture discourse about how to advance their society.

it differs

One thing that last week’s exchange with Jan‑C., and also a follow up elsewhere, brought me is the focus on the diversity of a (product) society. This word wonderfully captures how in dozens and dozens of dimensions people of a society are different, have different needs and different approaches to get stuff done.

I can now review my work over the last decade and see that diversity is a big factor in making designing for users so demanding. The challenge is to create a compact system that is flexible enough to serve a diverse society (hint: use the common interests to avoid creating a sprawling mess).

I can also think of the hundreds of collaborators I worked with and now see what they saw: diversity was either ‘invisible,’ in their mono‐cultural environment, or it was such an overwhelming problem that they did not dare tackle it (‘let’s see what the user asks for’). Talking about ‘the user’ is the tell‐tale sign of a diversity problem.

The big picture emerges—

If you want to know why technology serves society so badly, look no further than the tech industry’s problem to acknowledge, and adapt to, the diversity of society.

Yes, I can see how the tendency of the tech sector to make products that only its engineers understand has the same roots as the now widely publicised problem that this sector has a hard time being inclusive to anyone who is not a male, WASP engineer; it is a diversity problem.

but why?

Back to the punters. That we all act like one was described ages ago by the tragedy of the commons. This is—

‘[…] individuals acting independently and rationally according to each’s self‐interest behave contrary to the best interests of the whole group by depleting some common resource.’

If you think about it for a minute, you can come up with many, many examples individuals acting like that, at the cost of society. The media are filled with it, every day.

what a waste

What common resources do punters strive to deplete in (software) products? From my position that is easy to answer—

makers’ time; both in proprietary and F/LOSS, the available time of the product maker, the designer and developers is scarce; it is not a question of money, nor can you simply throw more people at it—larger teams simply take longer to deliver more mediocre results. To make better products, all makers need to be focussed on what can advance their society; any time spent on punter talk, or acts (e.g. a punter’s pull request), is wasted time.
interaction bandwidth; this is, loosely, a combination of UI output (screen space, sound and tactile output over time) and input (events from buttons, wheels, gestures), throttled by the limit what humans can process at any given time. Features need interaction and this eats the available bandwidth, fast. In good products, the interaction bandwidth is allocated to serve its whole society, instead of a smattering of punters.

The tragedy of (software) products is that it’s completely normal that in reaction to punters’ disinformation and acts of sabotage, a majority of maker’s time and a majority of interaction bandwidth gets wasted.

Acts of sabotage? SME software makers of specialised tools know all about fat contracts coming with a list of punter wishes. Even in F/LOSS, adoption by a large organisation can come with strings attached. Modern methods are trojan horses of punter‐initiated bounties, crowdfunding or code contributions of their wishes.

the point

This makes punters the fifth column in the UI version of war and peace. Up to now we had four players in our saga—product maker, users (i.e. the society), developers and the designer—and here is a fifth: a trait in all of us within society to say and do exactly that what makes (software) products bloated, useless, collapse under their own weight and burn to the ground.

It is easy to see that punters are the enemy of society and of product makers (i.e. those who aim to make something really valuable for society). Punters have an ally in developers, who love listening to punters and then build their wishes. It makes the both of them feel real warm and fuzzy. (I am still not decided on whether this is deliberate on the part of developers, or that they are expertly duped by punters offering warmth and fuzziness.)

That leaves designers; do they fight punters like dragon slayers? No, not at all. Read on.

the dragon whisperer

Remember that punters and society are one and the same thing. The trick is to attenuate the influence of punters to zero; and to tune into the diversity and needs of society and act upon them. Problem is, you only get to talk to punters. Every member of society acts like a punter when they open their mouth.

There is a craft that delivers insight into a society, from working with punters. It is called user research. There are specialist practitioners (user researchers) and furthermore any designer worth their salt practices this. There is a variety of user research methods, starting with interviewing and surveying, followed up by continuous analysis by the designer of all punter/society input (e.g. of all that ‘community’ pub talk).

the billion‐neuron connection

What designers do is maintain a model of the diversity and needs of the society they are designing for, from the first to the last minute they are on a project. They use this model while solving the product‐users‐tech puzzle, i.e. while designing.

When the designer is separated from the project (tech folks tend towards that, it’s a diversity thing) then the model is lost. And so is the project.

(Obligatory health & safety notice: market research has nothing to do with user research, it is not even a little bit useful in this context.)

brake, brake

At this point I would like to review the conflicts and relationships that we saw in part one of war and peace, using the insights we won today. But this blog post is already long enough, so that will have to wait for another day.

Instead, here is the short, sharp summary of this post:

Users groups can be looked at in two ways: as a congregation of punters and as a society.
We all are punters, talking in a in a self‐centred way and acting in our self‐interest.
We are also all members of (product) societies; bustling, diverse populaces and clubs of people with common interests (the photoshop society, gmail society, product‑XYZ society).
Naturally reactionary punters take angry action to hinder structural product development.
Punters will loudly push their special‐interest ideas, oblivious to the negative impact on their society.
The diversity of societies poses one of the main challenges in designing for users.
The inability of the tech sector to acknowledge, and adapt to, the diversity of society explains why it tends to produce horrible, tech‐centric products.
In a fine example of ‘the tragedy of the commons,’ punters behave contrary to the best interests of their society by depleting makers’ time and interaction bandwidth.
Punters act like a fifth column in the tri‑party conflict between product makers, society and developers.
You only get to talk to punters, but pros use user research methods to gain insight into the diversity and needs of a society.
Everyone gets bamboozled by punters, but not designers. They use user research and maintain a model of diversity and needs, to design for society.

Interested, or irritated? Then (re)read the whole post before commenting. Meanwhile you can look forward to part three of war and peace, the UI version.

wishful thinking; ignite the shirts

noreply@blogger.com (Anonymous) — Fri, 07 Aug 2015 11:31:00 +0000

A week ago I presented about my wishful thinking and act to succeed series at Ignite Berlin. That led to some unforeseen developments, with the result that you can look forward to some real cool t‑shirts.

kaboom!

The Ignite format is pretty demanding. I better let them explain it themselves:

‘Each speaker gets 5 minutes on stage. 20 slides, which auto‐forward every 15 seconds, no going back. So it’s pretty brutal, although nothing that a rehearsal can’t fix.’

the Ignite format, from their about page

Yes, this is really different than presenting 20 to 45 minutes at your own rhythm, which is what I am used to. A strategy, careful planning of the 20 slides and a generous helping of rehearsal are asked for. What I regularly see at conferences—some (recycled) slides banged together the night before and winging it during showtime—is bound to have a 99.99% fail rate at Ignite.

bang, you win

The upside is that the audience wins. All the speakers are an order of magnitude more prepared than they normally would be. There is no time for waffling and even single‐issue talks are engaging for five minutes.

At this event there were fourteen talks, two runs of seven each, which sounds like a looong marathon to sit through. In praxis, one run of seven talks takes 35 minutes of pure talk time, plus some for applaus and changeover (everything is pre‐sequenced on a single laptop). Thus in 38–40 minutes, seven engaging topics have passed and then it is time for a break, to digest and discuss.

Since my talk was scheduled almost at the end of the event, I expected to be too preoccupied to enjoy all these talks before mine. On the night, all of the talks engaged and entertained me, which put me in a good mood for mine. (When is the last time you could say that about a conference?)

show and tell

In my Ignite talk I showed a selection of wishful‐thinking issues, together with the positive action that ~~can~~ must be taken to remedy them. Meanwhile, I told the back‐story, for instance, that—

I have seen all of this wishful thinking in practice;
I wanted to expose a destructive streak that runs through the IT industry;
it was more work to make issues and remedies fit a single tweet, than to come up with them;
I felt that I could go on ‘forever’, but called it quits at fifty;
being in interaction design—which is essentially product realisation and involves seeing all dimensions (product, users, tech)—makes it easy to see the damage from wishful thinking;
it is a real shame to see the right people, with the right intentions, run projects into the ground through wishful thinking;
this is not valid only in IT, but in any industry;
please, it is difficult, but resist the wishful thinking when you believe in what you are working on;
what is needed is process change, which is also difficult, introducing a design process that from the first to the last minute of the project shapes and runs all product realisation, including manufacturing or fixing that final bug.

aftermath

I had plenty of interesting discussions after the talks were through, but one really took me by surprise: fellow speaker Onika Simon of Spokehub said something along the lines of ‘why don’t you put this wishful thinking on t‑shirts? There are plenty of people who deserve to get one.’

During my talk I had admitted that I am not a product maker and that never in my life I’ve had a good product idea. Thus it did not surprise me that I never had thought of wishful‐thinking t‑shirts. But now that the genie was out of the bottle, how difficult could it be?

snakes and ladders

Some parts were really straightforward. The content was already there. Deciding what should go on front and back, and picking some free‐as‐in‐speech fonts (right, no pirated components in my products) was no big deal. Neither was typesetting the texts.

Making EPS files already involved jumping through one hoop (why not accept pdf? It is just about the same tech). Dealing with spreadshirt was a three‐ring circus. Spreadshirt is suppose to make it easy to open your own merchandising outlet, but forget about the easy part.

I could go on and on, about requiring flash <spit>, crashes, usability disasters, the pervasive ‘how do I get that done?’ and ‘how do I know it did it?’ anxiety, and only finding out what you will get when you get there. But let’s say that unless you are a spreadshirt executive, I won’t bother (you with it).

lift‑off

Against these odds, I did manage to put up a t‑shirt shop in less than a week. There is one MVP: a limited‐edition t‑shirt (available one month only) in female and male cuts, and two variants, dark and bright:

I found out at the very end, when I got to check it out (typical, eh), that you can change the shirt colour in the shop. Suits me fine; a simple ‘menu’ to choose from and then freedom to customise, a bit.

When I checked the wishful thinking topic page, I noticed how hard‐hitting these are by themselves, so it was clear that these go, solo, on the front:

This is the wishful thought for August ’15 and you can see that I plunged for the first one I saw. Each month I will pick a different one (no, not in the order on that page) and change the ‘bright’ colour scheme.

On the back we ensure that everyone gets the point…

…just in case the beholder wishfully thinks the statement on the front is best‐practice.

postscript

And out of the blue m+mi works offers a hardware product. It will be fun offering these and I hope spreadshirt cooperates a bit more to keep it that way. I look forward to seeing one of these t‑shirts being worn in the wild.

designing openType‐features UI /intro

noreply@blogger.com (Anonymous) — Tue, 23 Jun 2015 07:24:00 +0000

This blog post kicks off my involvement with bringing openType features to F/LOSS (typo‐)graphical software. I will explain why this is a special, complicated project, followed by the approach and structure I will apply to this design project and finish with what to expect as deliverables.

a bit of a situation

First things first. It is quite likely that when you are reading this, you know what openType features in fonts are. But just in case you don’t, here is a friendly, illustrated explanation of some of the features, without putting you straight into corporate specification hell. The reason I said ‘some’ will become clear below.

What is interesting is that there is a riot going on. The 800‑pound gorillas of (typo‐)graphical software—the adobe creative suite applications—have such bad and disparate UI for handling openType features that a grass‐roots protest movement started among typographers and font designers to do something about it. What followed was a a petition and a hasty promise by adobe to do better—in the future.

meanwhile in Toronto…

These events prodded Nathan Willis into action, because ‘open‐source applications aren’t any better in this regard.’ He organised a openType workshop at this year’s LGM to get a process started to change that. I went there because this is smack in the middle of one of my fields of specialisation: interaction for creatives. As you can read in Nathan’s report, I got immediately drawn into the UI discussion and now we have a loose‐knit project.

The contents and vibe of the questions, and my answers, in the UI discussion all pointed in a certain direction, that I was only able to name a day later: harmonised openType features for all F/LOSS (typo‐)graphical applications definitely has an infrastructure component.

the untouchables

Pure infrastructure—e.g. tap water, electricity, telecoms—offers its designers some unique challenges:

everybody uses it: and everybody’s needs are equally important; there is no opportunity to optimise the design for the specific needs of user groups.
nobody cares: usage is ubiquitous, i.e. we all do not even register that we are using this stuff all the time—until it stops working, then we miss it a hundred times a day. This makes it very hard to research; no recollection, feelings or values are connected to infrastructure, just entitlement.
anyplace, anywhere, anytime: there is no specific contextual information to work with: why is it used; what is the goal; what does it mean in the overall scheme of things; how much is a little, and a lot; it is used sparsely, all the time, at regular intervals, in bursts? It all depends and it all happens. Just deal with it, all of it.
millions of use cases: (not that I consider use cases a method that contributes positively to any software project, but‐) in the case of infrastructure something funny and instructive happens: after a week or two of exploration and mapping, the number of use cases grows exponentially towards a million and… keeps on growing. I have seen this happen, it is like peeling an onion and for every layer you peel off, the number goes up by an order of magnitude. These millions of use cases are an expression of everybody using it anyplace, anywhere, anytime.
heterogeneous capabilities: this is not always the case, but what is available can vary, a lot. For instance public transport: how many connections (incl. zero) are available for a given trip—and how fast, frequent and comfortable these are—is set by the network routes and timetables. An asked‑for capability is on offer, or not. It all depends and it all happens. Just deal with it, all of it.

I have worked as design lead on two infrastructure projects. One was Nokia dual‑SIM, the other openPrinting, where we designed printing dialogs for all linux users (everyone), as used in 10.000 applications (anyplace, anywhere, anytime), connected to 10.000 different printer models (heterogeneous capabilities). I dubbed it the project with five million use cases.

Ah, and since both application and printer configure the available options of the print dialog, there are potentially 100 million configurations. Even if in reality the variability is far less (say, just 1% on both application and printer side; i.e. 100 significantly different printer models and 100 apps that add serious, vital printing options), then it is still an overwhelming 10.000 configurations.

drowning, not waving

In my experience, designing infrastructure is very demanding. All the time one switches between making the big, abstract plan for everything, and designing, minutely, one of many details in complete isolation. Mid‑level interaction design, the journeyman, run‑of‐the‑mill, lay‑out‐a‑screen level, is completely missing.

It is like landscaping a featureless dessert, where every grain of sand is a detail that has to be dealt with. With no focus on particular users, no basis for research, no context, no just‑design‐the‐example, millions of use cases and highly variable capabilities, I have seen very capable design colleagues lose their bearings and give up.

back at the ranch

Enough war stories. How large is this infrastructure component of openType features in (typo‐)graphical software? Let’s check the list:

everybody uses it—nope. Whether the user groups turn out to be defined real narrow or quite wide—a matter of vision—they will have in common that all of them know their typesetting. That is a craft, not common knowledge.
nobody cares—well, soon they won’t. Right now there is upheaval because nothing is working. As soon as users get a working solution in the programs they use, it will become as interesting as the streetlights in your street.
anyplace, anywhere, anytime—right on! This has to work in (typo‐)graphical software; all of it—even the kind I have never heard of, or that will be invented in five years from now. All we know, is that serious typesetting is performed there by users, on any length of text selection.
millions of use cases—not quite. The limited user group provides the breaks here. But there is no such limit from the application side; on the contrary: most of these are (open‐ended) tools for creatives. Just thinking about how flexible a medium text is, for information or shapes, gives me the confidence to say that 10.000 use cases could be compiled, if someone would sit down and do it.
heterogeneous capabilities—hell yeah! OpenType‐features support in fonts is all over the place and not just because of negligence. First there is the kaleidoscopic diversity of scripts used around the world, most of which you and I have never heard of. Latin script is just the tip of the iceberg. Furthermore, what is supported, and how each supported feature is actually realised, is completely up to the font designer. The openType‐features standard is open‐ended and creates opportunities for adding sophistication. This is only limited by the combined imagination of the font design community.

Adding that up, we get a score of 3½ out of 5. By doing this exercise I have just found out that openType features in (typo‐)graphical software is 70% infrastructural. This is what I meant with that it is a special, complicated project.

structure—the future

In projects like these structuring the design work is make‑or‐break; either we set off in the right direction, or never get to any destination—not even a wrong one. The structure I use is no secret. Here is my adaptation for this project:

A product vision is not that easy to formulate for pure infrastructure; it tends to shrink towards ‘because it’s there.’ For instance at openPrinting the vision was ‘printing that just works.’ I still regret not having twisted some arms to get a value statement added to that. There were times that this value void was keeping us from creating true next‐generation solutions.

Apart from ‘what’s the value?’ also ‘who is this for?’ needs to be clarified; as we saw earlier, openType features is not for everyone. The identity question, ‘what is it we are making?’ may be a lot less spectacular, but it needs to be agreed. I will take this to the Create mailing list first, mainly to find out who are the ‘fish that swim upfront’, i.e. the people with vision and drive. Step two is an online vision session, resulting in a defined vision.

The deliverable is a to‑the‐point vision statement. If you want to get a good picture of what that entails, then I recommend you read this super‐informative blog post. Bonus: it is completely font‐related.

we want the funk, the whole funk, nothing but the funk

A deep understanding of the functionality is the key to success in this project. I already got burned once with openType features in the Metapolator project. Several font designers told me: ‘it is only a bunch of substitution rules.’ Until it turned out it isn’t. Then at the LGM meeting another surprise complication surfaced. Later I briefly check the specification and there is yet another.

This is what I meant before with that friendly page explaining some of the features. I do not trust it to be complete (and it is only Latin‐centric, anyway). As interaction architect I will have to be completely on top of the functionality, never having to rely on someone else to explain me what ‘is in the box.’ This means knowing the openType standards.

Central to it is the feature tags specification and the feature definition syntax. This contains both the material for understanding of how complicated it all can get and the structures that I can use to formulate UI solutions. It is one of the few aspects that are firm and finite in this project.

The deliverable is a functionality overview, written up in the project wiki.

talking heads

I will do user research, say interview half a dozen users, to gain insight into the act of typesetting, the other aspect that is firm and finite in this project. Which users to recruit depends on what is defined in the product vision. Note that the focus is on the essence of typesetting, while ignoring its specific role in the different (typo‐)graphical applications, and not get swamped by the latter’s diversity.

The deliverable is notes of interest from the interviews, written up in the wiki.

I look forward to an exchange with F/LOSS (typo‐)graphical applications via the Create list. This is not intended to get some kind of inventory of all the apps and how different they are. In this project that is taken as abstract and infinite—the good old infrastructural way.

What I want to find out is in how many different ways openType features must, or can, be integrated in the UIs of (typo‐)graphical applications. In blunt terms: how much space is there available for this stuff, what shape does it have and what is the duty cycle (permanently displayed, or a pop‑up, or…)? These diverse application needs are clustered into just enough UI models (say, six) and used below.

The deliverable is the UI models, written up in the wiki.

getting an eyeful

Then it is time to do an expert evaluation of existing openType‐features UI and all these UI ideas offered by users when the petition did its rounds. All of these get evaluated against—

the product vision: does it realise the goals? Is it appropriate for the defined user groups?
the functionality: can it cope with the heterogeneous capabilities?
the user research: how tuned is it for the essence of typesetting?
the UI models: how well does it fit with each model?

All of it gets analysed, then sorted into the good, the bad and the ugly. There will be a tiny amount of gold, mostly in the form ideas and intentions—not really what one would call a design—and a large catalog of what exactly not to do.

The deliverable is notes of interest from the evaluation, written up in the wiki.

warp drive

Then comes the moment to stop looking backwards and start working forwards; to start creating the future. First a solutions model is made. This is a combination of a broad‐strokes solution that cuts the project down to manageable proportions and a defined approach how to deal with the rest, the more detailed design work.

The next stage is to design a generic solution, one that already deals with all of it, all the hairy stuff: text selections of any length, all the heterogeneous capabilities, the typesetting workflow, clear representation of all openType features available and their current state. This will be specified in a wiki, in the form of UI patterns.

With the generic solution in place it will be real clear for the central software library in this small universe, HarfBuzz, which new capabilities it will need to offer to F/LOSS (typo‐)graphical software.

home straight

The final design phase is to work out the generic solution for each UI model. These will still be toolkit agnostic (not specific for KDE or gnome) and, btw, for desktop UI‐only (touch is a whole ’nother kettle of fish). This will also be specified in the wiki.

With this, every (typo‐)graphical software project can go to the wiki, pick a UI model that most matches their own UI structure and see a concrete UI design that, with a minimum of adaptations, they can implement in their own application. They will find that HarfBuzz fully supports their implementation.

While working on Metapolator in the last year I had good experience with sharing what I was doing almost every day I was working on it, through its community. There were encouragement, ideas, discussions, petitions and corrections—all useful. I think this can be replicated on the Create list.

a half‑century of success

noreply@blogger.com (Anonymous) — Thu, 11 Jun 2015 10:48:00 +0000

This is the final instalment of the mini‐series I ran on the usual social channels—twitter, g+, linkedin and xing—called positive action ships successful products. There, for every wishful thought that persists in the (mobile) software industry, I supplied a complementary positive action.

To complete the round number of fifty, I present the final dozen + two of these for your reference. If you are a product maker, or manage a product‐shipping organisation, then you can initiate at least one of these today:

Make the lead designers of your hard‐ and software work as a pair; make them inseparable.

cf. ‘The hardware specs are fixed, now we can start with the software design.’

Define your focus so tightly, it hurts (a bit); deploy it so you ship, instead of discuss.

cf. ‘We spent ages discussing this, trying to find a solution that pleased everyone.’

Make interaction design the backbone of your product realisation; or compete on low, low price.

cf. ‘We thought we could spend a couple of man‐days on the low‐hanging usability fruit.’

Deploy lightweight design and engineering documentation to keep everyone with the programme.

cf. ‘The source is the ultimate documentation.’

Ban hacks, at least from those who are supposed to shape your product for the long term.

cf. ‘There is no need to go for the gold‐taps solution.’

Set a ‘feature budget’ and set it way below bloat; be frugal, spend it on user value.

cf. ‘It does not hurt to have those features as well.’

Set the goal to be competitive on each platform you support—that starts with your interaction.

cf. ‘One code base; fully cross‐platform.’

Root out boilerplate thinking for any product aspect; your design process is your QA.

cf. ‘You have to pick your battles.’

Set up your designers for big impact on the internals of your software, instead of vice versa.

cf. ‘Once you get familiar with the internal workings of our software, it becomes easy to use.’

Define your target user group(s) so tightly, it hurts; focus on their needs, exclusively.

cf. ‘Our specific target user group is: everyone.’

Introduce this KPI: the more your developers think the UI is ‘on the wrong track,’ the better.

cf. ‘Our developers are very experienced; they make the UI of their modules as they see fit.’

Hire those who are able to take your interaction beyond the HIG, once you achieve compliance.

cf. ‘We religiously adhere to the HIG.’

Regularly analyse workarounds adopted by your users; distill from them additional user needs.’

cf. ‘You can do that by [writing, running] a script.’

Make the connection: product–users–tech. Design is the process, the solution and realisation.

cf. ‘What do you mean “it’s all connected”? we just don’t have the time for those bits and pieces.’

ask not what this blog can do for you…

Now, what else can you do? First of all, you can spread the word; share this blog post. Second, I invite you to connect via twitter, g+, linkedin, or xing.

And third, if you able and willing to take some positive action, then email or call us. We will happy to help you ship successful products.

ps: you can check out part three if you missed it.

designing interaction for creative pros /3

noreply@blogger.com (Anonymous) — Thu, 04 Jun 2015 08:13:00 +0000

Part three of my LGM 2015 lecture (here is part one and two). It is about equal opportunities in creative‐pro interaction. To see what I mean, let’s make something: a square.

two‐way street

There are two ways for masters to get the job done. The first way is to start somewhere and to keep chipping away at it until it is right:

heads up: animated gif

So let’s throw in some material, move and size it (bam, bam, bam)—right, done. That was quick and the result is perfect.

like putty

This is called free working; squeeze it until it feels right. It is always hands‑on and I always move both my hands in a moulding motion when I think of it, to remind me what it feels like.

Although done by feeling, it is still fast and furious. Don’t mistake this for ‘trying out’, ‘fiddling’ or ‘let’s see where we end up’; that is for dilettantes. When masters pick up their tools, it is with great confidence that the result they have in mind will be achieved in a predictable, and short, amount of time.

on the other hand…

The second way for masters to get the job done is to plan a bit and then create a precise, parametric, set‑up:

This is called a jig. Now the master only has to ‘cut’ once and a perfect result is achieved:

another animated gif

measure twice, cut once

This is called measured working. It is an analytical approach and involves planning ahead. It delivers precise results, to the limits of the medium. You will find it in many places; everywhere where the hands‑on factor is zero, parameters are entered and—bam—the result is achieved in one stroke.

It might be tempting to think that setting up the jig always involves punching in numbers. However also making choices from discrete sets, e.g. picking a color from a set of swatches, is part of it. Thus it is better to talk in general of entering parameters.

old‐skool

I did not make up all this by myself. I am indebted to this very cool book that goes deep into the matter of free and measured working, as practiced for centuries by masters. Luckily it is back in print:

Once familiar with this duality in how masters work, it can be used to analyse their workflows. For instance while reading this article about Brian Eno working with the band James.

In the sidebar (Eno’s Gear) it says ‘I don’t think he even saves the sounds that he gets. He just knocks them up from scratch every time’ about using one piece of gear, and ‘It’s stuffed full of his own presets’ about another. Reading that, I thought: that has, respectively, the vibe of free and measured working.

I have looped that insight back into my designs of creative‐pro software from then on. That is, giving equal importance to users building a collection of presets and knocking‑it‑up‐from‐scratch for tool set‑ups, configuring the work environment and assets (brush shapes, patterns, gradients, et cetera).

(There are more nuggets of that’s‐how‐masters‐work in the Eno article; see if you can spot them.)

the point

And with that I have arrived at rule numero one of this blog post:

All masters work free and measured; the only thing predictable about it is that it occurs 50–50, with no patterns.

We cannot rely on a given master taking the same route—free or measured—for all the different tasks they perform. It’s a mix, and a different mix for every master. Thus design strategies based on ‘remember if this user tends to do things free or measured’ are flawed.

We cannot rely on a given task being predominantly performed via either route—free or measured—by masters. It’s a mix, a 50–50 mix. Thus design strategies based on ‘analyse the task; is it free or measured?’ are flawed.

same, not same

The same master doing the same task will pick a different route—free or measured—at different times, based on the context they are in. For instance how difficult the overall project is. And for sure their own mood plays a role; are they under stress, are they tired (that night shift meeting that deadline)?

Masters will guesstimate the shortest route to success under the circumstances—and then take it.

dig it

With this 50–50 mix and no patterns, software for creative pros has only one choice:

Equal opportunity: offer every operation that users can perform in—at least—two ways: one free, one measured.

If you now say either ‘man, this will double my software in size’, or ‘yeah, my software already does that’, then my reply is: experience says that once we really start checking, you will see that current creative‐pro software achieves 60–80% equal opportunity.

how low can you go?

The question is not how do we prevent this list of operations from ballooning. It is: are there any more innocent, boring, easy to overlook operations to go on our list? For instance: setting the document size. Yeah boring, but often enough key to the creative result. A crop tool is the free way to do that operation.

From the Brian Eno episode above we have seen that it is not enough to filter the operations list by ‘does it change the creative end result?’ There we saw that meta‐operations (set up tools, configuring the work environment and assets) are also fully in scope.

picture show

To illustrate all this, let’s look at some of my designs for Metapolator.

a final animated gif

This is measured central: the parameters panel. Literally here parameters are entered and—bam—applied. With the popup action shown the system is taken to the next level. Preferably for wide‐ranging selections, expressions of change (e.g. new value = A × old + B) can be built.

Most on‑canvas interaction is by nature of the free variety. The hands‑on factor is simply up for grabs. In Metapolator this interaction complements the parameter panel shown above to achieve equal opportunity.

Specimens are a huge factor in the Metapolator design. It is the place to evaluate if the typefaces are right. That makes it also the logical place to squeeze it until it is right: free working.

All on‑canvas interaction is performed directly in the specimens for this reason. If that looks natural and normal to you, I say ‘you’re welcome.’ This is completely novel in the field of font design software.

Here are these fellows again, the slider set for freely mixing master fonts to make new fonts. These new fonts are shown by the blue markers, so that users can feel the clustering and spread of these new fonts—clearly a component of free working.

The numbers you see are all editable, also quickly in a row. This supports measured working. That number input is straightforward and gives predictable and repeatable results was a big factor for me to choose the algorithm of these sliders over alternatives.

boom, boom

In short: software for creative pros has to offer every operation that users can perform in two ways: one free—squeeze it until it feels right—one measured—involving planning ahead, entering parameters and ‘cutting’ once.

That’s it for part three. Stay tuned for part four: how to be good.

designing interaction for creative pros /2

noreply@blogger.com (Anonymous) — Tue, 12 May 2015 17:29:00 +0000

Part two of my LGM 2015 lecture (here is part one). It is a tale of cars. For many years I have had these images in my head and used them in my design practice. Let’s check them out.

freude am fahren

First up is the family car:

source: netcarshow.com

It stands for general software. It is comfortable, safe and general‐purpose. All you need to use it is a minimum of skills, familiarity and practice—in the case of cars this is covered by qualifying for a driving licence.

In the case of software, we are talking casual and enthusiast use. A good example is web browsers. One can start using them with a minimum of skills and practice. After gaining some experience one can comfortably ~~drive~~ use a browser on a daily basis. If a pro web browser exists, then it has escaped my radar.

(It would make a very interesting project, a pro web browser. But first a product maker would have to stand up with a solid vision of pro web browsing; its user groups; and some big innovation that is valuable for these users.

vroooom

When I think of creative pro interfaces, I think of this:

source: imgbuddy.com

The rally car. It is still a car, but… different. It is defined by performance. And from that, we can learn a couple of things.

speed, baby

First, creative pros work fast. They ‘wield the knife’ without doubt. A telltale sign of mastery is the speed of execution. I have this in mind all the time when designing for creative pros.

I vividly remember one of the earliest LGMs, Andy Fitzsimon went on stage and demonstrated combining pixel and vector in one image. The pace was impressive, Andy was performing nearly two operations per second.

Bam bam bam bam. At a tempo of 120 beats per minute; the solid tempo of marching bands and disco. That is the rhythm I aim to support, when designing for creative pros.

command and control

Second, creative pros really know their material, the medium they work with. They can, and need to, work with this material as direct and intimate as possible, in order to fulfil creative or commecial goals. This all can be technology‐assisted, as it is with software, but the technology has to stay out of the way, so that it does not break the bond between master and material.

The material I am talking about is that of film, graphics, music, animation, garments, et cetera. These can be digital, yes. However data and code of the software‐in‐use are not part of a creative pro’s material. Developers are always shocked, angry, then sad to learn this.

Thus Metapolator, has been designed for font designers and typographers who know what makes a font and what makes it tick. They know the role of the strokes, curves, points, the black and the white, and of the spacing. They are experienced in shaping these to get results. It is this material that—by design—Metapolator users access, just that it is organised such that they can work ten times faster.

dog eat dog

Third, it’s a competitive world. Creatives pros are not just in business. Also in zero‐budget circles there are real fun and/or prestigious projects where exactly those with proven creative performance, and ability to deliver, get asked.

Tools and software are in constant competition, also in the world of F/LOSS. It is a constant tussle: which ones provide next‐generation workflows with more speed and/or more room for creativity? Only competitive tools make masters competitive.

the point

Now that we got the picture, here is the conflict. The rules—the law and industry mores—that make good family cars may be a bad idea to apply to rally cars. And what makes rally cars competitive, may simply be illegal for family cars.

Every serious software platform has its HIG (human interface guidelines). It is the law, a spiritual guide and a huge source of security for developers. That is, for general software. It is only partly authoritative for software for creative pros. Because truly sticking to the HIG, while done all in good faith, will render creative pro software non‐competitive.

vorsprung durch technik

Rally cars contain custom parts, handmade from high performance materials like aluminium, titanium, carbon, etc. This is expensive and done because nothing off‐the‐shelf is sufficient.

Similarly creative pro software contains custom widgets, handmade at great expense—in design and development. For a decade I have witnessed that it is a force of nature to end up in that situation. Not for the sake of being cool or different, but all in the name of performance.

tough cookie

So, with loose laws and a natural tendency for custom widgets, can you do just what you like when you make creative pro software? Well no. It is tough, you still have to do the right thing. If this situation makes you feel rather lost, without guidance, then reach out and find yourself an interaction designer who really knows this type of material. Make them your compass.

picture show

To illustrate all this, let’s look at some of my designs for Metapolator.

Speed, baby! Big handles to select and move individual points on the skeleton of a glyph (i.e. direct control of the material). During a brainstorm session with Metapolator product visionary Simon Egli, he noticed how the points could be connected by rigid sticks to big handles.

I worked out the design with big (fast) handles available for furious working, but out of the way of the glyph, so it can be continuously evaluated (unbroken workflow).

This is a custom slider set for freely mixing master fonts—metapolation—to make new fonts. In this case four fonts, but it has been designed to easily scale up to nine or more; a Metapolator strength (vis‑à‐vis the competition).

One of the sliders—‘Alternate’—is in an “illegal” configuration; it is reversed. This is done to implement the rule that the mix of fonts has to always add up to 100%. There is special coupled behaviour between the sliders to ensure that.

The design of this part included a generous amount of exploration and several major revisions. Standard widgets and following the HIG would not deliver that every sliders setting maps to one unique font mix. Apart from a consistency goal, that is also about maximising input resolution. So I broke some rules and went custom.

This is also a metapolation control. In this case a three‐dimensional one involving eight master fonts. Working with that many fonts is really a pro thing; you have to know what you are doing and have the experience to set up, identify and pick the ‘good font’ results.

The long blue arrow is a font family, with nine or so fonts as members. The whole family can be manipulated as one entity (i.e. placed and spanned in this 3‑D space) as can each member font individually.

Final example: complex selections. Across three different fonts and three different glyphs, several points have been selected. Now they can be manipulated at the same time. That is definitely not consumer‑grade.

If that looks easy, I say ‘you’re welcome.’ It takes serious planning ahead in the design to allow this interaction; for the three fonts to appear, editable, at the same time; for deep selections within several glyphs to be possible and manageable—the big handles‑on‐sticks help also here.

vroom, vroom

In short: if there is one thing that I want you to take away from this blog post, then it is that image of the rally car. How different its construction, deployment and handling are. Making software for creative pros means making a product that is definitely not consumer‑grade.

That’s it for part two. Go straight to part three: 50–50, equal opportunities.

designing interaction for creative pros /1

noreply@blogger.com (Anonymous) — Thu, 07 May 2015 17:23:00 +0000

Last week at LGM 2015 I did a lecture on one of my fields of specialisation: designing interaction for creatives. There were four sections and I will cover each of them in a separate blog post. Here is part one.

The lecture coincided with the launch of the demo of Metapolator, a project I have been working on since LGM 2014. All the practical examples will be from that project and my designs for it.

see what I mean?

‘So what’s Metapolator?’ you might ask. Well, there is a definition for that:

‘Metapolator is an open web tool for making many fonts. It supports working in a font design space, instead of one glyph, one face, at a time.

‘With Metapolator, “pro” font designers are able to create and edit fonts and font families much faster, with inherent consistency. They gain unique exploration possibilities and the tools to quickly adapt typefaces to different media and domains of use.

‘With Metapolator, typographers gain the possibility to change existing fonts—or even create new ones—to their needs.

‘Metapolator is extendible through plugins and custom specimens. It contains all the tools and fine control that designers need to finish a font.’

theme time

That is the product vision of Metapolator, which I helped to define the moment I got involved with the project. You can read all about that in the making‑of.

One of the key questions answered in a product vision is: who is this for? And with that, I have arrived at what this blog post is about:

Products need a clear, narrow definition of their target users groups. Software for creatives needs a clear definition whether it is for professionals, or not.

Checking the vision, we see that Metapolator user groups are well defined. They are ‘“pro” font designers’ and ‘typographers.’ The former are pro by definition and the latter come with their own full set of baggage; they are pro by implication.

define it like a pro

But what does pro actually mean? And why is it in quotes in the Metapolator vision? Well, the rather down‐to‐earth definition of professional—earning money with an occupation—is not helping us here. There are many making‐the‐rent professionals who are terrible hacks at what they do.

Instead it is useful to think of pros as those who have mastered a craft—a creative craft in our case. Examples of these are drawing, painting; photographing, filming, writing, animating, and editing these; sewing, the list goes on and on.

Making software for creative pros means making it for those who have worked at least 10.000 hours in that field, honing their craft. And also making it for for the apprentices and journeymen who are working to get there. These two groups do not need special ‘training wheels’ modes; they just need to get their hands dirty with the real thing.

the point

The real world just called and left a message:

making it for pros comes at a price.

First of all, it is very demanding—I will cover this in the follow‑up posts. Second, it puts some real limits on who else you can make it for. Making it for…

pros: is perfectly focussed, to meet those demanding needs.
pros + enthusiasts: (the latter also known as prosumers.) This compromises how good one can make it for pros; better keep in check how sprawling that enthusiast faction is allowed to be.
~~pros + enthusiasts + casual users~~: forget it, because pros and casual have diametrically opposite needs. There is no room in the UI for both, and with room I mean screen real estate and communication bandwidth.
~~pros + casual users~~: for the same reasons one can royally forget about this one too. Enough said.

the fall‐out

You might think: ‘duh, that speaks for itself, just make the right choice and roll with it.’ If it was only that easy. My experience has been that projects really do not like to commit here, especially when they know the consequences outlined above. And when they did make a choice, I have seen the natural tendency to worm out of it later.

I guess that having clear goals is scary for quite a few folks. Having focussed user groups means saying ‘we don’t care about you’ to vast groups of people. Only the visionary think of that as positive.

Furthermore, clear goals are a fast and effective tool to weed out bad ideas, on an industrial scale. That’s good for the product, but upsets the people who came up with these ideas. So they renegotiate on the clear goals, attacking the root of the rejection.

no fudging!

In short: define it; is your software for creatives made for pros, or not? Then compile a set of coherent user groups. In the case of Metapolator the ‘pro’ font designers and typographers fit together beautifully. Once defined, stick with it.

That’s it for part one. Here is part two: a tale of cars.

[editor’s note: Gee Peter, this post contains a lot of talk about pros, but where is the creative angle?] True, the gist this post is valid for all professionals. The upcoming parts will feature more ‘creative’ content, more Metapolator, and illustrations.

writing a product vision for Metapolator

noreply@blogger.com (Anonymous) — Fri, 25 Apr 2014 20:01:00 +0000

A week ago I kicked off my involvement with the Metapolator project as I always do: with a product vision session. Metapolator is an open project and it was the first time I did the session online, so you have the chance to see the session recording (warning: 2½ hours long), which is a rare opportunity to witness such a highly strategic meeting; normally this is top‐secret stuff.

boom boom

For those not familiar with a product vision, it is a statement that we define as ‘the heartbeat of your product, it is what you are making, reduced down to its core essence.’ A clear vision helps a project to focus, to fight off distractions and to take tough design decisions.

To get a vision on the table I moderate a session with the people who drive the product development, who I simply ask ‘what is it we are making, who is it for, and where is the value?’ The session lasts until I am satisfied with the answers. I then write up the vision statement in a few short paragraphs and fine-tune it with the session participants.

To cut to the chase, here is the product vision statement for Metapolator:

‘Metapolator is an open web tool for making many fonts. It supports working in a font design space, instead of one glyph, one face, at a time.

‘With Metapolator, “pro” font designers are able to create and edit fonts and font families much faster, with inherent consistency. They gain unique exploration possibilities and the tools to quickly adapt typefaces to different media and domains of use.

‘With Metapolator, typographers gain the possibility to change existing fonts—or even create new ones—to their needs.

‘Metapolator is extendible through plugins and custom specimens. It contains all the tools and fine control that designers need to finish a font.’

mass deconstruction

I think that makes it already quite clear what Metapolator is. However, to demonstrate what goes into writing a product vision, and to serve as a more fleshed out vision briefing, I will now discuss it sentence by sentence.

‘Metapolator is an open web tool for making many fonts.’

There is no standard template for writing a product vision, the structure it needs is as varied as the projects I work with. But then again it has always worked for me to lead off with a statement of identity; to start answering the question ‘what is it we are making?’ And here we have it.
open or libre? This was discussed during the session. At the end Simon Egli, Metapolator founder and driving force, wanted to express that we aim beyond just libre (i.e. open source code) and that ‘open’ also applies to the vibe of the tool on the user side.
web‑based: this is not just a statement of the technology used, of the fact that it runs in the browser. It is also a solid commitment that it runs on all desktops—mac, win and linux. And it implies that starting to use Metapolator is as easy as clicking/typing the right URL; nothing more required.
tool or application? The former fits better with the fact that font design and typography are master crafts (I can just see the tool in the hand of the master).
making or designing fonts? I have learned in the last couple of weeks that there is a font design phase where a designer concentrates on shaping eight strategic characters (for latin fonts). This is followed by a production phase where the whole character set is fleshed out, the spacing between all character pairs set, then different weights (e.g. thin and bold) are derived and maybe also narrow end extended variants. This phase is very laborious and often outsourced. ‘Making’ fonts captures both design and production phases.
many fonts: this is the heart of the matter. You can see from the previous point that making fonts is up to now a piecemeal activity. Metapolator is going to change that. It is dedicated to either making many different fonts in a row, or a large font family, even a collection of related families. The implication is that in the user interaction of Metapolator the focus is on making many fonts and the user needs for making many fonts take precedence in all design decisions.

‘It supports working in a font design space, instead of one glyph, one face, at a time.’

The first sentence said that Metapolator is going to change the world—by introducing a tool for making many fonts, something not seen before; this second one tells us how.
supports is not a word one uses lightly in a vision. ‘Supports XYZ’ does not mean it is just technically possible to do XYZ; it means here that this is going to be a world‐class product to do XYZ, which can only be realised with world‐class user interaction to do XYZ.
design space is one of these wonderful things that come up in a product vision session. Super‐user Wei Huang coined the phrase when describing working with the current version of Metapolator. It captures very nicely the working in a continuum that Metapolator supports, as contrasted with the traditional piecemeal approach, represented by ‘one glyph, one face, at a time.’ What is great for a vision is that ‘design space’ captures the vibe that working with metapolator should have, but that it is not explicit on the realisation of it. This means there is room for innovation, through technological R&D and interaction design.

‘With Metapolator, “pro” font designers are able to create and edit fonts and font families much faster, with inherent consistency.’

With “pro” font designers we encounter the first user group, starting to answer ‘who is it for?’ “Pro” is in quotes because it is not the earning‑a‐living part that interests us, it is the fact that these people mastered a craft.
create and edit balances the two activities; it is not all about creating from scratch.
fonts and font families balances making very different fonts with making families; it is not all about the latter.
much faster is the first value statement, starting to answer ‘where is the value?’ Metapolator stands for an impressive speed increase in font design and production, by abolishing the piecemeal approach.
inherent consistency is the second value statement. Because the work is performed by users in the font design space, where everything is connected and continuous, the conventional user overhead of keeping everything consistent disappears.

‘They gain unique exploration possibilities and the tools to quickly adapt typefaces to different media and domains of use.’

exploration possibilities is part feature, part value statement, part field of use and part vibe. All these four are completely different things (e.g. there is inherently zero value in a feature), captured in two words.
quickly adapt is a continuation of the ‘much faster’ value statement above, highlighting complementary fields of use for it.

‘With Metapolator, typographers gain the possibility to change existing fonts—or even create new ones—to their needs.’

And with typographers we encounter the second user group. These are people who use fonts, with a whole set of typographical skills and expertise implied.
possibility to change is the value statement for this user group. This is a huge deal. Normally typographers have neither the skills, nor the time, to modify a font. Metapolator will open up this world to them, with that fast speed and inherent consistency that was mentioned before.
create new goes one step further than the previous point. Here we have now a commitment to enable more ambitious typographers (that is what ‘even’ stands for) to create new fonts.
to their needs is a context we should be aware of. These typographers will be designing something, anything with text, and that is their main goal. Changing or creating a font is for them a worthwhile way to get it done. But it is only part of their job, not the job. Note that the needs of typographers includes applying some very heavy graphical treatments to fonts.

‘Metapolator is extendible through plugins and custom specimens.’

extendible through plugins is one realisation of the ‘open’ aspect mentioned in the first sentence. This makes Metapolator a platform and its extendability will have to be taken into account in every step of its design.
custom specimens is slightly borderline to mention in a vision; you could say it is just a feature. I included it because it programs the project to properly support working with type specimens.

‘It contains all the tools and fine control that designers need to finish a font.’

all the tools: this was the result of me probing during the vision session whether Metapolator is thought to be part of a tool chain, or independent. This means that it must be designed to work stand‑alone.
fine control: again the result of probing, this time whether Metapolator includes the finesse to take care of those important details, on a glyph level. Yes, it all needs to be there.
that designers need makes it clear by whose standards the tools and control needs to be made: that of the two user groups.

this space has intentionally been left blank

Just as important as what it says in a product vision is what it doesn’t say. What it does not say Metapolator is, Metapolator is explicitly not. Not a vector drawing application, not a type layout program, not a system font manager, not a tablet or smartphone app.

The list goes on and on, and I am sure some users will come up with highly creative fields of use. That is up to them, maybe it works out or they are able to cover their needs with a plugin they write, or have written for them. For the Metapolator team that is charming to hear, but definitely out of scope.

User groups that are not mentioned, i.e. everybody who is not a “pro” font designer or a typographer, are welcome to check out Metapolator, it is free software. If their needs overlap partly with that of the defined user groups, then Metapolator will work out partly for them. But the needs of all these users are of no concern to the Metapolator team.

If that sounds harsh, then remember what a product vision is for: it helps a project to focus, to fight off distractions and to take tough design decisions. That part starts now.

a Maslow hierarchy of software making

noreply@blogger.com (Anonymous) — Tue, 18 Mar 2014 09:50:00 +0000

This morning, I whipped up a Maslow hierarchy for breakfast, one for the activity of software making:

My thoughts started where one normally starts explaining the hierarchy: at the bottom. I recalled what I wrote here a while ago:

‘Everyone knows that in order to get software, it needs to get built, i.e. code developed.’

And with that I had my first, ‘physiological’ level of software making: to build. Without it, there is nothing. This is the hammer and saw level; just cut it to size and nail it together.

You would be surprised how much software is made like this—yes, also for top dollar.

moving on up

The next level is to engineer. At this point one is not just cobbling code together, there is also thought and structure involved, on a technological level. This is all about avoiding chaos, being able to scale up—in size and complexity—and code being maintainable in the future.

We can use these two levels to illustrate a common source of strife in software development outsourcing. The customer thinks they will get an engineered solution for their money; the supplier thinks they can just build whatever passes the acceptance tests.

Maslow’s second level is called safety. Somehow that matches quite well with what software engineering is about.

a giant leap

One level up is a whole new ballgame: to plan features. This requires having a product vision and picking only those features that make the product stronger, while saying ‘no’ to 95% of the features that users, marketing and engineering come up with.

This is the entry level for putting some purpose into the activity; to make software that matters. It is not easy to make it up to here; respect for those who do. It takes a visionary person, confident enough to deal firmly but correctly with all the wild impulses that come from users and engineering.

The corresponding Maslow level is called love. Indeed, to plan features is the first step of putting some love into the software you are making.

accident prune

The fourth level is to take the random factor out of software making: to specify. Define first what needs to be made, before engineering figures out how it can be built. This roots out the standard practice of the how determining what the result will be.

I am totally not a fan of heavyweight, bureaucratic specifications. Just keep in mind: the point is that a project should be able to tip the code, swap out the complete engineering crew and be confident to resurrect exactly the same software from spec—just with different bugs.

full potential

And now we reach the top, the level of complete product realisation: to design. The focus moves to product value delivery, by addressing user needs, while taking into account what is feasible with technology.

A software project that is operating smoothly on all five levels of the hierarchy is one that is delivering its full potential. It can concentrate on realising its vision and through that be a leader in its market.

Conversely, a project where one or more levels of the hierarchy are missing, or not functioning well, will spend a considerable amount of its energy on trying to fill the void(s). The organisation may not quite be able to put its finger on what is wrong, but spend a lot of communication, meetings, time and action on correcting it.

Maslow’s top level is summed up as—

‘morality, creativity, spontaneity, problem solving, lack of prejudice and acceptance of facts’

That’s a pretty good trait‐requirements list for a designer. Stated the other way around, to design is a human need of the highest level.

use it

Now we can work the diagram, in true Maslow style:

An organisation will only be motivated to fix the lowest level that is found lacking.

As we have already seen, the build level trumps anything. Problems on this level—e.g. lack of developers, or ‘physiological’ bugs (crashing)—will crowd out any other considerations. Moving up, if the engineering is found lacking, then an organisation will not be inclined to take feature‐planning, specification, or design serious.

If an organisation fails to plan features then design and/or specification initiatives will be in vain. Is the specification process found lacking? Then it will be hard for an organisation to become design‑driven.

Working the diagram, we can understand how software‐making organisations act.

postscript

Here is something I noticed when I looked at the hierarchy diagram: it doesn’t mention software or anything related, does it?

Turns out the diagram is general for any design discipline; it is a Maslow hierarchy of making anything.

12 things you can do to succeed, enterprise edition

noreply@blogger.com (Anonymous) — Thu, 30 Jan 2014 10:54:00 +0000

Part three of the mini‐series I am running at the moment on the usual social channels—twitter, g+, linkedin and xing—called positive action ships successful products. There, for every wishful thought that persists in the (mobile) software industry, I supply a complementary positive action.

Today’s offering is enterprise grade; let’s turn water into wine. If you are a product maker, or manage a product‐shipping organisation, then you can initiate at least one of these today:

Better go for it, deploy user research and design to ensure that new is really better.

cf. ‘Better play it safe, because it has not been done before.’

Better go for it, ban meetings; get the makers to collaborate in (pairs of) pairs.

cf. ‘Better play it safe, so it won’t cause all these extra rounds of meetings.’

Better go for it, evangelise the new, listen carefully to any needs, ignore naysayers.

cf. ‘Better play it safe, because the first feedback was rather reserved.’

Better go for it, make it an offer that can’t be refused—if it gets nixed, go underground.

cf. ‘Better play it safe, so we get the OK.’

Better go for it, negotiate until you trust that the engineers can build the design.

cf. ‘Better play it safe, because the engineers say it cannot be done.’

Better go for it, it is faster to build a completely new core product from scratch.

cf. ‘Better play it safe, because that code base is spaghetti.’

Better go for it, and enjoy every minute; save time through structure, research + design.

cf. ‘Better play it safe, so we all can go home at five—and on 14:30 (D) / to the pub (GB) on friday.’

Better go for it, because the blame will fall on us anyway.

cf. ‘Better play it safe, because the blame will fall on us.’

Better go for it, once the core product blows away the competition, features can be added.

cf. ‘Better play it safe, so we have time for more features.’

Better go for it, use frequent user testing to debug the innovative design.

cf. ‘Better play it safe, to pass the usability test.’

Better go for it, define a new game, on your terms, and ditch them old millstones.

cf. ‘Better play it safe, to pass the regression test.’

Better go for it, model careers are built on delivering remarkable results.

cf. ‘Better play it safe, to not jeopardise my promotion.’

ask not what this blog can do for you…

Now, what else can you do? First of all, you can spread the word; share this blog post. Second, the series continues, so I invite you to connect via twitter, g+, linkedin, or xing, and get a fresh jolt of positive action every workday.

And third, if you able and willing to take some positive action, then email or call us. We will happy to help you ship successful products.

ps: you can check out part two if you missed it.

another 12 things you can do to succeed

noreply@blogger.com (Anonymous) — Thu, 09 Jan 2014 18:08:00 +0000

Part two of the mini‐series I am running at the moment on the usual social channels—twitter, g+, linkedin and xing—called positive action ships successful products. There, for every wishful thought that persists in the (mobile) software industry, I supply a complementary positive action.

Below I list the second dozen pairs of these for your reference. If you are a product maker, or manage a product‐shipping organisation, then you can initiate at least one of these today:

Identify the different nature/vibe of your product modules and flows; design them accordingly.

cf. ‘A list is a list is a list. Why do these two parts of our app need such a different design?’

Hire a (lead) designer whose career is longer than that of your most senior developer (and the CTO).

cf. ‘Sure, it needs to be designed. Let’s get a [student, intern] for that.’

Tackle usability from the core outwards: how your product works; stop tinkering on the fringes.

cf. ‘Our usability sucks. To fix that, maybe we can take some guidelines and apply them religiously.’

Erect a chinese wall between your product and the customer wishes you are forced/paid to build.

cf. ‘The features our most‐valued customers ask for are implemented asap, future plans be damned.’

Start your development cycle by structuring it with your designer(s); serious work starts then.

cf. ‘The development is almost finished, now we need some design on top to jazz it up.’

Celebrate that your organisation is an exclusive group of insiders; real users are out there.

cf. ‘We are the typical users.’

Plan with a single, integral solution from your designer(s), which gets continuously refined.

cf. ‘Let’s get the designer(s) to deliver 3 proposals, then we pick—and mix—what we like.’

Refuse to get your data separated from the value your product delivers.

cf. ‘For that you can export the data to excel.’

Hire user researchers to map out how your core users tick and what their needs are.

cf. ‘We did do user research; we asked them what they liked and not, and what was missing.’

Fight rust; regularly identify product areas that were stable for years and redesigned them.

cf. ‘We have been doing it like this for many years.’

Stamp out the tinkering; get it designed, completely—no holes; documented nimbly, ‘on paper.’

cf. ‘We design in code.’

Hog effort, your organisation deals with it; your users get to do their thing, effortlessly.

cf. ‘Really, users could also put some effort into using our software.’

ask not what this blog can do for you…

And third, if you able and willing to take some positive action, then email or call us. We will happy to help you ship successful products.

ps: you can check out part one if you missed it.

12 things you can do to succeed

noreply@blogger.com (Anonymous) — Wed, 18 Dec 2013 08:50:00 +0000

‘Stop the wishful thinking and get on with some positive action.’ That is what I was thinking when I wrapped up the mini‐series wishful thinking breeds failed products on the usual social channels—twitter, g+, linkedin and xing.

Thus I kicked off a new series: for every wishful thought, I devised a complementary positive action that ships successful products. Below I list the first dozen pairs of these for your reference. If you are a product maker, or manage a product‐shipping organisation, then you can initiate at least one of these today:

Drive your market, beyond your customers’ wildest dreams; stamp out any reactive thinking.

cf. ‘Just ask the customers, they know best.’

Establish technology selection processes where the driver is user value delivery.

cf. ‘Users will love our hot, new technology, they will be queuing around the block.’

Institutionalise QA beyond bugs—of design; its execution; usability; of your communication.

cf. ‘With zero (major) bugs in the tracker, this feature must be working well.’

Improve your product—just because you know it can be done better: design it, test it, ship it.

cf. ‘But why? nobody ever complained about that.’

Pick the right defaults for your product; let users configure it by ‘just putting it right.’

cf. ‘We’ll leave that choice to our users, via a setting in the preferences.’

Get the usability right early on, then follow through on the design details to the very end.

cf. ‘In this phase of development, usability is a nice‐to‑have.’

Establish a design department, working at eye‑level with product management and engineering.

cf. ‘Our product designers are part of the [marketing, engineering, product, operations] department.’

Improve the status quo—because you know it can be done better: design it, test it, ship it.

cf. ‘This is what users are used to; we better not change it.’

Stamp out any notion that making your product is somehow directly related to using it.

cf. ‘We started out by scratching our itch; today, we still make it exactly how we like it.’

Consistently feed qualitative data into your design process; leave numbers to bookkeepers.

cf. ‘With all this quantitative tracking data, we know exactly what works, and what not.’

Plan every version—major and dot—around increased user value; the rest follows from that.

cf. ‘For our next version, we will refactor a lot of the code; a huge effort, so no other changes.’

It is your market, you design what is right for it—in an ever‐changing world.

cf. ‘I can’t see why we would do it differently from how [facebook, microsoft, google, adobe] do it.’

ask not what this blog can do for you…

Now, what can you do? First of all, you can spread the word; share this blog post. Second, the series continues, so I invite you to connect via twitter, g+, linkedin, or xing, and get a fresh jolt of positive action every workday.

And third, if you able and willing to take some positive action, then email or call us. We will happy to help you ship successful products.

a half‑century of product fail

noreply@blogger.com (Anonymous) — Sat, 16 Nov 2013 12:26:00 +0000

This is the final instalment of the mini‐series I ran on the usual social channels—twitter, g+, linkedin and xing—called wishful thinking breeds failed products. It distilled what I have witnessed and heard during 20 years in the (mobile) software industry.

To complete the round number of fifty, I present the final dozen + two wishful thoughts for future reference. I am curious if you recognise some of these:

‘The hardware specs are fixed, now we can start with the software design.’

‘We spent ages discussing this, trying to find a solution that pleased everyone.’

‘We thought we could spend a couple of man‐days on the low‐hanging usability fruit.’

‘The source is the ultimate documentation.’

‘There is no need to go for the gold‐taps solution.’

‘It does not hurt to have those features as well.’

‘One code base; fully cross‐platform.’

‘You have to pick your battles.’

‘Once you get familiar with the internal workings of our software, it becomes easy to use.’

‘Our specific target user group is: everyone.’

‘Our developers are very experienced; they make the UI of their modules as they see fit.’

‘We religiously adhere to the HIG.’

‘You can do that by [writing, running] a script.’

‘What do you mean “it’s all connected”? we just don’t have the time for those bits and pieces.’

ask not what this blog can do for you…

Now, what can you do? First of all, you can spread the word; share this blog post. Second, I invite you to connect via twitter, g+, linkedin, or xing; there is a new series starting, again with a thought every workday.

And third, if you recognise that some of the wishful thinking is practiced at your software project and you can and want to do something about it, then email or call us. We will treat your case in total confidence.

ps: you can check out part three if you missed it.

12 reasons why products fail, enterprise edition

noreply@blogger.com (Anonymous) — Wed, 30 Oct 2013 16:56:00 +0000

Part three of the mini‐series I am running at the moment on the usual social channels—twitter, g+, linkedin and xing—called wishful thinking breeds failed products. It distils what I have witnessed and heard during 20 years in the (mobile) software industry.

For this instalment I compiled a synergetic set of enterprise‐grade wishful thinking. By request, they are listed below for future reference. I am curious if you recognise some of these:

‘Better play it safe, because it has not been done before.’

‘Better play it safe, so it won’t cause all these extra rounds of meetings.’

‘Better play it safe, because the first feedback was rather reserved.’

‘Better play it safe, so we get the OK.’

‘Better play it safe, because the engineers say it cannot be done.’

‘Better play it safe, because that code base is spaghetti.’

‘Better play it safe, so we all can go home at five—and on 14:30 (D) / to the pub (GB) on friday.’

‘Better play it safe, because the blame will fall on us.’

‘Better play it safe, so we have time for more features.’

‘Better play it safe, to pass the usability test.’

‘Better play it safe, to pass the regression test.’

‘Better play it safe, to not jeopardise my promotion.’

ask not what this blog can do for you…

ps: you can check out part two if you missed it.

war and peace, the abridged UI version

noreply@blogger.com (Anonymous) — Fri, 18 Oct 2013 14:47:00 +0000

Not to worry, this is not going to be as lengthy as Tolstoy’s tome. Actually, I intend this blog post to be shorter than usual. But yes, my topic today is war and peace in interaction design.

peace

I like to think that my work as an interaction architect makes the world a better place.

I realise product makers’ dreams, designing elegant and captivating embodiments they can ship. I save terminally ill software and websites from usability implosion, and in the meantime get their makers a lot closer to what they always intended.

On top of that, I provide larger organisations with instruments to reign in the wishful thinking that naturally accumulates there, and to institute QA every step along the way.

All of this is accomplished by harmonising the needs of product makers, developers and users. You would think that because I deliver success; solutions to fiendishly complex problems; certainty of what needs to be done; and (finally!) usable software, working with these three groups is a harmonious, enthusiastic and warm experience.

Well, so would I, but this is not always the case.

war

The animosity has always baffled me. I also took it personally: there I was, showing them the light at the end of the tunnel of their own misery, and they get all antsy, hostile and hurt about it.

After talking it through with some trusted friends, I have now a whole new perspective on the matter. Sure enough, as an interaction architect I am always working in a conflict zone, but it is not my conflict. Instead, it is the tri‑party conflict between product makers, developers and users.

The main conflict between product makers and users: Each individual user expects software and websites really to be made for me‐me‐me, while product makers try to make it for as many users as possible. Both are a form of greed.; There is also a secondary conflict, when users ‘pay’ the product maker in the form of personal, behavioural data, and/or by eyeballing advertisements—’nuff said.
The main conflict between product makers and developers: Product makers want the whole thing perfectly finished by tomorrow, while reserving the right to change their mind, any given minute, on what this thing is. Developers like to know exactly up front what all the modules are they have to build—but not too exactly, it robs the chance to splice in a cheaper substitute—while knowing it takes time, four times more than one would think, to build software.; That this is a fundamental conflict is proven by the current fad for agile development, where it is conveniently forgotten that there is such a thing as coherence and wholeness to a fine piece of software.
The main conflict between developers and users: This one is very simple: who is going to do the work? Developers think it is enough to get the technology running on the processing platform—with not too many crashing bugs—and users are free to do the rest. Users will have no truck with technology; they want refined solutions that ‘just work™,’ i.e. the developers do the work.

All of this makes me Jimmy Carter at Camp David. The interaction design process, the resulting interaction design and its implementation are geared towards bringing peace and prosperity to the three parties involved. This implies compromises from each party. And for me to tell them things they do not like to hear.

Product makers need to be told

to make real hard choices and define their target user groups narrowly—it is not for everyone;
that they cannot play fast and loose with users’ data;
to take the long, strategic view on the product level, instead of trying to micro‐manage every detail of its realisation;
to concentrate on the features that really make the product, instead of a pile‑up of everybody’s wish lists;
to accept that they cannot have it all, and certainly not with little effort and investment.

Users need to be told that

each of them are just part of a (very large) group and that in general the needs of this group are addressed by the product;
using software and websites takes a certain amount of investment from them: time, money, participation and/or privacy;
software cannot read their minds; to use it they will need to input rather exactly what they are trying to achieve;
quite a few of them are outside the target user group and their needs will not be taken into consideration.

Developers need to be told

that we are here to make products, not just code modules;
no substitutes please, the qualities of what needs to be built determines success;
users cannot be directly exposed to technology; an opaque—user—interface is needed between the two;
if it isn’t usable, it does not work.

No wonder everybody gets upset.

peace

How do I get myself some peace? Well, the only way is to obtain a bird’s‐eye view of the situation and to accept it.

First, I must accept that this war is inherent to any design process and all designers are confronted by it. Nobody ever really told us, but we are there to bring peace and success.

Second, I have to accept that product makers, developers and users get upset with my interaction design solutions for the simple reason that they are now confronted with the needs of the other two parties. They had it ‘all figured out’ and now this turns up. (Yes, I do also check if they have a point and discovered a bug in my design.)

Third, I have to see my role as translator in a different light. We all know that product makers, developers and users have a hard time talking to each other, and it is the role of the interaction architect to translate between them.

It is now clear to me that when I talk to one of the parties involved, I do not only fit the conversation to their frame of reference and speak their language, but also represent the other two parties. There is some anger potential there: for my audience because I speak in such familiar terms, about unfamiliar things that bring unwelcome complexity; for me because tailored vocabulary and examples do not increase acceptance from their side.

Accepting the war and peace situation is step one, doing something about it is next. I think it will take some kind of aikido move; a master blend of force and invisibility.

Force, because I am still implicitly engaged to bring peace and success, and to solve a myriad of interaction problems nobody wants to touch. This must be met head‑on, without fear.

Invisibility, because during the whole process it must be clear to all three parties that they are not negotiating with me, but with each other.

postmortem

That is it for today, I promised to keep it short. There are some interesting kinks and complications in the framework I set up today, but dealing with them will have to wait for another blog post.

another 12 reasons why products fail

noreply@blogger.com (Anonymous) — Wed, 09 Oct 2013 08:49:00 +0000

Part two of the mini‐series I am running at the moment on the usual social channels—twitter, g+, linkedin and xing—called wishful thinking breeds failed products. It distils what I have witnessed and heard during 20 years in the (mobile) software industry.

By request, here are the second dozen of these for future reference. I am curious if you recognise some of this wishful thinking:

‘A list is a list is a list. Why do these two parts of our app need such a different design?’

‘Sure, it needs to be designed. Let’s get a [student, intern] for that.’

‘Our usability sucks. To fix that, maybe we can take some guidelines and apply them religiously.’

‘The features our most‐valued customers ask for are implemented asap, future plans be damned.’

‘The development is almost finished, now we need some design on top to jazz it up.’

‘We are the typical users.’

‘Let’s get the designer(s) to deliver 3 proposals, then we pick—and mix—what we like.’

‘For that you can export the data to excel.’

‘We did do user research; we asked them what they liked and not, and what was missing.’

‘We have been doing it like this for many years.’

‘We design in code.’

‘Really, users could also put some effort into using our software.’

ask not what this blog can do for you…

ps: you can check out part one if you missed it.

12 reasons why products fail

noreply@blogger.com (Anonymous) — Mon, 23 Sep 2013 09:31:00 +0000

At the moment I am running this mini‐series on the usual social channels—twitter, g+, linkedin and xing—called wishful thinking breeds failed products. It distils what I have witnessed and heard during 20 years in the (mobile) software industry.

By request, I now put the first dozen of these into a blog post for future reference. I am curious if you recognise some of this wishful thinking:

‘Just ask the customers, they know best.’

‘Users will love our hot, new technology, they will be queuing around the block.’

‘With zero (major) bugs in the tracker, this feature must be working well.’

‘But why? nobody ever complained about that.’

‘We’ll leave that choice to our users, via a setting in the preferences.’

‘In this phase of development, usability is a nice‑to‑have.’

‘Our product designers are part of the [marketing, engineering, product, operations] department.’

‘This is what users are used to; we better not change it.’

‘We started out by scratching our itch; today, we still make it exactly how we like it.’

‘With all this quantitative tracking data, we know exactly what works, and what not.’

‘For our next version, we will refactor a lot of the code; a huge effort, so no other changes.’

‘I can’t see why we would do it differently from how [facebook, microsoft, google, adobe] do it.’

ask not what this blog can do for you…

teaching interaction /13

noreply@blogger.com (Anonymous) — Sat, 08 Jun 2013 12:13:00 +0000

At the end of March I was at the FH Vorarlberg, Austria to teach my course, interaction design for the real world. As always, things evolved further: last year I had written the product vision briefing for GIMP, the software project that supplies the course with real‐life interaction design challenges. This briefing started to play a major role this year.

In a very natural manner, the value and traits of GIMP, as described in the briefing, became central to all evaluation and design work done during the course. Though not 100% premeditated, this is a very welcome development and I will certainly expand on it next year.

I also had the pleasure of introducing another interaction design taboo phrase. In the past two years they were ‘intuitive’ and ‘the user.’ This year it was ‘we tried,’ I have seen it used often enough by my students in reports. Interaction designers do not try, they make. Yes, not everything works exactly as expected, that is what iteration is for. But in general interaction designers are in a unique position for making, it work.

I just can’t get enough

The GIMP design challenge I picked this year was the align tool. It can be used to align—left, middle, right, top, centre, bottom—image layers with various image objects (layer, path, image, selection, channel). This relatively compact tool needs an interaction redesign, it has never received any design love.

While preparing the course, I checked out the tool. Within ten minutes I was asking myself why only layers can be aligned—i.e. moved—and not all the other objects (paths, channels, etc). Also the whole distribute mode does not actually distribute (objects evenly between themselves), it just aligns them with some extra offset. It became clear that the align tool is woefully underpowered: it has not enough functionality.

How quaint. Normally interaction designers have to fight too much and gratuitous functionality, and make it manageable. Conversely, during this course the student design teams had to concern themselves with what functionality to add, to make the align tool fit for use.

scenarios + variants

To flesh out the essential use of the align tool, we made a few user scenarios:

just align: this is as simple as it gets: align top/left/etc. of one object (layer, path, selection, channel) with another (all of the above, plus image).
keeping things together: pick multiple objects that belong together, e.g. a layer with a corresponding mask, and align as one unit with another object; the same for multiple of these units.
true distribution: distribute objects evenly among themselves, or in an absolute way with a fixed offset.
all together now: this is as complicated as it can get: combined alignment and distribution of combined units and single objects.

The students used these scenarios for their evaluation of the interaction of the existing tool. With the gained insight into the good and the bad, the students were then ready to brainstorm better solutions. Apart from ideas for fleshing out the functionality, I asked the students to brainstorm two variants of the tool: one as it is now—a toolbox tool—the other anything but a toolbox tool (i.e. using only the menu bar and dockable dialogs).

hands‑off

This was in response to the fact that the current align tool is not much of a toolbox tool. It does not let users change things hands‑on on the canvas (e.g. like paint tools do). On a higher level, it simply does not feel like a toolbox tool. The question then simply becomes: should the align tool be in the toolbox at all? This is what I let the students explore.

This exploration set the student teams up for their reasoned decision on which approach to take—toolbox tool or not—when they moved to the solution design phase. By exploring diametrical opposites they did not only got to know the potential of either solution, they also learned more about either solution, from studying the opposite.

As you will see in a moment, all four teams chose to design the align tool for the toolbox, with some teams adding non‑toolbox interaction to the mix.

four team results

And now the design results of the student teams. The work of all four teams is available under the GNU Free Documentation License 1.2. I will present them in team order.

team one

members: Allison Cook, Dominic Berchtold + Eva‑Yola Hajdu
design concept document (pdf, 1.2 MB)

Team one gets straight to the point where it comes to making the align tool a hands‑on tool. Layers can be grabbed and moved around and magnetic points will perform the alignment:

This is a good realisation of the ‘just align’ spirit of the first user scenario. For more complex situations, involving more layers, the team requisitioned the layers dialog, which changes appearance to reflect that (right):

On the left, in the tool options, users can see the list of layers which have been selected for manipulation and unselect them there without having to dig around either on the canvas or the layers dialog.

team two

members: Dylan Burns, Paula Hidalgo + Nora Huber
design concept document (pdf, 2.3 MB)

Team two put their minds towards providing quite a few ways to align and distribute (or disperse, as they called it). There is the objects mode, which further develops the existing align tool:

And then there is the points mode, which lets users set a point, a marker on each object that needs to be aligned with a reference point (the star):

This takes into account that in pixel‐based applications like GIMP, the ‘edge’ or ‘centre point’ of subject matter is not necessarily that of the layer, path or mask. Apart from the two modes, also magnetic snapping—similar to team one—is part of the design.

Nice and compact is their design of three different ways to distribute objects in the tool options. The Box mode lets users define a rectangle on the canvas to set up distribution.

team three

members: Florian Rehlendt, Linda Latzelsberger, Madeleine Mouton + Lizzie Hinojosa Allen
design concept document (pdf, 508 KB)

Team three expanded align in three new directions:

The outcome of these three are shown below. Align‐along‐path (middle) makes very good use of the path concept:

Team three allows the centre point simply to be moved. As stated above, it is not necessarily located in the centre of a layer or mask (left):

On the right we see the preview option demonstrated, invoked by hovering over an align or distribution button.

team four

members: Sabina Loacker, Barbara Nader, Nicole Paulo + Thomas Windisch
design concept document (pdf, 2.4 MB)

Team four designed a different version of working hands‑on on the canvas. Their reference object shows an ‘alignment map’; clicking one of these six lines aligns other highlighted objects with it:

They extended this to the edges of image canvas; click them to align objects with them:

Good to see that team four allowed for different horizontal and vertical offsets and clearly shows these can be negative:

postscript

What started as fleshing out an unassuming tool turned into serious design work when user needs entered the picture. At the end of the final design day, one of the students said ‘there are just so many things in my head!’ Yes, that is what designing is about: connecting many, many things.

Again I had a great week at the FH in Dornbirn this year. I would like to thank all the students for the hard work they put in and for the energy they returned.

design lessons with Daft Punk

noreply@blogger.com (Anonymous) — Thu, 23 May 2013 20:51:00 +0000

I am sure you have noticed the Daft Punk marketing master plan that is taking over all media channels at the moment. And I admit that I am happy to consume—and inhale—anything (semi‐)intelligent that is being written about them.

Yesterday I read this Observer interview with the ‘notoriously shy French duo.’ Afterwards, intuition told me there was something vaguely familiar about what they had said. I checked again and sure enough, plenty of it applies to (interaction) design.

punk rules, OK?

Below are Daft Punk quotes I lifted from the article, followed by what I associate with each. There are also a couple of cameo appearances by hit‑production legend Nile Rodgers.

‘The music that’s being done today has lost its magic and its poetry because it’s rooted in everyday life and is highly technological.’

Wow, not the most hands‑on quote to start with. But I swore that I’d present them in the order they appear in the article. With the mentioned ‘magic and poetry’, I associate fantastic design work. This means sweeping solutions, for which there needs to be at least one designer on the project with a big‐picture view.

Being constantly ‘rooted in everyday life’—e.g. relying on testing (A/B or usability); or working piecemeal, or driven by user requests, or in firefighter mode—shortens the horizons and shrinks the goals. It surely programs the project for mediocrity, i.e. humdrum, incremental solutions.

Every user has to deal every day with software that ‘is highly technological.’ Everybody thinks this sucks. Making software is highly technological when one is staring at code; when thinking about code; when taking prototyping capabilities into account; when technology informs the interaction, verbatim. Designing great interaction means not making any of these mistakes.

‘In early interviews they came across as suspicious and aloof. “It’s because you’re 18 and you feel maybe guilty: why are we chosen to do these things?” says Thomas. “There’s definitely reasons to feel less uncomfortable now. It’s one thing to say you’re going to do it and another to have done it for 20 years.”’

Now that is the voice of experience talking. The first part of it is this early phase; fresh out of school and real (work) life is starting. This suspicion of one’s own talents, entering a company, scene or industry and expecting the folks around you to be like you, see things like you. And then they don’t. Very confusing, who is wrong here?

The second part is having ‘done it for 20 years.’ If that involved a portfolio of successful work; continuous self‐development; the discovery of what a difference ‘being experienced’ makes and getting to know a few peers, then it has become more comfortable to be a designer. Just don’t get too comfortable; make sure every new project you take on challenges and develops you.

‘The only secret to being in control is to have it in the beginning. Retaining control is still hard, but obtaining control is virtually impossible.’

The first level where this holds is getting a design implemented. Quite often developers like to first put some temporary—and highly technological—interaction while they sort out the non‑UI code. The real design will be implemented later. Then time ticks away, the design lands in a drawer and the ‘temporary’ UI gets shipped.

I do not think this is a malicious trick, but it happens so often that I do not buy it anymore. The only secret to getting interaction design implemented is to do it in the beginning.

The second level is that of the overall collaboration; ‘obtaining control is virtually impossible,’ no matter how big a boost a designer has given the project. So one has to start out with control from the beginning, it has to be endowed by the project leadership. And then one has to work hard to retain it.

‘Guy‑Man, who designed the artwork, says that Thomas is the “hands‑on technician” while he is the “filter”: the man who stands back and says oui or non.’

Filter is the stuff designers are made of. In the case of interaction designers it means filtering out of all the things users say, the things they actually need. It means saying non to many things that are simply technologically possible, but useless, and oui to exactly that what realises the product, addresses users needs and is, yes, technologically possible.

Being the filter does not always make you friends, having to say non to cool‐sounding initiatives that in the bigger scheme of things are incredibly unhelpful. But being a yes‑man makes an ineffective designer, with non‑designed results.

Making software is not a game with unlimited time and resources; user interaction is not one with unlimited screen space and communication bandwidth. A filter is crucial.

‘“The genius is never in the writing, it’s in the rewriting,” says Rodgers. “Whenever they put out records I can hear the amount of work that’s gone into them—those microscopically small decisions that other people won’t even think about. It’s cool, but they massage it so it’s not just cool—it’s amazing.”’

I learned some years ago that it is not only the BIG plans and sweeping solutions that make a master designer. It is also in the details. All the tiny details.

All these ‘microscopically small decisions’ have to be taken in the way that strengthen the overall design, or else it will crumble to dust. This creates tension with all the collaborators, who ‘won’t even think about’ these details. They cannot see the point, the crumbling. Masters do.

‘We wish people could be influenced by our approach as much as our output. It’s about breaking the rules and doing something different rather than taking some arrangements we did 10 years ago that have now become a formula.’

Design is not a formula, not a sauce you pour over software. Design is a process, performed by those who can. A designer cannot tell upfront what the design will be like, but knows where to start, what to tackle and when it is done. That sounds trivial, but for non‑designers these four points work exactly opposite.

Apply the design process to a unique (i.e. non‑copycat) project and you will get an appropriate and unique design. Blindly applying this design to another project is by definition inappropriate.

‘“Computers aren’t really music instruments,” he sniffs. “And the only way to listen to it is on a computer as well. Human creativity is the ultimate interface. It’s much more powerful than the mouse or the touch screen.”’

This quote hits the nail on the head by setting the flow of creativity between humans as the baseline and then noting how computer interfaces are completely humbled by it. It is too easy to forget about this when your everyday world is making software.

The truth about software for designers (of music, graphics and other media) is that not much of it is designed—the interaction I mean, although it may look cool. Being software for a niche market makes it armpit of usability material: developers talking directly to users, implementing their feature request in a highly technological way.

To make an end to this sad state of affairs, a design process needs to be introduced that is rooted in a complete—but filtered—understanding of the activity called human creativity.

‘Enjoying the Hollywood analogy, Thomas says Daft Punk were the album’s screenwriters and directors while the guest performers were the actors, but actors who were given licence to write their own lines.’

I am also enjoying that analogy, and the delicate balance that is implied. On the one hand, interaction designers get to create the embodiment of the software ‘out of thin air’ and write it down in some form of specification, the screenplay. Being in the position of seeing how everything is connected, it also falls naturally to them to direct the further realisation, by developers and media designers.

If that sounds very bossy to you, it is balanced by the fact that these developers and media designers already have complete ‘licence to write their own lines.’ For developers every line of code they write is literary theirs.

The delicate balance depends on developers and media designers being able to contribute to the interaction design process—in both meanings of that phrase. And it depends on all written lines fitting the screenplay.

‘“What I worked on was quite bare bones and everything else grew up around me,” says Nile Rodgers. “They just wanted me to be free to play. That’s the way we used to make records back in the day. It almost felt like we’d moved back in time.”’

This is what design processes are about; to create a space where one is free to play. This in the dead‐serious context of solving the problem. Play is used to get around a wall or two that stand between the designer and the solution for making it work.

It takes a ‘quite bare‐bones’ environment to be free: pencil and paper in the case of interaction design. That may ‘feel like moving back in time’ but it is actually really liberating; it offers a great interface for human creativity. Once you got around those walls and hit upon the solution, every part of the design can grow up around what you played.

And on that note, I’ll finish today’s blog post.

masterclass in san francisco

noreply@blogger.com (Anonymous) — Mon, 13 May 2013 11:58:00 +0000

The day after Volkswagen + Wolfsburg I was on my way to San Francisco. I had been invited by the California College of the Arts (CCA) for their Dutch Design Week, ‘a series of events celebrating Dutch Design and fostering exchange between Dutch and American Designers.’

My personal highlight of these events was a two‐day masterclass for design graduates and interaction design undergraduates. Not only because of the intense and re‑energising work with the CCA students, but also because I learned something new from two cases of unintended consequences.

begin the beguine

While I was planning the class, Kristian Simsarian—chair of the interaction design program at CCA—encouraged me to pick a topic which I am passionate about. So I picked two: product realisation and mobile. The last decade these have been the most important themes in my design practice, with the highest impact.

So the masterclass was going to consist of designing a proper mobile website or app for a software product, a service, website or organisation. Question was: which one?

uncanny valley

I am not comfortable with structuring my teaching around imaginary projects. Only when there are one or more persons inside a project who burn to make something valuable, it is viable for designers to work on it and realise this goal.

So instead of making up an imaginary project for this class, I asked the participating students to bring their own project, one they are passionate about. I was curious to see what they would bring in: could be some app they love but wanted to redesign, or a local community project. At the end each student brought a personal project to work on, some of them with a local (transport/biking) flavour.

on the one

Fast‐forward to the first morning of the masterclass. The CCA’s SF building is like a cathedral part‐filled with a labyrinth of cosy spaces to teach and work. Next door to my class was the one of industrial designer Maarten Baptist. Right in front of us, the floor of the ‘nave’ filled up with the graphic design students of Marijke and Chantal, i.e. Cobbenhagen Hendriksen, working on posters. Everyone was inspired.

After a riveting introduction by Alexander Baumgardt—who had been instrumental in bringing me over for the week—it was time for me to get to know the students, seven graduates and five undergrads. I am always interested in the reason why each chose to participate, it tells me something about this student and her/his expectations, and the future of my industry.

get with the program

I then explained the main building blocks of the class, product realisation and mobile, and two auxiliary ones: ‘design is solving the problem’ and ‘designing is done pencil on paper.’ I wove these together with an overview of my career, to show where they are coming from and why they play such an important role in my practice.

Next, I structured our work for the first day. We started off with the product phase; building a foundation for the design work: product vision; functionality overview; user scenarios; expert evaluation. First up was the method that I see as crucial for product realisation: compiling a product vision.

vicious games

Experience tells me that it is incredibly hard for project insiders to define their vision; it’s like pulling teeth. It also takes a long time; weeks of pulling teeth. I did not have the time for this, although I had created the situation that every student entered the class as a full insider of her/his own project.

What I needed was what every project needs: a moderator to tease the vision out of the project insiders. Luckily I had a class full of potential moderators. Product realisation means working from a vision, thus it became natural to go through the exercise of moderating one.

1 + 1 = 2

During the morning, I introduced the product vision method and told the story of how I developed it years ago. I showed the Krita example—long live open working—and explained what each part means, down to single words. Then I asked the students to work in pairs.

Because I found the interaction specialisation vs. maturity asymmetry in my class interesting, I asked the undergrads to pair up with a graduate student, just to mix things up. Looking back I can report that collaboration was exemplary.

Within each pair, one would take the role of moderator, helping the other—insider to her/his own project—to formulate a vision. Then they swapped roles.

altogether

Getting a product vision together takes time and each pair had to formulate two of them. As a result we spent a couple of hours on this method. Apart from doing Q+A and guidance with the six pairs, I also held two rounds of discussion with the complete class.

In these discussions we spoke about how we were doing, what we were observing and experiencing, and I explained the more tricky parts of a product vision. From the reaction of my students, I got my first dose of unintended consequences.

1 + 1 = 4

By now you know that I had the students work on a vision in both moderator and insider roles just to stand a chance of getting it done. I could have predicted that by playing both roles they would get twice the insight into the product vision method.

But judging from the overwhelming reaction of my students, I seemed to have a struck a quadratic effect. They were enthusiastic and ‘getting it’ as if they just had four times the insight. That really made my day.

can you dig it?

Here are three product vision statements made in the class:

‘The Thrive App gives a voice to household plants. Thrive lets busy, novice plant owners know their plant’s well‐being via a paired sensor in the soil and recommends appropriate care through the voice of the plant.

‘Thrive notifies owners of their plant’s vitals in real time. Thrive connects people to nature in a small way by creating an emotional bond between people and their plants.’

‘Echosphere is a mobile application that creates and controls sounds based in your movement.

‘By combining live movement with sound and visuals, it helps an older audience reawaken their sense of play.

‘Echosphere is an individualized, immersive experience that encourages breaking out of analytical thought.’

‘MyWay is a smartphone app to optimize the daily use of public transportation. Users can personalize their regular destinations and schedules. The app keeps track of the public transportation times and provides accurate feedback to the user, sending updates. It learns from users’ behavior and automates their routine trip plans.

‘It is meant for San Franciscans, in their 20’s to 50’s, who use public transportation, own smartphones and are familiar with the streets of San Francisco. The users have busy schedules, commute daily with normally 2 to 4 regular destinations.

‘With MyWay people will be able to clear their minds from repetitive tasks of keeping tracks of their time to catch public transportation. It will free the user from the burden of keeping constant eye on the transit schedule.’

It is clear what each of these three is about and what value it aims to deliver. And that is the point of a vision.

bat man

On the second day of the masterclass the accent moved to mobile interaction. It was time to lead the students to a series of hard mobile design choices that they had to make for their project. For instance:

mobile website or app?: This choice should not be based on how cool, or confident one feels designing it, but on what is best implementing the product vision.
fragmentation: With limited time available for this class, I made the students pick one platform and one screen size (‑range, in cm/inches of course) to design for. In the real world, each (supported) combination of these two needs a separate, optimised design.
the nr.1 issue in mobile: a.k.a. the battery. It has been the issue for decades. As interaction designer—i.e. designer of ‘the whole thing’—one will either be confronted with severe limitations set by the platform on how much the app/site can be ‘alive’ all the time, or there are no limits and one has the full responsibility to not drain the battery, all the time.

The overall goal of the masterclass was to design a solutions model; i.e. the broad‐strokes plan that solves the main design challenges, plus a strategy to design the rest. A complete (draft) design of even a small app would have been too much work for our two days.

go west

I encouraged my students to explore and brainstorm before working reductive and settling for a solution. But in practice, quite a few of them settled too quickly.

So I challenged these students: ‘I see your design hinges largely on XYZ, It would be good if you brainstorm a few ideas that do not involve XYZ. Either you’ll find something better than your current plan, or you will learn valuable lessons about XYZ.’

go next

Working with the students showed a lot of variation. Each had her/his own pace, project, approach, and design. I enjoyed immensely working with each individually and I am sure all of us would have enjoyed a couple of days more of designing together. Then there was the second case of unintended consequences.

The feedback of most students was that they were going to continue working on their project. This is really different than usual, where the project gets dumped the moment the class is over. Why was it different this time? Ah, because each of them brought a personal project.

All in all it is very rewarding to see the impact of the masterclass. To see how the project of every student made at least two steps in the right direction. To see how the students ‘got’ something out of it that they can use during their design careers.

postscript

I did a panel discussion and a Q+A session with first year interaction design students during the CCA Dutch Design Week. I also met a lot of interesting people. But the masterclass stands as my personal highlight because from all the feedback I got, it was clear that both the students and the CCA got a real kick out of it. And so did I.

I would like to thank the students for their hard work; Tatsiana, Kathleen and Ramunė for allowing me to share their work here; Alexander Baumgardt for getting the ball rolling; and all at the CCA and the Dutch consulate who enabled this trip.

collisions in software projects… and a Volkswagen bus

noreply@blogger.com (Anonymous) — Fri, 26 Apr 2013 09:37:00 +0000

A week or two ago I was the guest of Volkswagen, in their hometown of Wolfsburg. They had asked me to lecture on in‑house software projects, friction and usability. Great question, could fill many an hour answering it. With one hour at my disposal, I picked one main aspect. Here we go.

the fashion trade

Usually I design interaction for software products; off‐the‐peg software so to say: desktop applications, in browsers, and since 1997 also mobile. A recent twist are services, for instance social networks or B2B websites.

A quite different world is that of software projects; bespoke software, made to measure for clients and—hopefully—its users too. Comparing software products and projects, there is remarkable effect that I want to address in this blog post.

slidin’ down

Below we see from left to right a continuum of software specialisation: from general (email, web surfing), via specialised (software for doctors, or engineers) to bespoke projects. Plotted against that is their usability, in general:

I have blogged before about this ‘armpit of usability,’ its cause and effect. Today I will go into why software projects are located at its smelliest end. For this, we need to take a look at the three worlds that collide in software projects, what they need, and offer.

clients

The first world we will take a look at is that of clients. This is logical because it is clients who instigate software projects (there are also illogical ways to start a software project—e.g. have to spend the budget before year’s end, ask supplier how—but I will disregard these).

A first client need in software projects is to get ‘it’ built; ‘finished and working.’ This alone is already a cause of many a conflict in software projects. I will show later how to get a much better handle on this issue.

people, get moving

Another client need in software projects is to save money. At least, it used to be in the past decades, when software automated a lot of mechanical, brain‐dead labour, especially in office environments. Additionally, looking at a software project in this way is very spreadsheet‐friendly. The temptation of this should not be underestimated.

But time has moved on and just about all mechanical jobs have been rationalised away. What remains is creating value. This is exactly what people do: deal with situations with flexibility, provide a human touch to communication, solve issues and create new ways to do things. Machines and software do not stand a chance there. Over the years I have made this value creation the core of my design praxis.

intermezzo: what about value?

Let’s take a short detour and see some examples of value creation. We start with a plain project description:

‘We need a new order‐taking system.’

Then we ask where the value is:

‘We need a new order‐taking system, tightly integrated with manufacturing and warehouse operations.’

No, that is not it. That is still a very mechanical description of what needs to be achieved. Try again:

‘We need a new order‐taking system that allows users to unbureaucratically engage with any customer wish.’

There we have it: value. Feels really different than the previous two, doesn’t it? Introducing software that realises this will be of clear competitive advantage to this client.

‘We need a new order‐taking system that allows users to be order makers, instead of order takers.’

Another statement with value; not better, not worse, just different. This demonstrates that defining value is a strategic choice for clients.

Flesh out the two statements above to three paragraphs, answering ‘what is it we are making, who is it for and where is the value?’ and you have what I call a vision. And vision is exactly what I expect from management and leadership in a software project.

back on track

Where were we? Ah, value is definitely a client need in a software project. And by formulating that in a vision statement we have moved to the first thing clients have to offer.

We did already see that clients offer that software projects exists at all. And therefore they have to offer funding, because projects without funding turn out to be sad affairs, in my experience.

tech

The second world that we will take a look at is that of technology, i.e. the in‑house IT department or the external suppliers. All engineers, developers, technical architects, DBAs and functional analysts are part of this world.

Cut to the bone, the sole reason these in‑house IT departments and external suppliers exist is to hoover up those software projects and budgets that clients have to offer. It is their first, and prime, need. This is a marked difference with the world of software products, where technology departments are achievement‐focussed.

XOR

The second need the tech world has is that of clarity. From the zero/one definition of a bit upwards, in black and white terms. What needs to be built and when can we call it finished? This is compounded by the need of the tech world to frame and communicate everything in technical terms.

As such, the tech world is completely at ease working from the statement we have seen before:

‘We need a new order‐taking system, tightly integrated with manufacturing and warehouse operations.’

Given enough time and budget, they can bring this to a good end by themselves. But they are completely lost with the value part in this statement:

‘We need a new order‐taking system that allows users to unbureaucratically engage with any customer wish.’

Yes, the sales types of the tech world will nod understandingly when clients express the value they need. But when the actual work starts, their colleagues will hem and haw until the statement is reduced to something like the first one, i.e. technically precise, but without value.

truly, always

What the tech world has to offer is the engineering and building of software. Everyone knows that in order to get software, it needs to get built, i.e. code developed. The brutal reality of software making is that everything else I describe in this blog post is perceived by clients as optional, even down to the proper engineering part: ‘just bang some code together.’

The tech world expertly plays this ‘you need to get it built’ card. They play it to get (just about) all of the available budget, and to bury deep under the ground anything they don’t ‘feel’ like doing.

users

The last world that we will take a look at is that of users. And here the circle closes, because what users have to offer is value creation. We can now see what software is:

It is a means of value transport, provided by the client and built by technology. The software is there to meet its users, pick up the value they create and bring it back to the client:

But to pick up that value, the users will have to get on the bus. Paying them is not enough, neither is a direct order. These will make them endure the software, but they will not even consider getting on the value bus.

How do you entice users to get on the bus? You do it by observing the needs of these users and addressing them in the software. What are these user needs? Well, that is exactly the question the IT industry has been struggling with for the last 50 years.

Morse code

What happens traditionally in software projects is that (indirectly) the three worlds—client, tech and users—sit down to discuss what users need. It is literally three different worlds meeting, three different cultures, speaking three different languages:

You can see that the intersection of all three is very small. It has a name: discussing features. Features, features, ever more features. A very human phenomenon is feature hoarding. Just like kids and toys, there can never be less features. No, that is a regression.

Everything gets phrased as a feature request—the only means of communication available. Often users are asking that an existing feature gets improved (e.g. finally made findable, or usable), but it gets phrased as an additional feature.

gimme some dough

Features are a commodity, think staple foods like rice, corn and wheat. Sure, not enough and users will starve. But increase supply beyond enough and you have glut. In real life, people’s attention turns to better food when they have enough. In the software world, the need for a better meal is answered by a huge buffet of mediocre food.

The biggest mistake the software industry makes is listening to these feature requests and supply what users want. This is the prime reason supposedly tailor‐made project software ends up being the armpit of usability. Remember, the goal was to find out what users need. There is a solution for this, it is called usability.

intermezzo: what about usability?

Another detour. There are two definitions for the word usability that you have to know:

Measure of how usable, i.e. fit for use, something is. It is qualitative; this makes the tech world nervous because there is no hard numbers.
A group of empirical professionals who measure usability and survey user needs. Their general background is psychology. Tech‐splanation: they are specialised in this type of hardware called humans.

This is incredibly useful. Usability professionals can be engaged to deliver an exact map of a software project users’ needs and measure whether software is actually fit for use. The effort and cost of this scales with the size of the project. In general it is peanuts compared to what development hoovers up.

back on track

Where were we? Ah, knowing users’ needs is fully within reach, a question of just do it. Now we need one more thing. We need to connect the world of clients, technology and users; to translate between them and hook up the needs and offers. There is a solution for that, it is called interaction design.

That is what I do as interaction architect. It involves making the plan for the bus. For clients I realise the value transfer; for tech I make clear what needs to be built; for users I ensure their needs are met.

To show how this works I will now present my recommendations for software projects, in nine easy steps:

1. you got to have a vision

Before kicking off a project, even getting that budget, why not make it crystal clear what value is going to be created and formulate a project vision? I help my customers all the time to discuss, clarify, reach consensus and formulate one; this fits nicely in a one‐day workshop.

It serves as a first feasibility check, getting a convincing vision together. And it can be immediately used to ‘sell’ the project internally and get a modest budget for the next steps. Costs involved? One–two man‐days for the workshop.

2. start with user needs

Right here, at the very beginning of the project, is the right moment to get the user needs mapped out. These are already a useful foundation for strategic platform—desktop, browser, tablet and/or smartphone?—and architectural decisions. Why take these without knowing what is needed?

Usability specialists survey and observe your project’s users and bring back the facts. As mentioned, you are still not spending any serious money at this point.

3. integrate usability + interaction

Now is the time to integrate usability and interaction design with your project. This does not happen by itself. The software industry has the tendency to bolt on interaction design somewhere at the bottom of the development pyramid and stick usability research in a drawer. Sorry, but that is not going to help you.

Usability professionals are the only objective partners a client has for knowing what users need and if the software is really working. The interaction architect is the partner for realising your project vision of value creation. Processes will have to change too; you cannot make software like you did ‘last time’ when the results should really not be like last time.

4. design it first

With your vision, user needs and platform choices known, the largest open question of the project—what do we need to build?—can be answered. A first, rough design of the user interaction can be made by an interaction architect (‑team for larger projects).

This will include a solutions model: a large‐scale solution for realising that value creation, plus a design strategy for working out the complete software in detail. This will take the whole project out of the dark, into the light.

It is a good idea to have your prospective tech partners on board during this design stage as discussion partners. Technical feasibility has a profound impact on interaction design. And vice versa: interaction design has the same profound impact on the architecture and design of back‑ends.

5. test it first

Yes, not a line of code needs to be written to find out if the interaction design is meeting your users’ needs—and by extension, if the goals you set for value creation are fulfilled. A usability test with your users can be performed with a paper prototype. I have seen many of these and they simply work.

These tests are practical, quick and lightweight, involving six users, maybe up to twelve if your user group is very heterogeneous. Anything beyond that is project bloat, making it less agile. If you do insist on having it tested on a real computer/tablet/mobile screen, then a prototype can be made. This should take three days, not weeks or longer.

6. refine + test again

The reason we made a rough design in step 4 and performed practical, lightweight testing in step 5 is that we are going to iterate. From the analysis of the tests the interaction architect keeps the parts of the design that work well and redesigns the parts that performed badly.

These changes can be sweeping, because up to now relatively little time, budget and commitment have been invested.

Then it is time for another round of usability testing and it will show that giant step have been taken towards a fully working interaction design. If still any big issues are found, then repeat this step of refinement and test.

7. make interaction spec part of the contract

You still have not spent any serious money up to now. You do have a refined interaction design specification that shows what has to be built. It has been tested to fulfil your users’ needs and to realise your vision of value creation.

Now is the time to take this specification to your tech partners, the in‑house IT department or the external suppliers, and ask for a quote. It will be much easier to provide an estimate on this basis and it will be more accurate. You will also be able to define much better contractually what ‘finished and working’ means.

8. test + test

That’s two different tests. The first one is the usual, functional testing of what is being built. Doing this against the interaction design specification ensures that you get exactly what you expected. Passing these test gives the tech partners an exact moment to call it finished.

The second type of testing is usability testing of alpha versions of the built software. It checks for more subtle usability issues and validates the overall interaction design. Again the interaction architect resolves the issues and refines the design. The project impact of this is low, because all the bigger issues were dealt with before development started.

9. agile? interaction architect is co‑owner

Agile development was invented in + for the world of software projects. Working agile does not change much of the eight steps above. In step 4 one certainly needs to get to a solutions model, to knock the project into shape.

More detailed interaction design can be postponed, to be delivered just‐in‐time for the start of an implementation sprint. Usability tests are performed on the evolving software, as described in step 8.

In the piecemeal work that agile entails, it is very easy to lose track of a coherent user experience, one that meets your users’ needs. Making the interaction architect software co‑owner in the agile process, highly involved in planning of the next sprint and further sprints, solves that.

postscript

And that’s it. I have shown that it is fully possible to set up software projects where the needs of all the parties involved are met. The clients’ need to get it built and for value creation; the tech worlds’ need for clarity on what needs to be built and of when it can be called finished.

Last, it is straightforward to find out what software users’ needs are and to meet them through interaction design. At that point you can build the value bus, one that users are pleased to take, to bring their value home:

bus symbol from openclipart.org