実際のUX戦略。 パート3-プラットフォーム思考

UX戦略に関する一連の記事の最初の部分では、UXの体系的な開発に必要な一般的なビジョンとデザイナーについて説明しました。 彼の仕事の結果はどうでしょうか？



多くは、アーティファクトとそれらを作成および調整するプロセスについて考えることに慣れています。 ユーザーと市場を調査し、シナリオと情報アーキテクチャを検討し、スケッチとプロトタイプを作成し、設計レイアウトとガイドラインを準備し、開発に提供します。 そして、このすべての後、市場での製品の適合性と望ましい品質レベルに達するまで、実際に何が起こったかを見て改善します。 このアプローチは一般に正しいものですが、コンベヤーに近いプロセスを使用する従来のスキームでは、アーティファクトのために多くの時間が消費されます。 このすべてが焦点と責任を侵食します。多くの努力が製品自体ではなくサイドドキュメントの研磨に費やされます。 また、これらのTalmudsのほとんどは、製品チームの参加者間で知識を伝達するためにのみ必要であり、すぐに陳腐化するため、トランザクションコストも高くなります。 良くない



この記事では、ドキュメントを使用して思考を停止し、プラットフォーム思考に移行する方法について説明します。 設計者は、新しいデザインや特定の機能を立ち上げるための一時的なプロジェクトとしてではなく、市場での立ち上げおよび全体的なプラットフォームの開発として自分の仕事を認識する必要があります。 その後、製品は体系的に成長し、会社のUX戦略は、運用、戦術、戦略のすべてのレベルで機能します。

UX製品への体系的なアプローチ

製品の体系的な開発のための古典的なソリューションは、ガイドラインとパターンライブラリです。 製品ラインでの作業中に遭遇する典型的なインターフェイスソリューションについて説明します。 使用ルールや、デザイナー、マネージャー、開発者、テスターが画面、製品、チーム間で一貫性を保つのに役立つその他の有用な詳細情報も含まれています。 もちろん、既製のソリューションを使用することで、コストを削減し、開発をスピードアップします。 これらは大企業にとって重要ですが、定評のある製品を使用する中小規模の組織にとっても同様に有用です。 そして、ユーザーの一貫性と親しみやすさが快適さを向上させます。



しかし、通常の意味でのガイドラインは、追加の手順でソリューションを渡す必要がある別の静的な成果物です。 「 ガイドライン→レイアウト→レイアウト→実装 」というチェーンが生まれ、各段階で詳細が失われ、バグが生成されます。 これにはいくつかの問題があります。

• デザイナーは、開発者はドキュメントを読んでいないとよく言います。 しかし、率直に言って、複数の人々が同期する必要がある場合、彼ら自身も愛しています。
• 仕様による設計は、一度に複数の製品に対して行われる場合、100％を実装することは困難です。 まず、仕様自体に定期的な更新が必要です。新しいパターンが出現するか、既存のパターンに対するより成功したソリューションが見つかります。 第二に、再設計中、彼らは何かを実装する時間がないかもしれず、サービスは「ほぼ洗練された」状態で起動します。 そして、製品ライン全体は「ほぼ同じ」です。 そして、参照設計とは何ですか？ もちろん、リファクタリングすることもできますが、結果的に高価になります-製品ごとに絶えず実行する必要があります。
• これにはすべて、実装の品質を制御するための多大な労力と設計者の多大な時間が必要です。 これは高価で疲れる。 同じことを定期的にレンダリングするルーチンは言うまでもありません。
• 設計の更新により問題が強化されます。 やり直しが必要です-やり直して制御、やり直して制御...
• 設計実験も費用がかかります。 また、付随的なアーティファクトの生成を強制し、その結果、エントロピーを増加させます。

アドック！ また、アダプティブデザインのような重要な「ニュアンス」についても話していません...この場合、多くのデザイナーがより多くのデザイナーを採用しています。 しかし、体系的に考える人は、設計と技術の交差点で解決策を見つけようとしています。 リファレンスデザインを静的ドキュメントから実装レベルに転送することによってのみ、チェーンを「 ガイドライン=設計=レイアウト→実装 」に減らすことができます。 これは、製品の実装、改善、サポートのためにhemoの束を取り除くことを意味します。

