ユーザーインターフェイスデザインの未来:次世代UIツール

公開: 2022-03-11

UIデザインツールは、動的なユーザーインターフェイスを作成するのではなく、写真を編集することを目的としたプログラムであるAdobePhotoshopの第1世代から長い道のりを歩んできました。 Adobe XD、Figma、Sketchなどの現世代のツールにより、私たちの仕事はより簡単かつ迅速になりました。

しかし、日常のワークフローには非効率性がたくさんあり、人々が使いたい製品を設計するために貴重な時間とリソースを浪費しています。 現在利用可能なデザインプログラムは、私たちが始めたものよりも優れていますが、現在のテクノロジーを活用できず、UIデザイナーとしての可能性を最大限に発揮できません。

新世代のUIツールが登場しました。

デザインとコードの統合

将来のユーザーインターフェイスツールは、設計とコードを統合して、設計者と開発者によりシームレスなエクスペリエンスを提供します。 現在のツールは、WebUIの設計に役立っていません。 それらは、WebUIの抽象的な表現を設計するのに役立ちます。 FigmaとSketchで作成されたモックアップは、ソースコードから切断されます。

今日、多くの設計者はHTMLとCSSの基本を知っています。 一部の強硬派はコードで設計しますが、それは複雑なプロジェクトには効果的ではありません。 設計者は、概念実証に取り組む前に、概念実証を迅速に調査する能力を必要としています。

ソフトウェア開発者は、コードの編集と開発を統合し、エンジニアが同じ環境でコードをビルド、テスト、およびデバッグできるようにするツールであるVisualStudioCodeを使用しています。 同様に、設計者は、完全な設計機能を提供しながら、本番環境に対応したコードを生成するビジュアル開発環境を必要としています。

これが未来がどうなるかです。

並列作成は、デザイナー/開発者のハンドオフに取って代わります

特にハンドオフフェーズでは、設計者と開発者の間で行き来が多すぎます。 場合によっては、引き継ぎは非常に時間がかかり、疲れ果てて、作業の質が低下します。 ソースコードとインターフェイスする次世代の設計ツールにより、開発者はUIの構築に単独で責任を負うことはなくなります。 代わりに、製品のUIをバックエンドに接続して適切に動作させる論理アーキテクチャの開発に集中できるようになります。

設計者はコードを焼き付けてUIの基礎を築き、開発者はこのコードに基づいて製品に命を吹き込みます。 設計者は、「モックアップに示されているように、8ピクセルではなく16ピクセルのパディングを追加してください」などの要求で開発者を悩ませる必要がなくなります。 また、開発者は、「このコンポーネントをタブレットとデスクトップのブレークポイント間でどのように拡張する必要があるか」などの設計上の質問をするために一時停止する必要はありません。

代わりに、設計者と開発者は、時間と予算を考慮して設計アプローチが実行可能かどうか、またはUIコンポーネントのすべての状態に対処したかどうかなど、より重要な問題について提携します。

デザインUIツールと開発者ソフトウェアが連携します

現在のツールは、設計コンポーネントを生成するために特注のプログラミングモデルに依存しています。 これらのモデルは通常、CSSほど堅牢ではなく、設計者が設計ファイルの基礎となる自動生成されたコード(最終的にHTML、CSS、またはJavaScriptにエクスポートする必要があるコード)を表示することはできません。 ツールでHTMLとCSSをネイティブに使用すると、はるかに簡単になります。

たとえば、CSSはボックスモデルを使用します。このモデルでは、高さ、幅、境界線、およびパディングを定義するようにコード化されたボックス内の各ページにHTML要素を配置する必要があります。 Figmaは、自動レイアウト機能でこの機能を提供することに近づいています。 しかし、FigmaがすでにほとんどのWeb UIを強化しているボックスモデルを使用している場合、開発者は翻訳とエクスポートを少なくする必要があります。

