🥜 📯 🧓🏽 ソフトウェア開発におけるプロトタイプのテスト 🖐🏽 🐧 🚔

特にNetologyブログのPaneglifの設計部門の責任者であるDmitry Melentyevは、ソフトウェア開発におけるプロトタイプテストの経験について語りました。

開発プロセスでは、このようなジレンマに遭遇することがよくあります。製品を優れた高速なものにすると同時に、ユーザーと顧客の両方にとって興味深く理解しやすいものにする方法です。これがどのように機能するかについて何百万もの同一の質問を注ぐことは誰も望んでいません。

市場に参入する前に製品をテストするというレシピがあります。

もちろん、リリースの直前にテストできます。多くの企業がこれを行います。彼らはベータ版をリリースし、反応を見て、フィードバックを収集し、バグを修正します。良い習慣ですが、ユーザーがインターフェイスの雑学だけでなく、すべての基本的な機能を理解していないこともあります。そして、すべてを再描画し、すべてをやり直す必要があることがわかりました。または、競合する開発者以外は読まないユーザー向けの巨大なマニュアルを作成します。

したがって、製品開発の最後ではなく、はるかに早い段階で、おそらく最初でもテストする必要があります。

プロトタイプのテストは、開発の最初の段階で時間を欺き、グローバルな問題を排除するのに役立ちます。

私たちは常に、野菜のふりをしてプロトタイプのテストを避けたいと思っています。すべてがすでに明確であるかどうかをテストするのはなぜですか？製品の開発と組織的な問題の追加には時間がかかります。テストのために同じ人を選ぶことは価値があります。そして、あなたはどこかに静かな場所をとる必要があります、そして、たとえ彼らが穏やかに言えば、何が起こっているのか少し知らないときでさえ、すべての回答者にまだ親切です。この小さな「エピソード」を解消し、リソースを節約できれば、誰も気付かないでしょう。そして、すべてがうまくいきます！

しかし、それは機能しません。

実際には、設計、レイアウト、プログラムを行うよりも、ユーザーでプロトタイプをテストするのに30分を費やしてから、[検閲済み]すべてをやり直す必要があることがわかります。

回答者が会社の従業員であっても、最も重要なのは製品設計の責任者ではありません。

製品をテストするには、時間と経験によってテストされるいくつかの方法があります：スケッチの形でのみ存在する段階から開始し、これが既製のサイトでありプロトタイプではないと考えるユーザーのためにプロトタイプのテストで終了します。時々、そうです。

紙のプロトタイプ

論文では、対象読者と数人の研究者がアクセスできる場合に概念をテストすることが理想的です。多くの画面、100万個のボタンがある複雑なシナリオをテストするのが最善です。一般的には、完成した製品でのみ同様にテストできるものです。

はい、プロトタイプは実際の結果とはかけ離れていますが、回答者は「写真が私のものではない理由」、「スニーカーの写真をクリックして、ベルトが表示された理由」、「このウィンドウに美しいアニメーションがない理由」、スクロールが動かない理由、「」ボタンが曲がっている理由、など

誰もがこれが紙であることを理解しており、その双方向性について奇妙な質問はありません。はい、なめられた最終製品とはあまり似ていませんが、機能、インタラクティブな要素との相互作用、インターフェイスソリューションと画面のナビゲーション、ボタンの意味の理解において巨大な群れを識別することができます。

経験から

かつて彼らは、市区町村向けに統一されたウェブサイトの設計プロジェクトを作成しました。まず、サイトに配置できるもの、不可能なものを理解するために調査を実施しました。次に、訪問者にとって何が重要で、何が重要でないかを決定しましたが、法律はサイト上になければなりません。

私たちは紙の上にプロトタイプを作成しました：すべてのスクリーンとウィンドウ。そして、彼らは紙でテストし、私たちの側から3人のテスト参加者がいた

1つの「ロボット」
司会者
一人のオブザーバー。

司会者はシナリオを解決することを提案し、回答者を導き、オブザーバーは回答者を注意深く観察し、自分の観察結果を書き留めて沈黙します。

