製品と運用について: ユーザーの認識とは何ですか?

周紅毅氏はこれまで何度もユーザーの認識というテーマについて語ってきました。製品の場合、どのようなテクノロジーを使用し、どのような実装アーキテクチャを使用し、どのようなプロセス ロジックを使用するかに関係なく、最終的にユーザーに反映されるのはユーザーの認識です。おそらく、あなたがやっていることは単純ですが、ユーザーはそれを充実していると認識します。おそらく、あなたがやっていることは非常に複雑ですが、ユーザーはそれを十分に認識していません。これらは、製品運用で対処する必要がある問題です。

もちろん、ユーザーの認識を誘導し、実際には存在しないテクノロジーをユーザーに体験させる方法など、このトピックは簡単に脱線する可能性があります。

グレーな業界の例は次のとおりです:警告!あなたのコンピュータ/携帯電話にウイルスが感染しています! ウイルス対策ツールをすぐにダウンロードしてください。

ダウンロード後、取得されたファイルの数、検出および駆除されたウイルスの数が表示されます。コンピュータ/携帯電話を常に保護するためにメモリに保持する必要があります。

これは良いと思いますね。他のソフトウェアは警告を出さないので、これが最も信頼できるのです。それで、電話を自動的に起動し続けました、それは何をしましたか?悪いことをしているわけではなく、広告を乗っ取って、毎日の閲覧記録に末尾を追加し、 Taobaoのトラフィックを Taobao に、Baidu のトラフィックを Baidu に、 Amazonのトラフィックを Amazon に販売して、密かにあなたから手数料を稼いでいるようですが、あなたはまだそれに気付かず、セキュリティ ツールだと思っているようです。

これは、グレーな業界におけるユーザーの誤解を招く典型的な事例です。

周紅一氏も360ルーターを例に挙げた。アンテナを隠すために新しい技術を使用したとのことですが、これによって良好な信号伝播も実現できるそうですね。ユーザーはアンテナがないことに気がつくと、信号が悪いに違いないと考え、4 つのアンテナを備えたルーターを購入します。したがって、どのような技術が使用される場合でも、最初に 4 つのアンテナがインストールされます。これは、ユーザーの認識に無条件に準拠するケースです。

私はオフラインで技術製品のコミュニケーションを行い、需要の限界というテーマについて共有していましたが、そのトピックの 1 つは典型的なケースでした。Taobao の検索結果のページをめくっても、100 ページを超えることはできません。検索結果の数は、Taobao、Baidu、 Googleのいずれの場合も、非常に少ない数であれば正確ですが、非常に多い数であれば推定値です。

この例を挙げた後、オフライン共有中に出席者に尋ねました。皆さんは Taobao を訪れたことがありますか? Taobao では 100 ページ以上閲覧できないことを知っている人はいますか?誰もが Taobao を訪れたことがあるでしょう。私が言わなければ、100 ページ以上はめくれないということを誰も知りません。

それはどういう意味ですか？ ユーザーは、100 ページを超えるページをめくる必要性を認識しておらず、検索結果の数値的な推定値も認識していません。 私がCNZZに取り組んでいた頃は、何十万人ものウェブマスターが CNZZ を使用しており、毎日数十億のページビューをカバーしていました。ウェブサイトの情報源やインタビュー対象者に関するすべての情報を保存しているわけではありません。最初の 1,000 件だけを保存しています。この問題について苦情を申し立てたり、質問したりするウェブマスターはいません。これは何を意味するのでしょうか?ユーザーの認識には影響しません。

これが、私が需要境界の概念を提案した理由です。ユーザーの認識に影響を与えることなく、多くの削減を行って技術コストを節約することができます。ご覧のとおり、ページめくりが大きいのは、Baidu、Google、Taobaoでも解決できない問題であり、ユーザーの認識に影響を与えない問題でもあります。この例を見れば十分に明らかです。

（ちなみに、私の経験を共有していたところ、多くの技術スタッフが、なぜ大きなページめくりが効率面で最適化が難しい技術的な問題なのかをまだ理解していないことがわかりました。これは技術面接の質問としても使えると思います。）

製品開発では、2 つの極端な誤解に陥ることがよくあります。

1 つ目は、技術的なバックグラウンドを持つ起業家がよく犯す間違いで、製品は技術的なアーキテクチャによって形作られるというものです。私の技術的な構造とデータ構造はこのようになっているので、ページの機能は次のようになります。

以前、私はチームの管理バックエンドを批判しました。それはマネージャが見るべきものではないと私は言いました。それは単なるデータ構造のマッピングでした。phpMyAdmin を渡せばいいので、自分で開発する必要はないと私は言いました。

