これは、企業のChronos CRMの再設計に関する最後の部分になります。 残りのセクションについて説明し、完了した作業についていくつかの結論を導きます。 最初の3つの部分を見逃したばかりの方は、リンク（ first 、 second 、 third）をたどってください。 このプロジェクトに関する私の文章にすでに飽き飽きしている人-コーヒーを飲みに行き、残りはサブカテゴリに深く入り込むことができます ...
ちなみに、Figmaを使用する場合は 、 既製の設計システムに注意することをお勧めします 。 フリーランサーが1か月あたりの注文を増やすのに役立ち、プログラマーは自分で美しいアプリケーションを作成できます。また、チーム作業用の既製の設計システムを使用して、チームが「スプリント」スプリントをすばやくリードできます。
また、深刻なプロジェクトがある場合、当社のチームは、ベストプラクティスに基づいて組織内に設計システムを展開し、Figmaを使用して特定のタスクに合わせて調整する準備ができています。 Web /デスクトップ、および任意のモバイル。 また、React / React Nativeにも精通しています。 Tへの書き込み： @kamushken
タスクマネージャー
システムでは、各トランザクションで常にタスクのリストがサポートされています。 履行のステータスによって、取引がどれだけうまくいくかを判断することができます。 このセクションの詳細にアプローチする最初の試みは、完全に標準的なかんばんの3列で終わりました。期限切れのタスク/今日のタスク/明日のタスク：
各タスクはカテゴリに関連付けられており、色で示されています。 たとえば、円の薄い赤の背景は「解雇」を意味しました。 濃いピンク色は「取引」への言及を示唆しています。 一定の時間が経過すると、従業員は色の組み合わせを習得し、角にアイコンのある円にほとんど気付かないことで、タスクのタイプを判別しやすくなると想定されていました。
上記のレイアウトの各タスクの右隅にある鉛筆が多すぎます。 鉛筆はonhoverを使用して本番環境に表示されるはずです。
これは、インターフェースの設計における近年の良い傾向です。 システムに同じタイプのコントロールが多数含まれている場合は、少しアンロードしてささいなことをするのが理にかなっています。 再び表示するまで非表示にします。 次に、同じタイプのコントロールが接続されているシステムの場所で正確にonhoverイベントに頼って、ユーザーに明らかな関係を示します。 例：ブロックにカーソルを合わせ、このブロックにのみ小さなアイコンを表示します。したがって、それらをクリックすると、ユーザーはこのブロックでのみ拡張効果を得ることができます。 追加のプラスは、視覚的なノイズからインターフェイスをアンロードすることです。
GMDは、仕様に従ってドラッグアンドドロップを設計する方法についてはいたずらに沈黙しています（なぜモバイルデバイスに由来するのでしょうか？）
少し後に、ほとんどの従業員がTrelloを使用していることが判明しました。 いいね！ これで、タスクマネージャを同様の機能に移行すると、堅実な利益が得られるという理解が得られました。 いいえ、クロノス内で独自のカウンターパートを作成することではありません。 4列目といくつかの小さなことを紹介するだけで十分です。 すぐに言ってやった：
上記に慣れるためにしばらくの間、onhoverによって「チートシート」を覗く機会があります。
この「ディスコ」全体の色には、明らかに、より企業的な範囲での改善が必要です。
これは、たとえば編集のために、特定のタスクをクリックするように見えます。
タスクマネージャーインターフェイスの開発は、すべての作業の最終段階でした。 この章では、システムの他のセクションの同じタイプのすべての画面を除外しました。 彼らの配置はあまり意味がありません、なぜなら それらの一般的な外観と相互作用の原則は、前の章で検討したのと同じアプローチに基づいています。 このような作業で最も困難で重要なことは、プロトタイプの最初のステップを検討することです。 そして、他のすべてはすでに承認されたスキームに該当し、何らかの形でルーチンになります。
おわりに
とにかく、ウェブ/デスクトップインターフェースを開発するときにGoogle Material Designを使用する利点はありますか？ 純粋に文体的だと思います-プラスはありません。 これは、ファッションとトレンドに対する通常のオマージュです。 まったく逆です。最初の章で述べたように、これは独立したデザイナーにとって創造的な行き止まりです。 彼は、まったく同じスタイル、フォント、テクニックを使用して、すべてのプロジェクトと後続のプロジェクトの作成を開始すると想像してください。 すべてがルーチンにスライドします！ 彼の仕事を楽しんでいる人は、それをルーチンに変えることはできません。
モバイルデバイスのみに適用されるGMDルールに完全に準拠しているため、デスクトップインターフェースで非効率が発生する可能性があります。 前の章の熱心な読者は、フローティングボタンに対するalreadyりを既に表明しています。 私は完全に同意します-これは論理的なユーザーエクスペリエンスに反します。 「+」ボタンは、「この世界からではない」かのように、右下隅に孤独にぶら下がってはいけません。 その場所は、新しいオブジェクトが作成されるコンテキストで、そのインターフェイス要素の隣になります。 タスクマネージャーの最後の画面に戻る...最初にシステムに連絡するとき、ユーザーはその正当な場所（Googleによる）でフローティングボタンを見ると仮定する傾向があります：「おそらくこのボタンで新しいタスクを作成しますが、 100％自信になります。」 一方、「+」ボタンがトップタイトルの近くにある場合、ユーザーは「このボタンが新しいタスクの作成につながると確信しています」と考えるかもしれません。
GMDは、主にスマートフォンのタッチスクリーンを最適化するために設計されました。 ここでのメインツールは、まだ指です。 そして、プロポーションとインデントのすべての厳密さは、これから正確に続きます。 たとえば、Webオフィスの誰もが作業している間、「マウス」マニピュレーターで操作しています。 したがって、この場合、16x16のアイコンには依然として生存権があります。 GMDルールに記載されているように、要素のインデント、配置、および動作には厳密な依存関係はありません。 わかりやすく便利なデスクトップインターフェイスを作成するだけです。
これはすべてスタイルです。 プレーン内の要素と動的オブジェクトの配置のロジックにより、物事は完全に異なります。 ここで、GMDは大きな一歩を踏み出し、ユーザーにマテリアルである現実世界のエクスペリエンスをより多く提供しようとしています。 経験豊富なインターフェース設計者は、これらのルールを採用する必要があります。 たとえば、動的に生成されたオブジェクトの優先度と位置を示すためにシャドウを操作します。 または、インターフェイス要素をナビゲートまたはクリックするときのアニメーションおよびマイクロ反復のルール。 フォームやドロップダウンリストなどの動作の一般的なロジックも定式化されています。 これはすべて、設計におけるGoogleのルールに従って構築するのに理にかなっています。 それは確かにユーザーエクスペリエンスを向上させます...
ご清聴ありがとうございました。 興味深いプロジェクトと新しい経験をしてくれたPerformance Labに感謝します。