our blog12 reasons why products fail, enterprise edition
30 October 2013, 17:56
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.
. By request, they are listed below for future reference. :
‘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…
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 example of wishful thinking 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 two if you missed it.
Labels: practical, why products fail
war and peace, the abridged UI version
18 October 2013, 16:47
Actually, I intend this blog post to be shorter than usual.
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: architects, fundamental, top story, war and peace
another 12 reasons why products fail
9 October 2013, 10:49
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…
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 example of wishful thinking 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 one if you missed it.
Labels: practical, 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