2 番目の間違いは、エントリーレベルのテクノロジー レベルの企業がよく犯す間違いで、技術アーキテクチャが製品の目標に基づいていることです。 さまざまな機能を実行したいため、コードとデータ構造はこの機能設計に完全に忠実に記述されています。

何が問題ですか？ 再利用性と結合性が考慮されておらず、スケーラビリティの概念も、要件の変更の可能性の概念も、ビジネス開発と運用の概念もありません。初期段階では完成していて、見た目も問題なかったのですが、後になってイベントを開催したり、新しい機能を作成したりしたいと思ったときには、最初からやり直さなければなりませんでした。

この話題は少し突飛かもしれませんが、これがいわゆる建築家の役割と意義です。

プロダクトマネージャーの目標はユーザーの認識です。私が望む機能や特徴、ユーザーが期待するもの、ユーザーのインタラクティブなフィードバックなど、これらすべてはユーザーの認識を中心に据える必要があります。技術的なアーキテクチャがどのようなものかだけに基づいて構築することはできません。もちろん、伝えられることもあります。ユーザーの認識を可能な限り満たしながら、技術コストを削減し、研究開発の効率を向上させる方法は、コミュニケーションと交渉によって実現できます。

テクニカルアーキテクチャの仕事は、ユーザーの認識を可能な限り満たしながら、技術コストを効果的に削減し、将来のビジネスや運用との互換性を向上させることです。もちろん、両者は少し矛盾するかもしれませんが、完全に矛盾するわけではありません。

したがって、1 つのインターフェース ビューに複数の技術構造が混在したり、同じデータ構造内のコンテンツがさまざまな条件に応じてさまざまなロールのさまざまなシナリオに反映されたりすることがあります。これは問題ではありません。製品アーキテクチャと技術アーキテクチャの間には必ずしも接続は必要ありません。最も典型的な例は検索エンジン、つまり検索ボックスです。その背後には非常に複雑で巨大な技術的アーキテクチャがありますが、ユーザーに与えられる認識は非常に単純かつ明確です。つまり、何を望んでいるのか、そしてどうすれば期待にできるだけ応えられるのかということです。

そのため、多くの起業家も低コストでユーザーの認識を満たす方法を模索しています。簡単に言えば、「ユーザーに考えさせる」というアプローチです。

これは過去にあまりにも多く使われてきたトリックです。多くの美しい女性の別名がソーシャル ネットワーク上で常に活動していますが、実際はロボットです。ロボットが登場する前から、ロボットを操作していたのは少年たちだった。他の人たちはもちろん、馬化騰もOICQの活動を増やすために同じことをしたのではないだろうか？

いまだにこの手口を使って人々から金銭を騙し取っている出会い系プラットフォームはたくさんあるのではないでしょうか？そして、それは実際に効果があります。少し前にインターネットで衝撃的な記事をいくつか見ました。これで儲けている人がいるのは知っていましたが、こんなに多くの人が騙されるとは思いませんでした。

別のタイプとしては、チェスやカードなどのゲームがあり、そこにもロボットが存在します。ユーザーのアクティビティが高くない場合は、プレイヤーの戦闘ニーズを満たすことができますが、一部のロボットはあまりにも愚かで、プレイヤーに簡単に見抜かれてしまいます。

成功例を一つお話ししましょう。Snake ゲームが最初にリリースされたとき、オンライン バージョンはありませんでしたが、ほとんどのプレイヤーはオンラインの人と戦っていると思っていました。また、遅延がないのでオンラインよりも効果は優れています。

低コストはユーザーの認識を満足させます。ユーザーを誤解させて間違ったことを信じさせたり、「価値が高いように見えるが実際には価値が低い」ものに対してユーザーに高いコストを支払わせたりすることは、確かにあまり良くありません。

しかし、娯楽シーンの中には、実際にはそれほど深刻な罪ではないものもあります。たとえば、ゲームでは、数値 PK を使用してリアルタイム PK をシミュレートすると、技術コストが低く、効果も十分で、プレイヤーの要求を満たすのに問題はありません (もちろん、一部のディープ プレイヤーは間違いなくこの問題を発見し、より良い製品を追求するでしょうが、浅いプレイヤー向けの市場も存在します)。

さらに、ユーザーの認識の境界、つまり需要の境界を正しく理解することで、多くの無駄な作業を省くことができますが、これについては詳しく説明しません。

ユーザーの認識とユーザーの期待は、シナリオによっては同じものになる場合もありますが、他のシナリオでは若干異なる場合があります。いくつかのシナリオでは、ユーザーは予期しない状況に直面します。このとき、ユーザーは何を認識するのでしょうか?言葉についてはあまり詳しく説明しません。しかし、上記の事例と概念が、製品担当者と運用担当者がより適切に製品を設計し、R&D とより効率的にコミュニケーションをとるのに役立つことを願っています。