最初は、回答者はこのタイプのプロトタイプを理解していないように思われました。紙のボタンを「クリック」して、紙のリストや地図をめくるのを想像するのは困難です。

しかし、突然すべてがうまくいきました。ユーザーはプロトタイプボタンをクリックし、ページをスクロールし、タブをクリックして、検索で情報を検索しました。つまり、彼らは実際に紙のプロトタイプで「働いた」。はい、少し珍しいですが、かなりのワークフローです。

最初のプラスは、3時間で紙のプロトタイプを作成できることですが、プログラムでプロトタイプを設計するのに最低1日かかります。そして2つです。次に、コンテンツを埋め込み、すべてを調整し、テストのために調理する必要があります。

2番目のプラス：テスト中に何かが「機能しない」場合、紙の上で鉛筆と消しゴムですばやく修正します-さらにテストできます。そして、これにはインターネットは必要ありません。

さらに、人々はそのようなテストに対する拒否、誤解、否定性を経験しませんでした。すべてが明確で、要点です。ナビゲーションおよびサイトとのユーザーインタラクションで多くの株を特定することができました。

詳細なインタラクティブプロトタイプ

インタラクティブプロトタイプは、ロジック、特に単純なロジック、およびユーザーの期待を十分にテストします。もちろん、難しいナビゲーションを取り上げることはできますが、画面の数と品質に懸命に取り組む必要があります。回答者は多くの場合、インタラクティブプロトタイプをプロトタイプとして認識しないため、常にそれについて思い出す必要があります。

悪いプロトタイプは何ですか：

深刻なスクリプトとアニメーションを使用して複雑なロジックをテストするため。
ビジュアルデザインを評価する。これはおそらく最も遅延した回答者ではありません。

このようなプロトタイプのコンテンツは、できるだけリアルに近いものにする必要があります。

インタラクティブプロトタイプには、ロレムイプサム、Axure山と交差した長方形の標準画像は使用しないでください。

そのようなコンテンツは、ロジックをテストするための単なるプロトタイプであり、コンテンツと視覚的なデザインに焦点を合わせていることを忘れがちな回答者にはあまり認識されません。

これはやる価値がありません。はい、そしてなぜ、トピックで「魚」を見つけることが非常に簡単な場合：

fishtext.ruのテキストを取得します。
Yandex.Picturesから写真をダウンロードします。
標準のブートストラップアイコンを設定します。
VKで検索したユーザーのユーザーの写真を投稿します。
後で実際の見出しを書いて、後でそれらが画面の幅に含まれないことが判明しないようにします。

そのようなプロトタイプは白黒で行われるべきであると考えられています。はい、いいえ。はい、インタラクティブプロトタイプで必要な要素に色のアクセントを付けないでください。これは、このようなアクセントが存在しなくなる現実の観点からは正しくないためです。それにもかかわらず、白黒のプロトタイプでうまくいくとは限りません。たとえば、アートギャラリーと絵画の強調が想定されている場合、プロトタイプをすぐに現実のように見せて、検索から画像を取得することをお勧めします。そのため、プロトタイプの種類と、それが必要な理由がすぐに明らかになります。

インタラクティブなプロトタイプは、対象ユーザーを対象としたテストに最適です。 Skypeでは、多くのプロトタイプを簡単に共有できます。ユーザーはスクリーンブロードキャストをオンにし、自分の行動を観察できるようになります。

中央アジアの人を見つけることができず、複雑すぎるプロトタイプを確認する必要がない場合は、「コリドーテスト」を行います。 CAのように見える単純な会社員を連れて行きます。この状況での主なことは、製品全体を完全に知っている人や開発に直接関与している人を連れて行かないことです。

すべての専門家が「回廊」アプローチに同意しているわけではなく、サンプルは対象読者を表していないと主張しています。しかし、私は歯を提供します。これはまったくテストしないよりも優れています。愚かなインターフェイスエラーが頻繁にポップアップします。まさか！

