Figmaで行うプロトタイピング・・・のはずだった

piqcy
piqcy
Dec 10, 2019 · 7 min read

サービスやアプリの開発を行う時、ちょっと動くデモを作りたくなることが良くあります。本職のデザイナーさんがいればお願いするのが筋なのでしょうが、いないorまだふわっとしていて要件を伝えるコストが高い場合、自分でサクッとできると検証のスピードをぐっと上げられます。

本連載では、Figmaというサービスを使いプロトタイピングを実践してみます。Figmaのチュートリアルはオフィシャルを含め良いコンテンツがたくさんあるので、適宜それらを参照しつつ「プロトタイピングの速度を上げる」のに必要なノウハウをまとめていこうと思います。

題材として、サンプルの鉄板であるTodoアプリをFigmaでデザインしてみます。最初は・・・そう思っていました。

最終的にこの記事は失敗談となっているので、それでもいいという方だけ読み進めください。

Figmaとは

FigmaはUIデザインツールの一種です。同様のツールとしてSketchAdobe XDなどがあります。以下記事の比較がわかりやすかったですが、各ツールの機能は日々開発されているので、機能比較については最新版を確認するようにしてください。

今回Figmaを選んだのは、ブラウザベースの開発が可能である点、それによりコラボレーションが行いやすい点の2点があります。ただ、どのツールも似た機能があるのでどれを選んでも大差はないと思います。えいやとどれか一つ決めて、まず試してみるのが良いと思います。

Figmaはオフィシャルでチュートリアル動画を提供しています。Getting Startedを一通り見れば使い方はおおむね把握できると思います。

また、以下の連載がとても分かりやすいです。

チュートリアル的な内容は上記のありがたいコンテンツに譲り、本連載ではプロトタイピングに必要な機能にフォーカスして解説していこうと思います。

デザインを行う前の設計: 戦略・要件・構造

開発と同様に、デザインも行う前に要件定義を済ませることが重要です。デザインの要件定義はUX設計とも呼ばれます。UXの構成要素は、Jesse James Garret(ジェシー・ジェームス・ギャレット)さんが2000年にまとめています。発表されてからずいぶん経ちますが、現在でも通用する考えです。

「ユーザーエクスペリエンスの要素」より

実際目にするビジュアルデザインの背景に、扱う情報の構成/構造、さらにサービス/アプリケーションの要件と戦略(達成目標)がある、という考えです。システムの開発は要件定義、扱う情報を定義するスキーマ設計(DB設計)、最後に画面設計、という流れで進むのでこの分け方自体はごくごく自然だと思います。非機能要件も考慮すると、デザインだけでなく(ユーザーが目的を達成するのに求められる)パフォーマンス、1画面当たりの情報量なども検討に上がると思います。

UXデザインの各構成要素の成果物は以下の記事によくまとまっています。

実際にUXデザインから手を付けると日が暮れてしまうので、今回は簡易に済ませます。UX5段階モデルのうちFigmaを使う前に決まっている必要がある戦略・要件・構造についてそれぞれ以下のように定義しました。

戦略の定義
要件の定義
構造の定義

「簡易に済ませる」と言いつつかなり時間がかかりました。書いていて感じたのは、「要件」の段階であまりユーザー体験について考えすぎない方がいいということです。プロトタイプがないこの段階でユーザー体験について思いを巡らせても、実際観測することができないので妄想が入ってしまうためです。要件の段階では「必要なもの」の洗い出しと「懸念点」(プロトタイピングで確認すべき点)を洗い出すにとどめた方がいいかなと感じました。

「何を届けるか」と「どう届けるか」は異なると思います。これらはある程度分離しておかないと、コンテンツに問題があったのか伝え方に問題があったのか分析が難しくなると思います。戦略・要件・構造はプロトタイピングの反応いかんであまり変わってはいけない(変わるべきではない)要素ではないかと個人的には思います(※あくまで個人の解釈です!)。

Figmaを使った設計: 骨格・表層

さて、ここから実際に「UI」と呼ばれる領域を作成していきます。作成していく・・・んですが、ここで気を付けないといけないことがあります。現在の工程はあくまで「UX検証」であり、「開発」ではないということです。

Figmaで作った画面をReactやVueのコンポーネントにして・・・と思っていると、途端にプロトタイピングツールでの開発が重たくなります。Componentはどうしよう?ログイン画面はいるかな?モーダル作るのめんどくせー・・・などです。

(Todoではないけれど)実際作っていたプロトタイプ

本職の方はどうやっているんだろう?と実際にデザイナーの方に伺う機会があったので聞いてみました。すると、冒頭で述べた通り「プロトタイピングのツールはUXを検証するためであって、UI開発とは違う」「ユーザーの感情を爆発させるパートをまず作る」といった意見をいただきました。VueやReactへの書き出し、CSSの書き出しは機能が中途半端だし実際動くわけではないのでほとんど使わないとも聞きました。

ユーザーエクスペリエンスの要素は階層型になっているので下から順に作らないといけないと思っていましたが。ユーザーの需要やコンテンツ要件などは反応を見てみないと単なる妄想になってしまいます。プロトタイピングツールとは、ユーザーエクスペリエンスのUIパートを作るためのツールではなく、ユーザーエクスペリエンスの階層全体を文字通りプロトタイピングするツールだったのだ、と気づきました。

そんなわけで、使い方を見直して再チャレンジしたいと思います。次回は実践的な記事になる!はず。

programming-soda

Exciting research & programming like soda!

piqcy

Written by

piqcy

All change is not growth, as all movement is not forward. Ellen Glasgow

programming-soda

Exciting research & programming like soda!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade