WEBサイトの間違った「常識」。
WEBサイトを制作するときに何気なく当たり前に使っている表現・言葉・手法を見つめ直すために記事を書きました。
WEBサイトを作る方・初心者・中級者も含めて、見つめ直しの参考にしてみてください。
本記事のはじまり
■よくある質問は必ず畳まなくていい
質問をクリック(タップ)してから回答が表示されるUIをよく見かけますが、必ずしもクリックさせる必要は無いです。
元々クリックさせる理由としては、情報量を最小限に抑えるためです。回答の情報量が多い場合、スクロールする領域が多くなるため、探したい質問を探せない可能性があるため、回答表示を隠しています。
しかし情報量が少ない場合は、表示を隠していようが、情報量があまり変わらないので、表示を隠すアコーディオンを実装しない方が適切です。回答を見るために毎回1クリック(タップ)を要求するのは、ユーザーにとって面倒だと考えます。情報量に合わせて必要なときにアコーディオンを実装しましょう。
おまけ:
ノーコードツール「STUDIO」は2023年2月現在、機能の都合上、アコーディオンの実装が難しいです。下記サイトみたいに、hoverで質問の回答を目立たせて、次のページへ誘導する表現も面白いですね。
■ユーザー登録・ログイン時に、パスワードを2回入力してもらう必要があるのか
近年は減ってきましたが、パスワードの2回入力を要求するサイトも存在します。
2回入力は、1回目の入力でユーザーが入力したパスワードが、意図したものであるかどうかを確認。その後、2回目の入力で再度同じパスワードを入力するように要求することにより、ユーザーがタイプミスをしたり、誤ったパスワードを入力することを防ぐことができます。
しかし、わざわざ入力するよりもコピー&ペーストする方が多く、セキュリティの向上という意味では多要素認証の導入の方がセキュリティを強化につながります。
本当にパスワードを2回入力させる必要があるか見つめ直しましょう。
参考:
■PC・SP・タブレット画面全てに最適化された対応をするか
レスポンシブサイトと言ったサイト作りが主流となっていますが、必ずしも全てのデバイスに最適化されたサイトを作る必要はないと考えます。
例えば下記のサイトはPC画面でもスマホのレイアウトを保ったまま表示させています。
近年では、こういったスマートフォンの横幅を保ったまま表現したWEbサイトも増えてきています。実装コスト・制作リソース・WEBサイト公開の目的を見つめ直しながら、どういった実装がよいか考えてみましょう。
参考:
ROPÉ PICNIC ロペピクニック: “今をあそぼう。” ロペピクニックの冬あそび。(公開終了)
■WEBサイトの実装にWP(ワードプレス)を使わなくていい
目的別に合わせて、Webサイトの実装を考える必要があります。
といったレベルであれば、近年はWP(ワードプレス)よりもノーコードツールを使ってサイトを構築する方が簡単で、運用も便利であることが多いです。
個人的なオススメはNotion(ノーション)です。
基本機能としてはメモアプリですが、使い方は無限大でシンプルなWEBサイトも作れてしまいます。
「WEBサイト内の文言を変えたい…。」そんな時はNotionのスマホアプリを開いて文字を編集すれば終わりです。1分で出来ます(反映にはもう少し時間がかかる可能性あり)。今までは細かな修正もサイトを運用している会社に依頼しないといけないですが、Notionであればスマホで自己完結です。
もちろん多機能なWEBサイトを実装したい場合もあるので、WP(ワードプレス)もまだまだ重宝されています。
しかし近年ではヘッドレスCMS(コンテンツマネジメントシステム)といった新しい実装方法に注目が集まっています。
WEBサイトの実装方法は、WP(ワードプレス)以外にも拡がっていますので、ぜひ参考にしてみてください。
参考:
■FV・MV・KV と略すのはやめよう
「FV・MV・KV」それぞれ何の略称か分かりますか?
FV:ファーストビュー(WEBサイトに訪れた時、一番初めに画面表示される領域全て)
MV:メインビジュアル(WEBサイトに訪れた時、一番上に見えるメインコンテンツ)
KV:キービジュアル(WEBサイトに訪れた時、一番初めに見えるキーとなるビジュアル)
それぞれの言葉の使い分けとしては、ほぼ同じ意味なので、どれも一緒と思って大丈夫です。たまに略称を使う方もいますが、一部のディレクター、デザイナー以外には伝わらない略称なので、使わない方が無難です。
■FBは2通りの意味がある
「FB」は、人によって「Facebook(フェイスブック)」「FeedBack(フィードバック)」と略されます。
こちらも誤解を生みますので、略すのはやめましょう。
■WEBサイトの改善を定量的に行うために、ABテストを行う
WEBサイトを分析する手法として、ABテストが使われますが、あまり効果的ではないケースが多いです。
むしろ良くない結果をもたらすケースもあります。下記がABテストの失敗例です。
信頼性の欠如:WEBサイトに訪問するユーザー数が少なく、分析結果が信頼性に欠ける。
時間と労力の負担:ABテストを実施するには、適切なテスト計画、適切なサンプルサイズの決定、実験の実施、結果の収集、分析、報告などの一連の作業が必要です。これには多大な時間と労力がかかります。
仮説の欠如:仮説を立てることなくABテストを実施。結果から辻褄を合わせた報告を行った。
不具合:実装した言語と相性が悪く不具合が発生。申込みフォームへ遷移ができなくなり、ユーザーから「申込みができない」と言った問合せが届く。
時間と労力の負担:適切なテスト計画、適切なサンプルサイズの決定、実験の実施、結果の収集、分析、報告などの一連の作業が必要です。これには多大な時間と労力がかかる。最低でも3ヶ月は必要と考えます。
米国のオバマ大統領(当時)陣営が選挙戦にABテストを使ったことで分析手法として有名になりましたが、取り扱いを誤ると時間と工数をかかるだけとなってしまいます。
参考:
さいごに
WEB制作の常識は時代と共に変わっていきます。情報を取り入れて、何が最適化見つめ直していきましょう。
(他にも見つめ直す必要がある慣例があれば、noteのコメントかTwitterで教えてください。お待ちしてます!)