デザイナーとしてご活躍されている方々の中には、Figmaを使用しながら作業をする上でデザインファイルをどのように共有・連携したら良いのか、コンポーネントの作成や設計について悩まれている方も多いのではないでしょうか。
そこで、「デザインファイルを属人化させないFigma活用・コラボ方法 Part2」では、現在すでにFigmaを活用されている方に向けてFigmaを更に効果的に活用していただけるヒントを、ロンドンを拠点にフリーランスプロダクトデザイナーとして活躍されている「キャシさん」に教えていただきました。
Part1はこちら：【イベントレポート】デザインファイルを属人化させないFigmaの活用法を探る。
この記事で得られる学び
- 拡張性のあるUI設計について学ぶことができる
- コンポーネント設計について知識を深く掘り下げることができる
- デザインシステムの構築と維持に大切なことを知れる
- 1.デザインファイルを属人化させないFigma活用・コラボ方法 Part 2
- 2.登壇者紹介
- 3.拡張性のあるUI設計について
- 4.デザインシステムの構築と維持
- 5.コンポーネントの重要さ
- 6.質問コーナー
- 7.まとめ
1. デザインファイルを属人化させないFigma活用・コラボ方法 Part 2
Figmaの活用は、デザイナーがチームと一体となってプロジェクトを進め、デザインファイルの属人化を防ぐ手助けをしてくれます。前回のPart1では、Figmaを使用した具体的なデザインファイルの共有方法と実践方法を教えていただきました。今回は「デザインファイルを属人化させないFigma活用・コラボ方法 Part 2」として、現在ロンドンを拠点にフリーランスプロダクトデザイナーとして活躍されている「キャシさん」に将来を見据えた画面・コンポーネント設計を中心にお話ししていただきます。
2.登壇者紹介
キャシ 氏
プロダクトデザイナー／Figma Community Advocate
Figma Community Advocateとして、Figmaの魅力を発信する勉強会やセミナーで多数登壇。
3. 拡張性のあるUI設計について
デザインが壊れてしまう主な要因
デザインを行う際に、拡張性のあるUI設計はとても大切です。まず拡張性のあるUI設計についてお話しする前に、デザインが壊れる要因としてよくあるものをお伝えしたいと思います。最初に覚えておいて欲しいことは、「度重なるデザイン変更」と「事業側決定の影響」についてです。
例えばスタートアップで多く採用されているアジャイル型開発の場合、開発メンバーだけではなくチーム全体で、開発しているものやデザインするものについて優先度に順番をつけ、短いスパンで納品やリリース目指して動いています。そのため毎日のミーティング実施や、チーム内でスムーズに連携が取れるようなスクラムと呼ばれる手法が主に取られています。そうすると開発が始まった後でも、要求や仕様の変更は頻繁に起こり、その度重なるデザイン変更がデザインの崩壊に繋がります。
拡張性のあるUI設計がなぜ必要なのか
デザインが壊れてしまう要因でもう一つ主に考えられるのは、「自由奔放なデザイン」です。デザイナーがデジタルデザインのルールを知らないということは少なくありません。またアジャイル型開発だと特にそうなのですが、基本的な設計をする際に具体的な形がないところから設計を始めていかないといけないため、色々な内容を盛り込んでしまいがちです。
そのため、明確な根拠がないまま進んでしまい、実装ができないデザインになってしまう=デザインが壊れてしまうということに繋がります。
それらを防ぐために拡張性のあるUIを最初から設計する必要があるのです。
拡張性のあるUI設計って？
それでは拡張性のあるUI設計とはどのようなものでしょうか。お伝えさせていただきたいポイントは3つ。まず1つ目は既存部品の組み合わせで新しいMoleculesとOrganisms、Templatesを作り出せること。次に、見た目の一貫性を保持しつつ機能の追加・削除が可能であること。これは例えば、B to B向けのものを作成する場合、画面の数が何百と増えてしまいます。その全てのレイアウトを自由奔放に決めてしまうと全く使えないものになってしまうため、レイアウトのルールを部品単位だけではなくページ単位でもパターン化し設定しなければいけません。
画面全体がきちんと整理されていて、実装の難航やユーザー自体が迷子になってしまうことを防ぐために、操作や見た目の一貫性を保ったまま機能の追加・削除が可能であることが条件として必要となってきます。つまり拡張性のあるデザインとは、変更に強く実装チームの負荷にならないデザインのことを示しています。
拡張性のあるUI設計を実現するために
次に、拡張性のあるUI設計を実現するために、具体的に考慮すべきポイントをお伝えします。こちらも主に3つあります。まず1つ目は「事業側の目標を知る」ということです。これは物事を上空から見るように全体的な視点を持つことで、事業側だけではなくお客様の視点、運用面での視点など立場を変えて考えた時に、目の前のデザインはどのようなインパクトを与えるのか、使い勝手はどのようなものかなどを考えながらデザインを設計するということです。
2つ目に、「構造とはUX+API/データ」ということです。ここでいう構造とは情報設計の話で、UXのことは皆さんもちろん考えると思うのですが、実装者にとっての構造とはAPIとデータを示します。そのため、UXだけを考慮した画面構造だけではなく、実装者が見るときにデザインがどこのデータベースのものなのか、どのAPIなのかを考慮する必要があります。
その際に大事になってくるのが、3つ目の「部品・画面をパターン化」です。画面の骨格を全く別々に考えることはできません。結局、進めていった先に実装できなかったり、性能自体に問題があるプロダクトになってしまったり、運用に負荷がかかるようなものになってしまったりするのを避けるために、部品画面をパターン化する（コンポーネント化する）ことがとても大事になってきます。
