なぜ私たちのウェブサイトはOSのように見えるのか

 (posthog.com)
1 ポイント 投稿者 GN⁺ 2025-09-12 | 1件のコメント | WhatsAppで共有
  • 多くの大規模な技術系ウェブサイトでは、複数のページを同時に参照しようとするとタブが増えすぎる問題が発生する
  • PostHog.comも同様の問題を抱えており、これを解決するためにOSスタイルのUIを導入した
  • 新しい構造では、マルチタスク、ウィンドウスナップ、キーボードショートカットなど、さまざまなインタラクション機能を提供する
  • 視覚的階層とコンテンツの分離、JSONベースのコンテンツ管理、顧客データベースなどの技術的革新が適用されている
  • 当初は慣れない面もあったが、開発体験と利用体験は前向きに変化し、柔軟性と拡張性を確保できた

問題意識: 技術系ウェブサイトのタブ過多

  • 多くの大規模な技術系ウェブサイトでは、一度に複数のページを参照しようとすると CMD + クリックで新しいタブをいくつも開くことになる
  • 同じファビコンと似たデザインのため、各タブを見分けるのが難しい
  • PostHog.comもサービスの成長に伴って同じ問題を抱え始め、有料プロダクトの増加やページ数の増加によって識別しづらさがさらに深刻になった

代替案の模索とUIの革新

  • 既存のマーケティングサイトやドキュメントサイトのスクロール中心のインターフェース、大きなフッター、過剰な余白に疑問を持った
  • 意味のないスクロールを促すのではなく、より良いコンテンツ消費の方法が必要だと認識した
  • これを解決するため、新しいPostHog.comではマルチタスク、複数の記事の同時閲覧、画面内での自由な移動ができるよう設計した

OSのように動作するサイト

  • 新しいUIでは、ウィンドウスナップ、キーボードショートカット、ブックマークアプリなどの機能を実装した
  • ブラウザ内のOSのように、複数の作業を同時にこなせる体験を提供する
  • 例として、エンジニア向けニュースレターを見ながら、デモ動画を視聴し、ゲーム（ヘッジホッグモード）を同時に動かせる

初期適応とユーザー反応

  • OSスタイルのインターフェースは、最初はやや見慣れない体験を与えることがある
  • 従来のブラウザパターンから外れているため違和感を覚えることもあったが、繰り返し使ううちに慣れ、前向きに受け止められるようになった
  • 社内の同僚たちからもこの新しい体験には好意的なフィードバックがあり、もはや従来のやり方には戻りにくいレベルに達した

構築プロセスと技術的ハイライト

  • Eli KinseyとともにTypescript、TailwindベースでUIを設計・開発し、サイトを構築した
  • 5年分のコンテンツを拡張可能に整理する方法を考案する過程で、さまざまな技術的アプローチを探った

主な技術ポイント

  • 視覚的階層とコンテンツの分離

    • すべてのプロダクトページをJSONファイルベースでレンダリングする
    • JSONがページレイアウト、コンテンツの展開、機能ごとの競合比較、さまざまなテーマ（ライト/ダークモード）のスクリーンショットを直接制御する
    • 長期的には、この構造をPostHogアプリと共有するリポジトリへ移し、単一の情報源にする計画だ

  • テーマとカラースキニング

    • ライトモードとダークモードを維持しつつ、主要・補助・第三の色など多様なテーマを調和させて適用する方法を検討した
    • これに関する経験は、今後別の記事で共有する予定だ

  • リファレンス顧客データベース

    • コード内で単一の顧客レコードを定義し、プロダクトごとの利用状況、顧客の引用文、SVGロゴ（ライト/ダークモード対応）の情報を保存する
    • ページごとに異なるプロダクトに関連する引用文、名前、写真、会社ロゴを自動で読み込めるため、柔軟性を確保できる

開発手法とプロトタイピング

  • TypescriptとTailwindでUIを実装しながら、サイト設計と開発を同時進行で進めた
  • 新しいアイデアの創出や機能拡張がしやすい、本番環境内でのプロトタイピング方式を選択した
  • 必要に応じてBalsamiqなど外部のモックアップツールも併用し、コンセプトを具体化した