同じことがスタイル継承にも当てはまります。スタイル継承は、デフォルトと同様に、特定の要素にスタイルが指定されていない場合に何が起こるかを制御します。 CSSはそれを使用しますが、Web固有であるように作成されていないほとんどの設計ツールは使用しません。

静的なアートボードやモックアップではなく、Webビューを出力するためのツールが必要です。 HTMLやCSSシミュレーターは必要ありません。 HTMLとCSSが必要です。

2つの重なり合う青い円。左の円にはUIDesignerというラベルが付いています。右の円には「フロントエンド開発者」というラベルが付いています。左の円には「次世代設計ツール」、右の円には「Complex Logic(Javascript)」と書かれています。それらが交差する紺色の真ん中に、「レイアウト(HTML)」、「スタイリング(CSS)」、「シンプルロジック(JavaScript)」と表示されます。
次世代の設計ツールはソースコードと直接インターフェイスし、使い捨ての成果物を排除し、設計者と開発者が同じ成果物であるソースコードで共同作業できるようにします。

モックアップは廃止されます

使い捨てのモックアップの代わりに、モックアップをドアの外に投げましょう。

モックアップでは、多くの質問に答えられません。 すべてのデジタル環境に対応するように設計することは不可能です。 現在、デザイナーは画面幅が320ピクセル、834ピクセル、1440ピクセルのレイアウトを作成しています。 しかし、レイアウトの一部が1220ピクセルのビューポートで壊れた場合はどうなりますか? そして、今日の大型電話で一般的なサイズである375ピクセルに最適化してみませんか?

暗いテーマは言うまでもなく、すべてのブレークポイントとビューを考慮する場合は特に、すべてのシナリオにアートボードを作成することは実用的ではありません。 これらすべての変数を考慮して設計すると、アートボードの数が理由を超えて複雑になります。

モックアップもリソースの浪費です。 それらは構築に時間がかかり、デジタル製品の設計ではあまり目立たなくなりました。 Webflowはモックアップを廃止し、代わりにレスポンシブでインタラクティブなプロトタイプを提唱しています。 (残念ながら、WebflowはWebベースのソリューションに限定されており、単純なWebサイトに対応しています)。 使い捨ての成果物は、構想の際には意味があるかもしれませんが、ソリューションの段階では無駄になります。

すべてのシステム状態が考慮されます

すべてのデジタル製品には、特定の瞬間に実行していることに対応する状態があります。たとえば、ロード中のストールやエラーメッセージの表示などです。

すべての状態を考慮する必要がありますが、現在のUIツールはこのタスクを設計者に任せており、単一のコンポーネントの多数のバリアントを作成する必要があります。 開発ツールのReactとVue.jsを使用すると、開発者はコンポーネントのすべての可能な状態を簡単に調整できます。 設計ツールは、すべてのコンポーネントの状態が設計されていることを確認するために、それに倣い、設計者を奨励する必要があります。

Storybook.jsのスクリーンショット。左側はメニューで、最初のヘッダーはライブラリです。その下には「チャート」という言葉があり、その下には「ヒストグラム」と書かれています。その下の次のレベルには、3つの状態がリストされています。最初の「デフォルト」が強調表示されます。ページの主要部分には、「レイテンシー分布」というヘッダーが付いた棒グラフがあります。その下にコントロールのリストがあります。
Storybook.jsは、リポジトリのUIコンポーネントの百科事典として機能します。 コントロールを微調整すると、考えられるすべての状態のコンポーネントが表示されます。 設計ツールは、製品のコードベースから切り離された孤立したサイロではなく、この方向に移動する必要があります。

実際のデータがプレースホルダーコンテンツに置き換わる

設計者が複数の状態のコンポーネントを作成するのと同じように、さまざまなデータの設計も行います。 UI設計者は、実際の入力(コピー、画像、日付、名前、タイトルなど)を使用してコンポーネントをテストできる必要があります。これにより、最終的にコンポーネントがデザインに組み込まれます。 現在、設計者はデータを手動でコピーしてアートボードに貼り付けることによってのみデータをシミュレートできます。これは非常に面倒な作業です。 このプロセスを自動化するのに役立つプラグインがありますが、それらは面倒です。

