予定どおりに公開されたプロジェクトを思い浮かべてください。サイトは速く、デザインはすっきりしていて、コードも整っています。半年後、「これは何を変えるためのものだったのか」と聞かれても、すぐに答えられる人がいません。
多くのデジタルプロジェクトは、このようにして失敗します。派手に壊れるのではなく、動くのに意味を持たない製品が残るのです。原因はほとんどの場合、デザインもコードも存在しない最初の数回の打ち合わせで決まっています。成果が出るプロジェクトとそうでないプロジェクトを分けるのは、次の4つの判断です。
1. 課題を、平易な言葉で言い表す
うまく進むプロジェクトは、「スタッフが同じ注文を2つのシステムに打ち直している」「お客様がスマートフォンで予約フォームを途中で離れてしまう」といった一文から始まります。フレームワークの名前は必要ありません。
そのうえで、率直な質問にいくつか答えます。毎週最も時間を取られている業務はどれか。お客様はどこで諦めているのか。月曜の朝にチームが見たいのに見られないものは何か。そして、よく飛ばされる質問です。公開から3か月後、成功したとどうやって判断するのか。答えが「なんとなく良くなった気がする」なら、まだ目標がありません。週あたりの削減時間や予約の完了数など、1つか2つの数字を決めて書き留めてください。
2. 使う人にとって、シンプルにする
予約アプリや社内ダッシュボードのマニュアルを読む人はいません。人はタップし、スクロールし、迷った瞬間に離れていきます。良い製品は、探しているものにすぐたどり着け、少ない手順で終えられ、ボタンを押した後に何が起きたかも分かります。失敗したときには、何が問題だったのかを示します。決済が通らなかったからといって、注文内容を最初から入力し直させるべきではありません。
シンプルとは、機能を削ぎ落とすことではありません。数十の機能が必要なシステムもあり、その場合のデザインの仕事は、ユーザーがその瞬間に必要なものだけと出会えるように並べることです。
3. お客様に見えない部分を、先に計画する
きれいな画面の下には、間違っているときにだけ表面化する判断が積み重なっています。誰も画像を圧縮しなかったせいで重いページ。入力された内容をそのまま信用するログインフォーム。バックアップがなく、必要になった日に初めて気づくデータベース。
キックオフの場で話して楽しい内容ではないので後回しにされがちですが、後回しにした分だけコストが膨らみます。公開後にセキュリティを追加したり、コードの構造を作り直したりするより、最初のスプリントから計画しておくほうがずっと安く済みます。何かが壊れたときにお客様より先に気づけるよう、監視も整えます。
4. 公開は終わりではなく、途中経過と考える
実際に人が使い始めると、要件定義書には書けなかったことが見えてきます。誰も見つけないボタン、半数が途中でやめるフォーム、誰も触らない機能。アクセス解析や、お客様と社内チームからの直接のフィードバックが、どこを見るべきかを教えてくれます。
適切な対応が全面的な作り直しであることはめったにありません。いちばん大きな問題を直し、効果があったか確認し、次の問題に進みます。優先順位は、声の大きさではなく事業への影響で決めてください。
SUMの進め方
ウェブサイト、モバイルアプリ、Shopifyストア、社内システムのどれでも、この考え方で進めています。最初にヒアリング、次に設計、その後は短いスプリントで開発し、公開後もサポートを続けます。解決する価値のある課題をお持ちなら、SUMのウェブ・モバイル開発サービスをご覧いただくか、次のプロジェクトについてお問い合わせください。