our blogwar and peace—the 5th column
21 August 2015, 10:22
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,
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.
Labels: design stage, fundamental, top story, war and peace
wishful thinking; ignite the shirts
7 August 2015, 13:31
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.
Labels: act to succeed, top story, why products fail
If you like to ask Peter one burning question and talk about it for ten minutes, then check out his available officehours.
Peter Sikking is an
experienced
interaction architect. He unabashedly puts
shipping great products at the centre of his design practice. He is known for
his work for Google, Nokia, the
Metapolator &
GIMP
open source projects,
and startups.
What is Peter up to? See his /now page.
- info@mmiworks.net
- +49 (0)30 345 06 197
- imprint