Axureタイプのプログラムでカラープロトタイプをテストする

ここではすべてが非常に簡単です。デザイナーは、何が起こるべきかと対話するときに、領域をマークする美しいインターフェースを作成します。これは通常、「クリック時」または「移動中」です。もちろん、カッターを使ってさまざまな要素を切り取ることができますが、これは長すぎます。そのような完璧主義者はいますが。

この美しさはすべてインタラクティブになり、ユーザーによってテストされます。つまり、ユーザーが配置した色のアクセントによってユーザーが必要な要素をすばやく見つけることができます。回答者は行動を大声で言うことができ、あなたは彼が希望する行動を取るまで待つだけです。または、あなたがデザイナーなら、待って泣かないでください。あなたがデザイナーでない場合、あなたの仕事はデザイナーにコメントを送ることです。

ターゲットオーディエンスでのテストは、Skypeでも可能です。小さなニュアンスがあります。これはプロトタイプであることを常に思い出す必要があります。常に！そのようなプロトタイプは現実にあまりにも似ているからです。ちなみに、意味のない「魚」を置く場所はありません。通常のテキスト、写真、アイコンが必要です。あなたはインターネットからそれらを取ることができます、ただ著作権所有者を覚えておいてください。

回答者が想像を絶する論理エラーを犯した場合、設計者が非常に悪い決定をしたか、前の段階でプロトタイプのテストが非常に不十分でした。

このようなテストは、次の評価に役立ちます。

以前は大きなボタンだった特定の要素が、どれだけ細いバーになっているかは、ユーザーがどれだけ理解できるか。
すべての重要な設計要素のアクセントと可視性。

ユーザーが必要な要素に気づかないか、無駄にクリックした場合は、編集する必要があります。

テスト中、これを行ったUIまたはグラフィックデザイナーはすべて黙っておく必要がありますが、回答者から遠く離れた方がよいことに注意してください。次の場合は、「ポーカーフェイス」という表現のみを使用します。彼はsoapや石けんでロープをつかむのが難しいので、ユーザーのデザインをテストするプロセスから少し離れておくのが最善です。

スクリプトを使用したテスト、または製品のアルファバージョンでのMVPテスト

すべてが正常に機能しますが、これまでのところ、10億のユーザーの代わりに5人のユーザーがいます-プロジェクトの友人、500万のSKUのベースの代わりに、100の製品に対して1つのデータベースがあり、Amazonの専用サーバーの代わりに、1gb.ruで共有ホスティングしています。しかし、すべてが正常に機能します。

すべてが正常に機能します。これが主な条件です！

ここで、ターゲットオーディエンスからユーザーを取得し（プログラマーを次の部屋から取得する必要はありません）、ユーザーに目標を与え、それを実現させます。すべてが完璧に進むはずです。実際のユーザーが目標に迅速かつ効率的に到達するのを妨げる小さなバグが記録され、修正されます。

againな人のためにもう一度。 CAをテストする必要があります！ CAがBarvikha Luhari Villageの少女である場合、オフィスの食堂労働者で製品をテストしないでください。

少なくとも1年間開発する必要がある複雑で高価な機能をテストする必要がある場合は、迅速な決定を下してテストしてください。

主なことは、すべてがサハラ砂の1グラムのダスト密度の将来の超電卓と同じように機能することです。市販の既製のソリューションを置き換えることもできます。

外から見ると、それはすべて不必要に高価な地獄のようです。しかし！複雑な機能を持つモバイルアプリケーションを作成します。これは、作成ごとに最低5000ドルであり、いくつかの重要なソリューションでは、この数に100を掛けることができます。

解決策：

500ドルで、同じ機能を持つサイトのモバイルバージョンを作成します。
正常に機能することを確認します。
CAのテスト。
高価な開発に入れてください。またはアップロードしないでください-結果によって異なります。

ビッグデータのテスト

これがYandexと大企業の道です。簡単なソリューションを考え出し、ベータ版をリリースし、プレリリースを行い、何百万もの毎日のトラフィックを投入して、その仕組みを観察します。

