実践的な初回ビルド
役立つものを作るための無料アプリビルダーチュートリアル
この無料アプリビルダーチュートリアルでは、明確なアイデアからテスト可能な初版まで進めます。現在の出発点に合うルートを選び、必要最小限の有用なワークフローに沿って進め、中心となる体験が機能してから改善します。
自分に当てはまるケースを判断する
目標に合うパスから始めましょう。どちらのルートでも役立つ最初のアプリを作れます。違いは、最初の生成前にどれだけ構成を決めておきたいかです。
-
1
明確なアプリのアイデアがある
ユーザー、主なタスク、そしてアプリが提供すべき1つの成果を説明できるなら、パスAを選びます。将来の機能をすべて列挙するのではなく、初版の範囲を絞りましょう。
-
2
問題は分かっているが、インターフェースは分からない
漠然としたニーズを画面、フィールド、アクションに変える手助けが必要なら、パスBを選びます。ワークフローから始め、アプリの構成はそれに合わせましょう。
-
3
すでに大まかな下書きがある
どちらのパスでも進め、生成された結果を元のニーズと比較しましょう。タスクに役立つものは残し、混乱を招くものは削除します。
パスA
アプリが実行すべき仕事をすでに理解しているなら、具体的な要件を使います。焦点を絞った依頼により、ビルダーが解決すべき前提が少なくなり、最初の結果をテストしやすくなります。
- 漠然としたアイデア
- テスト可能な初版
追加の画面を加える前に、依頼内容を1つのユーザージャーニーに変換します。
パスB
アイデアがまだ漠然としているときは、この左右比較を使ってください。左列では問題を説明し、右列ではビルダーが実行に移せる決定事項に変換します。
不明確な出発点
役立つビルドブリーフ
ユーザー
不明確な出発点
そのアイデアを使う可能性があるすべての人
役立つビルドブリーフ
具体的なニーズを持つ主要ユーザー1人
主なタスク
不明確な出発点
考えられる機能の一覧
役立つビルドブリーフ
ユーザーが完了しなければならない1つのアクション
最初の画面
不明確な出発点
複数の進み方を示すホームページ
役立つビルドブリーフ
主なタスクを開始する画面
データ
不明確な出発点
アプリがいつか必要とする可能性のあるすべての情報
役立つビルドブリーフ
最初のタスクに必要なフィールドのみ
成功の指標
不明確な出発点
アプリは完成しているように見える
役立つビルド概要
ユーザーは意図したタスクを完了できる
フィードバック
開始地点が不明確
コンセプト全体への一般的な意見
役立つビルド概要
特定のステップで観察されたつまずき
次の変更
開始地点が不明確
すぐに別の機能を追加する
役立つビルド概要
最大の障害を最初に解消する
最終確認
最初のバージョンが完成したと言う前に、画面数で判断するのではなく、実際の利用の流れをテストしてください。こうした制約は通常のものです。回避策によってプロジェクトの焦点を保てます。
-
プロダクト上の意思決定に取って代わることはできない
生成されたインターフェースでは、どのユーザーを最も重視すべきか、また成功を定義する成果が何かを判断できません。
回避策生成する前に、ユーザー、タスク、結果を明記した一文を書いてください。
-
それだけで需要を検証することはできない
動作するアプリは、フローを作成できることを証明するだけで、人々がそれを必要としていることや、採用することを証明するものではありません。
回避策実際の対象ユーザーに主要なタスクを完了してもらい、どこでためらうかに耳を傾けてください。
-
通常とは異なるルールを見落とす可能性がある
エッジケース、権限、例外、そしてドメイン固有の制約は、最初の短いブリーフには現れない可能性があります。
回避策最もコストのかかる3つのミスを挙げ、アプリを拡張する前にそれぞれをテストします。
-
最終的な品質チェックにしてはいけません
洗練された画面でも、わかりにくいラベル、欠落した状態、または壊れた手順が含まれている可能性があります。
回避策クリーンな状態からアプリを起動し、主要なフローを完了して、つまずいた箇所をすべて記録します。
今すぐ最初の役立つバージョンを作る
具体的なワークフローを1つアプリビルダーに持ち込み、生成されたものを確認し、利用者にとって最も重要な部分を改善します。テスト済みの小さなアプリから得られる学びは、想像上の機能を長々と列挙するよりも多くあります。
最初のアプリを作る- 1人のユーザーと1つのタスクから始める
- 拡張する前に完全なフローをテストする
- 推測ではなく、観察したつまずきから改善する
チュートリアル FAQ
無料で最初のアプリを作り始める前に、よく寄せられる質問への回答です。
在庫リスト、予約リクエスト、チェックリスト、シンプルなトラッカーなど、明確な成果が1つある小規模なアプリを選びましょう。最初のプロジェクトには、最初から最後までテストできる短いワークフローが最適です。
はい。まず、ユーザー、タスク、情報、期待する結果を平易な言葉で説明します。プロダクトに関する判断や結果のテストは必要になる場合がありますが、最初からコードを書く必要はありません。
主要なユーザー、主なアクション、重要なフィールド、成功とはどのような状態かを特定できるだけの詳細を記載します。最初のワークフローが使えるようになるまで、将来の機能をすべて追加するのは避けましょう。
実際のユーザーと同じように、クリーンな状態から開始して主要なタスクを完了します。ラベルが理解しやすいか、必要な情報が揃っているか、エラーがわかりやすいか、意図した結果を簡単に認識できるかを確認します。
結果を元のタスクと比較し、最も大きな不一致を1つ特定します。その要件を明確に書き直し、1つの変更に集中して、関係のない複数の部分を一度に変更するのではなく、同じ操作の流れをもう一度テストします。