そのため、ユーザーエクスペリエンス(同じUX、ユーザーエクスペリエンス)などがあります。 一般に、UXは製品(たとえば、サイト)に対するユーザーの印象です。 これには、外観、ボタン、リンク、その他の要素の場所の利便性が含まれます。
インタラクションエクスペリエンスが重要な理由 初級:ユーザーはサイトで快適です-あなたは利益を上げます。 ユーザーがブラウザのタブを紛失し、動揺して閉じたため、何も表示されません。 ちょうど2倍のように。
そして最も悲しいことは、開発中にUXで修正すると、絶えずお金(マーケティング予算)を失うことです。 「キュート、セクシー、ミミミ;-)」をすぐに実行することをお勧めします。
当初、アジャイル開発ではUXはまったく考慮されていませんでした。 そして、驚くべきことではありません。結局、アジャイルのパイオニアは、独自のITプロジェクト(特別なソフトウェア)に取り組んだり、企業のソフトウェアを書いたりしました。 ユーザーの習慣を考慮しますか? 申し訳ありませんが、他にユーザーはいますか?
現在、開発中のソフトウェアのほとんどは、エンドユーザーの利益に基づいています。 それにもかかわらず、克服しなければならない2つの主要な問題があります。ソフトウェア製品の利便性の程度を測定できないこと (相互作用、UXの同じ経験)とユーザーから一定のフィードバックを受け取れないことです。
UXマトリックスの目的は、プロジェクトバックログとUXをリンクすることにより、これらの問題を解決することです。 まず、そのようなプレートに記入します-将来マトリックスを構築するためにデータが必要になります:
列名 | 可能な値 | 説明 |
---|---|---|
人 | 人の名前 | このユーザーストーリーまたはそのユーザーストーリーを適用できる人を定義します。 |
難易度UX | 1から5 | デザイナーの実装コストを見積もります。 |
履歴確認済み | はい/いいえ | この物語は事実ですか、それともフィクションですか? 研究と統計に基づいていますか? |
デザインが完成しました | はい/いいえ | 設計は開発者の要件を満たしていますか(技術的実現可能性) |
タスク完了率 | 0から100% | 支援なしでストーリーを完了したユーザーの割合。 |
人員配置 | 資源 | 設計の責任者 |
たとえば、支払い後にダウンロードできる電子ブックストアを設計しています。
たとえば、「Student Vasya」(最初の人を簡単に説明すると、「1年目のマーケティング担当者の勉強、新しいガジェットが好き、ソーシャルネットワークで自分のアカウントを持っている」など)に役立ちます。
私たちはその人のために物語を作り上げます。
- 学生のVasyaは本を購入したいのですが、彼は著者の名前と本のページが少ないという事実しか知りません。
- 学生Vasyaは、著者Xの本Nが発売されたときに知りたいと思っています。
- 学生のVasyaは、一度に複数の本を購入し、電子財布で支払いたいと考えています。
- 学生Vasyaは、友達の誰が本を読んでいるかを見たいと思っています。
- Student Vasyaは、読んだ本にコメントを追加したいが、サイトにログインしたくない。
従来のスクラム手法と同様に、UXスペシャリスト(アナリストおよびWebデザイナー)は、ストーリーを特定のタスクに分割します。 その後、結果はかんばんボードと開発タスクで修正され、統合UXマトリックスを使用してバックログに実装されます。
重要:人には比重が割り当てられます。 主なターゲットオーディエンスの代表者は、より大きな影響(優先度)を持ち、ターゲットではありません-したがって、少ないです。 ストーリーは、ビジネス目標への影響に関してプロダクトオーナーによって評価されます。 これらすべてを念頭に置いて、バックログのタスクは合理化されます。
この人物のストーリーが完成したら、表に従ってそれらを評価し、Vasinsとは異なる目標ストーリーを追求する次の人物に進みます。 情報の正確さのために、各人は生きている人々に関する研究を使用して確認されます(統計的確認を受け取ります)。
私たちの仕事の結果は、そのような行列になるはずです。
「ストーリーは独立して作成されます」-テストされたユーザーの何パーセントが外部の支援なしでストーリーを完成できましたか。
特に、この一見複雑なアプローチの意味は、パフォーマーのタスクが完全に新しい意味を獲得することです。 比較する:
以前: 「商品画像の下にソーシャルレコメンデーションボタンを描く」
現在: 「ユーザーがお気に入りの製品を友人と共有するのに役立つツールを追加します。」
一見、同じこと。 ただし、最初のケースでは、タスクは引数なしの「do it」という単純な朗読です。
第二に-タスクには、権威主義的な兆候は含まれませんが、UX専門家に顧客の実際のニーズに基づいたソリューションを求めることを強制する目標です。 ユーザビリティアナリストは、チームにいる場合、ユーザーのソフトウェアの利便性を向上させることを目的とした予備調査に取り組み、機能デザイナーがインターフェイスパーツを設計し、ビジュアルデザイナーが最終製品を作成します。
さらに、プロジェクトは開発段階に入り、プログラマーはすべてのアジャイルルールに従って実装を評価し(ところで、 Planning Pokerは評価ツールとして推奨されます)、最終的にはユーザーに向けてリリースされます。
プロジェクトは最初のユーザーエクスペリエンスに既に基づいていることが重要です。したがって、デザインは現在、特定のユーザーの利便性に関するアイデアではなく、ユーザー自身の相互作用のエクスペリエンスに基づいているため、より実行可能です。
では、出力には何が得られますか? 美しいラッパーだけでなく、使いやすいデザイン。 各ユーザーのニーズは、レイアウトに組み込まれる前に分析されます。したがって、このサイトは「ビジネスツール」の定義を満たします。 そのため、デザインが不適切だからといって、穴から「マーケティング予算の漏れ」を心配する必要はありません。 そしてそれは良いことです。
脅威。 私たちと同じくらいアジャイルを愛する人はプレゼントとしてボーナスを受け取ります-エクセルファイルの同じマトリックス: docs.google.com/spreadsheets/d/16ZbCnVMeGer09EGkIIVZmqsKfU_8R-DEJg0WJ9GSfzE/edit?usp=sharing
これにより、柔軟なプロセスの利益のために、一般的に、所有、使用、および廃棄する値をソート、整理、グループ化、入力できます。