アイデアから成功するアプリへ：戦略・UX・デザインの融合

良いアイデアでも、使われるとは限らない

アプリのアイデアは、最初は期待に満ちていることがよくあります。「こんなアプリがあれば、みんな使うはずだ」と。そして、プロジェクトでは残念ながらよくある展開が待っています。開発され、リリースされるものの、その後は静まり返ってしまいます。レビューはなく、再び使ってくれるユーザーもほとんどおらず、やがて更新も途絶えてしまいます。

市場には、こうした静かな終わりがあふれています。Business of Appsによると、2年以上更新されていない放置されたアプリは約1.86百万件あります。Business of Apps (Pixalate, 2022)↗ この数字は単なる統計ではなく、ひとつの傾向を示しています。多くのアプリは、派手に失敗するわけではなく、 しかし、関与が不足しているためです。

なぜでしょうか。そのアイデアが「悪い」から、ということはめったにありません。多くの場合、早すぎる段階で解決策として捉えられてしまうからです。しかし、アプリは機能の寄せ集めではなく、一連の意思決定です。どのような人たちに届けたいのでしょうか。本当に解決しようとしている問題は何でしょうか。気軽に使い始められる最初の体験は、どのようなものでしょうか。 では、何かがうまくいかないときはどうなるのでしょうか？

継続率については、厳しい現実もあります。業界全体の平均30日継続率は、多くの場合わずか2–4 %です。Business of Apps (2025)↗ これは「すべてのアプリに未来がない」という意味ではありません。つまり、最初の1か月には容赦なく実態が表れます。オンボーディングがわかりにくい場合、 動作がカクついたり、アプリに実質的な価値がなかったりすると、すぐにアンインストールされます。

私たちの最も重要な気づきは、成功は最後のスプリントで生まれるのではなく、最初のスプリントが始まる前に決まるということです。戦略、UX、デザインが別々に進むと、摩擦が生じます。デザインは、技術的な実装に高いコストがかかるものを約束してしまいます。開発は、後になって不要だと判明するものを作ってしまいます。 そしてブランディングは、最後に「化粧」として加えられます。

朗報です。より早い段階で問いを立て、より明確に検証し、推測を減らすプロセスによって、これは避けられます。

明確なビジョンがすべての機能判断を整理する

誰かが私たちのところに来て「アプリを作りたいです」と言うと、私たちはほぼ必ず、まず別のことを尋ねます。「将来、どんな成果につながれば、アプリを作るという判断が正しかったと言えますか？」 哲学のように聞こえますが、実際にはとても実用的な問いです。なぜなら、目指す姿がなければ、 どの機能についての議論も、直感頼みになってしまうからです。

このために、私たちは社内でよく「Three-Sentence Strategy」と呼ぶ手法を使います。会話の中で試せるほどシンプルでありながら、曖昧さを浮き彫りにできるほど厳密な手法です：

1) 誰のためのアプリで、どのような状況で使いますか？

2) この人は2分以内にどのような成果を達成できるべきですか？

3) なぜこれがあなたのビジネス（またはプロジェクト）に関係するのですか？

この三つの文がしっかり定まると、妥当な判断はほぼおのずと導かれます。MVPに何を含め、何を含めないのでしょうか？正しい方向に進んでいるかを示す指標は何でしょうか？最大のリスクは、需要不足、過度な複雑さ、信頼性の不足のどれでしょうか？

実務で私たちが重宝している2つ目のツールは、Risk Mapです。Excelシートとしてではなく、ストーリーとして使います。まず、アプリの「最悪のシナリオ」を一度書き出します。たとえば、「ユーザーがインストールするものの、メリットを理解できず、オンボーディング中に離脱し、評価が悪くなり、チームが意欲を失う」といったストーリーです。 次に、文ごとにストーリーを逆転させます。逆のことが起こるには、何が必要でしょうか？ こうすることで、初回アクティベーションの改善、価値提案の明確化、読み込み時間の短縮、プライバシーに関するわかりやすい説明といった具体的な課題が生まれます。

そして、そうです。UXはすでにここから始まります。最初の画面だけでなく、アプリがどの真実を伝えるべきかという判断から始まるのです。

業界の小さな事例を見ると、これが具体的にわかります。Amazonは、一見小さな変更、つまり障壁となっていた「登録」をなくしてゲスト購入を可能にすることで、莫大な追加収益を生み出したと言われています。Incarabia (Amazon UX Story)↗ 個々のケースでその数字に議論の余地があるかどうかはさておき： 方向性は正しいです。明確な戦略があれば、早い段階でユーザーに多くを求めすぎずに済みます。