コンポーネントがデータを処理する方法を評価するように開発者に依頼することも、答えではありません。 コンポーネントがテストに入るまでに、コンポーネントを再設計するには時間がかかりすぎます。 また、設計者が実際のデータを使用してコンポーネントをテストおよび反復できない場合、カードが長いタイトルで機能するか、タイトルがまったく機能しないかをどのようにして知ることができますか? フォントがアラビア文字をサポートしていないこと、またはサイトが右から左に読み取られる言語に対応していないことをどのようにして発見しますか?

Googleマテリアルデザインの「ページタイトル」コンポーネント。左側は、タイトルを左から右に読んだ場合のコンポーネントの機能を示しています。画像の下の列には、画面の端からのアイコンのパディングの量、画面の端からのタイトルの距離、タイトルの下のパディング、ナビゲーションバーの高さ、オーバーフローメニューのパディングに関する情報が表示されます。右側には、アラビア語で同じページタイトルコンポーネントが表示され、右から左に読み取られる言語のコンポーネントがどのように機能するかを示しています。画像の下の列には、画面の端からのアイコンのパディング、画面の端からのタイトルの距離、タイトルの下のパディング、ナビゲーションバーの高さ、オーバーフローメニューのパディングに関する情報が表示されます。
マテリアルデザインはデフォルトで双方向性をサポートしています。

エッジケーステストがより簡単になります

UIツールが最終的にすべての状態に対応し、実際のデータテストを可能にすると、設計者はエッジケースをより適切に予測できるようになります。 コンポーネントが作成されると、設計者はそのさまざまな状態をストレステストし、さまざまなデータでコンポーネントをブラストして、さまざまなシナリオでのパフォーマンスを確認します。 このようにして、UIは設計者のドメインになり、開発者はJavaScriptの修正やAPIのテストなどのタスクに集中できます。

2ブロックのテキストは、異なる言語が必要とするピクセル数の違いを示しています。一番上のブロックには「RepeatPassword」と書かれています。上の赤​​は「英語で210ピクセル幅」と表示されています。テキストの2番目のブロックには、「WiederholenSiedasKennwort」と書かれています。上の赤​​は「ドイツ語で幅380ピクセル」と表示されています。
UIコンポーネントは言語の変更に対応できますか? 見つける唯一の方法は、さまざまなデータでテストすることです。

開発者ツールとサードパーティのブラウザ拡張機能の世界が開かれます

作業がHTMLとCSSで行われると、パフォーマンス、SEO、アクセシビリティの監査に不可欠なLighthouseや、デバイスのブレークポイントと低速のネットワーク速度をシミュレートするさまざまなブラウザー開発者ツールなど、拡張機能のエコシステム全体が設計段階で利用できるようになります。 ブラウザツールセットは、Figma、Sketch、またはAdobe XDのどのプラグインよりも、本番環境に対応したUIの作成とテストに非常に役立ちます。

デザイナーと開発者は並行して作業します

私は、製品開発の現在の状態を、あるシェフが別のシェフに何をすべきかを指示することによって料理を調理しようとしているキッチンに例えます。それはうまくいくかもしれませんが、かなり時間がかかり、はるかに効率が悪くなります。 コードベースの設計ツールを開発している企業があります。Hadron、Modulz、およびRelateにはベータ版の製品があります。 これらのツールが広く採用されることで、デジタル製品の作成に革命が起こります。

また、デザイナーと開発者の関係の根本的な変化を示します。 両者が並行して機能することで、製品チームは飛躍的に効率的になります。 開発者は、モックアップの解釈に時間を浪費したり、ピクセルを完全に微調整するように設計者に求めたりすることなく、UIアーキテクチャの複雑なロジックに自由に取り組むことができます。 また、デザイナーは、成功するデジタル製品の共同ビルダーになるため、チームや企業にとってより価値のあるものになります。