設計と技術の統一

多くの大企業はすでにこの方向に向かっています。これにより、生活が大幅に簡素化され、ビジネス開発で手を自由に使えるようになります。 優れた設計は、手早く実現することは不可能であり、安価かつ迅速に入手できます。 この技術的な解決策は何でしょうか？ 2つのオプションがあります。小さなBootstrapを作成すると簡単になり、より複雑になり、コンポーネントの完全なシステムを作成できます。



最初のオプションは、作成が安価で高速です-簡単なサポート、低コストの設計実験、簡単なプロトタイピングからすでに利益を得ています。 実際には、実際の製品で使用すると壊れる可能性のあるHTML / CSSスタイルのセットを使用するだけです。 過去数年にわたって、この主題に関する多くの先見の明のある記事がありました。たとえば、 Mark OttoやDave Rupertからで、 多くの企業がこの原則に取り組んでいます 。



speakerdeck.com/mdo/build-your-own-bootstrap



2番目のオプションは作成するのにより費用がかかりますが、出力では、設計実装の品質が保証され、製品の更新が簡単であるというすべての利点があります。 Mail.Ru Groupの私たちはこの方法を採用しました。 このアプローチには、5つの成熟度レベルがあります。

1. 一般的な設計原則は、CSSで定義および保護されています。
2. すべての製品は、単一のコンポーネントに基づいて動作します。
3. 設計原則と一般的なコンポーネントを説明するライブガイドラインがあります。 スクリーンショットではなく実装を示しています。
4. ライブガイドラインに基づいてページのプロトタイプを作成できます。
5. さまざまなアプローチを比較するためのコンポーネント設計実験。

既製のコンポーネントの道を進む企業は多くありませんが、 IntuitのHarmonyエコシステム 、 Rizzoフレームワークに基づくLonely Planetソリューション 、 Yandex.Lego 、そしてもちろん、Material Designを実装するGoogleのPolymer Projectを使用した非常に強力な例があります。





Intuit Harmonyエコシステム



なぜこのアプローチは良いのですか？

• 統一された視覚スタイルとインターフェイスの原則、およびその情報アーキテクチャ。 これはユーザーにとって便利です-同様の製品のグループは、同じように明確で使い慣れています。 また、ブランドにとっても良いことです-サービスの全ラインは全体的に見えます。
• 90％の設計の統一は、開発アプローチによって保証されます。すべての既製のブロックと要素は、単一のコードベースからのみ取得されます。 さらに10％-既成のソリューションを使用するときの注意と思いやり。 理想的なデザイナーであっても、モンスターを組み立てることができます。
• 新製品の発売と既存製品の再設計の簡素化。 フレームワークには、あらゆる場合に必要なブロックとコンポーネントのほとんどが含まれているため、新しいインターフェイスをすばやく組み立てることができます。
• プロジェクトの大規模なプールの制御は、それらが同じ方法で設計されている場合に簡単になります。 何百もの個別のプロジェクトの代わりに、いくつかのガイドラインに従います。
• より少ないレイアウトを描画する必要があります。 既製のブロックからページを組み立てることができ、将来的にはPhotoshopをまったく起動することなく組み立てることができます。 同じことがさまざまな特別なプロジェクトにも当てはまります。
• 成功した製品ソリューションの累積効果。 たとえば、いずれかのサービスの表示深度を上げると、これらの改善を他のサービスに簡単に適用できます。
• 数年ごとの大規模な再設計から、インターフェースの関連性の継続的な維持への移行。 再起動には多くのエネルギーが必要であり、長い間開発に費やされた何千もの小さな開発が失われます。

そして、フラットデザイン後の次のトレンドは簡単かつ迅速にキャッチされます:)もちろん、トレンドの追求は最も称賛に値する仕事ではありません。 ただし、昨年のiOS7のリリースのように、業界では視覚的なパラダイムの急激な変化が定期的に発生するため、企業はそれに迅速に対応する必要があります。



