「患者の手にある精神病院」のスクイーズ

私は最近、アラン・クーパーの本「患者の手の中の精神病院」を読みました。 それから、「開発を改善する方法」というトピックに関する多くのアイデアを引き出すことができました。 以下は、私が採用している本からのいくつかの推奨事項です。

Milfgard はこの投稿で私にインスピレーションを与えました。 このリストから、興味のあるすべての本を読みます。







1.人メソッド



ドミトリーサテンや他の尊敬される同志のプレゼンテーションで彼のことを聞いたことがありますが、行動のガイドとして彼を取り上げたことはありません。 しかし、アランクーパーは、これを行う必要があると言います。



したがって、最終的な結論は、「ユーザー」の概念から離れて、実在の非現実的な人々に移ることです。 つまり 製品の本当のターゲットオーディエンスから登場するキャラクターを考え出しますが、同時に、彼らは本物の人間であってはなりません。 たとえば、ホテルのWebサイトの場合、次のようになります。



マリーナ、25歳。 30人の小さな会社のオフィスマネージャー。 彼女は日中明るいモスクワ事務所で働いており、すべてが好きです。 責任:オフィスで良い雰囲気を維持し、すべてが機能することを確認し、出張を準備し、このための文書を作成します:ホテルの部屋を予約し、チケットを予約します。 ほとんどの決定は独立して行われ、最終請求書にのみ署名します。 良い夫と3歳の娘。




そのような人にとっては、真空中の球状のユーザーよりもすでに設計がはるかに簡単であり、印刷機能が必要かどうかという質問が発生した場合、はい、私たちはそれを必要とします:マリーナは予約に関する情報を印刷し、出張に行く人を通過します。 または、PDFで保存し、メールで従業員に送信します。



2.目標を思い出す



当社製品を使用するすべての人には、いくつかの目標があります。 これは:

  1. 個人的 (愚かさを感じず、間違いを犯さず、十分な量の仕事をして、楽しんでください)。
  2. 実用的 (会議を避け、顧客の要件を満たし、注文履歴を保持し、顧客に電話をかける);
  3. 法人 (利益の増加、競合他社の敗北、スタッフの採用、さらに2つの店舗のオープン);
  4. false (学習しやすく、メモリを節約し、外観を改善し、データ入力を高速化します)。


これらの目標は、人々の優先順位に従って与えられます。 まず第一に、個人的な、そして他のすべて。 個人的な目標が企業の目標と矛盾する場合、個人的な目標が長期的には勝ちます。



目標とタスクを区別することが重要です。 1つの目標を達成するために、多くの小さなタスクを実行できますが、最終的な目標を決して忘れないでください。



3.スクリプト



人々のシナリオに焦点を当てる これにより、前の例のマリーナの代わりに自分を置くことができます。 「旅行の日付、送られる必要がある従業員、送られる必要のある場所が伝えられます。 インターネットでこの街のホテルを探しています。価格、空室状況を確認し、すべてが自分に合っていれば予約します。」



また、シナリオには次の3つのタイプがあります。

  1. 毎日 (これらは最も有用で重要です。それらに記載されているアクションは最も頻繁に実行されます);
  2. 必須 (まれにしか使用できませんが、その使用の可能性は必然的に必要です。たとえば、法人からの現金前払いによる緊急予約や予約のキャンセルなど)。
  3. 例外的な状況 (これらは最後に開発され、インターフェースの奥に隠れることができます。例:Marinaのキーボードは壊れていますが、すぐに部屋を予約する必要があります)。


プログラマーは通常、例外的な状況に焦点を合わせますが、シナリオの場合、日常の、しばしば繰り返される行動に焦点を合わせる必要があります。



4.平均的な視聴者向けの製品



プログラマは、人々が私たちのウェブサイト/プログラムを開いており、ここで何をすべきかを知っていると思いがちです。 ただし、より多くの機能を使用するほど、エントリのしきい値が高くなります。 訓練された聴衆に向かって明確な傾きがあります。

一方、幹部と営業マネージャーは、ユーザーの能力を過小評価しています。 彼らは、できるだけ簡単にすべてを噛み、見せて、実行する必要があると考えています。 準備のできていない聴衆に向かって転がりましょう。



正しいものは中央の農民に頼ります。 もちろん、これらの真ん中の小作人が誰であるかを事前に決定します。



5.主なもの-主なもの



頻繁に使用する機能を覚えて、できるだけアクセスしやすくすることが重要です。 使用頻度の低い機能は非表示にすることができます。 マイクロソフトは、2007年バージョンからMS Wordにこのようなアプローチを実装しようとしましたが、現在では見つけることができない希少な機能を損ないました。



6.共通の辞書に同意する



多くの場合、プロセスの異なる参加者による同じ概念は、異なる解釈が可能です。 クライアントは1つのことを意味する場合がありますが、開発者はまったく異なります。 例:「私のサイトでは、カスタムリサーチを購入できるはずです。」 支払いの可能性についてクライアントに尋ねると、カスタムスタディの価格は前もって決定されていないため、サイトで支払うことはできないと答えます。 アプリケーションが郵便局に送られた方が良いです。 したがって、「購入」という用語を指定するだけで、それが意味するすべての機能を備えた購入/支払い機能を放棄しました。



7.相互作用の設計と詳細なドキュメント



最も重要なことの1つは、相互作用の設計です。 スクリプトを準備したり、人のことを考えたりするインタラクションデザイナーは、プロジェクトの成功に責任を持つ必要があります。 製品の全体的な成功に対する「UIの設計→設計→プログラミング→テスト」というアプローチを持つプログラマーからは削除されます。



設計者が設計したすべてのものを注意深く文書化することが重要です。 そうすれば、いつでも読み直して、正しい方向に進んでいるかどうかを理解できます。 ドキュメントでは、必然的にpersonメソッドによって開発されたキャラクターの名前が使用されます。



PS:私たち自身はまだこれらの原則のどれも完全に適用していません(しかし、本当にしたいです)。この本を読んだ人がコメントでこれらの原則を実装する経験を共有することは興味深いでしょう。



All Articles