戦略が定まれば、「アプリを作っています」という言葉が、重点、成功基準、現実に即した優先順位を備えた、それ自体で成立する計画になります。

想定は実際の人を通じてこそ確かなものになる

ほぼすべてのアプリのアイデアは、想定から始まります。それは普通のことです。危険になるのは、想定を事実として扱うときだけです。

だからこそ私たちは、「調査のための調査」ではなく、日常に根ざしたディスカバリーフェーズから始めることを大切にしています。実際にクリックしたり、スワイプしたり、離脱したり、使い続けたりすることになる人たちに話を聞きます。求めているのは褒め言葉ではなく、使ううえでのつまずきです。

私たちは、現場で検証した2つ目の手法を「5つのタスク、5人の参加者」と呼んでいます。初期段階でも使えるように、あえて小規模にしています。クリックして操作できるごくシンプルなフローを作成し（多くの場合、Figmaを使います）、テスト参加者に5つの典型的なタスクを提示しますが、 それぞれ2分以内に解決できるものにします。例えば、「Xを最も速く完了する方法を見つける」「Yにかかる費用を把握する」「設定を変更する」「サポートを受ける」「エラーなく手続きを完了する」などです。その後に尋ねるのは、「気に入りましたか？」ではなく、「何を期待していましたか。そして、実際には何が起きましたか？」です。

なぜ5人だけなのでしょうか？ 初期段階で必要なのは、統計的な確証ではなく、パターンだからです。5人中3人が同じ箇所でつまずくなら、それはもはや意見の問題ではなく、明確な兆候です。

そして、見落とされがちな点がもう一つあります。ユーザーは不満を感じても、それを口にすることはめったにありません。 よく引用される調査によると、不満を抱くユーザーの96 %は積極的に苦情を伝えず、ただ離れていきます。Userpilot (UX Statistics)↗ 実際には、これは次のことを意味します： フィードバックが自然に届くのを待っているなら、待ちすぎです。

だからこそ、私たちにとってDiscoveryは、単に完了のチェックを付けるだけの「Phase 1」ではありません。アプリの方向性が定まる瞬間なのです。インタビューは仮説になり、仮説は初期のUser Journeysになります。そして、そのジャーニーから、後にインターフェース上でごく当たり前に感じられるものが生まれるのです。

ここで丁寧に取り組めば、後々のコストを節約できるだけでなく、「なぜ実際には誰もこれを使わないのか」という、チームにとって非常にストレスのたまる議論も避けられます。

製品の品質を具体的に捉える7つの視点

私たちが「良いUX」と言うとき、それは「美しい」という意味ではありません。言葉で説明できるようになる前に、感覚でわかる品質を意味します。これを具体的に捉えるために、私たちはPeter MorvilleのUX Honeycombに基づくフレームワークを活用しています。7つの視点が組み合わさることで、一貫性のある体験を生み出します。 Purple Griffon (Morville UX Honeycomb)↗

有用性： アプリが実際の問題を解決します。当たり前に聞こえますが、最もよく欠けている点です。特に、すでに「似たアプリ」がある場合はそうです。

使いやすさ： 説明がなくても目的を達成できます。「ここでこれをどうするか」を説明する必要がある時点で、操作の流れのどこかに問題があります。

見つけやすさ： 機能が期待どおりの場所にあります。これはナビゲーションや検索だけでなく、手順の順序にも当てはまります。

信頼性： ユーザーはあなたを信頼します。それは認証があるからだけではなく、アプリの言葉遣い、デザイン、動作に一貫性があるからです。研究から得られた興味深い知見として、第一印象の大部分はデザインによって形成されます。Userpilot (UX Statistics)↗

魅力的: アプリからあなたらしさが感じられます。動き、語り口、マイクロコピー、そして信頼を育む小さな瞬間を通じて、ここでブランドに命が吹き込まれます。

アクセシビリティ対応: 2025年以降、EUでは多くの場面でアクセシビリティ対応が必須となっています。法的に義務付けられていない場合でも、より多くの人に利用してもらえるようになり、製品の堅牢性も高まります。

価値: 最終的に、アプリは双方の役に立つ必要があります。ユーザーは価値を得て、あなたのプロジェクトは目標を達成します。まさにここで、戦略とUXが交わります。

