慣用表現に基づくデザインを取り戻そう

私はデスクトップソフトウェアの世代に育ちました。Windows 95 から Windows 7 まで、タブレットやスマートフォンが広まるはるか以前に、マウスとキーボードで操作されるコンピューター上で、ほぼオフライン環境となるソフトを主に使用して成長しました。最近になって私がその時代から特に懐かしむものは、デザインにおける一貫性です。私は、慣用的なデザイン（idiomatic design）について語り、均質なインターフェースの重要性を強調し、私たちが何か大切なものを失ったことを示唆したいと考えています。

ウェブサイトのログイン画面を想定してください。「ログイン状態を維持してもよろしいですか」と聞かれる場面があります。ウェブサイトがこの回答を求めるには多くの方法が考えられます：例えば、「はい」や「いいえ」と入力できるテキストフィールド、あるいは「 ログイン状態で残す」「ウィンドウを閉じたときにログアウトする」を選べるドロップダウンリストなどです。しかし現実には、これらに過ぎないのではなく、常にチェックボックスが使われます。なぜそうなのか？

それは「チェックボックス」というデザインの慣習（idiom）だからです。ユーザーにとって、これを意識せずとも使い方が分かっているほど普遍的なデザインであり、もしあなたがウェブサイトを作り、この質問をする立場であれば、考えることなくチェックボックスを選ぶはずです。構築者も利用者にとっても、誰もが信頼できる標準的なデザインパターンです。また、チェックボックスはインターフェースの一部でもあります。データを投入してシステムと対話するために使用します。インターフェースは、思考を必要とするほど少ないほど良いものです：ステアリングホイヤーかオンラインフォームであれ、その使い方を考えるのに時間をかける必要があればそれは望ましくありません。多くの事物と対話していく中で、一貫した体験をもたらす均質なインターフェースを望みます。Command+C がコピーのキーボードショートカットであることを覚えれば、それをどこでも機能することを願います。状況に応じて CTRL+Shift+C を使うか、あるいは右クリック→コピーを使うかなどを覚えるのは面倒です。

しかしそこで私たちは現在に至っています。ソフトウェアはインターネット上にあり、インターフェースは全く均質ではありません。日付を選ぶ、クレジットカード番号を入力する、あるいはあらゆる一般的なタスクを行うには、数百通りの方法が存在します。キーボードショートカットもアプリごとに異なります。相互作用する方法が多すぎるため、すべてを記憶したり学習することも不可能です。2023 年のウェブアプリケーションを使うとは、「自分がしたいことをどこで見つけようか」を繰り返す練習のようです。

クレジットカード情報を入力しているにもかかわらず、20 年以上経った今なお最適な入力方法について合意が得られていないことは奇妙に思えます。有効期限の日付にはテキストフィールドやドロップダウンリストを用いるのか？先日、私は新しいものを発見しました：各オプションごとにボタンを表示する方法です。

対照的に、デスクトップソフトウェア時代の強みは、デザイン慣習を用いてインターフェース全体に高い一貫性をもたらした点にあります。Windows 2000 のこの画像を見てみましょう。視覚的には少し醜く古めかしい感じがします：ブロック状であり、フォントも優れておらず、色合いも地味です。しかしインターフェースは数点において本当に正解に達しています：

• ファイル、編集、表示といったメニュー構造が標準化されていました。Adobe Photoshop だとしても Microsoft Excel でも、「保存」は「ファイル」、「やり直し」は「編集」、フルスクリーンは「表示」の下にあることを知っていたためです。
• メニューはキーボードで操作可能であり、各項目の下にアンダーライン（例：「File」の F や「New」の N）が表示されており、これがキーボードショートカットを示しています。ALT+F を押してファイルメニューを開き、その後 N を押して新しいファイルを開くことができます。これはパワーユーザー向けであると同時に、ショートカットを学ぶことも容易にします。
• 下部の状態バーには、現在の状態に関するあらゆる情報が表示されます：ページ位置、列、単語数、変更追跡の有無、インサートモードかどうかなど。
• メニュー項目は明確にラベル付けされており、アクションへの主要なインターフェースは文字でありアイコンではありません。アイコンは最も自明な場所でしか使用されていません。 Entire インターフェースは何も想像に委ねていません。上記の画像では「これは何をなさるのだろう？」といった疑問は一切ありません。たとえ以前に使ったことがなくても、使い方は分かっています。

