技術者以外のビルダー向けガイド
最初のアプリで何を証明する必要があるかを決めます。
画面や機能について尋ねる前に、幅広いアイデアを短くテスト可能な概要にまとめてください。
01 — 1 人の人物と 1 つのタスクについて説明します
コミュニティ グループがボランティアのシフトを組織するのを手伝うとします。最初の質問としては、ボランティアが適切なシフトを見つけられるか、興味を表現する方法を理解できるかどうかが考えられます。これは、リマインダー、権限、給与計算を備えた完全なスケジュール システムよりも小規模であり、レビューが簡単です。
- その人が今日何をしているのか、何が難しいのかを説明してください。
- より明確または簡単にしたいアクションを選択してください。
- 最初のバージョンが機能した場合に観察されることを書き留めてください。
02 — 紙の上で旅を辿る
ボランティアの例では、シフトリスト、シフトの詳細、お問い合わせフォームをスケッチします。各画面に 1 つのジョブを与えます。完全なシフトや空のリストなど、いくつかの現実的なサンプル シフトを使用して、洗練されたハッピー パス以上のものをレビューでカバーします。
- 開始画面と次のアクションに名前を付けます。
- このテストに必要なフィールドをリストします。
- 空の状態と失敗したアクションの状態を含めます。
- 探索的なプロンプトや例には実際の個人情報を含めないでください。
03 — デモを運用サービスから分離する
このバージョンではジャーニーのみを示すか、実際のリクエストを保存する必要があるかを決定します。デモでは、明確にラベル付けされた確認例を示すことができます。動作中のサービスには、宛先、適切なアクセス、およびリクエストを取得する方法が必要です。実際の参加者を招待する前に、これらの要件を確認してください。
- ブリーフ内のサンプルのみのアクションをすべてマークします。
- 接続、権限、公開のニーズを個別にリストします。
- 最初のテストがそれらに依存しない限り、アカウント、支払い、リマインダーは後回しにしておきます。
- 機密情報や複雑なアクセスが含まれるタスクの場合は、資格のある支援者に依頼してください。
04 — 結果を概要と照らし合わせてレビューします
以下のワークシートを使用し、製品プロンプト ガイドに従ってそれをビルド リクエストに変換します。世代を経て、同じ旅を歩き、何が起こったのかを書き留めてください。ボランティアの例では、デモが成功したということは、新しい訪問者が適切なシフトを見つけて、あなたからの説明がなくても次のステップを理解できることを意味するかもしれません。
- このアイデアに慣れていない人に、そのタスクを試してもらいます。
- 追加の機能をリクエストする前に、わかりにくい手順を記録してください。
- 焦点を絞った変更を 1 つ行い、同じチェックを繰り返します。
- 最初の行程で元の質問が解決された場合にのみ、範囲を拡大してください。
出発点
概要を具体的にします。
この例をあなたのビジネスに当てはめてください。サンプル データを実際の顧客情報から分離して保管してください。
最初のバージョンのスコープ ワークシート 使用者: ___ 今日直面している問題: ___ 完了する必要がある 1 つのタスク: ___ そのタスクに必要なページ: ___ 表示または入力された情報: ___ メイン アクションの後に何が起こるか: ___ サンプルのみとして残るもの: ___ 後で使用するために残される機能: ___ 最初のバージョンは、観察できた時点で合格します: ___
次のステップが必要なとき
製品ドキュメントに従ってください。
始める前に。
最初にプログラミング言語を選択する必要がありますか?
ユーザー、タスク、情報、観察可能な結果から始めます。既存のシステムまたは技術的制約によって言語またはプラットフォームが決定される場合は、それを概要に含めて、そのシステムの責任者に確認してください。
最初のバージョンにはいくつの機能を含める必要がありますか?
1 つの完全な旅行を検査できる最小のセットを使用してください。普遍的な機能数はありません。機能なしではタスクを有意義にテストできない場合、その機能は最初のバージョンに属します。
次のステップを見つけてください。
便利なタスクを 1 つ始めましょう