私たちならではの新鮮な視点、そして「隠し味」の一つは、これらの柱を最後に確認するチェックリストではなく、プロジェクト全体を通じた意思決定のフィルターとして扱うことです。ある機能について議論するとき、私たちは「その機能は、どの柱を本当に強化するのでしょうか？」と問いかけます。答えがはっきりしない場合は、 この機能は通常、まだ準備が整っていません。

もう一つ、良いUXは無駄を防ぎます。うまく機能しないことに気づくのが遅くなるほど、修正にかかるコストは高くなるからです。よく引き合いに出される目安として、リリース後のバグ修正は、構想段階での修正に比べて何倍も高くつくことがあります。Userpilot (UX Statistics)↗

この7つの柱は、品質を語るための言葉を与えてくれます。そして、資金をコードに変える前に、何に目を向ければよいかを示してくれます。

ブランドは一つひとつのやり取りでつくられる

多くのチームは「アプリが完成してから」初めてブランディングについて考えます。そこでロゴを配置し、色を調整し、場合によってはイラストをいくつか追加します。その結果、完成した製品にステッカーを貼り付けただけのように感じられることがよくあります。

私たちは違うやり方をします。私たちにとってブランディングとは、誰かが何かをしているときに、信頼がどのように感じられるかという問いです。アプリでは、それはホームページではなく、個々の瞬間に表れます。エラーメッセージはどのような語り口ですか？価格をどのように説明しますか？ エンプティステート（「プロジェクトはまだありません」）はどのくらい親しみやすく、次のステップはどのくらい明確ですか？

とても人間味があるので、私たちがよく紹介する事例があります。2009年、Airbnbは信頼の問題に直面していました。突破口となったのは新機能ではなく、より良い写真でした。創業者たちが自らアパートの写真を撮影したところ、予約が大幅に増加しました。 Passionates (Airbnb Design Story)↗ それこそがブランディングの本質です。信頼性と欲求は、体験の質から生まれます。

3つ目の新たな視点：UXツールとしてのブランドボイス。 初期段階でいくつかの文を定め、後にすべてのマイクロコピーの指針とします。たとえば、「明確に伝え、決してとげのある言い方はしません。説教せずに説明します。ユーザーに主導権を返します」といった文です。穏やかな方針に聞こえます。 しかし、インターフェースで唐突に突き放すような表現が出るのを防ぎます。

パーパスを軸にするブランドであれば、これはさらに重要になります。パーパスは主張ではなく、行動だからです。「公平」でありたいアプリは、ユーザーにオプトアウトの選択肢を分かりにくく提示すべきではありません。 「持続可能」でありたいアプリは、バックグラウンドで不必要にデータを読み込んだり、プッシュ通知を大量に送ったりすべきではありません。

実際には、これはブランディング、UX、プロダクトに関する意思決定を同じ場で行うべきだということです。だからこそ、私たちが構築するデザインシステムには、色やコンポーネントだけでなく、トーン・オブ・ボイスやコピーのブロックも含めています。細部の一貫性が、大きなインパクトを生むからです。

アプリがブランドらしさを感じさせるものであれば、多くを説明する必要はありません。ユーザーは自然に「ここは自分に合っている」と感じます。

最小限のバージョンで学びを得る

MVPはしばしば「安価な初期版」と誤解されます。私たちにとって、MVPはそれとは異なります。学びを得られる最小限のバージョンであり、何か月にもわたる遠回りに迷い込まずに済むものです。

典型的な落とし穴は二つあります。一つ目は、チームが「不完全」に見えることを恐れて、詰め込みすぎてしまうことです。二つ目は、チームが盛り込む内容を少なくしすぎて、誰も価値を実感できなくなることです。適切なバランスは、プロトタイプを通じて見つけます。そのプロトタイプは「美しい」必要はありませんが、誠実である必要はあります。

実際には、すぐに試せる3つのレベルで進めることをおすすめします。

1) クリック可能なプロトタイプをFigmaで、またはMazeのようなツールでテストします。目的：ユーザーはフローを理解できますか？

2) 価値を実感できる瞬間を備えたMVP：すぐに価値を感じられることを一つ提供します。十個の機能ではなく、一つの明確な成功体験です。

3) 計測ポイント: リリース後に実際に観測できる少数のイベントです（例：アクティベーション、主要タスクの完了、7日後の再訪）。