重要なことは、これらのデザイン慣習が Microsoft Word だけでなく、Windows エコシステム全体で使用されていたということです。Windows XP のログアウト画面を見てみてください：それぞれのボタンは視覚的に明確に「ボタン」として認識でき、まさにその機能を記述しています。それぞれにはキーボードショートカットを示す小さなアンダーラインがあり、それは素敵ではありませんか？

デスクトップソフトウェア時代は、均質なインターフェースの時代でした。おそらくこれは、オペレーティングシステムとそれらの GUI ライブラリがデザインの広範な部分を規定し、その制約が開発者が準拠するパターンへと導いたためでしょう。

ブラウザソフトウェア時代は異質なインターフェースの時代です。私が最も気に入っている 2 つのウェブアプリケーションからのスクリーンショットを見てみてください：Figma と Linear です。これらは現在利用可能なエンタープライズソフトウェアの中でおそらく最高峰の 2 つでしょう。そして、チーム設定、抽象的なアイテム階層、協働コメントなど多くの共通機能を有しているにもかかわらず、互いに共通するアイコンは一つも共有していません。デザイン慣習は一切共有されておらず、キーボードショートカットも異なります。どちらも第一原則から非常に良く設計されていますが、ユーザーが既になじみのある他のインターフェースに準拠していません。私たちは個々には優れた設計と有用性を備えたウェブアプリケーションの時代におりますが、すべてはユニークです。同一企業が生み出した製品でも、体験は異質なものです：Gmail の使い方は Google Sheets とは全く違い、Google Docs とはまた違います。全体としてこれは非常に挫かせるものです。均質なインターフェースの欠如は、私がデジタル時間の大部分を生産的なフローの状態ではなく、画面のあちこちで「クリックしても良いのか？これは新しいタブで開くのか？ブラウザの戻るボタンで戻れるのか？」と探す状態で過ごすことを意味します。ひどい！

この一貫性の欠如には 2 つの理由があります：

1. マウスとキーボードアプリケーション向けのあらゆるデザインパターンは、タッチスクリーンの登場に伴って再考されなければなりませんでした。ほとんどのウェブアプリケーションはモバイル環境とデスクトップ環境の両方をサポートする必要があり、それらの相互作用形式は非常に異なります。その結果、その後の多くのユーザー体験は不恰好な中途半端な状態に固定されてしまいました（例：モバイルアプリ向けに用意されたハンバーガーメニューがデスクトップアプリでも使用されている）。したがって、あらゆる場所に悪いデザインパターンが見られます。現代のフロントエンド開発には、モジュラーコンポーネントをコピーして再利用する文化があり、悪いデザインパターンをコピー＆ペーストすることで問題を悪化させるのは容易です。10 年以上にわたるこの慣行は、UI/UX デザインの質に対する世代を超えた腐食効果を及ぼしました。誰もが同じデザイン慣習に従えば、インターフェースはかなり一貫性のあるものになります。
2. インターネットの初期には強力なデザイン慣習がありました：他のページへのハイパーリンクは青色でアンダーライン付きに、既に訪問済みであれば紫色にするなど。素晴らしい！しかし今日では、各ウェブサイトが独自の方法でインターフェース要素をスタイル化するありえない方法を提案しています。あれはリンクでしょうか？もしかするかもしれない！

現代的なウェブデザインがこれほど非慣用的であることは驚くべきことです。HTML/CSS の標準は非常に指示的だからです。問題は、HTML を書くための標準が存在しても、誰も HTML は書かないということです。人々は TypeScript を用いた React や最新のフレームワークを書きます。無数の npm パッケージをインポートし、これらすべてが複雑なビルドプロセスを通じてブラウザで動作する何かを出力します。フロントエンド開発者が这样做ることに間違いはありません。今日のブラウザは非常に強力であり、創意工夫があればほぼ何でもできる一般用途の API を提供しています。例えば Figma は HTML デザイン慣習に従っていません：HTML がないからです；WebAssembly で書かれているため、ブラウザ内でデスクトップ型ソフトウェアを実現する最前線の技術を実装しています。当然ながら、これは「HTML ウェブページ＝ドキュメント」というモデルを崩壊させます。ブラウザの戻るボタンやキーボードショートカットなどが脇に置かれながら、ヒューマンコンピュータインタラクションのパラダイムが再構築されています。

