プロダクトチームのワークフロー
チームで構築できるソフトウェアのアプリデザインを計画する
要件、画面スケッチ、エンジニアリング上の疑問が別々の場所にあると、ソフトウェアチームのアプリデザインはより難しくなります。まずはブラウザファーストのデザイン案を作成し、全員が同じフローと未解決の決定事項について議論できるようにしましょう。
このシナリオの課題：画面間に隠れた決定事項
洗練された画面でも、その前後に何が起こるのか、または問題が発生したときにどうなるのかについて、チームに不確かさが残ることがあります。
共有デザイン案のための3つの具体的なワークフロー
ソフトウェアのアプリデザインは、孤立したモックアップの集まりではなく、一連の決定事項として進めます。各ワークフローでは、次のレビュアーが確認できる成果物を作成します。
-
1
1つのユーザータスクをマッピングする
プロジェクトにチームメンバーを招待するなど、範囲を絞った成果を選びます。画面を配置する前に、開始地点、必要な情報、成功メッセージ、起こりそうな中断を一覧にします。プロダクトマネージャーはスコープを確認でき、エンジニアは不足しているシステムの挙動を指摘できます。
-
2
つながった状態を下書きする
そのタスクのデフォルト、空、読み込み中、エラー、成功の各状態をスケッチします。下書き全体でラベルとナビゲーションの一貫性を保ちます。このアプリデザインの工程では、インタラクションが実装済みである証拠として画像を扱うことなく、早い段階で不足を可視化できます。
-
3
レビューして決定事項を記録する
デザイン、エンジニアリング、関係するプロダクトオーナーと一緒に下書きを確認します。どのテキスト、権限、データフィールド、エッジケースが未解決のままかを記録します。画面を修正したうえで、次の引き継ぎが記憶に頼らずに済むよう、別の決定事項ログを残します。
成果物の例：ラフなワイヤーフレームからレビュー可能なコンセプトへ
プロジェクトへの招待フローを想像してみましょう。有用な成果物は招待画面だけではありません。誰かがどのように開始し、送信し、成功し、エラーから復旧するのかを示す、つながったコンセプトです。
これらの画像はアプリデザインの各段階を示すものであり、リンク先の製品で確認されたコンバージョンや、検証済みの成果物を示すものではありません。実際の招待フローでは、誰が招待を送信できるか、リンクの有効期限が切れた場合にどうなるか、配信に失敗した場合にどのメッセージが表示されるかを注記してください。
初期レイアウトの参考資料レビュー用ドラフトの参考資料コンプライアンス上の注意点：デザイン案では検証できないこと
ブラウザー上で作成したコンセプトは、ソフトウェアチームが検討すべき点を明らかにするのに役立ちます。ただし、リリース前に必要な専門家によるレビューや実装の検証に代わるものではありません。
セキュリティ承認ではない
画面だけでは、認可、セッション管理、保存データの安全性は確認できません。分かりやすい権限ダイアログでも、バックエンドのルールに未解決の点が残っている可能性があります。
代わりにすべきこと
セキュリティとエンジニアリングの責任者に、想定される権限を確認し、実装された動作をテストしてもらってください。
アクセシビリティの認証ではない
読みやすく見えるレイアウトでも、実際に動作する製品でのキーボード操作、スクリーンリーダーによる読み上げ、フォーカス順序、十分なコントラストは証明できません。
代わりにすべきこと
操作に関する要件を文書化し、実装されたインターフェースをアクセシビリティツールとユーザーによってテストしてください。
法務・プライバシー上の判断ではない
同意を求める文言やデータ入力画面だけでは、データの収集、保持、開示の方法が組織の義務を満たしているかは確認できません。
代わりにすべきこと
適切なプライバシーまたは法務の担当者に、実際のデータフローと最終的な文言を確認してもらってください。
ドラフトで示せることと、リリースに必要なこと
この比較を使い、アプリデザインのレビューを本番リリースの承認と混同しないようにしてください。
| ブラウザー上で作成したデザイン案 | レビュー済みのソフトウェア実装 | |
|---|---|---|
| ユーザーの利用フロー | 選択した画面と状態を通る、想定上の経路を示します。 | 実際に動作する画面遷移と現実の条件に照らして、その経路を確認します。 |
| 権限 | チームがサポートする予定の役割とアクションを明確にします。 | アプリケーションでそれらのルールを適用し、テストします。 |
| エラー処理 | 想定されるメッセージと、可能な復旧アクションを記述します。 | 障害を発生させ、復旧が機能することを確認します。 |
| アクセシビリティ | 想定されるラベル、フォーカスの動作、操作に関する注記を記録します。 | 支援技術を使って、実際に表示された画面での体験をテストします。 |
| データとプライバシー | 各フィールドと、その用途に関する疑問点を洗い出します。 | 実際の収集、保存、保持、アクセスを確認します。 |
| 引き継ぎ | 未決定のプロダクト上の事項をレビュー担当者に見えるようにします。 | 開発、テスト、リリースを通じて決定事項を追跡します。 |
議論を具体的な次のステップにつなげる
チームで明確にする必要があるタスクを1つ選び、その画面と未解決の疑問点を、ブラウザを起点としたデザインワークフローに取り込みましょう。成果物は議論の材料として扱い、完成と判断する前に、実装、アクセシビリティ、セキュリティ、プロダクトの意思決定を担当する人たちと確認してください。
ソフトウェアプロダクトチームのよくある質問
1つのユーザータスクと、それによって達成すべき結果から始めます。視覚的な詳細を詰める前に、開始点と主な状態を整理しましょう。そうすれば、レビュー担当者は画面間の動きを推測するのではなく、実際の動作について話し合えます。
プロダクトオーナー、デザイナー、実装上の制約に詳しい担当者を交えましょう。アクセシビリティ、セキュリティ、プライバシー、法務に関わる疑問が生じる場合は、それぞれの担当者にも確認を依頼してください。草案は議論のための資料であり、担当者の承認を意味するものではありません。
いいえ。画面は想定する操作を伝えられますが、すべての業務ルール、データの依存関係、エラーが起きる条件まで表せるとは限りません。ビジュアルの草案と併せて、決定事項と受け入れ基準を文書に残してください。
画面間のつながりと各画面の状態、想定する画面遷移、関連する文言、未決事項とその担当者の一覧を渡してください。エンジニアには、適用される技術要件と、開発中に生じる疑問を解決する方法も必要です。