全体として、これはUX戦略の重要な部分です。 しかし、最も重要なことは、フレームワークが技術的な統一にもなったことです。 「シェル」に対して多くのアプローチを行いました。仕様を作成し、単一のソースを収集し、要素のライブラリを作成しました。 しかし、これらはすべて居心地の良いデザインの世界にあり、開発者からの需要が少なかったため、すぐに消えていきました。 そして、レイアウトから実装までの途中でデザインがどれだけ頻繁に「ねじられる」かを知っています。 しかし、コードを修正して一度再配布すると、実際の製品で動作する設計の品質に自信が持てます。 したがって、統合プロジェクトの成功の主な基準の1つは、特定の実装レベルへの移行です。

ビル・スコットは、 NetflixからPayPalに移行した経験を同様の方法で共有しました。 技術的な制限により、PayPalはメインページの簡単なテキストブロックを変更するのに1か月半かかりました。 これは、設計の開発を妨げ、頻繁な実験を不可能にします。 Netflixでの最初の仕事の1つは、開発プロセスを促進することでした。 その結果、サポートされるすべてのデバイスで機能する強力なHTML5フレームワークが作成されます。

手ではなく、デザイナーの頭を使いたい。 ルーチンの削減により、焦点を製品タスクとビジネスソリューションにシフトすることができます。また、目立たないが重要な設計上の問題もあります。



同社も黒字です。 プラットフォームへの製品の移管のエントリー価格を差し引くと、製品の効率を改善するための体系的なアプローチを受け、市場での新機能の立ち上げを加速し、設計の統一を保証します。 共通の言語を話す能力は、私たちが経営陣にフレームワークへの投資を説得するのを助けました。

プラットフォームを構築する方法

画面について考えるのをやめて、製品をプラットフォームとして認識する必要があります。 たとえあなたの会社がそれほど大規模で野心的でなくても、Apple、Google、Microsoftの経験は役に立ちます。彼らはプラットフォームとエコシステムの構築に優れています。 それらを主要なコンポーネントに分解すると-視覚スタイルと相互作用の一般原則、独自のアプリケーションのセット、サードパーティ開発者からの膨大な数のアプリケーション（パートナーやアウトソーシング業者によって作成されたものを考慮）-製品会社の仕事と共通点がたくさんあります。





Android、iOS、Windows Phone



統一は2つの側面から始めることができます。 最初にガイドラインを作成してから、既存の製品に適用します。 または、そのうちの1つのデザインを正常に更新して参照として選択し、その動機に基づいてガイドラインを作成します。 どちらのアプローチにも長所と短所があります。



会社の私たちは2番目の方法に行きました 。 すでに実証済みの設計はスケーラブルであり、分析とユーザー調査で最適化されています。 実際、リリースの直前と直後に、多くの実験とテストが実行され、その後、設計が何度も調整されます。 パスはやや曲がりくねっていますが、結果のパスをリファクタリングし、システムを上から下に構築しています。

Matt McManusは、 連続設計には2つの主要な原則があると言います。 最初に、「最終」設計の概念を放棄します。 設計者は、開発プロセスの始まりだけでなく、開発プロセス全体に関与する必要があります。 第二に、設計者は、PSDのような静的ドキュメントの代わりに、再利用可能なフロントエンドコードまたはインタラクティブプロトタイプを作成する必要があります。

もちろん、製品とガイドラインの両方を同時に作成することもできますが、実際には、一定の反復により、「典型的な解決策を提案した→製品を試しました→いくつかの矛盾を見つけました→チーム全体で問題を議論し、解決しました→製品をもう一度試しました」 .. "。 そして、プロジェクトには何百ものそのような決定があるので、リリースは決して行われません。



蓄積された経験に基づいて、プラットフォームの開発にはいくつかの段階があります。

1.一般原則

統合に関する作業の開始時に、プラットフォーム全体を構築する基本を決定する必要があります。 すべてのレベルで設計の意思決定を促進し、その開発を体系的にします。 すばらしい例は、IBM設計言語です。

宣言または一般的な設計原則

