慣用的デザインを取り戻そう
(essays.johnloeber.com)- ユーザーが即座に理解できる デザインの慣用表現 は、学習コストを減らし、一貫したインタラクションを可能にする
- 過去の デスクトップソフトウェア時代 には、OSとガイドラインのおかげで、メニュー構造やショートカットなどのインターフェースが統一されていた
- 一方、ブラウザベースのソフトウェア時代 には、フレームワークとカスタム実装の拡大によって、インターフェースの 一貫性が崩壊 した
- Apple と Substack は、限定的なカスタマイズと統一されたデザインシステムによって、現代的な慣用表現の成功例 を示している
- プロダクト設計者は既存の慣用表現に従い、明確さと一貫性 を優先して、Web全体の 標準化されたユーザー体験 へ進むべきだ
デザインの慣用表現
- チェックボックス は、ユーザーが別途学習しなくてもすぐに理解できる代表的な デザインの慣用表現 として提示される
- ログイン状態を維持するかどうかを尋ねる場面では、さまざまな入力方法があり得るが、実際には常にチェックボックスが使われる
- これはユーザーと開発者の双方にとってなじみのある 標準化されたインタラクションパターン として機能する
均質なインターフェース
- インターフェースはユーザーがシステムと相互作用するための手段であり、考える必要が少ないほど良いインターフェース と評価される
- たとえば、Command+C のショートカットでコピーする機能は、どこでも同じように動作すべきである
- しかし現在のWebソフトウェア環境では、インターフェースの一貫性が失われている
- 日付選択やカード番号入力といった基本機能ですら、サイトごとに異なる形で実装されている
- ショートカットや操作方法がアプリごとに異なるため、ユーザーは毎回「どこで何を押せばよいのか」を学び直さなければならない
デスクトップソフトウェア時代
- Windows 95～7 の時代 のデスクトップソフトウェアは、高いインターフェースの一貫性 を保っていた
- 「File, Edit, View」というメニュー構造が、あらゆるプログラムで同様に存在していた
- メニュー項目の下線は キーボードショートカット を意味し、ALT+F、N などで操作できた
- 下部の ステータスバー(status bar) は、現在の状態（ページ、単語数、モードなど）を明確に表示した
- テキストベースのメニュー が中心で、アイコンは明確な意味を持つ場合にのみ使われた
- こうした慣用表現は Microsoft Word だけでなく、Windows 全体のエコシステム にわたって統一されていた
- Windows XP のログアウト画面でも、すべてのボタンが明確にボタンだと視覚的に示され、ショートカットも表示されていた
- このような一貫性は、OS と GUI ライブラリの制約 があったからこそ可能であり、Microsoft は何百ページにも及ぶ デザインガイドライン を配布して、開発者にそれに従うよう促していた
ブラウザソフトウェア時代
- 現在のWebアプリケーション時代は、異質なインターフェース の時代として描かれる
- Figma や Linear のような優れたWebアプリでさえ、共通のアイコンやショートカットがない
- 各アプリはそれぞれよく設計されているが、互いに異なるインタラクションパターン を持っている
- 同じ会社の中でも、Gmail、GSuite、Google Docs の体験はそれぞれ異なる
- その結果、ユーザーは 生産的なフロー(flow) ではなく、操作場所を探す時間 に多くを費やすことになる
-
モバイル移行の影響
- タッチスクリーンの登場 によって、マウス・キーボード中心のデザインパターンが再発明された
- モバイルとデスクトップを同時にサポートしなければならない状況で、中間形態の不完全なUI が広がった
- 例: モバイル向けのハンバーガーメニューがデスクトップでもそのまま使われるケース
- モジュール型コンポーネント再利用の文化 が誤ったパターンを複製し、品質低下を招いた
- 10年以上積み重なった結果、UI/UX 品質の世代的な浸食 が生じた
-
HTML を超えた慣用表現の不足
- 初期のWebには、青い下線付きリンク のような明確な慣用表現が存在したが、現在ではサイトごとにスタイルがばらばらである
- HTML/CSS の標準は厳格だが、実際には多くが React・TypeScript ベースのビルドシステム を使っている
- その結果、標準の HTML 要素の代わりにカスタム実装 が氾濫し、アクセシビリティの問題まで引き起こしている
- 例:
<a>の代わりにonclickが付いた<span>を使うことで、スクリーンリーダーの機能が壊れる - Figma のように WebAssembly ベース で、HTML を完全に離れたアプリも存在する
- ブラウザの 戻るボタン、ショートカットなどの基本機能 が無視され、新しい人間-コンピュータ相互作用のパラダイムが再構成されている
- フロントエンド開発が 速度と可能性重視 で発展してきたため、一貫した慣用表現の定着が難しい
- 数多くのフレームワークとインタラクション形式が存在し、単一標準の確立が構造的に難しい環境 になっている
慣用的デザインの成功例
- Apple は、現代において 強力なデザインの慣用表現を維持している代表例 とされる
- フォント、ボタン、色など全体的なデザインシステムが統一されており、iOS 全体で一貫したインタラクション体験 を提供している
- この一貫性が、「it just works」という信頼感を生み出す
- Substack もまた、限定的なカスタマイズと あらかじめ定められた美的デフォルト によって、安定したユーザー体験を提供している
- Apple と Substack のデザイン原則は、その成功を通じて 業界標準として広がり、最終的に 新たな慣用表現として定着する
プロダクト設計者が従うべき原則
- プロダクト開発者は、可能な限り 既存のデザインの慣用表現に従うこと が、使いやすさと互換性を高める道として示される
- HTML/CSS の基本的な慣用表現を守る: リンクは下線・色・ポインターカーソル・
<a>タグで実装する - 基本的な HTML 要素を JavaScript で再実装しないこと。例: React Button の代わりに
<button>を使う - ブラウザの慣用表現を守る: 戻るボタンが機能すること、URL をコピーしても同じインターフェースにアクセスできること、CTRL+クリックで新しいタブが開くこと
- 一般的な慣用表現から外れる場合でも、組織内では少なくとも一貫したルール を維持する
- テキスト優先、アイコンは最小限に。アイコンは普遍的に理解可能な場合にのみ使う
- 視覚要素では、明確さが美的な美しさより優先される
- 判断が難しい場合は、優れたWebサイトの事例 と 過去のインターフェースデザイン書 を参考にする
- HTML/CSS の基本的な慣用表現を守る: リンクは下線・色・ポインターカーソル・
- 最終的には、Web 上の 日付ピッカーやカード入力フォームがすべて同じように動作する未来 を目指し、 数十年にわたる反復と改善の末に最適な慣用表現へ収束するWeb環境 が理想として提示される
1件のコメント
Hacker Newsの意見
あるアプリでは Enter が送信で Ctrl+Enter が改行（例: Slack）、また別の場所では逆（例: GitHub）。
この一貫性のなさは、ユーザーにとってかなり混乱する。"慣用的なデザインを復活させよう"と言うものの、肝心の共通した慣習が足りないのが問題だ。
今ではキーが1つに統合され、一般に複数行入力欄では Enter が改行、Ctrl+Enter が送信になっている。
一方でチャットアプリは短文入力が多いため、逆に動作する。良いアプリはこれを設定で切り替えられるようにしている
どの組み合わせが改行かは表示されるものの、依然として分かりにくい
意図は理解できるが、使い勝手はひどい
最近のソフトウェアは、昔のように思慮深い設計者が作っているわけではない。
その代わり、急いで昇進した PM や Product 担当者が主導し、収益のためのダークパターンまで奨励されるのが現実だ
UX の一貫性と情報アーキテクチャ（IA）の重要性を強調しなければならない。デザイナーも問題解決者であることを忘れてはいけない
例えばクレジットカードフォームを作る際には、コピー＆ペーストの許可可否、古いブラウザ対応、アクセシビリティとセキュリティのバランスなど、無数の変数がある。
参考までに Steve Yegge のプラットフォーム記事 も、こうした複雑さをよく説明している
システムフレームワークは慣用的な UIを作る土台だった。
Win32、AppKit、UIKit は細部まで面倒を見てくれるので、開発者は自然と一貫した UX に従うことになった。
一方、Web にはそれがなく、すべて自前で実装しなければならないため、結果として半端にできた UIが多い
Web は最初から文書中心で標準的なアプローチがなく、のちに Bootstrap のようなものが現れて一時的な標準が生まれた
実際、日付ピッカーやカード入力は標準 HTML コントロールを使うべきだ。
そうすればブラウザが OS レベルの安全性と利便性を提供できる（例: Safari は Apple Wallet、Android は Google Pay と連携）
しかし Web とモバイルはまったく異なる箱庭的な環境であり、こうした一貫性は崩れた。
例えばデスクトップの右クリックをモバイルの長押しに統一する機会はあったが、一貫して推進されなかった
アプリ UI を作るには文書 UI の上に重ねる必要があるため、衝突が生じる。
ブラウザはこれを緩和してきたが、根本的な改善ではない
日付ピッカーは本当にUX の悪夢だ。
ユーザーが直接日付を入力しようとすると止められ、無理やりクリックさせられることが多い。
入力ミスだけ防げばよいのに、わざわざ不便にしている
アナログ時計型のピッカーのほうが直感的なので、これが標準になってほしい
国際的なユーザー向けなら YYYY-MM-DD 形式が安全だ
50年前までスクロールさせられ、自分の年齢だけを痛感させられる
最近はUX 品質の低下がひどく、特に銀行の Web サイトで目立つ。
スクロールバーの非表示、無駄な余白、フラットボタン、分かりにくいアイコンなどで、昔のデスクトップ UI よりはるかに使いにくくなっている
GCP や Google のツールは不必要に複雑で、枠のない入力欄などによって UX を損ねた。
幸い、最近ではこうしたスタイルは時代遅れと見なされつつある
昔の Mac 由来の概念の1つに、ボタンのテキストの末尾に**省略記号（…）**がある場合は追加の入力が必要だ、というものがある。
一方、省略記号のないボタンは、クリックした瞬間に動作が完了する
「アイコンより単語を優先せよ」という意見に共感する。
ほとんどの人は単語の認識速度のほうがアイコンより速い
テキストの説明がなければ、まるでロシアンルーレットのようにクリックして意味を確かめるしかない
最近 CSS という新技術を発見したのだが、宣言的にレイアウトを定義し、DOM ベースで階層的なスタイルを適用できる。
クライアントとサーバーの負荷を減らし、スタイルシートの共有やユーザーごとのテーマ作成も簡単になる。
これを "no-framework" UI パラダイムと呼びたい
サンプル画像
しかも「クライアント負荷を最小化」は神話にすぎない。実際にはもっと遅い
私たちが失った共通機能:
Undo/Redo、ヘルプ（F1）、マウスオーバーのヒント、ショートカットのカスタマイズ、メインメニュー、ファイル/ディレクトリ、ESC で閉じる、ドラッグ＆ドロップなど
かつて革新的だった機能の数々が、今ではモバイルや Web でほとんど消えてしまった
多くの問題は、ビジュアルデザイナーが製品設計に流入した結果でもある。
デザイン職の役割の混同はいまだに解決されておらず、実際には「デザイナー」が不要なプロジェクトにまで、あまりにも多く投入されているのが現実だ