この点を重視することがなぜそれほど重要なのかは、現実を見ればわかります。アプリをインストールしても、使い続ける人はほとんどいません。30日目には、アクティブなユーザーはわずか数パーセントしか残っていないことがよくあります。Business of Apps (2025)↗だからこそ、最初の核となる体験が重要です。ユーザーがその体験にたどり着かなければ、 どれほど機能が揃っていても、成果につながらなければ単なる可能性にすぎません。

MVPは予算を守る盾にもなります。Forresterの分析は、UXへの投資が非常に高いROIをもたらし得ることを示していると、よく要約されます。Userpilot（UX統計、Forresterを引用）↗ これを実務に置き換えると、テストを早く行うほど、「無駄になる」ものを作らずに済むということです。

だからこそ、MVPを定義するときは、単に削るのではなく、凝縮します。そして、こう問いかけます。ユーザーが初めてアプリを開いた後に「なるほど、これは本当に役に立つ」と思うには、何が必要でしょうか。その実感を生み出せれば、MVP以上のものが手に入ります。それは、次へと進むための出発点になります。

読み込み時間と安定性もデザインの一部

テクノロジーは、その存在を意識させられるまでは目に見えないものです。ところが、ひとたび存在を意識すると、読み込み時間、動作のかくつき、クラッシュ、バッテリー消費が、突然UXの問題になります。そして、信頼の問題にもなります。

技術に関する判断が遅すぎるケースをよく目にします。まず、一連の画面を「完成形」としてデザインしてから、問題が明らかになります。アニメーション付きのダッシュボードに必要なデータを、現在のアーキテクチャでは十分なパフォーマンスで提供できないのです。あるいは、オフラインモードが重要なのに、まったく考慮されていなかったということもあります。

だからこそ、私たちは次のアプローチを取ります。デザインと開発は、順番にではなく、並行して進めます。 実現可能性、セキュリティ要件、保守性を早い段階で明確にします。これらは「技術的な細部」ではなく、プロダクトの一部として扱います。

始めたばかりなら、次の3つの質問が役立つことが多いです。

1) リスクはどこにありますか。フロントエンド（操作）、バックエンド（データ）、それとも連携（API）ですか。

2) ネイティブのパフォーマンスが必要ですか。それとも、ハイブリッド方式で十分ですか。

3) 運用はどのように行いますか。誰がコンテンツを管理し、誰がサポートの問い合わせに対応し、誰が更新を展開しますか。

特にMVPでは、「手っ取り早く、雑に」作りたくなりがちです。しかし、MVPが成功した場合に、すべてを作り直す羽目にはなりたくないものです。きちんとした土台を築いておけば、過去の自分の仕事に足を引っ張られずに済むため、後々の時間を節約できます。

ツールや技術スタックは、目的を達成するための手段です。Web向けのプロダクトでは、チームが自律的に運営できるよう、モダンで軽量なフレームワークと整理されたコンテンツ構造を採用しています。コンテンツを管理するなら、Payload CMSのようなヘッドレスシステムが、多くの場合、優れた基盤になります。ハイブリッドアプリの場合は、 Capacitorは、ウェブ技術を使いながらネイティブ機能も必要とする場合に、有効な選択肢になります。

そして、過小評価されがちな点がもう一つあります。パフォーマンスは贅沢ではありません。Googleのモバイル利用に関する調査では、ページの読み込みに3秒以上かかると、53 %のユーザーが離脱することがわかりました。Userpilot（UX Statistics、Google Benchmarkを引用）↗ アプリの仕組みは異なりますが、ユーザーが待てないのは同じです。最初の画面の表示で待たせると、 ユーザーを失ってしまいます。

ですから、技術は「デザインの後の工程」ではありません。それは、デザインしたものが後になっても同じように感じられるという約束です。

アクセシビリティは後になるとほぼ必ずコストが高くなる

アクセシビリティは、多くのチームが「後で」取り組みたいと考えることの一つです。問題は、後回しにするとコストが高くなることが多く、2025年以降はEUの多くの場面で法的にもその重要性が大幅に増していることです。

2025年6月以降、欧州アクセシビリティ法は、一部のデジタルサービスやアプリを含む多くの分野で法的拘束力を持っています。Xarxalia (EAA Überblick)↗ ご自身の製品が直接の適用対象でなくても、確認してみる価値があります。アクセシビリティは単なる法令遵守ではありません。品質そのものです。