これは、ブランドイメージを特定の意思決定に結び付けるのに役立つ多数のルールのセットです。 つまり、インターフェイスパターンをチェックするための高レベルのチェックリストです。 たとえば、国際的なブランドMy.comの原則の1つは、インターフェイスのすべての作業面の最小限の白い背景と企業の赤い色のドットアクセントを組み合わせて、アイデンティティをより適切に識別できるようにすることです。 同時に、ブランドのもう1つの品質は感情と人格です。 それをサポートし、最初のルールに違反しないように、ジューシーな背景素材が使用され、主な作業領域は白い半透明の素材の上にあります。



原則は、ブランドにとって重要だと思うさまざまなものに関連付けることができます。 たとえば、 Mailchimpは、音声のトーン（インターフェイスのテキスト）に特に重点を置いています。 メトロデザインのマイクロソフトは、クロムではなくコンテンツに焦点を当てることを主張し、アニメーションの特別な役割も強調しています。 そして、これは単一の一貫した体験につながります。



マニフェストはそれ自体では存在せず、会社の全体的な戦略に結び付けられていることが重要です。 設計原則の場合-主にブランディングを通じて。 そうして初めて、彼らは完全な力で働き、デザイナーの次の新しい方法のおもちゃにはなりません。 彼らは会社のマネージャーと他の従業員によって分離され、彼らは本当に意思決定を支援します。 原則の数は覚えておくことができ、それらの間に重複がないように合理的なものでなければなりません。 ガイドとして、 Design Principles FTWコレクションを参照できます。





設計原理FTW

視覚言語

視覚的表現、相互作用ロジック、および情報アーキテクチャの基礎となる特定の原則。 マニフェストが価値のレベルで話す場合、デザインの基本は特定のソリューションに関するものです。 プラットフォームの将来の生活を簡素化するために、すべての定義で高レベルの抽象化に努めなければなりません。



情報アーキテクチャ 。 製品とその対象ユーザーの詳細に基づいて、画面上の機能と使用シナリオを分離し、階層を構築し、それらの間のナビゲーションを提供するための原則を説明する必要があります。 製品ラインについて話している場合、それらは大きく異なる可能性があり、異なるアプローチが必要になります。 したがって、1ページ、階層構造、線形、ネットワーク、ハブ、または複数の組み合わせなど、すべてを一度に記述すると便利です。 各アプローチには、ミニマニフェストのようなものが必要です-使用されるタスク、製品の機能と使用シナリオの転送方法。 さらに良いことに、すべてのニュアンスがあれば-カテゴリとリンクの名前、メタデータの説明、組織体系（アルファベット、地理、年代、テーマ、タスク、聴衆、人気）。



相互作用の原則 。 情報アーキテクチャの原則を実装する特定のナビゲーションソリューション-永続（地下室を含む）およびコンテキストメニュー（表示、右クリックまたはロングクリックで表示）、検索、ブレッドクラム、リストを操作するためのツール（並べ替え、フィルタリング、グループ化、ページング、または読み込み）、コンテンツのコンテキストバインディング、通知システム、アラート。 典型的な画面のモデルでのイラストの配置、および特定の製品の問題を解決するための推奨事項をお勧めします。たとえば、コンテンツをリンクすると表示の深さが増します。



これはすべて、サポートされているデバイスの種類に基づいている必要があります-大型およびモバイルWeb、さまざまなプラットフォーム（モバイル、タブレット、ウェアラブル）向けのアプリケーション。 それぞれに固有の特性があります-制御方法の詳細（マウス、タッチ、音声）、クイックアクション（ホットキー、ジェスチャー）、アクセシビリティ。



インターフェイスグリッド 。 これは、すべてのインターフェース要素が構築されるステップです-それらのサイズとそれらの間のインデント。 現在最も人気のある8ピクセルの1つで、AndroidとGoogleで一般的に使用されています。 iOSは11ピクセル、Windows 8-5ピクセルに基づいています。 8ピクセルピッチは、2にうまく分割されるため、特に便利です。たとえば、ブロックの2ピクセルの丸めを取得できます。 基本ステップは、可能な距離を決定します。 ソリューションは8ではなく4dpに基づいているため、この場合は4、8、16、24、32、48、96、128です。作業の円滑化を完全に伝えることは不可能です。些細なことに関する紛争やエラーの数は1桁減少します。 デザイナーは目ではなく、統一されたルールに従ってサイズを選択します。 確かに、ピクセルの代わりに画面密度（dp）に依存しないピクセルで測定を行うと便利です。



