🎅 メリークリスマス 🎄 この記事はGoodpatch Advent Calendar 2020 24日目の記事です。
Goodpatchのクライアントワークでは、エンジニアもデザインプロセスに参加し、一緒にアイデアを考えたり、プロトタイプを作って仮説検証を行うことがあります。普段はデザイナーがProttなどを使って、クリックスルーのプロトタイプを作るケースが多いですが、場合によってはエンジニアがコードを書いて実際に動作するプロトタイプを作ることもあります。
しかし、コードを書いてプロトタイプを作る場合、環境構築やライブラリ選定などを含めるとそれなりに時間も必要です。特に使い捨て型のプロトタイプを作る場合、プロトタイプの作成に時間をかけすぎないようにしたいので、そのようなケースではプロトタイピングツールを使うことでコードを書くよりも素早くプロトタイプをつくることができます。
今回ご紹介するプロトタイピングツールの「Framer」は私自身使い始めて間もないですが、UIのグラフィックを描けるだけでなく、コードを書くことでコンポーネントを拡張できるため、とても柔軟性が高く、インタラクティブなプロトタイプをつくるデザイナーやエンジニアにとって役立つのではないかと感じました。
また、Framerの話に入る前にそもそもプロトタイピングとは何か、プロトタイピングがなぜ必要なのかについても少し触れてみたいと思います。なお、Framer入門と言いつつもチュートリアル的なものではなく、いくつかの機能を示すことで活用シーンをイメージできることを目指します。
仮説を検証するためのプロトタイピング
ソフトウェアにおけるプロトタイピングについてWikipediaには以下のように書かれています。
ソフトウェアプロトタイピング（英: Software Prototyping）とは、将来完成する予定のソフトウェアの不完全なモデル（プロトタイプ）を作成することおよびその過程を意味する。
1960年代や1970年代の固定的な開発サイクルでは、完全なプログラムをまず製作し、それから設計と実装の不整合に対処したりしていた。この方式は開発費用の増大を招き、費用や期間の予測も難しかった。プロトタイピングは多大な出費を防ぎ、完成したプログラム修正という困難な作業を低減する。
プロトタイプは未だ明らかになっていない仮説を検証することで問題を早く検知します。たとえば、以下のような仮説のことです。
- このアイデアはユーザーの課題を解決できるはずである
- このアイデアは技術的に実現できるはずである
- このアイデアについてチームは同じ認識を持っているはずである
プロトタイプを作る上で「何のためにプロトタイプをつくるのか」をチームで認識を合わせることは重要です。目的を擦り合わせずにプロトタイプをつくってしまうと、プロトタイプに対する要求が大きくなったり、プロトタイプを作っても結果的に対して活用できなかったということも起こりえます。
特にソフトウェアは物理的に存在せず、人によってイメージがズレやすいため、合意形成のためにもプロトタイプをつくることに価値があります。
目次
なぜ、仮説を検証するのか
プロトタイプは何かしらの仮説を検証するために作りますが、ではなぜ仮説を検証する必要があるのでしょうか。「仮説思考 ＢＣＧ流 問題発見・解決の発想法 」によれば、仮説を考えること＝仮説思考について以下のように説明しています。
仮説思考とは、物事を答えから考えることだ。ベストな解を最短で探す方法ともいえる。仕事をしていると、毎日さまざまな問題に直面する。それらの問題を解決しようとするとき、考えられるあらゆる原因、そして、それぞれの原因に応じた解決方法を網羅的に調査するのは事実上難しい。問題を解決すべき時間が限られている場合に、そのような仕事の仕方をすると、結果を出せないまま時間切れになってしまう。
したがって、あらかじめ答えを絞り込むこと、つまり仮説を立てることが重要になる。仕事の進め方で大事なことは答えから発想することだ。課題を分析して答えを出すのではなく、まず答えを出し、それを分析して証明するのである。
仮説思考はさまざまなシーンで活用できる考え方ですが、プロトタイピングはまさに正解が分からない中で「仮の答え」をつくることによって、それが正しいのか正しくないのかを明らかにし、不確実性を減少させる行為だと言えます。
プロトタイプの忠実度
プロトタイプをつくる際には、目的に応じて必要な作り込み具合が変わります。この作り込み具合を「忠実度」と呼んでいますが、大きく３つの分類があります。
低忠実度のプロトタイプ
手軽かつスピーディーに作れるが、インタラクションが限られており、細かい点やフロー全体をテストするのは難しい。様々なバージョンのプロトタイプを数多く作る際に向いている。（例：ラフスケッチなどのペーパープロトタイプ）
中忠実度のプロトタイプ
画面遷移などの簡単なインタラクションを含めることができ、時間と質のバランスが良い。特定のインタラクションやフローのテストを行う際に向いている。（例：Prottなどでビューをつなぎ合わせたモックアップ）
高忠実度のプロトタイプ
詳細なインタラクションをテストできるが、時間がかかる上にコーディングのスキルを要する。ステークホルダーに最終的なデザインを提示したり、細部のインタラクションのテストに向いている。（例：コーディングなどで動作可能なワーキングプロトタイプ）
この記事で取り上げているFramerは高忠実度のプロトタイプを作ることを目的としたプロトタイピングツールですが、中忠実度のプロトタイプをつくる場合にも利用することができます。
Framerについて
前置きが長くなりましたが、Framerはデジタルプロダクトのためのプロトタイピングツールです。元々、FramerXという形でデスクトップアプリケーションが提供されていましたが、新たにFramer Webがリリースされたことで、ブラウザベースで利用することができるようになりました。
Framerの魅力はUIのグラフィックを描画できるだけではなく、高度なプロトタイプ機能やコードによる拡張性を備えているところにあります。この特徴により、UIの表現と実装の両面を統合的に考えることができます。
Framerを使ってみて良いと感じた点
私がFramerを使い始めてみて、良いと感じた点をいくつかご紹介します。ちなみに私は他のデザインツール、プロトタイピングツールにあまり詳しくないので、他のツールと比較できていないことを了承ください。
予め用意されているコンポーネントを利用できる
Framerにはソフトウェアでよく利用するUIコンポーネントが標準で用意されています。これらのコンポーネントを組み合わせることで素早くワイヤーフレームレベルのUIを構築することができます。
たとえば、Interface Componentsをキャンバスに配置してプレビューすると、フォーム部品のインタラクションを実際に確認することができます。
Interface Components以外にも外部パッケージをインストールすることで様々なコンポーネントを利用することができますし、SketchやFigmaでつくったデザインデータをインポートする機能もあるのでデザイナーから受け取ったデザインファイルを取り込むこともできます。
コンポーネントを自作できる
Framerには２種類のコンポーネントが存在します。１つ目はDesign Component、２つ目はCode Componentです。
Design Component
Design ComponentはFramerのキャンバス上で作成したコンポーネントを再利用可能にするためのもので、Sketchで例えるとシンボルのようなものになります。Design Componentを作成することで、同じコンポーネントをインスタンスとして複製できるだけでなく、テキストや画像などの情報をインスタンスごとに上書きすることができます。
Code Component
Code Componentはコードで作成する高度なコンポーネントです。FramerにはCode Editorが備わっており、ReactとTypeScriptを使ってCode Componentをすぐに書き始めることができます。
Framer APIを使ってさまざまなコンポーネントを実装することができます。たとえば、シンプルなコンポーネントは以下のようなコードになっています。
import * as React from "react"
import { Frame, addPropertyControls, ControlType } from "framer"
export function MyComponent(props) {
const { text, textColor, backgroundColor, onTap, ...rest } = props
return (
<Frame
{...rest}
background={backgroundColor}
onTap={onTap}
whileHover={{
scale: 1.1,
}}
style={{
color: textColor,
fontSize: 16,
fontWeight: 600,
}}
>
{text}
</Frame>
)
}
また、Code ComponentにはPropertyControlsという仕組みが備わっており、以下のようにtitleに名前、typeにPropertyControlsの型を指定し、addPropertyControlsでコンポーネントにプロパティを設定することでキャンバス上のProperties Panelで動的に変更可能なプロパティを設定することもできます。
addPropertyControls(MyComponent, {
text: {
title: "Text",
type: ControlType.String,
defaultValue: "Hello Framer!",
},
textColor: {
title: "TextColor",
type: ControlType.Color,
defaultValue: "white",
},
backgroundColor: {
title: "BackgroundColor",
type: ControlType.Color,
defaultValue: "#0099ff",
},
onTap: {
type: ControlType.EventHandler,
},
})
Code ComponentはPropertyControlsを使うことでコンポーネントの属性を定義できるだけでなく、前述のDesign Componentをインポートして子コンポーネントとして使えるなど非常に柔軟性が高いコンポーネントになっています。
トランジションを容易に表現できる
チームでアニメーションについて認識を合わせるときはどのような形式を取っているでしょうか。もしかしたら、「シュッと出てくる感じ」のような擬音語を使ってコミュニケーションを取ることはあるかもしれませんが、言葉だけで認識を合わせるのは中々難しいものです。
FramerにはMagic Motionという機能があり、同一コンポーネントの前後の状態を定義し、つなぎ合わせることによって状態遷移をトランジションで実現することができます。たとえば、ラジオボタンのOFFとONの状態をつくり、タップ時にMagicMotionを使って状態を切り替えることでアニメーションさせることができます。
データベースと連携できる
仮説の内容によっては実際のデータを使った方が検証しやすかったり、動的なデータで検証した方が良いケースがあります。データベースと連携するプロトタイプを作るためにはコードを書くことが多いと思いますが、FramerにはFramer Packagesと呼ばれる拡張パッケージが用意されており、これらのパッケージを利用することで容易に外部のデータベースと連携することができます。たとえば、パッケージの１つであるFirebaseDataを利用すると、FramerとFirebase Realtime Databaseを連携させて、リアルタイムチャットアプリケーションのプロトタイプをつくることができます。
２つのブラウザでチャットのプロトタイプを表示し、片方からテキストメッセージを送ると、もう片方のチャットにリアルタイムで表示されています。ここでやり取りした情報はRealtime Databaseにも保存されています。
他にもGoogle SpreadSheetやAirtableなどの外部サービスと連携するパッケージもあります。
おわりに
Framerの機能を使ってインタラクティブなプロトタイプが作れることをご紹介しました。Framerは柔軟性が高いプロトタイピングツールと言えど、学習コストはそれなりに高く、余計な部分でつまづくこともあるので実際にコードを書いた方が速い場合もあります。しかし、学習を重ねるごとにコードを書くよりもFramerでプロトタイプをつくる方が圧倒的に効率が良いケースもあり、実際にアイデア検証のためにFramerで作ったプロトタイプでユーザーインタビューをしたこともあります。
Framerはチーム開発で利用する場合は有償版の利用が推奨されますが、個人でプロトタイプを作る分には無償版でも十分に試すことができますし、チュートリアルも豊富に用意されているので、ご興味のある方は年末年始に触ってみてはいかがでしょうか。
Framer: A Free Prototyping Tool for Teams
最後にGoodpatchではデザインやプロトタイピングに関心があるエンジニアを募集しています。ご興味のある方は以下のページからご応募・ご連絡ください！
