TrueLink ウェブサイトのリニューアル実績：白地帯の解消からレスポンシブデザインへ、多言語とAIアシスタントの統合
# TrueLink ウェブサイトのリニューアル実績：白地帯の解消からレスポンシブデザインへ、多言語とAIアシスタントの統合を実現
概要
TrueLinkの今回のリニューアルでは、デスクトップ画面の利用率、記事の分類、複数デバイスでのナビゲーション、および多言語の一貫性を重点に検討しました。また、AIアシスタントが実際に機能に接続されているかを確認しました。本記事では、ワイドリストと記事読了領域の区別、固定検索および国／言語選択の設計、旧バージョンと修正後の回帰テストを用いて外観だけでなく機能の接続も確認する方法について説明します。一部の修正はすでにローカルで検証が完了していますが、全体のデザインおよび13言語サイトについては、バッチごとに公開および正式な検証が完了するまで、ランキングやコンバージョン率の向上に直接関する実測結果はまだありません。
ユーザーが直面した問題から始める
今回の調整にはいくつかの具体的な起点がありました。まず、大画面でコンテンツ領域が狭く、左右の空白がユーザーに記事を見つける手助けになっていない点。また、ホーム、ツール、Blogの分類とナビゲーションが一貫性が欠如していること。さらに、一部のページではAIアシスタントのエントリが見えるものの、対応する機能が完全に接続されていないという問題がありました。
多言語の導入には、さらに別の課題がありました。同じページで選択肢、コンテンツ、検索、およびログイン後の戻り先が異なる言語で表示されると、ユーザーが言語選択メニューを確認しても、システムが一貫していないと感じることがあります。そのため、デザイン、共有モジュール、および言語状態を検証の対象に含め、単にホーム画面のタイトルを翻訳するだけにとどまらず、全体を統合的に検証しました。
本記事では、改善方法と現在の検証結果を共有します。正式に公開されていない部分については、明確に表示し、新しいデザインの表示を正式な公開画面と誤って扱うことはありません。
リストのワイド表示と記事の行幅を分離して処理
我々が採用したアプローチは、リストは画面を最大限に活用し、本文は読みやすい行幅を維持することです。
Blog、ツールセンター、およびOffersは探索型のページであり、ユーザーは複数の項目を比較する必要があります。このようなリストは、利用可能な幅に応じて列数を調整し、分類、画像、および要約がユーザーの判断を助けるように設計されています。これにより、大画面でも狭い単列のブロックのままではなく、効果的に情報を提示できます。
一方、本文については、約65〜75文字をデザインの出発点として、繁体中文、英語、フォント、およびモバイルでの実際の読みやすさに応じて調整しています。これは今回のデザイン選択であり、すべての言語に適用可能な固定ルールではありません。特に、中国語の実際の文字幅については、別途検証が必要です。
レスポンシブデザインにおいては、すべてのデバイスサイズごとにページを作成する必要はありません。柔軟なグリッド、相対的なサイズ、および適切な断点を用いることで、コンテンツは空間に応じて自動調整されます。タイトルが読みにくくなったり、文字行が長すぎる場合にのみ、レイアウトを変更します。MDNのレスポンシブデザインに関する資料を参考にしました：https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/CSS_layout/Responsive_Design
この方法の利点は、大画面ではより多くの有用な情報を提示でき、スマホでは項目ごとに読み進められることです。一方で、画像、長タイトル、空状態、および分類操作のテストがより多く必要となり、低解像度の画像を引き伸ばして画面を埋めるような方法は避けなければなりません。
固定メニューと検索で、探索プロセスを中断させない
我々は、共有ナビゲーションを安定したエントリに統合するように設計しました。ブランド、主要分類、検索、国／言語、および会員操作を、デスクトップとスマホそれぞれに応じた表示形式で提供します。
固定検索は、記事やツールが多いプラットフォームに適しています。ユーザーがスクロールしても、次の検索を開始できます。ただし、固定領域はタイトル、フォーム、またはキーボードのフォーカスを隠すようなことは控えなければなりません。スマホで検索を展開する際には、明確な閉じる方法、理解可能な空結果、および戻った後の位置の保存が必須です。
分類の目的は、コンテンツにアクセスするまでの経路を短縮することです。記事、ツール、およびオファーアイテムは、共通の検索エントリを共有できますが、それぞれの結果タイプと可視性を保つ必要があります。公開紹介とログインが必要な作業領域を混同するような設計は避けるべきです。
国／地域と言語は、それぞれのユーザーの選択肢
台湾を選択すると、繁体中文が提案され、日本を選択すると日本語が提案されます。しかし、ユーザーは日本に住んでいて英語を好む場合や、台湾で他の言語を使用している場合もあります。
そのため、国／地域と言語は別々に設計しました：
- 地域は提案を提供し、明確に選択された言語は優先されます。
- 言語を切り替えると、同じコンテンツの対応バージョンに戻ります。
- 翻訳が存在しない場合、原文を明確に表示するか、選択に戻るオプションを提供します。
- 地域の選択によって、国籍、住所、税務、またはサービス資格が自動的に変更されることはありません。
- ログインや戻るプロセスは、ユーザーが選択した言語を意図的に上書きしないように設計されています。
検索エンジンの言語ラベルも、実際のページに一致する必要があります。Googleの多言語バージョンガイドラインでは、それぞれの言語ページが自身および対応バージョンをリストするよう求めています。これらの関連性は、実際に存在するコンテンツに基づいて確立される必要があります。Googleの多言語ページガイドラインを参考にしました：https://developers.google.com/search/docs/specialty/international/localized-versions
13言語の「エントリがある」ことと「完了している」ことは、別途報告
我々のウェブサイトおよびBlogは、13言語への統合を目指していますが、言語メニューに13のオプションがあるからといって、すべてのページに完全な翻訳が存在しているわけではありません。
検証には、いくつかの点を明確に区別する必要があります：インターフェースが翻訳されているか、記事が存在しているか、異なる言語が同じトピックにリンクしているか、検索が現在の言語を理解できるか、およびページが正しいインデックスと公開状態を持っているか。
翻訳が存在しない場合、原文を表示するようにします。これにより、コンテンツの可用性は保たれますが、読者に現在表示されている内容が何であるかを明確に伝えなければなりません。中国語のフォールバックを用いて外国語バージョンを装うことは許されず、存在しない翻訳に対して見た目上完全な言語関連性を設定することも避けるべきです。
このような段階ごとの配信により、実際のギャップが見えやすくなり、単一の言語が失敗した場合でも、他の既に検証済みバージョンに影響が出ることを防げます。
AIアシスタント：エントリが存在するだけで、機能が準備されているわけではない
今回の検証では、共有モジュールに関する有用なケースを確認しました。あるページには状態のエントリが表示されていますが、ページ内ではAI機能が完全に宣言されていないという状況がありました。また、別の代替エントリは、それが検出されたため退避しており、「エントリは表示されているが、機能は完全に接続されていない」という状態が生じています。
ローカルの修正では、以下の2つの原則を採用しました：
1. ページが明確に、許可されている機能を宣言する。例えば、コンサルタント紹介ページでは、アシスタントは本ページのサービスを説明するだけで、フォームや有料ツールの使用範囲を取得するべきではありません。 2. 代替のモジュールは、主モジュールが実際に準備が整った後で退避する。単にエントリ要素を見つけることや、プログラム資産を読み込むことだけでは、ユーザーが正常に操作できるとは限りません。
また、作業領域や言語を切り替える際の遅延応答もテストしました。共有の外観は一貫性を持たせても、会話は以前の状況に混じってはいけません。ページを変更した後の説明も、現在のページの内容に更新される必要があります。
旧バージョンの負のコントロールを用いて、テストが本当に問題を捕捉しているかを確認する
今回は、修正後の画面が表示されているかどうかだけではなく、既知の欠点を旧バージョンに再投入して、テストが失敗するかを確認し、修正後の検証が通過するかを検証しました。
現在のローカルの証拠には以下が含まれます：
- 2つの旧バージョンの欠点が予期通りに失敗しており、テストがこれらの問題を捕捉できていることを証明しています。
- 修正後のモジュールの回帰テストでは11項目が通過しましたが、これは全サイトのAIプロセスがすべて通過していることを意味しません。
- 必要なローカルチェックでは20項目が通過しましたが、正式バージョンと公開前の検証は別途確認が必要です。
- デスクトップ、375px、360pxのブラウザでの検証は、深色と浅色、失敗時の復元を含め、孤立した合成データを使用し、正式なAIにテストメッセージを送信していません。
- 正式なデプロイメントの検証はまだ完了していないため、新版が正式に修復成功したとは言えません。
現在の改善は、バッチごとに公開前の検証が完了するまで進行中です。読者には、この記録をデザインおよびテスト方法として参考にしていただき、正式な公開結果は検証が完了した後に別途更新されます。
長所と短所、および適用シーン
このアプローチは、記事、ツール、および言語バージョンが徐々に増加するプラットフォームに適しています。共有ナビゲーションとモジュールにより、重複したメンテナンスを減らし、ワイドリストは探索をサポートし、シチュエーションの分離により、ページ間の操作が明確になります。
ただし、コストもあります。共有モジュールの影響範囲は広いため、各ページの初期化と互換性について毎回注意が必要です。多言語では、コンテンツの関連性を検証する必要があります。単に辞書の数だけではなく、固定領域とアニメーションは、キーボード、文字拡大、および動的な要素の減少への配慮も必要です。
コンテンツが少ない単一ページサイトでは、ナビゲーションを簡略化した方が適切かもしれません。デザインはコンテンツとユーザーのタスクにサービスするものであり、プラットフォーム感を追求するためにすべてのコントロールを追加する必要はありません。
アクセシビリティについては、今後も内容の再配置および拡大後でも操作可能であることを検証の方向として継続します。W3CのReflow説明でも強調されている通り、内容を拡大した後は不要な二方向スクロールを避ける必要があります。今回のスマホの検証は、完全なアクセシビリティの適合性チェックを置き換えるものではありません。W3CのReflow説明を参考にしました：https://www.w3.org/WAI/WCAG22/Understanding/reflow.html
次のステップ
今後は、共有モジュール、Blogのデザイン、および多言語コンテンツの公開前の検証と正式な検証をバッチごとに完了していきます。旧バージョンの公開画面と新バージョンの表示はそれぞれ明確に区別し、仮想的な公開前後の比較は提供しません。
独自のウェブサイトを設計したい場合は、まず最も頻繁に利用されるパスを整理することをおすすめします。読者がどの場所からアクセスし、コンテンツを見つける方法、言語を切り替えた後にどこに行くか、およびログインまたは失敗した後にどこに戻るかを明確に把握することが重要です。これらのパスが明確になれば、視覚的な調整にも検証可能な目標が設定できます。
関連情報：TrueLink公式サイト https://truelink-group.com/ · TrueLinkコンサルティングサービス https://truelink-group.com/consulting/ · TrueLink知識ベース https://truelink-group.com/blog/