プロジェクトを通じて気づくことがあります。アクセシビリティを「標準」として扱うようになると、多くのデザイン上の判断がしやすくなります。「コントラストは後から高められますか？」と考えるのではなく、最初からアクセシビリティをしっかり確保できる色、タイポグラフィ、状態を選ぶようになります。ボタンも、親指で押しやすいように作ります。 スクリーンリーダーがアイコンを理解できるように、ラベルを付けます。また、文章は単に気の利いた表現にするのではなく、わかりやすく書きます。

アクセシビリティに配慮して設計されたアプリは、たいてい、ほかの誰にとっても使い心地がよくなります。推測する必要が少なく、隠されているものも少なく、混乱しにくいからです。それが、インクルーシブデザインの静かな強みです。

実践的な出発点をお探しなら、細部に入る前に次の3つを確認すると役立つことが多いです。

1) 屋外の日差しの下でも、コントラストと文字サイズは読みやすさを保てていますか？

2) スクリーンリーダーのナビゲーションを使って、アプリを実用的に操作できますか？

3) エラーメッセージは分かりやすく、解決方法を示していますか？

ツールとしては、すぐに自分で試せる定番をおすすめします。コントラストを確認できるWebAIM Contrast Checkerや、さらに詳しく知るための参考資料であるWCAGなどです。

Polaでは、アクセシビリティはやることリストの最後に置くものではありません。製品のDNAに組み込むべきものです。なぜなら、「すべての人がアクセスできること」は、単なる取り組みではなく、姿勢であり、ひいてはより良いUXを意味するからです。

無駄のない製品は、より良い製品であることが多い

アプリ開発プロジェクトでは、サステナビリティは「時間があれば、後で最適化しましょう」と、付加的な課題として扱われがちです。私たちは、むしろ逆だと考えています。Green UXは追加のレイヤーではなく、優れたプロダクト思考の試金石です。

そもそも、無駄のないアプリとはどのようなものでしょうか。読み込む量が少なく、スクロールが少なく、不要なアニメーションの再生が少なく、やり取りするデータ量が少ないアプリです。それは気候にとって良いだけでなく、ユーザーにとっても良いことです。動作が速く、落ち着いて使えて、バッテリー消費も少なくなります。

ウェブに関する数値は、デジタル利用による排出量がいかに速く積み重なるかを示しています。平均的なウェブサイトでさえ、日常的に利用すると、無視できないCO₂排出量につながることがあります。Happy Eco News (Website Carbon Footprint)↗ アプリはウェブサイトとは異なりますが、基本的な仕組みは同じです。データ処理や計算処理にはエネルギーが必要です。

ここでの「Pola」という視点は、意図的にミニマルなものです。私たちは、転送量を減らし、より多くを伝えることを目指しています。具体的には、アプリのプロジェクトでは、多くの場合、次のようなことを意味します。

• メディアは価値をもたらす箇所にのみ使用し、適切に最適化。
• 「せわしなく」見せず、状況をわかりやすく伝える読み込み表示。
• 適切な場合にオフラインで動作する機能。
• 責任に配慮したインフラ（例：可能な場合は環境に優しいクラウドの選択肢を採用）。

Green UXはPurposeにも直接つながっています。人々がより持続可能な行動を取れるよう支援するアプリなら、アプリ自体も無駄を生むべきではありません。厳しく聞こえるかもしれませんが、むしろ自由をもたらす考え方です。機能の詰め込みすぎや、ただ「目を引く」ことだけを狙ったデザインに陥るのを防いでくれます。

ここでも同じことが言えます。持続可能性は単なる理想論ではありません。製品の品質そのものです。無駄を省いたアプリは保守しやすく、より安定して運用でき、ホスティング費用も安くなることが多いです。

2年後もアプリが「放置されている」ように見えず、きちんと保守され、動作が速く、ユーザーに配慮したものであってほしいなら、Green UXは良い出発点です。流行としてではなく、あらゆる意思決定に表れる考え方として取り入れるのです。

実際の利用が始まるのはストア公開日を過ぎてから

ローンチはゴールのように感じられます。実際には、ようやく本当の答えが得られる瞬間です。

チームがストアでの公開日に向けて、スクリーンショット、説明文、最後のバグ修正、承認など、すべてを最適化する姿をよく見かけます。それは重要ですが、そこがゴールではありません。ここから大切なのは、アプリが日常生活で役に立つかどうかです。ユーザーがまた使いに来てくれるかどうかです。アップデートを通じて信頼を築けるかどうかです。

