| title | description | category | published | hidden | project |
|---|---|---|---|---|---|
我々はフィグマでKiwi.comの設計システムを扱う方法 |
In depth presentation of how we structure our files, what principles we follow, and how we work with our design system in Figma. |
Design systems |
true |
true |
kiwicom |
Original, 🇺🇸 English translation is available here. If you feel like something is wrong with this Japanese translation, please comment or edit this file.
のモバイルデザインチームは2つだけ私たちのがありますが、ごくわずかです。 しかし、いくつかの方法で、私たちのデザインに貢献周りに20人があります。 彼らは、私たちの最新の反復についてコメントコピーを固定、またはクロスプラットフォームの機能を設計しているかどうか。 軌道は、私たちのデザインシステムであり、現在、私たちのフロントエンドは、スケッチに設計されています。 オービットの可動部分が視覚的に異なっているので、しかし、我々はフィグマでそれを設計してみてください、それが私たちのためにどのように動作するかを見ることにしました。
- なぜフィグマに当社のモバイル設計システムを構築しました
- 最新のアップデートは、我々は仕事のやり方を変えどのように
- 私たちが（例で）私たちの設計システムを設計しましたどのように
スケッチ指向のワークフローでは、要約バージョン管理をカバーするために、ハンドオフを処理するゼプリンのようなツールに依存している、とマーベルは、静的なプロトタイプを設計します。 しかし、時々、物事が同期して取得します。 プロトタイプは、最新のテストの反復にはまり、人々は抽象へのコミットをプッシュするのを忘れ、多分ゼプリンは、最新の承認ビジュアルに更新されていない、またはDropboxの紙に埋め込まれたPNG画像は、3週齢で。 これらのツールは、設計により、同期から抜け出すためにバインドされています🤔
私はKiwi.comに入社する前に、私はフィグマをしようというアイデアで遊んでいたが、私はそれを取得することは困難でした。 私はそれを使用して非常に多くの価値を見ていない、と同期してすべてのツールを維持する必要がちょうどありませんでした。
never! :D I would rather move to iPad than a browser.
— Denis Rojčyk (@rojcyk) October 19, 2017
私もそれにブラウザ/クラウドアプローチにより延期されました。 私は私が望んでいた時はいつでも、私はスケッチを起動できることが好きで、それがネイティブのmacアプリです。 そしてそれは、あなたが雲の中にすべてのものを持っているのいずれか、それが同期して、100％の時間だ、またはあなたが非同期化ワークフローでオフラインのものを持って周りに方法はありません、私を襲いました。 だから、私は最初に、フィグマで作業をほんの少しを試みたが、私はそれをたくさん言っています。
それから私は、最後の11月Kiwi.comに参加しました。ヴォイタは、一度にモバイルでそこ作業だけでした。 彼はすべてのプラットフォームと自分ですべてのデバイスをカバーしました👏。 彼は素晴らしい仕事をしていたが、彼の作品は、その背後にある一貫したシステムを欠いていました。
You will eat your own words in a ~year 😆
— Robin Raszka (@robinraszka) October 19, 2017
我々はそれを試してみたかったが、チーム全体なしフィグマに賭け、そしてそれに軌道を設計、悪いコールのように思えました。 フィグマチームは中見出しされるものの方向は非常に明確ではなかった、と彼らは焦点を当てるだろうか。 また、機能のいくつかは、単に非常に準備ができていませんでした。 そして、まだ、私たちは、しかし、モバイルだけで、とにかくそれをしようとすることを決めました。 当社のフロントエンドと軌道がまだスケッチに設計され、維持されています。
最近まで、管理コンポーネントが痛みました。 これは、設計システムをスケーラブルにするための機能を欠いていました。 あなたが効率的にDSで作業したい場合は、単一のファイルに限られていました。
幸いフィグマは巨大な3.0アップデートを導入しました。 私は（ちょうどリンクをたどる）ここで多くの詳細に入るが、基本的に更新しません:
- メイドは、有効化、無効化、および簡単な更新を管理します
- ファイル間でオーバーライドしてコンポーネントを共有するための有効なユーザー
- レイヤーごとに異なるスタイルを共有するための有効なユーザー（それは色やエフェクトを使用してテキストのスタイルを組み合わせることができますよう、スケッチよりそれがよりアトミックになり）。
私たちは、新しいライブラリコンポーネント、または設計システムに、他の追加を設計するたびに、我々はUXの原則のカップルを追跡してみてください。 これは効率的で、一貫性を維持し、で動作するように簡単にライブラリを確認する必要があります。
コンポーネントの操作とそれらを入れ子にすることは、最初はかなり強力なようです。 あなたが知っているようしかし、偉大な力で大きな責任が伴います。 これは、船外に行くとオーバーデザインシステムを設計することは非常に簡単です。 私は約2レベルを行くことに深い使いやすさと可能性の最適なバランスを提供することを発見しました。
用語ヒットボックスは、それはあなたがあなたの対戦相手にダメージを与えるためには、ヒットする必要がある地域で、FPSゲームから来ています。 私たちの場合、それはあなたが編集したり、レイヤーを選択するために、ダブルクリックする必要がありエリアがあります。 時には層を注文すると、あなたは物事を大きくするために必要がある場合があります十分な、他の回です。 あなたがで作業することが容易に確認する必要がありいずれかの方法:)
コンポーネントオーバーライド提案は部品のサイズに基づいています。 あなたが何か他のものでコンポーネントを交換したい、とあなたが提案窓からそれを選択したいときに、それは同じサイズにする必要があります。
それは本当に私たちがデザインファイルを構造化するために使用するすべての小さなものが含まれている個別のファイルを、定義することができます。 「ヘルパー」というファイルを作成しました。 これは、視覚的要素を区別するのに役立ちますし、あなたのキャンバスに構造の感覚を与えます。 私たちも、非デザイナーと、会社でみんなと一緒にこれらのファイルを共有するので、我々はこれを行うと、彼らはしばしば、文書をナビゲートするために、いくつかの視覚的なヘルパーが必要です。
当社は、グループで私たちのすべてのコンポーネントを包みます。 このように、彼らは、ファイルコンポーネントライブラリにサイドバーを乱雑にしないでください。 これは、コンポーネントの多くはるかに簡単にページでの作業になります。 これは私がスケッチでかなり多くを逃すものです。
私たちのデザインで写真や他のビットマップで作業する場合、我々は、彼らがウェブ資産になるかのように、我々は彼らと仕事します。
- 私たちは、画像を最適化する： ImageOptim、Optimage、tinyPNGなどのようなツールで。 フィグマが何らかの最適化を行う場合、私は、よく分からないが、我々はとにかくそれを行います。 -**ファイル形式を最適化します：**シンプルなイラスト用のPNGと写真用のJPEG。
- **私たちは、資産のサイズを変更：**私たちは、一般的に私たちのモックアップでビルボードのサイズの写真を必要としません。
この練習の後には、私たちのファイルとライブラリコンポーネントのダウンロード時間を改善します。 また、手間の少ないファイルを再度開くことができます。
あなたは簡単に自分で使用することができますので、私は、次の例を再作成しました。 ただ、それらをコピーし、あなたのワークフローにそれらを適応して自由に感じます。
プロジェクトまたはフローごとに一つのファイル。 私たちは、場所ピッカー、日付ピッカー、検索および類似のようなファイルを持っています。 あなたは2つのファイルを接続し、そこからプロトタイプを作成することはできませんので、しかし、これはまた、独自の問題を抱えています。 しかし、それでもまだ、これが最善の解決策の管理が賢明です。
私たちは、標準X.Yの命名規則を使用してプロジェクトの異なるバージョンとしてページを使用します。 XはYより小さな反復しながら、巨大なバージョンの更新を表します。 トップの最新の繰り返しでは。 私たちは、メインUIライブラリに移動することを検討コンポーネント候補をホスティングおよびコンポーネントページ。
それは小さなことのように思えるかもしれませんが、あなたは、ファイルやプロジェクトの多くを持っているときフィグマをナビゲートすることは痛みをすることができます。 ファイルのタイトルは動作しますが、彼らが高速でスキャンすることは困難です。 私たちがカバー画像を使用する理由です。
If you have only one frame in @figmadesign file first page, and you set the frame size to approx 1240x660 (or the same ratio), you can use it as a file cover. Helps with the file organisation a bit. pic.twitter.com/w1CWxNXxAt
— Denis Rojčyk (@rojcyk) February 12, 2018
唯一のモバイルチームは現時点でフィグマを使用しているが、それは将来的に変更される可能性があります。 だから我々は両方のモバイルおよびフロントエンドライブラリをサポートした方法でファイルを設定する必要がありました。
私は少し先にこれを述べました。 それだけで私たちのチーム体制を支援し、ファイルを移動するために使用されているカップルのコンポーネントがあります。 私たちは、ページ、カテゴリを使用し、セクションでは、異なる構成要素を区別するために、コメントは直接フィグマを使用していない人のために存在し、かつカラーサンプルは、私たちのトークンのライブラリです。
このファイルはほとんど触れていません。 これは、全体の設計システムの最も基本コンポーネントが含まれています。 色、タイポグラフィ、そして影：ファイルには、3つのページがあります。 基本的にすべてが、あなたは部品を除いて、フィグマライブラリで定義することができます。
このファイルは、非常にまれにしか触れていません。 我々はすでに我々が使用する色を定義しました。
タイポグラフィは色と同じです。 我々はすでに我々が設計システムに必要なすべて（それはいくつかのFEフォントスタイルの定義が欠落している）を定義したため、稀にしか触れていません。 上記で定義されたタイポグラフィではなく、単純なようだが、他の共有スタイルと組み合わせたとき、それは我々がモバイル上で必要なものがすべてです。
影が、我々はまだで実験している何かをしているが、これまでのところ、我々は4つの標高レベルを定義したが、これは私たちのためにうまく動作するようです。
アイコンは、彼らはすべての異なるセクションに分割され、自分のページを持っており、24×24フレームに配置されています。 ほとんどすべてのアイコンが標準装備されています Material Design Icons.
イラストは、アイコンと非常によく似ています。 それは私たちの製品イラストの完全なだけの巨大なキャンバスです。 彼らは皆、同じサイズを共有しています。 しかしフィグマにSVGのいくつかの輸入制限により、我々は今のビットマップと仕事をしなければなりません。
当初、私たちは、iOSとAndroid用の2つの異なる移動図書館を持っていました。 彼らは多くのことをオーバーラップするのでしかし、我々はそれらを結合することに決めました。 私たちはこの方法でそれを維持することは簡単です。 しかし、UI要素のいくつかのプレゼンテーションの違いはまだ例のスイッチと、このようなために、残っています。 これはまだ進行中の作業であり、我々は、Android少しに追いつくために必要があります🙂
フィグマ3.0リリース前の機能に欠けていたが、私の必須アイテムのほとんどが追加されている、それは他のツールに深刻なライバルになりました。 それに設計システムを構築することは比較的容易であることが判明しました。 実は私はフィグマでそれを管理するように感じるが、他のツールに比べてはるかに簡単です。 これは完璧されるものではないが、それはほとんど私の好みに合います。
我々は、設計、システムのロジックを当社のファイルを構造化して分割する方法が絶えず更新のたびに進化していますが、この記事で言及したものは、私たち最長で立ち往生し、本当に効果的であることが判明しました。
今後の記事で、私は実際には、フィグマにネストされたコンポーネント、および他のいくつかのヒントでの作業の背後にある落とし穴のいくつかを設計システムを構築する方法をカバーしたいと思います。 これは右のあなたの路地までに何かあれば、それはアウトだ後はそれについて知っている最も安全な方法は、以下のサブボタンを粉砕することです👇