プロダクトオーナー
明確なユーザー像、主要な目的を1つ、そして検討する画面の短いリストがあります。
最初の概要にさらに構造が必要な場合は、rork アプリビルダーを参考にしてください。
rork アプリビルダープラットフォームガイド
ブラウザでアプリを形にするための rork web
rork webは、より深いテストの前にブラウザ上でアプリのアイデアを整理するための、ブラウザファーストな方法です。このガイドでは、準備するもの、焦点を絞った最初の試行を進める方法、そしてブラウザでできることの限界について説明します。
前提条件
有意義なブラウザセッションは、完成した製品仕様ではなく、小規模でテスト可能な概要から始まります。
モバイル起業家
ブラウザワークフローとデバイス指向の進め方で、アイデアを比較したいと考えています。
体験が端末上でどのように感じられるかが判断の基準になる場合は、rork androidを確認してください。
rork androidテクニカルリード
サービス設計が完成していなくても、体験に必要なデータを説明できます。
インターフェースのプレビューを完全なシステムとみなす前に、rork バックエンドについて読んでください。
rork バックエンドリリースプランナー
初期コンセプトが、より正式な提供に関する話し合いに進める状態かどうかを確認しています。
rork app storeを、プラットフォーム審査は別の段階であることを思い出すための目印として使う。
rork app store最初から最後まで一通り確認する
最初のパスは短い実験として扱う。要件を具体化し、結果を確認してから、変更が必要な点を記録する。
-
1
画面の構成を説明する
対象ユーザー、主なタスク、不可欠な画面、そして最も簡単に感じられるべき操作を明確にする。Rorkは、すべてを構築するという漠然とした約束よりも、観察可能な要件があるほうがうまく機能する。
-
2
重要な導線を1つ確認する
開始地点から主な成果に至るまでの流れをたどる。ラベル、欠落している状態、ナビゲーション、そして提案されたフローが説明した問題と一致しているかを確認する。
-
3
次の改訂内容を書く
曖昧な反応を具体的な変更に変える。画面を削除する、フィールドを明確にする、順序を変更する、またはステップに必要なデータを定義する。次の依頼は評価できる程度に小さく保つ。
うまくいかないこと
ブラウザでの確認は方向性を形作るのに役立つが、初期コンセプトの後に続く判断まで不要にするものではない。
デバイスラボではない
ブラウザでの確認だけでは、実際のスマートフォンでのタッチ操作、デバイス固有のレイアウト、権限、パフォーマンスを証明できない。
回避策
重要な導線を適切なデバイス画面に移し、そこでテストする。
バックエンドを選択するものではない
説得力のあるインターフェースだけでは、認証、ストレージ、連携、データの所有権、障害時の処理は決まらない。
回避策
データコントラクトを文書化し、バックエンドを別途確認する。
プロダクトブリーフの代わりにはならない
Rorkは曖昧さを明らかにする手助けはできるが、説明されていない対象ユーザー、ビジネスルール、成功条件を決めることはできない。
回避策
改訂する前に、ユーザー1人、仕事1つ、測定可能な成果1つを書く。
ストア公開の準備が整っていることを保証するものではない
検査済みのコンセプトは、プラットフォームのチェック、メタデータ、プライバシーの詳細、コンプライアンス対応を含む完成済みの提出物とは異なります。
回避策
アプリストアのチェックリストを、後のリリースゲートとして使用します。
曖昧なブリーフ
検証可能な方向性
有用な変化は、魔法のような変換ではありません。自由度の高いアイデアから、レビュー可能な方向性へ、より明確に引き継げるようになることです。
選択肢表
この比較を使って、次のステップとしてブラウザファーストの進め方が適切か、それとも作業がすでに、より本格的な実装環境に属するものかを判断してください。
- ブラウザファーストのワークフロー
- ローカルファーストのワークフロー
開始地点
ブラウザファーストのワークフロー
簡潔なプロダクトブリーフと、確認する対象を小さく絞った範囲から始めます。
ローカルファーストのワークフロー
インストール済みのプロジェクト、そのファイル、既存の開発環境から始めます。
フィードバックループ
ブラウザファーストのワークフロー
方向性をすばやく確認し、気づいた点を次の依頼に反映します。
ローカルファーストのワークフロー
コードまたは設定を変更してから、プロジェクトを再度実行します。
デバイス対応範囲
ブラウザファーストのワークフロー
初期の構成確認には役立ちますが、実際のデバイスでのチェックは引き続き必要です。
ローカルファーストのワークフロー
ローカル環境とデバイスでのテストにすでに対応できているチームに、より適しています。
バックエンドに関する判断
ブラウザファーストのワークフロー
サービス、データ、統合に関する課題を、未完了の作業として見える状態に保ちます。
ローカルファーストのワークフロー
プロジェクトで選択したサービスとデータの構成内で、直接作業します。
最適な段階
ブラウザファーストのワークフロー
アイデアの具体化、フローの確認、さらに深く取り組む価値があるものの判断。
ローカルファーストのワークフロー
実装、デバッグ、統合、リリース準備。
主なリスク
ブラウザファーストのワークフロー
明確なプレビューを完成したプロダクトだと勘違いすること。
ローカルファーストのワークフロー
ユーザージャーニーが固まる前に、実装に時間を費やしてしまうこと。
最初のアイデアを、より明確な次のステップに変える
まずは、1つのオーディエンス、1つの目的、1つの重要な導線から始めましょう。Rorkは方向性の確認をサポートできます。一方で、残りのプロダクトとプラットフォームに関する判断は明確にしておきましょう。
ワークフローを試す- 焦点を絞った概要から始める
- 重要な導線を確認する
- プラットフォームの確認を分けて行う
よくある質問
ブラウザ中心のワークフローでRorkを使い、アプリのアイデアを具体化して確認することを指します。この言葉は、すべての提供作業がブラウザ上で行われることの証明ではなく、画面または開始地点として理解するのが適切です。
ブラウザファーストのセッションは、概要の準備、初期段階の方向性の確認、メインフローの不足点の特定に役立ちます。ただし、デバイスの挙動、サービス、リリース要件については、それぞれの検証を担う環境で引き続き確認する必要があります。
提案したユーザージャーニーが理解しやすいか、また最初の画面セットが提示された目的に合っているかの検証には役立ちます。ただし、それだけでパフォーマンス、バックエンドの信頼性、デバイスの挙動、ストアのコンプライアンスを検証することはできません。
明確な対象ユーザー、主要なタスク、必要不可欠な画面、そして確認したい成果を1つ用意してください。データ、連携、制約事項の短いリストも、次の Rork の改訂をより具体的にします。