構造グリッド 。 インターフェイスのメインレイアウトが収まる列のセットを定義します。 12列のグリッドは非常に人気があり、ほとんどの一般的なフレームワークで使用されています。 むしろ「リズム」メカニズムを使用しますが、20ピクセルのインデントを持つ40ピクセルの列のセットです。 このアプローチにより、異なる世代のデザインを統合することが可能になりました（1024の場合は16列、1280の場合は20列、1440の場合は24列、1600の場合は26列）。 構造グリッドは、適応性ロジック、つまり異なる解像度でレイアウトがどのように変化するかも定義します。



レイアウトとコンテナ 。 構造グリッドに基づいた詳細-インターフェイスの作業領域の配置方法。 プロモーションサイトで人気のある1つの列？ 2列、ほぼすべてのタスクに対する古典的なアプローチ？ 混雑が原因で使用される列が3つ少なくなっていますか？ Pinterestで人気の無限のカードやタイルのストリーム？ レイアウトでは垂直比も設定できますが、これは一般的ではありません。



各レイアウト列は、コンテンツを持つ特定のブロックのコンテナが次々に配置されるスタックです。 コンテナ自体のレベルで、外観（境界線、背景、影、タイトルなど）およびコンテンツの動作のロジックを設定すると便利です。 これにより、新しいブロックを追加したり、一般的な原則を調整したりすることで、プラットフォームの開発が容易になります。 たとえば、ブロックに画面に表示できるよりも多くの要素がある場合、別のページの完全なリストへのリンクを追加し、「さらに表示」をクリックしてすぐに展開し、ページナビゲーションで分割するか、内部（垂直または水平）にスクロールします。 水平スクロールを選択し、将来的に矢印をやり直すか、タッチスクリーンのスワイプを追加する場合、コンテナーのすべてのコピーを確認する必要はありません。



ポップアップも含まれます。





4メッシュレベル



フォントグリッド 。 ベーステキストからスケーリングするという考えに基づいてフォントサイズを選択する方法は多数あります。 Gridloverサービスは、すべてが可能なようにまとめられています。 インターフェイスグリッドに注目する場合は、4の倍数にする必要があります。見出しの場合、これは簡単ですが、実際には組版に問題があります。 まず、本文の美しい16は特定のインターフェイスソリューションには大きすぎます。 第二に、WindowsでのWebフォントのレンダリングの機能により、多くの松葉杖と回避策が必要になります。 しかし、行間隔がインターフェイスグリッドにある場合、すべてがそれほど悪くはありません-インターフェイスと組版の両方がそれを壊しません。





グリッドセット



カラーパレット 。 ブランドの主要な色によって設定される基礎は、補助的な値を綴る必要があります。 まず、これらはインターフェイスの色です-白と黒（または純粋な値が収まらない場合は色合い）、エラーの色と他のシステムメッセージ（赤、緑、黄色）、リンク、および灰色の線（素材、境界線、補助）テキスト）。 第二に、アクセント-たとえば、コンテンツのカテゴリを示します。 さらに、バリエーションが必要な場合は、変更ロジックを設定できます（たとえば、アクセスできないカテゴリが強調表示されます）。 パレットのすべての色は、ブランドで定義されている主要な色を補う必要があります。



色に加えて、影を作成するための式を説明し、透明度のいくつかの標準パラメータを設定し、背景をぼかします。



コントロールのセット 。 インターフェイスとフォントグリッド、およびカラーパレットを使用すると、基本的な建築要素の作業に体系的にアプローチできます。 ボタン（メイン、通常、追加オプション付き、テキスト、アイコン、ツールバーのバージョン）、リンク、一般および特殊な入力フィールドとドロップダウンリスト（コンボボックス、カレンダー、電話コードのある国など）、スイッチ（チェックボックス、ラジオボタン、トグルスイッチ）、ユーザーコンテンツのダウンローダー（写真、ビデオ、ファイル）。 フォーカス、アクティブ、ガイダンス、利用不可の状態を設定する必要があります。



フォーム要素に加えて、それらのレイアウトを記述する必要があります。 フィールド名の場所、それらの説明テキスト、値の検証とエラー表示のルール。



