【思考術】　プロダクト製作におけるアンチパターンを読んで - 30代からの再勉強日記（ビジネス系/IT系の一般論の理屈を考えてみる）

　作るべきサービスや機能について考え設計していくことは本当にしんどいです。無数のパターンがあるなかで関連者の承認をえるのもそうですが、ユーザから心証がよくないといけない。常に正解の考え方はないにせよ、失敗するであろうアンチパターンについての記事を見付けられたので紹介しつつ、自分の頭の整理をします。

　ある機能やデザインを客観的に評価するために、A/Bテストで実際に試してみて評判がいいほうを本採用にするのは定番です。気軽に複数パターンを試せるが、その限度があることを忘れてはならない。

　例として、3機能（Ｘ機能、Y機能、Z機能）を追加して画面UI上に表示する新デザインがあるとする。その場合、各機能の有無で8パターン、画面上のタブにどの順番で表示させるかでまた複数パターン、タブの色でまた複数パターンと倍々に増えていく事になります。

　対策）ビジネスの現実においてスピードは大事なので、少数のパターンに絞り切る。

（ユーザに聞くべきという理想論を盾にデザイン候補を絞らないのはNG）

　ある機能を追加する事で、それが邪魔に思うユーザがいるかもしれない。

そこで、特に考えもなしに「実装はしておいて、いらないユーザは設定でOFF」という逃げ道も時にはあるが、大多数のユーザは設定でカスタマイズしないと使い勝手が悪いアプリからは逃げるので、やはり設定での回避は愚行。

　対策）想定されるペルソナを作り、そのペルソナが使いやすい物から崩さない事。

（また、結局は何をどうしても万人に受ける事はないと割り切りも大事）

　そのサービスで簡単なマクロやスクリプトを動かせて便利にする機能があるとうれしがるユーザもいるとは思われる。しかし、開発側やサービス開発側の会社にいる社員のリテラシーと世間一般にいる普通の人のリテラシーは大きく異なるため、使いにくいデザインになりやすい。

　対策）自分の母親が楽しく使えるか・友達に教えられるか、のレベルで考える事

　大きな声のユーザに惑わされてはならない。大多数のユーザはいいも悪いもわざわざ報告してこない。

　対策）データを見て、ユーザのアクセスパターンや推移を分析する事

　会社で評価される方向の機能やイベントを行う。ユーザの評価よりも、KPIで図られている数値が上がるような開発を行う事。※長期的にはサービス価値を下げる恐れ有

　対策）短期目標も重要だが、原点に立ち返り、どのユーザに何を提供するのか振り返る事。　（※上司側含めてですね）

　5個のアンチパターンについて記しました。確かにどれも引っ掛かりそうな所なので定期的に振り返る機会を設けて、こうした落とし穴にはまっていないか、注意していきたいと思います。