困りごとを、一つの作業まで小さくする

「勉強を便利にする」「Web制作を簡単にする」のような広い目標では、必要な機能が際限なく増えます。そこで、実際に手が止まった作業を一つ選びます。

  • 家庭学習に合う問題条件を毎回長文で書くのが難しい。
  • HTMLを作った後、サーバーのどこへ送るか分かりにくい。
  • 平面画像から簡単な立体データを試すまでの準備が多い。
  • 短期の連絡なのに、会話が長期保存され続ける。

対象を絞ると、必要な操作と不要な機能を分けられます。

利用者にとっての「完了」を決める

サービス側で処理が成功しても、利用者の目的が終わっていなければ完了ではありません。FTPなら転送完了だけでなく、公開URLで表示を確認するまで。3Dデータなら書き出しだけでなく、スライサーで形状を確認するまでを一つの流れとして考えます。

1開始前

必要なデータ、権限、保存先、利用条件が分かる。

2操作中

今どこにいて、次に何をするか画面から判断できる。

3完了後

結果を開き、目的どおりか自分で確かめられる。

4失敗時

入力や接続のどこを見直すか案内がある。

正しい操作より先に、間違えやすい操作を洗い出す

テストでは成功する一本道だけでなく、空欄、形式違い、通信切断、同じ操作の連続実行、保存先の誤りを確認します。特に、データの上書き、削除、決済、ポイント付与のように元へ戻しにくい操作は、確認画面と二重処理防止が必要です。

対象確認する失敗案内する内容
家庭学習AI条件不足・誤答・学年外保護者確認と問題を使わない判断
FTP接続先違い・上書き・秘密情報の公開バックアップと公開URL確認
3Dデータ輪郭不良・薄すぎる形状・造形範囲外素材修正とスライサー確認
期間制チャットURL誤送信・合言葉忘れ・期限切れ別経路共有と終了前の保存確認

保存する前に、保存しなくてよい情報を決める

データを多く集めるほど便利になる場合もありますが、漏えい、誤送信、削除依頼への対応も増えます。サービスの目的に不要な個人情報は入力させず、保存期間を決め、外部サービスを利用する場合は関係を説明します。

  1. サービス提供に本当に必要な情報か。
  2. 端末内だけで処理できないか。
  3. いつ削除するか利用者へ説明できるか。
  4. 外部サービスへ送る情報が明確か。
  5. 利用者が自分で確認・修正できるか。

機能、使い方、注意事項を同時に公開する

短い紹介文だけでは、利用者は自分に向いているか判断できません。そのため、操作手順だけでなく、向いている場面、向いていない場面、データの扱い、結果の確認方法も掲載します。

公開後は、不具合の修正だけでなく、説明と実際の動作が一致しているかを確認します。機能を変更した場合は、利用規約・プライバシー・使い方・サイトマップの更新漏れも確認します。

元データを残し、変更履歴を分ける

まひとつ開発では、公開物を更新するときに元の版を直接上書きせず、新しい連番フォルダへ複製して作業します。簡単な修正はパッチ、新機能はマイナー、大幅な正式更新はメジャーとして、三層のバージョン番号で記録します。

この方法は、変更前後を比較し、問題が起きたときにどの版から発生したか確認するための運用ルールです。

← 使い方と読みものへ戻る