こんにちは、もしくはこんばんは。

今回はアル社での、Figmaを使ったワークフローの話です。

アルでは2022年1月にハロマスというサービスをリリースしました。

ハロマスは、クリエイターが作ったオリジナルのギフトを買えるサービスで、デザインはFigmaで制作されています。

UIデザインはFigmaで作り、エンジニアが参照しながら開発を進める、それだけならば至って普通なのですが、ハロマスの場合、ディレクターもFigmaを利用しています。

要はワイヤーフレーム(画面の設計図)を作るのに、一般的なWhimsicalやGoogle Slides やPowerPointではなく、Figmaで作るということです。

なぜやったのか

これはサービス開発を爆速(※)でやるために、必要に迫られてやったということもあるのですが、ワイヤーフレームとUIデザインを作るツールが一緒である方が、効率的だと考えたからです。

• ワイヤーフレーム作成時に既存のコンポーネントを使いまわせる

• アプリ間での行き来がないので、手間が省ける

• ディレクターが入れた文言をそのまま流用できる

• 実現可能性の低いワイヤーフレームを描くリスクが減る

• Figmaでコミュニケーションも可能のため、資料が散らかることが無い

この辺りが、数ヶ月このワークフローをやってきてメリットだと感じる点です。書いてみて思ったのですが、めちゃめちゃ当たり前のことですね。

ただ、これをやっているケースはまだまだ少ないとは思います。

導入の壁

理由としては「学習コストが高い(もしくは高いという思い込み)」なのかなあ、と思っています。

全部の機能をちゃんと使おうと思えば確かに学習コストは高いのは事実ですが、ワイヤーフレームを効率的に作る程度の機能を使うのであれば、実はPowerPointやWhimsicalを駆使して作るのと同程度の学習コストで、慣れればより効率的であるという実感があります。

ですが、もちろんFigmaに慣れていない人に対して「明日からFigma使ってよ！」はあまりにも鬼畜すぎるので、社内向けに開催したのが「雰囲気でFigmaを使えるようにする会」という勉強会でした。

「雰囲気でFigmaを使えるようにする会」

この会は担当ディレクター数名にのみ実施予定でしたが、エンジニアや他業種の人も参加してくれたり、その時に参加してくれたメンバーが他のメンバーに再度実施してくれたり、なかなか実りがありました。

コンテンツとしては、

1. 用語の話

2. ワイヤーフレームを描いてみよう(実践)

3. グループとフレームの違い

4. オートレイアウト実践編(実践)

5. コンポーネント

というもので、FrameやPropertyなどの用語の説明をしたあと、単純な図形を描いて並べて編集するというワーク、特徴的なFrameの概念を少し厚めに解説して、あとはすぐにAutoLayoutのワーク、Componentについては概念だけ座学、という流れになりました。ぴったり1時間くらいでしょうか。

ショートカットも必要最低限、まずは図形を描いて、テキスト書いて、レイアウトが最低限組めるところまでやる、という感じです。

その後どうなったか

試行錯誤はまだしていますが、大枠のフローとして

1. Figmaでワイヤーを描く

2. Product Owner ワイヤーレビュー

3. FigmaでUIデザイン

4. 実装

というような形になっています。

1を担当するディレクターは複雑なComponentやVariantsは使わず、新しいComponentが必要になったタイミングでデザイナーが作ったり、もしくは3の作業の時にまとめて対応する、みたいなやり方をしています。

デザイナーの方も、ワイヤーフレームを見ながらUIの良し悪しを考えたり、ビジュアル表現に集中することができるので、大変やりやすいです。

ちなみに、担当のディレクターの優秀さももちろんあるんですが、触り始めて2週間そこらでAutoLayoutゴリゴリでワイヤー作ってきて、慣れ is Best UXだなーと思いました。

終わりに

明確に効率化できた施策が久しぶりだったのでnoteにしてみました。

効率化を考えているディレクター・デザイナーの方は検討してみるのも一興ではないでしょうか。

それでは！

※ どれくらい爆速開発だったかというと、要件定義・デザイン・開発が並行して行われ、1月2週目から本格スタート、1/21にはリリースされていたので、流石に時空が歪んだと思いました。