はじめに
Webシステム開発において、UI/UX(画面)デザインはユーザー体験を左右する重要な要素です。本来、デザインは専門のデザイナーが担当するべきですが、システムエンジニア自身がデザインを行うケースも少なくありません。
システムエンジニアがデザインを行う際、ExcelやGoogleスプレッドシートを「方眼紙」のように活用するケースが多く見られます。また、PowerPointやGoogleスライドといったツールもよく使用されています。
これらは、汎用的なドキュメント作成ツールなので、他ドキュメントと同様のアクセス権やライセンスで管理できることや、使い慣れているというメリットがあります。
ただし、これらは専用のデザインツールではないため、デザインの表現力や動き、忠実性の面で劣る点があります。たとえば、Excelの方眼紙を用いて作成した画面で顧客の承認を得たにもかかわらず、それを元にHTMLベースで画面を再現すると見た目が変わり、顧客から承認を得られないといった事態が起こり得ます。
専用のデザインツールを導入することで、デザインの表現力や作業効率を向上させることが可能です。その際には、プロジェクトや部門全体でツールを統一することが望ましいでしょう。ツールを統一することで、習熟が容易になり、アクセス権やライセンスの管理が簡単になるといったメリットがあります。
draw.ioやSketchなど、さまざまなデザインツールがある中で、今回はFigmaを選択しました。その理由は以下の通りです。
- 無料で使用できる
- 利用ユーザー数が多い
- 情報(Web/書籍)が充実している
- ブラウザ上で編集できる
- 複数人が同時編集できる
- 閲覧のみであればユーザー登録が不要
Webシステム開発プロジェクトでFigmaを試してみようと考えましたが、ちょうど画面デザインのスケジュールと合わなかったため、実際のプロジェクトを想定したロールプレイング形式でFigmaを試すことにしました。
Figmaを試す中で、「うまくいったこと」や「困ったこと」があったため、それらを紹介します。
Figmaをまだ使ったことがない方は、次の「はじめてのFigma」の記事もご参考ください。
また、ファイルを共有する場合は、次の「Figmaでファイルを共有する」の記事もご参考ください。
作業分担
ロールプレイング形式でFigmaを試すにあたり、作業分担を決定しました。プロジェクトの規模やチーム構成によって役割は異なりますが、今回は以下のように分担しました。
役割 | 人数 | 定義 |
---|---|---|
ユーザーA ユーザーB |
2 | 必要な要素や仕様を整理し、開発を依頼する 実際のプロジェクトでは顧客に相当する |
開発者A 開発者B |
2 | 要件に基づいて、Figmaでモック1を作成する 実際のプロジェクトではITベンダーの開発者に相当する |
Figmaを試す前の作業イメージ
作成するモックの概要は、「業務エラーやシステムエラーのログを一覧で確認できる画面作成」です。Figmaを試す前は、次のような進め方を想定していました。
順序 | 実施者 | 作業 |
---|---|---|
1 | ユーザーA ユーザーB |
要件をテキストにして提示し、モック作成を依頼する |
2 | 開発者A 開発者B |
Figmaでモックを作成してユーザーAとユーザーBへレビューを依頼する |
3 | ユーザーA ユーザーB |
Figmaでモックをレビューしてフィードバック(不足項目や改善項目)を開発者Aと開発者Bへ提示する |
4 | 開発者A 開発者B |
レビュー結果を反映する ※順序3と4を繰り返す |
ユーザーと開発者のコミュニケーションは、次のような形を想定していました。
Figmaで作業を進めてみた
最初に、ユーザーが要件をテキストにして提示し、開発者にモック作成を依頼しました。
■概要
業務エラーやシステムエラーのログを一覧で確認できる画面
■詳細
次の通知種類で表示を分けたい
・業務エラー通知(ユーザーが何らかの対応を行うための通知)
・システムエラー通知(開発側が対応を行うべき通知)
ユーザー毎に既読/未読を管理したい
通知を「既読/未読」「通知種類」「発生期間」で検索できるようにしたい
その後、開発者がFigmaでモックを作成し、ユーザーにレビューを依頼しました。ユーザーと開発者がコミュニケーションを繰り返しながら修正を重ね、モックを完成させていきました。
ユーザーと開発者のコミュニケーション
Figmaを使用してモックを作成する際、ユーザーと開発者がコミュニケーションを取りながら進めました。Figmaではリアルタイムでフィードバックを受け取り、その場で修正することが可能です。しかし、ユーザーや開発者のスケジュールが合わず、リアルタイムでのやり取りが難しい場合もあります。
そんな時に役立つのが、Figmaのコメント機能です。具体的な流れは以下の通りです。
- ユーザーや開発者: 特定の箇所にコメントを残し、ユーザーや開発者をタグ付けします。コメント内容は指摘や要件追加や変更など様々です。これによりメールも通知されます
- 開発者が対応: コメントを確認し、修正を行います
- ユーザーが確認: 修正に問題なければ、ユーザーが「解決済みにする」を押下して完了します
Figmaでは、変更を即座に反映できるうえ、コメント機能を活用して修正内容を迅速に共有できるため、作業スピードが飛躍的に向上しました。この仕組みにより、フィードバックから修正までのサイクルが短縮され、効率が大幅に改善されました。
開発者同士のコミュニケーション
開発者同士のコミュニケーションにも、Figmaの標準機能を活用したので紹介します。
コメント機能
ユーザーと開発者のコミュニケーションでも使用したコメント機能です。コメントは、Figma内で最も頻繁に使用されるコミュニケーション手段です。作業中に役割分担や気になる点、修正が必要な箇所にコメントを残し、担当者をタグ付けして通知を送ることで、迅速に対応できます。
見えるところにマークやテキスト要素を配置
画像のように、わかりやすい位置にメモとしてテキスト要素を配置し、それを共有します。
Figmaを試した後の作業イメージ
チームも少しずつFigmaに慣れてきた結果、最終的には作業の流れが以下のようなイメージに近づきました。ユーザーと開発者全員がFigmaの画面を共有し、それぞれの作業に取り組むことで、スピード感を持って対応することができました。
作業を進める中で気付いたことですが、 その場でフィードバックを反映できる のは本当に便利です。これまでは、要件を持ち帰って対応し、フィードバックをもらうサイクルでしたが、 よく使う要素が整ってくると 、その場でフィードバックや指摘に即座に対応できるようになりました。プログラミング知識も不要で、マウス操作で対応ができます。
同じコンポーネントを触って事故った件
Figmaは共同作業を支援するツールで、特にリモートチームに適しています。作業中にメンバーの動きがリアルタイムで確認できるため、隣にいる場合よりも進行状況を把握しやすい点が大きな特徴です。
ただ、 同じコンポーネントを触った場合 に事故が起きました。同じボタンやアイコンを2人が同時に編集してしまい、意図しない変更が加わってしまったのです。
対策
そこで、次の対策を検討しました。今回はスピード感を重視して①の対策で対応しました。プロジェクトの状況によっては、②③④の対策も検討すると良いかと思います。
- ①個人用の作業スペースを設ける
- ②コンポーネントごとに「誰が担当するか」を明確にしておく
- ③作業する際は少しの間でも「今、誰がどの部分を作業を行っているか」を共有しておく
- ④ロック機能やバージョン管理を活用して、他の人が作業している部分を編集しないようにする
初めてFigmaを使ってみて感じたこと
今回、初めてFigmaを使用するメンバーがいました。その中で感じたことを、以下の3点にまとめました。
制作速度
これまではHTMLやCSSを作成して画面を作ることが一般的で、本作業とほぼ変わらないうえ、時間がかかることが多くありました。しかし、Figmaでは図形やテンプレートを活用することで、本番画面と同じデザインを簡単に再現できます。配置、移動、入力といったシンプルな操作だけでモックを作成できる点が大きな利点です。
リアルタイムでの操作が可能
リアルタイムで操作が可能なため、他のメンバーの作業内容を確認できる点は大きなメリットでした。特に、コメントオブジェクトを他の作業者の周りに配置することで、指摘が目立ちやすくなり、迅速に対応することができました。
フィードバックのしやすさ
コメントは、好きな作業場所に配置できるため、修正箇所が明確でわかりやすかったです。また、既読・未読の確認や完了・未完了のステータス管理が可能であり、コメントを一覧から確認できるため、フィードバックへの対応が非常にスムーズでした。
おわりに
Figmaを活用することで、デザイン案の作成や要望の取り込みを効率的に行うことができました。導入の敷居も高くなく、まずはお試しでプロジェクトに取り入れてみるのも良い選択だと感じています。
今回はWebシステム開発のプロジェクトを想定しましたが、営業提案にも応用できるのではないかと思います。Figmaはその多彩な表現力を活かし、UI/UXを重視した提案が可能です。
今後もFigmaを活用し、より良いデザインやコラボレーションの実現を目指していきたいと考えています。
-
モックアップ。内部のシステムが実装されておらず機能しないものの、デザインは完成品に近いサンプル画面 ↩