ワイヤーフレームまたは機能要件を最初に作成する必要がありますか？
ウェブサイト再設計プロジェクトの機能要件ドキュメントをいつ作成する必要がありますか？ FRDがワイヤーフレームに通知するインスタンスはありますか？ワイヤーフレームが作成され承認された後に機能要件が作成されることに慣れていますが、最近その逆のことを誰かに話してもらいました。
ワイヤーフレームが逆にではなく機能要件を通知することは理にかなっていますか？
「機能要件文書」などの用語はあいまいであり、特に設計チームと開発チームの間で文書が受け渡される場合はよく誤解されるため、作成する文書の目的と範囲を定義するのが最善です。
- 始める前に、内容と形式について合意を得る
- ドキュメント自体で、誤解や接線フィードバックを回避するため
それは誰のためですか？何が文書化されていますか？
あいまいさは「要件」という用語に由来します-基本的に、文書化されている要件が
- 設計上の問題に対する有効なソリューションの動作に対するビジネス上の制約
- 特定の設計ソリューションの実装に対する制約
最初のケースでは、設計ソリューションを試す前に要件を文書化する必要があるため、ワイヤーフレームの完了の前に要件を確定する必要があります。
2番目の方法では、文書化する設計ソリューションが存在するまでFRDを開始できません。そのため、インターフェース設計が安定するまで、つまりワイヤーフレーミングプロセスの後半まで、FRDを開始できません。
最初の種類のドキュメントはデザインを制約します。
2番目の種類のドキュメントは、コードの実装を制約します。
コンテンツ管理要件
これは、注意が必要なもう1つのあいまいさです。
多くのWeb開発者にとって、機能要件ドキュメントには、アプリケーションの一部として実装する必要があるすべてのビジネスルールを含める必要があります。これには、ほとんどのUX担当者は通常、ワイヤーフレームの一部として指定する必要があるものとは考えていません。
共有理解
これらのあいまいさを念頭に置き、関係者や開発者と協力して、必要なドキュメントについての共通の理解に同意する場合、多くの不必要で役に立たない（そして気が遠くなるような）作業を行わないように自分を適切な立場に置くでしょう。 ） ドキュメンテーション。
設計プロセスについて私のお気に入りのイラストは次のとおりです。
それがどこから来たのかさえ気にしないでください。それは長く忘れられていた古いスタイルのソフトウェア設計です（個別のUXと技術設計がなかったとき、ソフトウェアエンジニアリングとエンジニアリングプロセスがありました）が、それでも鍵を握っています。
ご覧のとおり、すべてはおおよそ最初から始まりますが、それらの強度は変化しています。これらは約2〜4週間の繰り返しです。
最初も最後もありません：言うことができます：最初に開始、または最初に終了。
個人的には、システムの用途を定義する機能から始める必要があると思います。
しかし一方で、ユーザーはユーザー言語、つまりユーザーインターフェイスを話します。彼らはおなじみの環境内でのみ説明でき、それは通常GUIです。変更要求に関しては、UIの変更として、またはシステムの知覚された実装のユーザーモデルである奇妙なメンタル実装モデルに基づいて行われます。
いずれにせよ、重要なのはボタンではなくニーズにこだわることです：ユーザーが別のボタンを必要としない場合でも（そう言っても）、ボタンで解決したい新しい問題があります。その情報をできるだけ早く記録してください。
ボタンが行き来するため、問題は同じままです。アプリケーションは問題に関するものです。それらは、コンピュータに関連しないニーズをどのように解決するか、コンピュータに関連しない目標を達成する方法についてです。
仕様は、これらのニーズのシステムの明確で体系的な記録である必要があります。リネが 生物のシステム を説明しようとした方法だけです。説明する世界は、ニーズとドライブに満ちた世界です。
エレガントなソリューションは、対応するもの、問題を効果的に、最もシンプルでありながら独創的な方法と一致させるものです。エレガンスは美のミニマリズムです。
デザイナーは、特にユーザーのニーズを解決するアプリケーションに関しては、優雅さを追求する必要があります。問題に対処しないものはすべて問題に追加されます。
UIはユーザーのためのシステムです。それはシステムの比喩です。
最初に問題の明確な説明がない場合、どのようにして問題のエレガントなソリューションシステムを設計することができますか？
問題を理解するために必要なことは何でも行います（ユーザーを支援するためにUIモックアップが必要な場合それらのニーズについて伝え、図を使用した方がよい場合はそれらを使用します）、テキストを使用します）、そして、あなたはその問題の解決策を持つために必要なことを何でもします、それは他には何も解決したくないです。
そのため、私は重要な成果物は、ソリューションの詳細を示さない要件ドキュメントであり、ソリューションシステムの実際の設計（通常、UI用語で指定されます）が依存していると思います。最初に完全なワイヤーフレームを設計すると、それらは空中にぶら下がります。
しかし、もちろん、これは鶏または卵の問題です。両方を同時に庭に持っていることを確認してください。
私が協力しているチームには、ビジネス分析と設計の両方を担当する1人の人がいます（たまたま私です）。要件から始める場合と、大まかなモックアップ/ワイヤーフレームから始める場合とでは、主にいくつかの要因によって異なります。
- タスクの複雑さ：単純なものであれば、おそらくワイヤーフレームにジャンプします
- 対面または距離のレビュー：地理的に離れた人々に配布する場合は、文書化された要件から始めて、ワイヤーフレームに移行します
- 技術的対非技術的：リクエストが何か技術的/複雑なものである場合、私は文書化された要件から始めます
書かれた要件の良い点は、モックアップに固有のあいまいさを防ぐために使用できることです。つまり、ユーザーが自分の要求が実際にどのように見えるかを見ると、多くの場合、より多くの要件が考えられます。
そして、時々、私は視覚的な男なのでモックアップから始めるだけで、要件がどのように記述/伝達されるべきかを正確に理解するのに役立ちます。私の非常に大まかなBalsamiqモックアップは、要件を通知するのに役立ちます。このアプローチにより、私は間違いなく自分のデザインを放棄し、要件が確定した/さらに確定した後、最初からやり直します。
最初にワイヤーフレームを作成するときは、解決しようとしていることがわからないうちにソリューションを定義します。ソリューションの設計方法を知る前に、問題を定義する必要があります。したがって、要件は製品ではなくソリューションに必要なものを示します。
また、あなたのワイヤーフレームは文字通り議論のためのアイデアの部分ですか、それとも完全に機能的な仕様に向けて努力していますか？
私はUXの人ですが、UX分析とビジネス分析のハイブリッドであり、ワイヤーフレームが最初に行われるときに頭を動かします。 UXの人々は、サイトにどのように表示されるか、つまりコンテンツがどのように管理されるかなどを知っているべきだと私は信じています。
私がデザイン主導のプロジェクトに参加するたびに、私たちは大きな問題に直面しました。そして、これは主に要件がないためです。設計者は、ワイヤーフレームが常にプロジェクトの始まりであると考えることがよくあります。彼らはしばしば要件が創造性を破壊すると述べてきました。これは間違っていると感じており、プロジェクトの後の段階でチーム全体の地獄につながります。
まず、すべてのプロジェクトに異なる方法で取り組む必要があります。同じプロジェクトは2つないため、それに応じてアプローチする必要があります。ワイヤーフレームに言及する前に、まず次のことを理解してから、以下のバランスを取る必要があると私はいつも述べています。
- ユーザーを知る（ユーザー調査）
- コンテンツを知る（監査とモデリング、主題の専門家インタビュー）
- あなたの編集プロセスを知っている（ワークフローとガバナンス）
- あなたのビジネスを知っています（ビジネスモデル）
- あなたのシステムを知っている（CMS＆統制語彙管理＆ガバナンス）
要件は、機能と非機能に分かれています。早い段階で機能要件をリストアップすることが重要です。それらが書かれる方法は、すべての技術者と非技術者にとって簡単である必要があります。
これらの要件は、ソースの組み合わせから派生しています。
- ビジネスのニーズと要望
- さまざまなユーザー調査方法に由来する可能性があるユーザーのニーズと要望
- 編集の必要性（完全なエンドツーエンドプロジェクトの場合）
私はコンサルティング会社で働いており、クライアントはスーパーテクノロジーに精通していてデザインを理解しているだけでなく、サーバー構成について話し合って、テクノロジーやデザインについて1つのことを理解していなくても問題ありません。私は現在の雇用主でプロセスを切り替えました。
設計/機能要件を引き出すために会議を数回行うことは、クライアントがページ上に絶対に必要な要素と機能を特定するのに役立つ優れた方法であることがわかりました。ただし、これらのミーティングで、フローと相互作用を理解するためにクライアントにいくつかの迅速で汚いスケッチ/プロトタイプを表示することを止めさせないでください。これらの設計要件のミーティングで、UX /設計要件ドキュメントを作成します。これは、そのページで必要なセクション/コンテンツタイプとすべての要素、およびその要件に関する非常に一般的なメモをリストしたWikiの表です。それが承認されたら、ワイヤーフレーミングまたはプロトタイピングに進みます。私がプロトタイプまたはワイヤフレームを作成しているとき、開発者向けに機能ドキュメントが作成されています。
その相互作用がどのように機能し、どのように感じられるかを確認する前に、機能的なドキュメントを作成して設計上の決定を下すことは、実際に起こるのを待っている災害であり、通常よりもはるかに多くの反復が発生するだけだと思います。
私は要件がワイヤーフレームの前に書かれるべきだと私は信じています、そしてそれは私が私のキャリアを通してほとんど見た方法です。要件はクライアントまたは製品マネージャーからのものであり、エクスペリエンス全体を提供し、UI、開発者などを導くワイヤーフレームにそれらの要件を変換するのはUXチームの責任です。
それはすべてプロジェクトに依存します。ビジネス要件の収集に取り組み、ユーザーと競争力のある調査を行う人は、visionが表示されて魔法が始まる前に、ある程度の理解が必要です。
私は特に好まないが、現時点では気にしない別のアプローチを提供します。クライアントが要件を知らなくても注釈付きのワイヤーフレームとインタラクティブなプロトタイプの組み合わせを要求するプロジェクトで同僚と協力しています。彼らは迅速な内部レビューのためにワイヤーフレームを使用し、さらに迅速なテストのためにプロトタイプを使用してから、データを使用して前の作業に基づいています。このプロセスは、ユーザーのニーズとビジネス要件によって引き起こされるものではありません。これらは両方とも進行中に生成されるためです。
このプロジェクトでは、開発者向けの可能な限り最後の時点で、追加のすべてのワイヤーフレームとインタラクティブなプロトタイプを参照として使用して、FRDが作成されます。私はこの方法はお勧めしませんが、クライアントはビジネスの特定の側面に対してこの方法で作業することを好み、彼らにとってはうまくいくようです。彼らは既成概念にとらわれずに考えることを好むと言えます。
機能要件はワイヤーフレームの前に来ます。
FRの前に、一連のイベントを開始するビジネス要件があります。
ビジネス要件はニーズを伝達し、利害関係者が起こしたいことを伝えます。
機能要件は、新しい機能が実装された後に物事がどのように機能するかを伝えます。
ビジネス要件は次のようになりますユーザーがGoogle、FB、Twitterなどの他のサイトに自分のIDでログインできるようにします。これは、競争力のある比較から生じる可能性があります。
そのような機能を実装するためのワイヤーフレームは、OAuthを実装する他のいくつかのサイトからコピーされたもので、非常に明白である可能性があります。しかし、機能はそれほど明白ではありません。
そのため、少しカットアンドペーストを行った後、関係者にスクリーンショットを表示して、サインオフすることができます。
しかし、この特定のサイトでのこのような実装の影響の現実は、機能分析者として行動している誰かがそれを理解するまでわかりません。たとえば、すべてのバックオフィスのやり取りとユーザーデータベース構造に大きな影響が及ぶ可能性があり、あらゆる場所で大きな変更と移行計画が必要になります。
この技術的な複雑さは、開発費の増加を反映しています。
つまり、マネージャーに単純化したOAuthログインワイヤーフレームを表示した後、数日後に膨大な予算を要求するように対処するにはどうすればよいですか？ VPを意味しますか？
これが、機能要件が最初に来る理由です。
もちろん、雑種のスクリーンショットを見せて、宿題が終わっている間息を止めるように言うことができますが、これは形式レベルに依存します。 12人の会社の場合、Fortune-500の会社とは異なります。
とはいえ、機能的な要求を行う技術には、UIについて言及することを避けるための多くのことが含まれます。 「ユーザーが選択できるボタンを設定する」と書くのはよくありません。FRはユーザーが選択できるようにする必要があることだけを述べるべきです。
UIをFRから遠ざけることの大きな利点は何年も前から知られており（70年代かもしれないと思います）、 Larry Constantine の結果で表されます。
それらの重要な発見（Larry＆Lucy）は、プログラミングIDEでボックスの描画を開始するのが早ければ早いほど、アプリケーションが許容可能なユーザビリティレベルに達するまでに時間がかかるということです。
機能的な要求は、多くの場合、すべてで始まる短い文の長いリストのように見えます。システムは...でなければなりません。これらはFRではなく、運がよければ、ビジネスリクエストと見なすことができます（whatではなくhowそれを行うには）。
機能要件を表現する最良の方法は、ユースケースを使用することです。
しかし、そんなに速く眉をひそめないでください。これらはあなたの父親のUCではなく、RUPのUCではありません。
私は 到達 合理的な答えの長さを超えているので、まとめとして、機能要件を取り込むために、非公式で軽量なUCを書くことが理想的です。
2つの主な理由：
- これらは、ユーザーとIT担当者の世界の間のヒンジです。
- UCが適切に記述されていれば、コーディングがより高速で安全になり、コストが大幅に削減されます。
ウォーターフォール=要件が最初に来る。アジャイル=それらは並行して開発されます。
Webアプリ開発では、成長するにつれて並行して更新/維持するドキュメントをいくつか作成することをお勧めします。
- アプリに関する1〜5ページの概要、ストーリーラインとは
- 可能なすべてのユーザーロールを定義し、その後はユーザーの参照を停止します。登録済み、プロユーザー、管理ユーザー、所有者、閲覧者などです。
- 考えられるすべてのページビューを定義します。ログイン、ホーム、通知設定-階層を設定することなく
- どのページに関係なく、各ロールが実行できるすべての可能なアクションをリストします。ログイン、いいね、コメント、自分のコメントの削除など.
- 各アプリには、ユニークなものがあります。オークション、投票、注文プロセスなど。これらのケースでは、すべての可能な結果をカバーするためにフローチャートを描きます-より上級のユーザーには、非常に役立つスイムレーンフローチャートを試してください。
上記の各ステップを進むと、新しい要素が見つかります。ワイヤーフレーミングを開始する準備ができるまで、ストーリーラインとステップ1〜5を改善していきます。技術要件は、ノートとして直接ワイヤーフレームに挿入できます。
維持することをお勧めするもう1つの退屈なドキュメントは、各ページの変数のリストです。フィールド名、タイプ、ドロップダウンオプション、必須フィールド、検証、デフォルト値など-上級ユーザー向けには、データベースダイアグラムを使用します。
この方法を使用すると、一定のブロックがなければ、すぐにワイヤーフレームを作成できます。
現時点でクライアントと明確にしている問題について、ここにたくさんの素晴らしい考えがあります。
2つ（ワイヤフレーム/プロトタイプとFRD）が密接に絡み合っていることがどのように見えるかは関係ありません。「最初に何もない」ということは重要ではありません。状態。
FRDがビジネスルール、データ要件（ソース）、およびビジネスがユーザーに公開することを望んでいる機能を詳述することである場合、ビジネスは、インターフェイスとIAの設計に関して、このデータが利用可能であることをコミットまたは確認する必要があります。このデータ/機能は提供されます。この確認がなければ、データの存在は私の経験では時々疑わしいです。なぜなら、信頼されている基盤は常に期待したほど適切ではないからです。
この時点では、ビジネスルール、データ要件、機能はすべて設計上の課題であり、ビジネスを代表する人がFRDに含まれている詳細や欠如を十分に理解することはほとんどありません。
設計者としての私たちの役割は、FRD（必要に応じてデザインブリーフ）を、文書内の概念や要件に答え、重要な課題となる意味のあるもの（提示可能で理解可能なもの）に相互運用することです。この時点では、「ボタンは必要ありません」に固執しており、一般的な情報をナビゲートする慣れ親しんだ方法を十分な詳細とともに適用して、複雑さを確実にします。
これらの健全な基盤がなければ、研究、設計、プロトタイピングを通じて得られた理解の多くは瞬時に無効になる可能性があります。ボタンや機能を追加または削除してこれを修正することはめったにありません。各要素は、ユーザーが移動またはアクセスしているものをユーザーの金属モデルに通知および確認するコンテキストに存在する他の要素に依存していることが多いためです。
繰り返しますが、Aadaamが「最初も最後もない」と述べているように、それらは同じものの1つです。
ある程度できます。
しかし、あなたは以前考えられていたものの上に自分で取り組んでいることに気付くでしょう。そして、それは、急増するアイデアに対処しない、不十分なサイト構造とレイアウトに対してサポートされない機能につながる可能性があります。
主要なインタラクション、サイトマップ、ナビゲーションを超えない機能仕様を作成することをお勧めします。次に、やり直して更新する必要があります。