war and peace, the abridged UI version

18 October 2013, 16:47

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.

Labels: , , ,

PS logo

2 comments · post a comment

at 19 October, 2013 12:50,Blogger Unknown commented
Hi Peter,

these are very interesting insights.
In software engineering we know a similar role, the software architect, who designs the technical architecture of the software. Their similar role holds of course similar issues. I'd like to know where these technical architects are assigned in the projects you mention - are they part of the 'developer section' or a partner to you?

Thanks, Sven 
at 19 October, 2013 13:47,Blogger Unknown commented
hi Sven, good question.

I said there would be kinks and complications, and here is one.

from what I have seen and learned, in general technical architects live solely in the technology/developer world. I expect them to be visionary, innovating technology, addressing problems nobody else can (yet) see, and designing technology top-down. But solely in the technological dimension.

some technical architects may be able to take the product/business dimension into account, building bridges and translating. I do associate the job titles of functional analyst and business architect more with this.

None of these people work in the users dimension. They just have no idea how to address users’ needs.

—ps 

If you like to ask Peter one burning question and talk about it for ten minutes, then check out his available officehours.

portrait of Peter  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.

Peter teaches, mentors, lectures and publishes. He enjoys working with small teams in an international setting, but also the fact that his work can be found on half a billion mobiles and creates billion‐dollar revenues.

What is Peter up to? See his /now page.

get in touch: email · twitter · g+ · linkedin · xing