この記事では、このレポートの主な考えを表明するとともに、製品マネージャーが製品をどのように見るべきかについての私の考えを共有します。
問題の本質
素晴らしいプログラマーがどのようにUXを設計できるかという例は、常に出くわします。
たとえば、これは州のポータルのワークブックから履歴を記入する素晴らしい形です。 サービス（私はすでにそれについて書いています）。これは、開いてから15分後にセッションを強制終了し、ユーザーにすべてのデータの損失でページをオーバーロードさせます。
これらは、左の図のように、完全に理解できない情報を入力するための素晴らしい形式です。
これらはテキストエディタの閉じているウィンドウであり、テキストを保存しようとさえしません。このウィンドウでは、不幸なユーザーが一生のうち2時間を過ごしました。
このようなソフトウェアで作業することは非常に悲しいです。 私は一流の専門家がそれを書いたことを理解し、これらのシステムのコードも完璧な順序であると認めます。 ただし、それらは使用しません。 極端な場合、選択の余地がなければ、「サボテンを泣かせ、注射し、食べる」ことはできますが、同時に、少し文学的なコメントで開発者のカルマを台無しにします。
なんで？
もちろん、問題はすぐに発生します：なぜですか？ なぜこれが起こっているのですか？ 最高のプログラマーでさえ、完璧なアーキテクチャーを設計し、完璧なコードを書いているのに、ユーザーとのやり取りを設計するときに最大の間違いを犯すのはなぜですか？
これを理解するのは簡単です。 ソフトウェア製品を開発する場合、まず第一に必要なのは、明快さ、論理、綿密な分析、および利用可能な情報を構造化する能力です。 心理学者によると、これらは左半球の機能であり、論理、合理的思考、分析を担当しています。
次に、ユーザーの「痛み」を軽減するインターフェース、デザイン、および新しい製品要件を作成する場合、美意識、創造的に考え、新しい何かを作成および発明する能力だけでなく、共感の高度に開発された感覚も必要です。他の人に共感する能力、彼らが本当に必要なものを理解するために、彼らの場所に身を置く能力。 これは、同じ心理学者の保証によれば、感情と感情に責任がある右半球の機能です。
もちろん、ユーザーから受け取った数百の統計とフィードバックのシートを収集し、それらを分析して、それらのほとんどに欠けている機能を理解し、どの問題を解決する際に最大の困難が生じるかを理解できます。 しかし、これでは真に必要な成功した新製品を作成することはできません。
ユーザーは自分が望むものを常に正確に説明できるとは限らず、時には自分自身でさえ知らないこともあります。 彼らは「快適ではない」と感じるかもしれませんが、その理由を説明できることはほとんどありません。 さらに、彼らは不便を誤って解釈したり、自分が本当に快適になる方法を本当に理解せずに、「より快適になる方法」を独自に思い付こうとするかもしれません 。
ヘンリー・フォードがかつて言ったように：「私は人々に欲しいものを尋ねたら、彼らはより速い馬を求めます。」
どうする
それでは、ユーザー自身が自分が何を望んでいるかわからない場合、どうすればいいのでしょうか？
まず、「ユーザー」という言葉を忘れます。 私の意見では、製品を設計するときに非常に有害です。 「ユーザーができるべきである」と組み合わせて要件を作成する場合にのみ使用するのが理にかなっています。 なんで？ すべてが非常に簡単です。「ユーザー」には顔がありません。 彼には、名前、性別、年齢、髪型、仕事中に膝の上に座る子供はいません。 彼は車を修理に持って行ったり夕食を作ったりする必要はないと考えています。 「ユーザー」は「同じボタンを10回作成するのにどれほど疲れているか」と叫ぶことは決してありません。彼は決して「スマホ画面でこの要素を見逃しました。 バスが揺れた！」
「ユーザー」、別名「The user」、または「 Zeuser 」は、 地球上で最も灰色で 、意志が弱く、無力で抑圧されたクリーチャーです。
そのため、「ユーザー」という言葉は忘れます。 交換する方法は？ 手始めに、「 人 」と呼ばれる素晴らしいツールを使用できます。 擬人化により、顔のない「ゼユーザー」が名前、人、職業、趣味を見つけることができます。 とても簡単です。 しかし、それだけではありません。
完全な生まれ変わり
私の意見では、単に人を使うべきではありません。 私たちは彼らにならなければなりません。 これは非常に重要な瞬間です。これにより、システム管理者であるVasyaまたは自家製ビーズ製品の売り手であるAnyaとして、一瞬で生まれ変わります。 私たちはヴァシャのように考え、ヴァシャが望むものを望み、彼の心配、問題、喜びに完全に染み込まなければなりません。
これには発達した共感が必要です。 これには、ユーザーを理解するための長くて骨の折れる作業が必要です。 「Zeuser」ではなく、VasyaまたはAniのものです。 この作品は、役割に住んでいる俳優の作品に似ています。 しかし、この作品は常に実を結びます。 ユーザーの肌を深くすればするほど、彼が何を必要としているかを正確に理解し、製品が癒す痛みを感じます。
ちなみに、標準では、 ユーザーストーリーの形成について、おおよそ次の形式でアドバイスしています： " as <role> I want ... .... " したがって、彼らは直接それらを書く人（通常プロダクトオーナー）をユーザーの場所に置きます。
自分のドッグフードを食べる
おそらく、ユーザーの役割に慣れる最も簡単な方法は、自分の製品を自分で使い始めることです。
「私たちは自分で作ったドッグフードを食べます。」 このフレーズは、1970年代にペットフード会社であるAlpoの広告に最初に登場し、現在マイクロソフトのソフトウェア開発で頻繁に使用されています。 当社の製品は非常に優れているため、自分で使用しています。
おそらく、このアプローチの最も顕著な例の1つは、人気のあるGitバージョン管理システムです。 プロジェクトの開始から3日後、そのソースコードが Git に配置され 、このツールのさらなる開発が彼の助けを借りて行われました。
有名なソフトウェア開発会社へのインタビューのために来た私の友人は、ほとんどの従業員が競合他社のソフトウェアを使用しているのを見ました。 面接は意味がありませんでした。 彼はすでにこの会社で働かないことを知っていました。
あなた自身がそれを使用せず、競合他社の製品を好むなら、誰があなたの製品を必要としますか？ 彼の質は？ なぜあなたはそれをまったくリリースし、誰をだまそうとしているのですか？
本当に必要な製品を開発したい場合は、必ず使用してください。 そうでなければ、品質、信頼性、使いやすさを評価するのは非常に困難です。
一方、あなたの個人的な好みはほとんどのユーザーの好みと一致しないかもしれないという事実について非常に明確にする必要があります。 たとえば、 Win + Rを押してプログラムを呼び出すことに慣れています。その後、起動したアプリケーションの実行可能ファイルの名前を入力します。 しかし、私は、私たちの製品のユーザーの誰もこれを行わない可能性が高いことを完全に理解しています。
プロダクトマネージャーが自分のエゴを脇に置き、製品をオープンマインドで検討することは非常に重要です。 しかし、これはまったく異なる話です。
結論
良い製品を作るには、ユーザーの目を通してそれを見る必要があります。 ユーザーを直接知り、必要なものを理解し、問題を確認する必要があります。 そして、ユーザーがあなたの一部、あなたの製品の一部、すべての機能の一部、すべての決定の一部になるようにします。
そして、あなたの製品は有用で、便利で、需要があります。 だから-成功。
製品の開発を頑張ってください！