![見出し画像](https://assets.st-note.com/production/uploads/images/154623900/rectangle_large_type_2_e58bbde393f6b850432b2bfef9367a15.png?width=1200)
UIデザインガイドラインをAdobeXDからFigmaに移行した私の奮闘記録 ②移行作業編 (前半パート)
こんにちは!
イルグルムのUXデザイン室、デザイナーの松尾です。
![](https://assets.st-note.com/img/1726533207-JEkT8xvIO0afqdB1A2ZbFcuC.png?width=1200)
前回の「準備編」ではFigmaを導入することを決定し、業務ツールとして当時利用していたXDから移行するための計画を練りました。
今回は「移行作業編」ということで、実際に移行をどのように進めたのかをお話しします。
少しテクニカルな部分もあるかと思いますが、
「社内のデザインツールをfigmaに移行したいが何から取り掛かれば良いのか分からない!」
といった状況で悩まれているデザイナーやエンジニアの方の参考になれば幸いです。
また、内容が少し長いため前半、後半パートに分けてお送りします。
それでは、よろしくお願いします!
移行作業全体の流れ
![](https://assets.st-note.com/img/1726543226-ucFIGmwOoa3Mhn1BNdkteXC2.png?width=1200)
figma移行作業編は上図の通り、約4ヶ月間をかけた取り組みになりました。
前半パートでは最初の1ヶ月間で取り組んだ、
・figmaに慣れていくための修行
・移行でどんな状態になれば良いかのゴールを考える
について、お話ししていきます。
移行前準備
修行その1:Figmaを理解/習得する
まずは自身のスキルを身につけないと始まらない
元も子もない話かもしれませんが、いざfigmaでやるぞ!とは言っても私自身、figmaをほとんど触ったことがありませんでした。
後々修正することにならないよう、適切な方法で移行作業を行う必要があります。
ぶっつけ本番で移行作業を行うと流石に危ないので、figmaの使い方を習得するところから初めていきました。
スキルはこうやって身に着けようとした
新規プロダクトでUI作成に携わる機会があったので、そこでfigmaを用いて一からUIを作ってみることにしました。
すでに固まっているデザインよりも、一から作る方が様々な機能を試しながら自由度高くfigmaを触ることが出来そうなので、その点でも修行にはちょうど良さそうです。
初心者はこんな方法がおすすめ
全くfigmaを触ったことのない方は、教材で学びつつボタンを作ったり、ボタンを押して画面が切り替わるなどの基本から操作に慣れておくのが良いかと思います。
YouTubeにも無料で学べるものはありますが、Udemyなどのオンライン講座の方が教材は豊富にあり、レベルごとに学習範囲を設定しているものもあるので個人的にはこちらがおすすめです。
![](https://assets.st-note.com/img/1726533286-PqmubzciltG0Jk8Q63IXAYy7.png?width=1200)
修行その2:実際に業務で使ってみる
新規プロダクトで利用を開始
ちょうど担当することになった新規プロダクト開発でFigmaの修行をすることにしました。
固まった要件を元に、画面を作成していきました。
移行は必要ないので0から色々作ってみる
新規プロダクトのUIデザインなので、移行のあれこれを気にせずUIを一から作っていけるのですが、UI作成と機能理解の2つを効率的に進めたいと思い、まずは参考データを探しました。
他社のプロダクトや海外のデザイナーが提供しているサンプルUIなど、探してみると結構ネット上で参考データを見ることが出来るので、ここはXDよりも情報が豊富でありがたいです。
参考になりそうなデータのボタンやフォームなどのパーツがどんな機能を使っていて、どんな作りになっているのか見ていきながらUIを作っていきましたが、結果的に良いスタートダッシュになりました。
![](https://assets.st-note.com/img/1726533402-miWfqk3S2OBFY1NvbpsPUy46.png?width=1200)
figmaを触った感じ、私自身これまでもAdobe XDをはじめPhotoshopなどの関連ツールも使ってきたためか、そこまで学習時間は要さなかったように思います。分からない機能があれば都度調べるぐらいで習得することが出来ました。
1ヶ月後、移行すべきものが見えてきた
この1ヶ月間の取り組みで、figmaでのUI作成業務には少なくともコンポーネントとデザインルールが必要なことが分かりました。
コンポーネントはUIの作成上必要で、デザインルールは開発とのコミュニケーションを円滑にするために必要そうです。
また、UIをどのように運用や管理をしていくべきかも考えるきっかけになりました。
さて、新規プロダクトのUI作成も落ち着いた段階になり、いよいよ本来のターゲットであるアドエビスの移行作業に向けて動き出していきます!
移行前準備「移行とはなんぞや?を定義する」
アドエビスの移行作業前に、最終的にどんな状態になれば良いのかを整理しておきます。
言語化して整理することでやるべきことの範囲や優先度付け、作業の規模感も見えてくるのでおすすめです。
移行が出来ている状態とは何か?ゴールを決める
ここでは必須条件(MUST)と、あると良い条件(WANT)で分けて考えていきます。
必須条件(MUST)
必須条件は、今回の移行作業の大目的である、
「XDで出来ていた業務をそのままfigmaでも出来るようにすること」です。
そのためには2つの情報を移行する必要があると考えます。
1つ目は「UIコンポーネント」です。
UIコンポーネントは大元のデザインパーツです。基本的にUI作成ではこのUIコンポーネントを複製しながら画面を構成していくことになるので、これがないと業務が出来ないと言っても過言ではないです。
既にXDにあるデータでもあるので移行対象にします。
![](https://assets.st-note.com/img/1726534539-1w3qlmDBSyQgiK8E0Iz5RW2M.png?width=1200)
2つ目は「UIガイドライン」です。
UIガイドラインはデザイン上のルールを記したもので、例えばボタン1つにしても、キャンセルはこのデザイン、非活性の時はこのデザインなど、主にコンポーネントをどのような場面で使うのかをまとめています。
このガイドラインがあることで作成者、開発者共にUIの扱い方全般の認識合わせができ、統一感のある画面が実現できます。
それに、後に後述しますが今後は私のみならず非デザイナーのメンバーでもUIを作成出来るような状態を目指しているため、その観点でも優先度は高いです。
これもXDにまとめられてるので移行対象にします。
![](https://assets.st-note.com/img/1726534576-iw3rT45WMmtVEDRKv8U9sHeP.png?width=1200)
あると良い条件(WANT)
必須条件に加えてさらに望ましい状態を目指すなら、
「非デザイナーのメンバーでもUIを作成出来るような状態にし、業務効率を上げていくこと」です。
その状態を目指す上での障壁として、属人的な課題が1つありました。
運用ルール未整備による属人的な課題
従来のXDでの業務では、デザイナー独自の運用ルールでUI作成を進めていました。
例えばバックアップ場所やファイル、パーツの命名といった全般的なことやコンポーネントの扱い方などが、明確にルール化されていない状態でした。
私1人でXDを運用していた当時、極端な話、モノ(UI)さえあれば開発実装が出来ていたので、この辺りの整備の優先度が低く出来ていないままでした。
しかし昨今のチームの動きを見ると、ありがたいことに業務の範囲が広がってきています。
アドエビスだけでなく、様々なプロダクトを横断して開発やフロントメンバーとコミュニケーションするようになっており、今後私だけでなくチームメンバーでもUIに関してある程度検討が出来るようになる必要がありました。
今後非デザイナーのメンバーでもfigmaで作業を行える状態にするとなると、上記のようなルールを整備していく必要があります。
もし運用ルールが整備されないままだと、先ほどの例のようなルール全般の確認の手間が発生したり、管理方法が曖昧になってしまい、業務効率を下げる可能性があります。
チームの誰もがfigmaに触れるようになることで、関係各所とのコミュニケーションがスムーズになり業務効率化にもつながりそうなので、この機会に運用ルールの整備にも取り組むことにしました。
移行が出来ている状態をこのように定義した
これまでの整理で改めて移行が出来ている状態とは何か?をまとめると、
必須条件:
XDで出来ていた業務をそのままfigmaでも出来るようにすること
望ましい条件:
非デザイナーのメンバーでもUIを作成出来るような状態にし、業務効率を上げていくこと
となります。
これで今回の移行作業でどんな作業が必要なのかが見えてきました。
作業イメージを立てる
次に、先ほどの2つの条件を満たすために必要な作業を洗い出していきます。
1.UIコンポーネント
XDにあるデータを移行する
2.UIガイドライン
XDにあるデータを移行する
3.運用ルールの整備
・運用ルールを明確にしたドキュメントを作成
私のこれまでの業務を振り返りながら作業工程を洗い出し、ルールとして整理していく。
・チーム内にルールを共有
移行作業後に勉強会や業務を通して、整備された運用ルールに則って作業を進めていくようにしていく。
このように大きく3つの作業がありますが、いきなりこれらの作業を一気にやるとボリュームが大きいため、まずはfigmaで従来の業務が出来る状態になることを優先して、段階的に進めることにしました。
作業をレベルごとに3段階に分けてみた
以下のような形でざっくりと3つの状態に分けてみました。
レベル1:デザイナーのみ作業可能な状態
UIコンポーネントのみ移行している。
UIデザインルールを知っていればUI作成は出来る。
レベル2:サポートありなら非デザイナーでも作業可能な状態
UIガイドラインの移行も完了している。
デザイナーと開発双方でデザインルールの共通認識が持てるのでコミュニケーションがスムーズになる。
管理・運用面ではまだ整備が出来ていないため、非デザイナーが作業するにはデザイナーのサポートが必要。
レベル3:非デザイナーでも作業可能+業務効率が継続的に上がる状態
運用ルールが導入され、浸透している。
非デザイナーでも自走してUI作成やその管理を行うことができる。
これでまずどんな状態を目指し、そのために必要な作業が段階ごとに明確になりました!
レベル3は難易度が高そうですが、これが出来ればfigmaの運用体制に関するナレッジとして有用な記事が書けそうです。
![](https://assets.st-note.com/img/1726534769-LmCOYGD6vM2HTZFr7VPkNacs.png?width=1200)
後半パートでは最初の「レベル1:デザイナーのみ作業可能な状態」を目指すべく、コンポーネントの移行をメインにお伝えしていきます。
それでは、次回もお楽しみに!