このオプションはあなたにふさわしくないので、私はここでやめません。トラフィックが多く、チームがUIデザイナー+高速コーダー+高速プログラマー+高速BigDataスペシャリスト+高速プロデューサー+高速sisのチームである場合を除きます。管理者+ファーストアートダイアー。

そのような会社からの場合は、チームを編成し、すぐにベータ版をカットし、本番に記入し、リンクを介してトラフィックを送信し、仮説をテストします。すべてが問題ない場合-これらのベータ版に基づいてフルバージョンを作成します。

製品テスト

あなたが既に持っている、または競合他社と持っている同様の製品をテストすることは、「完全に、競合他社のように」したい人にとって素晴らしいことです。

このアプローチを使用する人はほとんどいませんが、特に製品設計のプロセスが変更される前に、それが既にある場合、それは本当にクールなことです。または、あなたはそうしませんが、あなたの主な敵は市場です。

これには以下が必要です。

ウェブサイトまたはアプリケーション
対象読者;
ユーザビリティ研究者;
CAまたはSkypeの生息地での個人的な存在。

私たちは持っているものを受け取り、CAをテスト（またはSkypeセッション）に招待し、画面上で回答者の行動を調べます。この時点で、彼は行動と考えを述べ、私たちは妨害を記録し、エラーに関する統計を編集します。

この方法は、監督の息子がそう考えているために機能が不十分であると考える人に特にお勧めです（20年後には優れたデザイナーになります）。何であるかをテストし、ジャムを確認します。本物の浅瀬。たとえば、誰もがあなたのサイトが青緑色であること、そしてそのボタンがマテリアルデザインではなく、90年代のグラデーションであることを気にしません。しかし、バグは誰でも見ることができます。ちなみに、これはメニューの色が気に入らない視覚的な完璧主義者や、1週間前に仕事に来たアカウントマネージャーの助けを借りて「ユーザビリティ監査」を実施する企業を排除するための非常に良い方法です。

別の方法があります...

「さまざまな安価なゴミからのプロトタイプ」と呼ばれますが、工業デザインにはより適しています。たとえば、IDEOを使用します。しかし、この議論の枠組みでは、私たちはデザイン思考についてここにいないので、それについては話しません。

おわりに

私の作品では、カラーを含むインタラクティブなプロトタイプを常に使用しています。彼は紙のプロトタイプを実際のプロジェクトで数回、さらに4回、さまざまなインテンシブとコースで作成しました。むしろ、紙の上で複雑な要素を設計しますが、特に必要とされることはあまりないので、テストしません。ただし、時間が近い場合は、紙に勝るものはありません。スクリプトでのテストは1回でしたが、これはそのようなMVPを作成する長い歴史です。各画面とボタンの状態、すべての展開リスト、特定のスクリプトの実行を描画する必要があります。多くの場合、多くの時間がかかります。

自分で結論を出す：プロトタイプのテストを使用するかどうか。いずれにせよ、これはあなたの決定です。自分の時間だけでなく、会社のお金も危険にさらします。

ただし、プロトタイプで製品をテストすることを申し出なければ、経営者がそれについて知ることはまずありません。このようなテストを実行できることを誰かが知っている可能性はほとんどありません。ユーザーの早期決定を確認し、10人のユーザーのうち9人がコミットするメインスクールを修正します。または10のうち7つ、または10のうち1つだけ-市場のわずか約10％。

この重要な決定を行うのはあなたです。完全な「使用不可能な」何かを市場にリリースするリスクを減らすことです。私の言うことを理解していますか？あなたが恐れて怠け者であり、これでさえあなたのお金ではない-あなたはそれをすることはできません。しないでください。テストするのに3日間はないのに、テストせずに出てきた不名誉を書き直すのに6か月あるからです。そして、3人の参加者による3日間のテストは、プログラマチームの半年間の作業と同じですよね？

それはすべてあなた次第です。

ソフトウェア開発におけるプロトタイプのテスト