グラフィックスとイラスト 。 写真やその他のコンテンツグラフィックには標準が必要です。 比率、典型的なサイズ、および異なる解像度のバリエーション。 理想的には、列グリッドに収まる必要があります。 アバターについても同じことが言えます。



良い方法でインターフェースアイコンは一般的なブランディングに結び付けられるべきです-あなたは徐々にそれらの普遍的なセットを開発できます。 イラストも一般的なアウトラインに収まる必要がありますが、ここでは、スタイルに対する一般的なアプローチを説明するだけで十分です。 線の太さ、カラーパレット、ボリューム転送の原則、インターフェイスの配置ルール、および販促資料。 大きいイラストアイコンは、インターフェイスアイコンのメタファーに基づいてより詳細に開発でき、中規模の場合は標準化されたグリッドを設定できます。



インフォグラフィックと視覚化 。 表、一般的な図（円グラフ、棒グラフ、棒グラフ、折れ線グラフ、散布図）、およびよりまれなもの（面積図、円形、花びら、散布図、ベン、サンキー）、地図作成、熱図、タグクラウド、グラフとツリー、フラットツリー、メンタルマップ、プロセスのフローチャートと図、タイムライン、コミュニケーションの図。 このリスト全体は、高度に専門化されたサービスでのみ必要ですが、最も人気のあるサービスを記述する必要があります。



アニメーションモデル 。 理想的には、インターフェースの状態と画面間の遷移は、特定のモデルに従う必要があります。 そうすれば、製品のアニメーションは一貫したものになり、ユーザーはそれを使用して作業しやすくなります。 たとえば、ポップアップは画面の上部から表示され、閉じた後に終了することができます。また、ステップバイステップアシスタントの場合、メインウィンドウが表示された後、新しい状態が右側から表示されます。 たとえば、Android（シンオーケストレーション）、iOS（iOS7以前）、Windows Phone（最新のアプローチの創始者）の3つの大きなプラットフォームのアプローチを学習できます。



広告 広告グリッドは多くの場合、外観を決定し、デザイナーグリッドの制限を設定します。 開発者よりも緊密に営業部門と協力することが重要です-これにより、プロジェクトのデザインやキャッシュフローを損なわない形式を見つけることができます。 広告インベントリを決定する必要があります-メディアとコンテキストブロックの種類とサイズ、ブランドブロックとページの原則、フルスクリーンレイアウトのレイアウト基準、およびその他の積極的なアプローチ。 内部プロモーションのための典型的なソリューションを作成することも役立ちます。 2番目のステップは、実際には、標準レイアウトに広告を配置するグリッドです。





IBMビジュアル言語

コードの原則

プラットフォーム設計の基本原則を定義したら、それらをCSSの中心に置く必要があります。 開発者と一緒に未来に優しいシステムを構築するために、デザイナーがそれを理解することは非常に重要です。 これはまさにこのシリーズの第2部で書いたものです。何らかの形での最終設計は、製品開発のすべての段階で決定されます。体系的に作業する場合は、忘れないでください。 SASSやLessなどの最新のCSSプリプロセッサを使用すると、グローバル変数を設定できます。これは、コードの基本原則を定義するのに最適な方法です。 また、アイコンフォントとSVGスプライトは、補助グラフィックスを便利に操作するのに役立ちます。



一般原則が抽象化されているため、強力なインターフェース数学が得られ、矛盾の可能性が排除されます。 たとえば、ボタンを取得するには、ベースフォントサイズで「保存」を記述し、上、下、および側面からの典型的なインデントを測定し、このスペースをボタン素材の標準色で塗りつぶし、標準色でストロークの輪郭を描き、標準シャドウを下に配置します。 そして、定数が変更されるまで、設計者がお互いにほとんど接触していなくても、この数学はチーム全体を同じソリューションに導きます。 また、これらすべてがコードに組み込まれている場合は、定数を簡単に更新して、製品ライン全体を変更できます。 ニルヴァーナとヴァルハラを同時に！



レイアウトに基づいた典型的なページの構造の例を挙げると便利です。 これらには、ヘッダー、地下室、コンテンツ領域、補助列が含まれます。 これは、ガイドラインの使用の基本をよりよく理解するのに役立ちます。