結論として、ウェブデザイン慣習が少ないのは、フロントエンド開発が速すぎるためです。エンジニアは、磨きの問題よりも「何が可能なか」に関心を持っており、当然と言えば當然です。マルチユーザーの実時共同作業はパワーユーザー向けのキーボードショートカットよりも価値があります。無数のフロントエンドパッケージとそれらをデプロイするための相互作用形式が存在するため、広い領域全体に「ワンサイズフィットオール」の慣習を設けるのは非常に困難です。最前線の技術が冷める時間が必要であり、最も成功したパターンが明らかになり、やがて慣習となるでしょう。

しかし、今日の最も成功している製品の組織の一部は、あえて独自のデザイン慣習を積極的になぎすすみ、そのインターフェースにおいて一定の一貫性を達成しています。Apple は良い例です。過去の Microsoft について話してきましたが、現在 Apple は非常に意見のあるデザインシステムを推進しています。Apple のフォントライブラリー、ボタン、色などの一般的なコレクションと、すべてのネイティブアプリケーションやデバイスにわたる一貫性は、サードパーティ製アプリケーションに対して強力な準拠効果を創出しました。iPhone でサードパーティ製アプリを使用する場合でも、キーボードによる入力、ピンチズームなどすべてが iOS によって制御されています。これは Apple の「何でも動く」効果の一部です。強く、味わい深く、慣熟的なデザインこそが Apple の成功の核にあります。

「何でも動く」効果について興味深いのは、それがユーザーをデフォルト値に信頼させ、カスタマイзацию から逃れさせることです。Substack のようなプラットフォームでも似た動的を見ることができます：著者として私はフォントを選ぶことも、テキストを太線にするさえもできません。しかし制限されたデフォルト値は味わい深く設定されており、効果的に機能します。Substack や Apple のデザイン原則は、それらの製品が成功するにつれて採用されるようになり、デザイナーらはそれらを成功した例として参考にしています。それらのデザインは最終的には（1）人々が優れたデザインであると認め合い合うことと（2）コミュニティにおける使用頻度によって慣習となります。

製品構築者としての私は、可能であればデザイン慣習を可能な限り忠実に従うことを望みます。それはソフトウェアを使いやすくし、デバイスやブラウザ間での互換性を最大化するからです。私は以下のような指針に従い、ごく稀にのみこれらを破ります：

• 可能であれば HTML/CSS の慣習を研究し従ってください。例えば、リンクはアンダーライン付きで色があり、マウスオーバー時にポインタカーソルになり、

  <a>

  タグで記述されるべきです。
• JavaScript を用いた HTML ベース機能の再実装を避けてください：React の Button コンポーネントを使う代わりに、スタイリングされた

  <button>

  要素を使用してください。
• 可能であればブラウザの慣習を研究し従ってください。戻るボタンは常に機能するべきです。URL をコピー＆ペーストすれば同じインターフェースに戻るべきです。ナビゲーション要素をクリックした場合は新しいタブで開かれるべきです。
• 一般的な慣習から逸脱する場合、あなたのデザインが完全に内部一貫性を有しており、少なくとも組織内では「慣習的」であることを確認してください。
• アイコンではなく文字を好んでください。普遍に理解されるアイコンのみを使用してください。
• 不確かな場合は、視覚要素を明白に見えるようにしてください。「これはボタンなのかタブなのか？」という混乱は決して起きないべきです。
• 易しく理解できるものを、視覚的に美しいものよりも優先してください。
• 行き詰まりの場合には、判断を助けるために 2 種類のリソースに頼ってください：あなたが知っている最高に良く設計されたウェブサイトと、過去の年代におけるインターフェースデザインの書籍。今日の多くのインターフェースデザインの問題は新しいのではなく、歴史の繰り返しであり、過去の解決済みのアナロジーが存在します。

私が夢見るのは、インターネット上のすべての日付選択機能やクレジットカードフォームが完全に同じであるようになる那一天です：30 年間の反復的開発と何百万もの試みの後でやっと最高のものへの収束を遂げたときです。また、あらゆるウェブアプリにおいて CTRL-クリックで新しいタブに開かれるようになる未来も夢見ています。それが嬉しいですね…

この記事についての議論 さらに準備就绪ですか？