Talk:Usability for Nerds/Convincing decision makers

Version 2.0 (Voluminous, alternative)

First step in convincing the decision makers is finding them. Finding those who are really responsible for the decisions, as the formal structure of the company may not be the actual one, and may exist solely for public purposes. In some weird cases, dictated by formal profit management and tax reduction, the decision makers may actually reside in another affiliated company or somewhere else. Hence the difficulty of finding the actual decision makers may vary, and the effort to persuade the formal decision makers may fail from the very beginning due to such reasons.

The second step is, solely for yourself, to define for yourself the purpose and attractive points in the design of a user friendly machine or software which may be generally considered as the ones supporting the statement that usability is important and that the usability of existing designs can be improved. At this step it may be also useful to make them appear more attractive to the suspected decision makers.

The third step is, indeed, to convince or try to convince them. The actual procedure may greatly vary, depending on your position - one thing is when you are working inside the company, and a completely different thing is when you are working outside the company. You may expect from the very beginning that no one would give a damn about it, unless you find some pressing arguments or force them to do it in some other way.

The decision makers may hold positions of managing directors, marketing department and development engineers in an innovative company, but not necessary - as stated above, they may actually hold some some random key job places and reside elsewhere, outside the company - then the options are to find them or relay your information or arguments to them from elsewhere. It is safe to assume that many of them are appointed from actual upper levels (real owners or high level managers) based on personal undisclosed attitudes and interests, non-formal relations, including family ones, business interests and so on, and high competence of them is something rather untypical, you would expect them to be guided more by conservative attitudes and designs, incompetence, wrong concepts (overheard, learned by social disinformation (rumors) or misunderstood and imposed by assertive attitude) and lack understanding of the importance of user friendly designs.

At this point one may question the necessity to explain to these persons what a usability is. The easiest way if you gained the approval of higher-ups, then they will formally have to listen to you (but most likely won't give a damn), in this case you have to prepare an easy list of desired actions for dummies, so that they could include them in their routine without thinking. Such explanations for dummies are best when extended (complimented) with examples. The result may be improved by more instructions for the lower ranked personnel, who are supposed to implement the changes, the decision makers would most likely just ignore it all and pass to lower level if successful, and the most convincing example you can give as such is probably a videotaped usability test of an existing product from the same company. Introducing the user feedback issues may have some meaning if they are going to use it in some next version, for competition or something alike, but there is a high chance that such arguments could be simply put away for better times, but this delay may be shortened if you put such arguments in situation under public pressure over the decision makers. As for the competence of those, involved in development, it is important to remember that persons who are very familiar with such a product very frequently cannot imagine that users can have problems using their product until they actually see a video of a user having problems.Just Coder (discuss • contribs) 21:52, 29 August 2015 (UTC)

Discussion >> Discussion Just Coder (discuss • contribs) 21:55, 29 August 2015 (UTC)

Well, their incompetence is not rare, by far not rare. They may be selected not for their actual achievements, but internal social-like relations, they may be appointed by concerned parties and so on. Their competence is usually in doing a strict routine, which they learned by heart, but they don't understand it, neither they can modify it when necessary. From my experience of trolling them, it is a very common problem, even for highest representatives. Some, the smarter ones, may even work for competitors after facing the reality when they were not given promised rewards (and remain undetected due to overall stupidity level) - because the overall encouragement is frequently based on lies - make a promise, force a worker to work more, then breach their promise, sometimes in a very stupid and apparent way, with the general idea not to pay for the extra work.

Another result of trolling - more evidence for the fact that the "decision makers" in fact frequently think like "it looks nice, it may look nice in the presentation, then it is ok" - meaning that their internal (not covered by lies) decision criteria is amazingly simple and dumb - they judge by the visual appearance and then let it pass, if it looks visually appealing. How they are appointed, is described above. It is one more actual reason for the things you described, Agner. No matter how dumb the menu may seem, if it looks visually appealing for some dumb higher-up, and it clicks ok, there is a high chance that it will pass without a second thought (as a part of their daily pretense routine mentioned earlier). Sometimes they may listen to a customer complaint (for primary large corporate consumer they most likely will, with scolding the ones guilty), but from my experience, it may take up to 1 year of very hard and complex trolling (warfare) against support department and other departments (for a single person) to get some feature implemented, hence usually is not available for an average user. Just Coder (discuss • contribs) 20:50, 24 August 2015 (UTC)