期待は何年も前から高まり続けています。人々は、アプリが定期的に改善されることに慣れています。そして、改善されていなければ、そのことに気づきます。だからこそ、放置されたアプリは強い警告サインとなるのです。失うのは機能だけではなく、信頼性も失います。Business of Apps (Pixalate, 2022)↗

実際にはどういう意味ですか？ローンチをサイクルの始まりとして計画します。第一に、QAとストア公開準備（安定性、権限、プライバシーに関する文面、クラッシュ監視）です。第二に、測定可能性です。すべてを追跡するのではなく、意思決定に役立つものを測定します。第三に、 フィードバック窓口は、誰かが悪いレビューを書くまで待つことはありません。

分析と安定性の確保には、Firebase AnalyticsやCrashlyticsのようなツールが、多くの製品にとって良い出発点になります。ここで重要なのはツールではなく、どの観察結果がどの意思決定につながるのか、という問いです。

そして、私たちが特に気に入っている段階に入ります。落ち着いて改善を重ねることです。慌ただしく新機能を次々と追加するのではなく、小さく、着実な改善を行います。オンボーディング中にユーザーが離脱していると分かれば、より分かりやすい説明や、より早く「最初の成功」を体験できる方法を試します。ユーザーがある機能を探しているのに見つけられないと分かれば、 私たちは「また新たなチュートリアル」を追加するのではなく、構造を変えます。

こうして、単発のプロジェクトではなく、本当にプロダクトと感じられるものを作ります。そして、まさにそれが、長期的に「インストールされる」ことと「使われる」ことの違いを生みます。

ローンチをこのように捉えれば、完璧である必要はありません。ただ誠実に学べばよいのです。

成果を生むのは、すべてのピクセルではなく、すべての良い判断

アプリを担当していると、いつかこんな疑問が浮かびます。「この取り組みは、本当にそれだけの価値がありますか？」私たちの率直な答えはこうです。すべてのピクセルに手間をかける価値があるわけではありません。でも、良い意思決定には、ほとんどの場合、それだけの価値があります。

その価値の一部は、コンバージョンの向上、離脱の減少、再訪問の増加という形でわかりやすく表れます。研究結果は、優れたUIがコンバージョンを大幅に増加させ、卓越したUXはさらに大きな効果をもたらすことを示していると要約されることがよくあります。 Userpilot（UX統計）↗ 数字だけで納得することはありませんが、直感だけに頼る負担を少し軽くしてくれます。投資しているのは「美しさ」ではなく、成功の確率です。

二つ目の点は地味ですが、チームにとってはより重要なことが多いです。それは、手戻りが減ることです。ユーザーが操作の流れを理解できていないことに気づくのが遅すぎると、大きなコストがかかります。お金だけでなく、労力もかかります。コードを変更すると新たなバグが生まれ、スケジュールが遅れ、士気が下がります。 そのため、私たちは早期のプロトタイピングとテストを非常に重視しています。

そして、ブランド価値もあります。アプリは、多くの場合、電車の中、夜遅く、予定と予定の合間など、人があなたのブランドに最も身近に触れる接点です。そんな場面で動作がもたつくと、大切にされていないように感じます。反対に、わかりやすく使えると、あなたが責任を持って向き合っていると感じられます。

リテンションを実際の数値で見ると、その影響の大きさがわかります。30日目にアクティブなユーザーがごくわずかな割合しか残っていない場合、Business of Apps (2025)↗、オンボーディングや主要なプロセスの小さな改善が大きな違いを生むことがあります。それは改善が「魔法のよう」だからではなく、最も厳しいボトルネックに働きかけるからです。

社内では、よく簡単な思考実験を使います。インストール数が10,000件あり、1か月後も利用を続ける人をあと200人増やせたとしたら、それだけでもサブスクリプション型やサービス型のモデルでは、目に見える収益につながり得ます。そして、サポートコストの削減やプロセスの迅速化に「しか」つながらないとしても： それは確かな価値です。

目的を重視するプロジェクトでは、多くの事業の採算計算から抜け落ちているものがもう一つあります。それは、もたらす影響です。アプリが人々のより良い意思決定を助け、教育へのアクセスを提供し、あるいは資源を節約するのであれば、UXは単なるROIではなく、責任でもあります。

結局のところ、成功するアプリは、機能が最も多いアプリとは限りません。人々にとって本当に必要なことを、確実に実行するアプリです。