アイデアから始める
大まかなコンセプト、いくつかの画面のイメージ、またはモバイルアプリで解決したい課題はあるものの、まだプロジェクトがない状態です。
ビルダーを開き、最初のバージョンを1つの目的に絞って説明し、iPhoneで確認できる少数の画面を作成するよう依頼してください。
rorkの使い方iPhoneチュートリアル
プロンプトからプレビューまで、iPhoneでrorkを使う方法
このiPhoneでrorkを使う方法のガイドでは、スマートフォンで始める場合でも、別の場所でプロジェクトを続ける場合でも、アプリのアイデアから動作するプレビューまでの最もスムーズな進め方を紹介します。
自分に当てはまるケースを判断する
適切なiPhoneワークフローは、現在のプロジェクトの状況によって異なります。長いプロンプトを書いたり、プレビューの問題を解決したりする前に、最も近い開始地点を選んでください。
既存のビルドを続ける
すでに生成済みのプロジェクトがあり、iPhoneで確認したり、フローをテストしたり、別のプロンプトで画面を改善したりしたい状態です。
リクエストを絞り、新しいプレビューを以前のものと比較し、一度に1つのインタラクションだけを変更してください。
rorkの使い方Android向けに作成したプロジェクトを確認する
別のモバイルプラットフォーム向けにプロジェクトを作成またはテストしており、iPhoneでは何が変わるのかを理解したい状態です。
iPhoneを別のテスト環境として扱い、同等だと決めつけずに、レイアウト、ナビゲーション、権限、キーボードの動作、タップ領域を確認してください。
Androidでrorkを使う方法クライアントのコンセプトを検証する
本格的なプロダクション開発に投資する前に、クライアント、チームメイト、またはステークホルダー向けに、すぐに確認できる具体的なデモが必要です。
短いプロンプトを使い、1つの完全なユーザージャーニーを実演し、デザインまたはエンジニアリングによるレビューがまだ必要な判断事項を記録します。
rorkアプリビルダーパスA：iPhoneで新しいアプリを始める
プロジェクトがまだ存在しない場合は、このパスを選択します。目的は、将来のすべての機能を細かく指定することではなく、実際に確認できる、まとまりのある最初のバージョンを作成することです。
-
1
ビルダーを開き、1つの成果を明確にする
アプリの主な目的から始めます。たとえば、予約を取る、習慣を記録する、現場のメモを集める、ワークアウトを整理するなどです。想定ユーザー、主要なアクション、そして最小限役立つ結果を明確にします。焦点を絞った概要のほうが、関連性のない機能のリストよりも、最初の生成結果の方向性を明確にできます。
-
2
具体的なモバイル向けプロンプトを書く
最初の画面、次のアクション、各画面に表示すべき情報、ビジュアルの方向性を説明します。下部ナビゲーションバー、読みやすい文字、大きなタッチターゲット、狭い画面でも快適に使えるレイアウトなど、iPhone向けの詳細にも触れます。空のプレースホルダーではなく、現実的なサンプルコンテンツを使うよう依頼します。
-
3
プレビューを確認し、1つの点を改善する
最初のバージョンが表示されたら、ユーザーになったつもりで主要なジャーニーを進めます。わかりにくいラベル、詰め込まれたコントロール、空の状態の不足、次に何が起こるかを説明していないアクションを探します。一度に1つの優先事項だけを変更するフォローアッププロンプトを送り、iPhoneで再度結果を確認します。
パスB：既存のプロジェクトをテストして改善する
すでに確認したいプロジェクトがある場合は、このパスを選択します。iPhoneでの確認は、開始画面だけを見るのではなく、実際のフローをテストすると最も役立ちます。
スマートフォンのプレビューは本番リリースではない
生成されたプレビューは構造やインタラクションの検証に役立ちますが、アプリがApp Storeの審査、プライバシー上の義務、アクセシビリティチェック、または本番環境のモニタリングに対応できる状態であることを自動的に証明するものではありません。
回避策
リリースチェックリストを作成し、配布前に適切なデザイン、エンジニアリング、コンプライアンスのレビュアーを関与させます。
iPhoneだけでは、すべてのデバイスの問題を明らかにできない
1台のiPhoneでは、すべての画面サイズ、OSバージョン、ネットワーク状況、権限の状態、または古いデバイスを代表することはできません。あるモデルでは問題なく感じられるレイアウトでも、別の環境では正常に動作しない可能性があります。
回避策
重要なジャーニーを複数のビューポートでテストし、接続状態が悪い場合、データが空の場合、長いテキスト、拒否された権限、中断されたセッションも含めます。
長いプロンプトでプロダクト上の判断を代替することはできない
1つのリクエストに要件を追加しすぎると、どの変更が新たな問題の原因になったのか判断しにくくなります。ビルダーは構造を提案できますが、優先順位、ポリシー、エッジケースの動作を代わりに決めることはできません。
回避策
作業を短い反復に分けます。まずナビゲーション、次に主要なアクション、その後にメインフローがしっかりしてから状態と仕上げを整えます。
デバイス機能には明示的な検証が必要です
カメラへのアクセス、通知、位置情報、サインイン、決済、ディープリンク、バックグラウンド動作には、ビジュアルプロトタイプの確認だけでなく、設定やプラットフォーム固有のテストが必要になる場合があります。
回避策
すべてのデバイス機能を事前に一覧化し、表示されるボタンを機能が動作する証拠とみなすのではなく、それぞれを個別のテストで検証します。
最終確認
プロジェクトを共有する前に、毎回同じ簡単な確認を行います。ここに挙げるのはチェックポイントであり、ビルダーが自動的に完了させる内容を示すものではありません。
- 開始画面から成功した結果に至るまで、主要なジャーニーをたどります。
- 01 フロー
- 主要なアクションについて、読み込み中、空の状態、エラー、完了の各状態を確認します。
- 02 状態
- タップ領域、テキストの折り返し、キーボードの動作、安全領域の余白を確認します。
- 03 表示
- 未解決のプロダクト、プラットフォーム、プライバシー、リリースに関する判断事項を書き留めます。
- 04 質問
iPhoneのアイデアをテスト可能な最初のバージョンに変える
役立つジャーニーを1つから始め、それを平易な言葉で説明し、プレビューを使って変更が必要な箇所を見つけます。rorkは、各プロンプトに明確な目的があり、すべてのiPhoneレビューが具体的な次の判断で終わるときに最も効果を発揮します。
iPhoneプロトタイプを作成する- ユーザーと主な成果を説明する
- デバイスで最初のモバイルフローを確認する
- 一度に1つのインタラクションを改善する
チュートリアルFAQ
これらの回答では、iPhoneを中心としたワークフローを始める際に多くの人が通常抱く実践的な疑問を取り上げます。
はい。アイデアを説明し、生成された体験を確認し、追加の指示を出す場所としてiPhoneを使えます。詳細な編集、デバッグ、プロジェクト管理には、より大きな画面のほうが快適な場合があります。
アプリの対象者、解決する主な課題、最初に行う操作、その操作を完了するために必要な画面を明記します。シンプルなナビゲーション、読みやすいテキスト、わかりやすいタップ領域、現実的なサンプルデータなど、モバイル向けの希望も加えましょう。
デバイスでプロジェクトのプレビューを開き、手順を飛ばさずに主要な操作の流れを完了します。キーボード、スクロール、タップ領域、テキストの折り返し、読み込み時の動作、空の状態、リクエストが失敗したときの挙動を確認してください。
いいえ。iPhoneでのテストでは、重要なユーザビリティやレイアウトの問題を発見できますが、リリース、プライバシー、アクセシビリティ、セキュリティ、複数デバイスでのテストの代わりにはなりません。プレビューは最終承認ではなく、改善のための根拠として扱いましょう。
該当する画面、操作、確認された問題を正確に説明し、1つに絞った変更を依頼します。更新後に同じ操作の流れを再確認し、後のプロンプトで関係のない修正が混ざらないよう、未解決の問題を短いリストにまとめておきましょう。