2.パターンと既製のソリューションのライブラリ

プラットフォーム構築の次のステップは、既成のコンポーネントを作成し、設計全体をそれらに転送することです。 生産チェーンを「ガイドライン=設計=レイアウト→実装」に簡素化するという目標に基づいて、コンポーネントは、特定の視覚スタイル、作業ロジック、ユーザーとの対話を備えた既成のコードです。 それは環境から独立している必要があります-それが壊れることを恐れることなく、どのページでも使用できます。



実際、これは古典的な設計パターンであり、設計者は通常、設計および設計ツール用のライブラリの形で収集し、ガイドラインで説明します。 実装の品質を毎回確認し、成果物のチェーン全体でそれを維持する必要はありません。 また、パターンを変更する場合は、元のコードを単一のコードベースで置き換える必要があります。その後、フレームワークを使用するすべてのプロジェクトで更新されます。



コンポーネントを記述するためにセマンティクスに従うことが非常に重要です。 基本原則への参照の観点から、パターンは「フォントサイズ24」または「カラー素材＃F0F0F0」という特定の意味を使用しませんが、意味は「レベル2見出し」または「カード素材」です。 だから一般的な目的の意味で-メインコンテンツ、トピックに関する情報、追加のバインディング。 そうすれば、製品ライン全体で簡単に更新できるアイデア全体が実際に機能します。



コンポーネントの例：

• ナビゲーション -タブ、インデックス、カレンダー、検索とフィルター、並べ替え、閲覧履歴。
• リスト -リスト、マトリックス、スクロール可能なテープ、非同期タイルレイアウト。
• メディア -ビデオ、インフォグラフィック、フォトギャラリー、ソーシャルネットワークからの投稿。
• 情報提供者 -天気、株価と商品、スポーツ統計、スケジュール、星占い、世界時間。
• ソーシャルインタラクション -コメント、投票、相談、評価、フィードバック、ソーシャルネットワークでの共有。

個々のソリューションに加えて、標準化されたコンポーネントで構成される典型的なページを記述することは有用です。 ニュースリスト、特定の出版物、検索結果、設定、ユーザープロファイル、承認と登録、「ゼロ」状態、サーバーエラーなど これには、メーリングリストテンプレートが含まれます。 , , . , — .



- , , — . . , — , . , , .

3.

, , . , CSS. — , . — . Bootstrap, .



100%. — . «». CSS . — .

4.

, — wireframes . HTML-, HTML- . « ».



, . - , HTML CSS . — . .



, - . , , Axure — . — Polymer Project Google, material. Bootstrap .





Polymer Project



, . «lorem ipsum», . . Sketch .



. , , . .

5.

-, , — . , . , , , . , , - A/B-.



-, — , , ( ). -, , — . , ( ) . , , .

6. ?

. — , , , . .



. , . . ( , , ..) . , . , . Flipboard .



— CMS The Grid , , , . A/B- . — Robofont , . — , . -.





The Grid

, . Bootstrap Foundation — , , . , .



Anna Debenham Brad Frost , . , .





Styleguides.io



Brad Frost , Atomic Design , . , .





Brad Frost «Atomic Design»

モバイルアプリ

. — , .. . -.

— - . :

1. . , .
2. . , - .
3. - . , .
4. . , . .

. — . , . , .



, . — . - — , . . , .



— , . , — . , - . .

合計

, UX- , . , — , .



:

• .
• .
• -.
• .
• — .

, , — . したがって、無限の設計サービスではなく、製品の作業により多くの時間を割くことができます。 .



PSデザイナーと開発者のチーム全体に感謝します。 — , , , , , , , , , , , , , . — , , , , , , , , , , , , , , , , . .



PPSただ極端に急がないでください！仕事への新しいアプローチはキャンセルされませんが、古いものを補い修正します。高度なデザイナーはブラウザーでのみ動作し、Photoshopにとどまった人はすべて祖父だと叫ぶのは愚かです。しかし、古典楽器の枠組みにとらわれ続けることも、あなたのキャリアを埋めるためです。











UXMattersマガジンのために書かれた記事。