結論と今後の改善方向

  • 現在は初期のMVP段階にあたり、今後も多くの改善が必要な状況だ
  • ユーザーがPostHog.comの新しいUXを楽しみ、サイト探索とともに面白さも感じてくれることを期待している
  • サイトの動作原理に関する技術文書は別途提供している

関連記事

1件のコメント

 
GN⁺ 2025-09-12
Hacker Newsの意見

  • なぜこれが既存のデザインと比べてここまで異例に魅力的に感じられるのかについては、心理学者や認知科学者、あるいは神経科学者なら答えられるかもしれない。今ソフトウェア業界で急いで書かれているブログ記事より、もっと深い研究が必要だと思う。
    個人的には一つ、経験的に言えることがある。私は大規模なSaaS製品向けのWebサイトと戦略を作る会社で働いたことがあり、こうしたサイトのターゲット層（エンジニアリングディレクターやVP）でもある。
    潜在顧客の立場からすると、欲しい情報を探す速度と手軽さが、これまで見てきたものより明らかに優れている。
    例えば、7つのカテゴリの下に34個の製品があることをすぐ確認できたし、人気の高い製品5つ、新着4つも即座に見える。
    製品を試したいなら: Docs > Product OS > Integration > Install and configure > Install PostHog
    エンジニアリング文化が気になるなら: Company > Handbook > Engineering > Internal Processes > Bug prioritization
    価格を確認するなら: Pricing calculator > 製品を選択 > 使用量を設定、追加機能を選択
    これらすべての操作が数秒で行えるし、すでに開いている概要ページと新しく開いた価格ページの間も、サイト全体を再読み込みすることなくすぐ切り替えられる。わざわざ新しいタブで開いたり、スクロールしたりする必要もない。
    だから単なる見た目の話を超えて、ここには何か本質的なものがあると思う。もしかすると、現在のUI/UX哲学そのものが、かえってユーザーに不親切になっているのではないかという結論になるかもしれない。

    • CoryとEli（フロントエンドエンジニア）が、Webサイトデザインについて「なぜどのWebサイトも縦に長くスクロールの多いページばかりなんだろう、これは自分たちのビジネスに合っているのか？」というテーマで議論していたのを覚えている。
      私たちは多様な製品と幅広いコンテンツ（10以上の製品、ハンドブック、採用情報、ニュースレターなど）を提供しているので、単一製品の会社に向いたフラットな構造は適していないという結論になった。
      たいていのWebサイトは3秒以内に自社のすべてを伝えようとするけれど、うちの会社は3秒の紹介に収まるほど単純ではない。だからあえて、人々がWebサイトを探索し、内容をより深く理解するよう促す構造にした。
      このため、すぐ離脱する訪問者もいるだろうが、残る人たちは（ときどきは！）このUXを本当に気に入ってくれる。
      このプロジェクト自体も楽しかったし、何か特別な形で目立てるので試してみた。
      従来のアウトバウンド営業よりずっとクールで、費用対効果も高い。
      スタートアップの指標としては、3か月のCAC回収期間で運営している。
      ただし、この戦略が本当に機能するには、「本当に」深く掘り下げてこそ人の記憶に残る、という前提が必要だ。

    • HNでこういう意見を見るとは思わなかった。
      普段のHNでは、JavaScriptを多用すると悪いデザインで、使えず移植性も低い、という認識が圧倒的だ。
      今回の例は、いわばJavaScript全開バージョンだ。

    • 必要な情報を素早く簡単に見つけられるという点で、本当にWebが昔のメニュー中心の設計に戻ったように感じる。
      最近の最新UIはシンプルさや「楽しい体験」を打ち出すが、よく設計されたメニューバーの効率性にはなかなか及ばない。

    • こういうインターフェースで感じる快適さを一般化するのは慎重であるべきだ。
      CLIやコマンドパレットと比べると、このUIは負担が大きく、認知的に疲れる。

    • 記憶が正しければ、この会社はすべてのコンテンツを同じCMSに入れていた。特に議論やヘルプフォーラムをメインサイトに統合していた。
      過去に似たプロジェクトをやった経験からすると、フロントページ上のすべてのコンテンツが一つの組織に主導権があり、統制されている感じが出る。部門同士の縄張り争いや、複数のサブドメインへの雑然としたリンクの痕跡がない。
      こういうサイトは、バックエンドにコンテンツ統合システム（CMS）があってこそ作れると思う。
      そして組織として、分権化（各VPが自分の縄張りを守るような形）へ流れようとする傾向に強く抵抗しないと、こうしたCMS構造は実現できない。

  • PostHog.comはサードパーティCookieなしで内部Cookieを1つだけ使うと言っているが、
    法的には、そのCookieがサイトの中核機能に必須でないなら、オプトアウトの選択肢を提供しなければならない。
    もし中核機能に必要なら、そもそもバナー自体が不要だ。

    • 実際にCookieを必須機能にしか使っていないなら、こういう冗談めいたCookieバナーは、訪問者のプライバシーを尊重しているふりをしつつ、むしろ無駄に苛立たせるだけだ。
      もっと悪いのは、EU法を実質的な意味のない煩雑な規制にしか見えなくして、本当にユーザーを追跡しているサイトにかえって有利な立場を与えてしまうことだ。
      本当にひどい。

    • Cookieバナーが必要かどうかの基準は、もっと単純だと思う。
      Cookieがトラッキング目的で使われていないなら、バナーは不要なはずだ。
      例えば、並び順を記憶するCookieのように、トラッキング目的ではないものにはバナーは要らないと思う。
      結局のところ、問題は「Cookie」ではなく「トラッキング」なのだ。

    • どの国がすべてのCookieに対してCookieバナーを義務づけているのか気になる。
      EUはトラッキング用Cookieにだけ義務づけているし、PostHogはその目的を明記していない。
      私自身も、実際にはCookieがなくても「必須ですから」と言って入れたことがある。
      すべてのサイトにCookieバナーが必要だという認識のほうが、実際にはバナーそのものより有害かもしれない。

    • ログインシステムがあるのだから、内部Cookieにはログイン情報（JWTなど）が入っている可能性が高い。
      この場合、そのCookieは中核機能用なのでバナーは不要だ。
      つまり、法的に必要なわけではないが、バナーがないと誰かに「なんでCookieバナーがないんですか？」と言われそうだから、とりあえず入れたのだと推測できる。
      結局、実質的な法的義務はなく、慣行上・認識上必要な程度だ。

    • 2025年にもなって、まだCookieを目で見て拒否したいと思う理由が気になる。
      ただブラウザが自動でやればいいのでは、と思う。

  • https://posthog.com/404 ページはブルースクリーン・オブ・デスのパロディだ。

  • 昔から「マルチドキュメントインターフェース（MDI）」はアンチパターンだと思っていた。
    すでに完璧なウィンドウマネージャーがあるのに、なぜアプリごとに独自の内蔵ウィンドウ管理ツールが必要なのか？
    もちろん、モバイルにはこういうOSレベルのウィンドウマネージャーがないので例外だ。

    • 一部のアプリ（例: 画像編集ソフト）では、アプリケーション内で複数ウィンドウが必要だ。
      だが、ほとんどの汎用MDI実装（Win32、Qt）はあまりにミニマルでがっかりする。
      Kritaでは複数ウィンドウを開きたいのに、QtのMDIはWindows 95にも劣る。

    • Gimpのようなアプリと比べると、私はむしろ全部が一つのウィンドウ内に収まっている構造のほうが好きだ。
      2つ3つのアプリを同時に開くと、ウィンドウ探しがまるでかくれんぼになる。
      ツールバーが別ウィンドウとして表示されるのは本当に嫌いだ。

    • Macを長く使ってきた立場からすると、MDIはOSにアプリケーション単位のウィンドウ管理機能が足りなかったために生まれた苦肉の策に感じる。
      昔のPhotoshopはMac上でウィンドウやパレットを自由に出せたが、CS4の頃にMDIタイプが導入されて、急に窮屈になったのでいつも無効にしていた。
      少なくともMacでは、とても不自然で息苦しく感じる。

    • Unixのほとんどのコマンドは、出力フォーマットがそれぞれ独自だ（カラム、テーブル、リスト、ファイル、TTYなど）。
      UNIXの抽象化は結局「テキスト」中心の構造だ。
      だがエコシステムが豊かなので、各ツールごとに多様な要件がある。
      もしテキスト以外に適した抽象化があるなら、とっくに出てきていたはずだが、結局はみなテキストのパイプラインに収まっている。

    • OSのウィンドウマネージャーは、一つの画面に小さなウィンドウがたくさんある状況を効率的に扱うのがあまり得意ではないように思う。
      一方で、アートソフトやCADソフトのカスタムウィンドウ管理ツールには、小さなタイトルバーで空間を節約するよう最適化されたものが多い。

  • ほぼ完璧で、インスピレーションを与えるプロジェクトだと思う。
    実際のOSのデスクトップのように、何もない部分をドラッグすると四角い選択枠が出て動かせるともっとよかったのに、
    それを可能にするコードスニペットを自分で作ってみたので、コンソールに貼り付けて試せば夢がかなう。
    （コード: マウスドラッグで画面に selection rect を表示するJS、コンソールに結果を出力）

  • アイデアも実装も素晴らしいが、正直ほしくはない。
    新しいUI/UXをまた覚えなければならないし、そのうえウィンドウの中のウィンドウまで整理しなければならない。
    Webサイトは凝ったインターフェースより、ただのテキストブロックで十分だと思う。

    • 本当に同感だ。
      すでに自分のOSがウィンドウ管理を完璧にこなせるよう設定してある。

    • もしこのページのすべてのコンテンツを一つのテキストブロックにしなければならないとしたら、それこそ途方もなく長くなると想像してみるといい。

  • どう表現すればいいのか難しいが、本当に素晴らしい仕事だ。
    何年もWeb開発に携わる中で、ひどいUIにはいつも不満があったが、今回のWebサイトは本当に優れている。
    単なる「Windows風」というだけではなく、実際の使い心地が、これまで触ったブラウザベースのデスクトップシミュレーター系サイトの中で一番よかった。
    一つだけ惜しい点を挙げるなら、背景を右クリックしたときに出るコンテキストメニューに「更新」があれば、ブラウザ上のデスクトップ感が完璧だったと思う（実行できなくても、雰囲気として完成する）。
    要するに、素晴らしい仕事、素晴らしいサイトだ。

    • リクエストありがとう、「更新」ボタンは検討してみる。

  • ビジュアル的には格好いいが、性能が遅すぎる。
    ウィンドウをいくつか開いて動かしてみると、かなりもっさりする。
    こういうマルチウィンドウのWebページを作るなら、性能も良くなければならない。
    昔はSEOのせいで、こういう構造は絶対に使わなかった。
    今ではSEOの重要性も昔ほどではなくなってきた感じがする。

    • Firefoxで遅い現象を体験した。
      Edgeブラウザで開いたら滑らかに動いた。

    • どんな環境で性能問題が出るのか気になる。
      最初のウィンドウまでは問題ないが、2つ目のウィンドウから少し引っかかり、その後はフルスピードになる。
      たぶんブラウザが特定の関数の使用を検知すると、最適化ルーチンの適用が少し遅れるせいではないかと思う。

    • 昔のSEOは「文書」としてのWebページだったが、今は皆がWebをゲームにしようとしているように見える。
      ゲーム系のWebサイトはランキング付けもしにくいのではないかと思う。

  • このWebサイトはあまりに斬新で本当に好きだ。
    同じセクション積み上げ型テンプレートを使うSaaSマーケティングサイトだらけの中で際立っている。
    とはいえ、実際に上で説明されているような使い方をする人はいないだろう。
    サイト専用のウィンドウ管理機能をわざわざ学んで使うほど、誰も長く滞在しないと思う。

    • 私はむしろUXが直感的に感じられた。
      しかも楽しい。
      普段ならこういう製品サイトはすぐ閉じるのに、今回は5〜10分以上見て回って、何があるのか隅々まで眺めてしまった。

    • 私も同じで、不思議なくらい新鮮に感じた。
      でもHNのコメントの大半はあまり好意的ではないようだ。

    • 私の反応も似たようなものだった。
      印象的で面白く、会社の哲学をよく表している感じがする。
      実用性は高くないかもしれないが、それが重要な問題だとは思わない。

  • PostHogと仕事をしたとき、分析量が自分の倫理基準に合わず居心地が悪かったが、技術的には本当によくできている。
    ランディングページが、製品そのものに込められた技術力と水準をよく示している。
    斬新で楽しいランディングページだったし、「Cookieバナー」のジョークにも思わず笑ってしまった。