2014.10.29 / Prototyping, UI

アプリ制作でプロトタイピングを導入する前に知っておきたいこと

Ryo Yoshitake

Form、Launch、Mitya、Origami、Pixate、Prott、Weld… これらが何であるか、みなさまはご存知でしょうか。

実は上に挙げたのは、ここ1年間で世に出たモバイルアプリ・Webページ用のプロトタイピングツール / サービスの名称です(まだローンチしていないものも含めればもっとあります)。

ここ2年ほどで、アプリを中心としたプロトタイピング市場は急激に拡大しており、すでに知られているメジャーなものも含めればその数は優に30を超えます。
それゆえに、プロトタイピングに興味を持ち始め、これから使ってみたいと考えている方の多くは、どのツールを使えばよいか迷っているのではないでしょうか。

しかし、プロトタイピングを行う上ではツール選び以上に『作ったプロトタイプをどのように使うのか』が大切です。

プロトタイピング=コミュニケーション

ここで主要なツールの使い方を説明することもできますが、プロトタイプはただ作って満足しておしまい、というわけではありません。その先のコミュニケーションを見据えたうえで活用することこそ、プロトタイピングの本質であると言えるでしょう。

本記事ではコミュニケーションツールとしてのプロトタイプに焦点を当て、はじめに3種類に分類しメリットとデメリットを解説した後、実際に起こりうるシチュエーションでどのようなコミュニケーションが発生し、どのプロトタイプが役立つのかを紹介します。

なお、今回はペーパープロトタイピングにはあまり触れず、ソフトウェアを用いたプロトタイピングに言及するに留めました。


3種類のプロトタイプ

まずはよく知られているツールを対象に分類をしてみたいと思います。分類は明確に定義されているわけではありませんので、筆者がこれまで使い分けてきて感じた特徴をもとに行いました。

トランジション型

主要ツール:Prott / Flinto / POP / InVision

『画面遷移の作成が容易になる』ツールを『トランジション型』と分類してみます。

Web上にアップロード、もしくはアプリで撮影した画面イメージ上にタップやスクロールなどのジェスチャーに反応するエリアを作成し、それに対してのアクション(別の画面に遷移する、前の画面に戻るなど)を割り当てるのが、トランジション型によく見られる流れです。 また、そのほとんどがWebサービスを基点としている点も特徴的です。

thumb01

トランジション型のメリットは

  • 実際に触って操作できる
  • 全体的な反復性がある
  • 複数人での共有が容易

です。ペーパープロトタイプをアプリ経由で取り込めば手早く全体の設計をチェックできますし、共有用のURLを送れば最新の状態が常時確認できるため「手書き or ワイヤーフレームで画面を作成して、全体的な遷移や使い勝手を早く把握したい」「チームのメンバーやクライアントと進捗を共有したい」といった要望に強いです。

反対に、デメリットは

  • 用意された動きしか適用できない
  • 細かい部分までは詰めづらい

です。
例えば「自分でアニメーションを制御したい」「ボタンをタップした時にボタンを揺らしたい」といった要望には弱いです。

インタラクション型

主要ツール:Origami / Framer / Pixate / Form

『画面内の動きを細かく作成できる』ツールを『インタラクション型』と分類してみます。

画面1枚1枚から成るトランジション型とは異なり、パーツを書き出して用意し、プログラミングに近い方法、もしくはプログラミングを用いて作成するツールが多いのが特徴的です。
ちなみにインタラクションと一言で言っても大小さまざまありますので、ここでは紹介するツールでできる内容に沿って『ユーザーの操作を助けるために画面もしくは要素が起こす反応』とします。

thumb02

インタラクション型のメリットは

  • 細かい単位での反復性がある
  • 実際に触って操作できる(一部を除く)

です。例えばサムネイルをタップした時に画像が拡大表示されるアニメーションや、メニューを開いた時の動きなどは、後述するアニメーション型のほうが作成が容易です。しかし、実際のアプリで一方向の動きだけというのはなかなかありません。メニューを開いたり閉じたりした時に派手な動きが毎回ユーザーの目に入るのが本当に良いのかは、動画では判別が付きにくいため、反復操作が行えるインタラクション型が有利です。
反対に、デメリットは

  • 全体の遷移が作りづらい
  • 習得に時間がかかる

です。
細かい動きを作れる分、トランジション型のように『全体の遷移を確認する』用途には向いていません。もし全体の遷移を作ろうとなればトランジション型で問題ないとなりますし、細かい動きも含めて全体を作ろうと思うと、習得にも実現にも膨大な時間が必要となります。

アニメーション型

主要ツール:After Effects / Flash

『アニメーションを1から作り、動画として確認する』ツールを『アニメーション型』と分類してみます。

AEやFlashといったおなじみのツールも、画面サイズをモバイル用に設定すればプロトタイピングツールとして使えます。Flashはインタラクション型に分類することもできますが、こちらに分類します。

thumb03

アニメーション型のメリットは

  • 細かい部分を作り込むこめる
  • インタラクション型に比べて作成が容易

です。
本格的なVFXやアニメーションを作ろうと思うと習得に必要な時間は膨大ですが、アプリでの用途に限定すればインタラクション型ほど難しくはありません。
「インタラクション型で作る時間はないけど動きを確認したい」「細かい部分をちゃんと作りこみたい」といった用途に向いています。

反対に、デメリットは

  • 実際に触って操作できない
  • 反復性がない

です。
性質上、成果物は一定秒数流れる動画を眺めるだけとなります。それに伴って反復性もないため、インタラクションを確認する用途には向いていません。もちろん逆の動きを作れば反復性を持った動画が作れますが、やはりインタラクションという面では弱いです。

こうして分類すると、トランジション型を基軸にプロトタイピングを行い、補えない部分をインタラクション型やアニメーション型で補足すると、うまいことプロトタイプ作りのサイクルが回せるのではないかと思います。


シチュエーション別にプロトタイプを考えてみる

それでは本題に入りましょう。私たちは日々さまざまなサービスやアプリのデザインに関わっていますが、そのプロセスの中でプロトタイプはどのような役割を担えるでしょうか。
サービスやアプリを作るうえで関わるフェーズを簡易的に以下の4つに分け、各フェーズでどのようなコミュニケーションが発生し、どのようなプロトタイプが有用かをご紹介します。
あくまでも一例ですので、プロジェクトの性質や規模、チームの構成などによって内容が変化することはご了承ください。

企画フェーズ

企画提案のフェーズでの依頼内容は様々ですので、今回は『既存アプリのUI(設計)の改善』の依頼と仮定してみましょう。改善、とあるのですから、すでに何かしらの問題を抱えていると考えられます。調査・分析を行い、提案ができる状況になった際に、+αの提案材料としてプロトタイプが使えます。

誰に:クライアントに
何を:トランジション型プロトタイプ
どんな形で:ワイヤーフレームレベルのものを、主要機能の設計意図が確認できる状態で
発生するコミュニケーション:仮説が正しかったか、問題が解決できそうか、次のステップに進めそうか

ここでのプロトタイプの役割は『クライアントが感じている課題を解決できそうかどうかを実感してもらう』です。そのためには、細かい動きが作れるインタラクション型や一方向的なアニメーション型ではなく、トランジション型が有効です。
提案時においてはビジュアルが丁寧に作りこまれた動かない1画面よりも、簡易でも実際に動いて触れるもののほうがイメージしやすいですし、次のステップの行動が具体的になります。

ただし、企画フェーズでプロトタイプを提案する際は注意も必要です。
あくまでもプロトタイプだと強調すること。特にプロトタイプを見慣れていないクライアントに対しては、話を進めやすくするための取っ掛かりなのだと理解してもらう必要があります。
スケジュールの都合で提案に含められなかった際は、以降のフェーズにおいてプロトタイピングの有用性を伝えられるとよいでしょう。
説明用のドキュメントを用意したり、サンプルのプロトタイプを触ってもらうと効果的です。

設計フェーズ

方向性も決まり、さあ具体的に動き始めるぞとなったら、いよいよ本格的にプロトタイピングを導入していきましょう。
設計を進める過程で方向性がブレたり、エンジニアやクライアント間との意思疎通にズレができると、その後のフェーズで手戻りが発生することがままあります。設計段階からプロトタイピングを回すことでこれらの問題を解決しやすくなり、プロダクトの質を高められます。

誰に:クライアントに / エンジニアに
何を:トランジション型プロトタイプ
どんな形で:最初はワイヤーフレームで。徐々にビジュアル面もアップデートしながら
発生するコミュニケーション:正しく課題を解決できているか、設計に食い違いがないか、実装的に問題はないか

ここでのプロトタイプの役割は、企画フェーズに引き続いて『今の仮説に基づいた設計で課題がちゃんと解決できるか』を常に確認すること、もう1つは『この設計で実装上問題がないか』をエンジニアとコミュニケーションすることです。
レイアウトされた要素によってはAPIから引っ張ってこれない情報だったり、小さい画像しか用意されてないから画面いっぱいに広げられない、なんてことも多々あります。そういった細かい指摘を事前にクライアントやエンジニアからもらうことでプロトタイピングのサイクルが回せるようになり、後々の制作フェーズがスムーズになります。

また、トランジション型プロトタイプはユーザーテストでも活躍します。実装が始まってからのテストで使いにくいといったフィードバックが出ても後戻りするのは至難の業です。この段階からテストが行えれば、設計時におけるバグ(ユーザー体験の低さ)が取り除きやすくなります。

thumb04

なお、設計フェーズにおいてはペーパープロトタイピングも有用です。
クライアント(決定権を持っている人が望ましい)・エンジニア・デザイナーなどが会する場を設け、半日〜数日ほどディスカッションしながら進めることで、要件の確認漏れや実装の可否、そして一番大切な『共通のゴールに向かってお互い協力し合う』意識の共有ができます。
もちろん、そのような場を仕切るにはツールを扱うのとはまた別のスキルが求められるため、事前に書籍を読んだりチーム内で模擬的に試してみるとよいでしょう。

制作フェーズ

具体的な方向性が見えてくると、ビジュアルの制作に入っていきます。じゃあプロトタイピングはもう終わりでしょ、と思う方もいらっしゃるかもしれませんが、実は違います。
ここでの役割は、主に『インタラクションの効果を見定める』ことです。つまり、インタラクション型とアニメーション型の出番です。

誰に:エンジニアに / あるいは自分自身に
何を:インタラクション型プロトタイプ、アニメーション型プロトタイプ
どんな形で:インタラクションが必要と感じた画面
発生するコミュニケーション:実装的に問題はないか、無駄なインタラクションを作っていないか

インタラクションをUIの補助として用いれば、画面の状態や次に取るべきアクションがユーザーに伝わりやすくなります。プロダクトの性質によっては、動きを伴った画面が楽しさに繋がる場合もあるでしょう。
だからと言って独自性の強いアニメーションをモリモリ付け加えれば、実装に手間はかかるし、使い所によってはユーザーの気分を害するものにもなってしまいます。反復性のあるプロトタイプが作れれば、トランジション型では難しかったインタラクションの検証が可能となります。
また「ファーーーな感じでお願いします」「ザッときてシュッと逃げる感じで」と言葉だけでエンジニアに伝えても、微妙な成果物とコミュニケーションロスができあがるだけです。
それらを未然に防ぐためにも、インタラクションにおけるプロトタイプ作成は必須です。

加えて、全体の設計が見渡せるトランジション型もできるだけアップデートを継続するのが好ましいです。
なぜなら設計フェーズだけで全ての問題が解決するかというとそうではなく、実装的に難しい箇所や、クライアントからの要望でどうしても追加しなければならない内容などが新しく判明する場合もあるためです。それによって使い勝手がどう変化するのかを手早く把握するためにも、サイクルは回し続けたほうがよいでしょう。
また、プロトタイプを普段から日常的に使い続けることで、今まで見えていなかった問題点が浮き彫りになったり、より良い解決方法に気付けます。実装フェーズに入る前に気が付けば、まだなんとか方向修正ができるかもしれません(もちろん、各方面への説得や調整が発生しますが)。

実装フェーズ

実装が始まってからはプロトタイプを新しく作るのではなく、エンジニアの実装を助ける作業に移行します。

誰に:エンジニアに
何を:アニメーション型プロトタイプ
どんな形で:秒数や効果の発生タイミングなどがわかる資料を添えて
発生するコミュニケーション:実装が問題なく行えるか、意図したものができあがるか

前フェーズでインタラクションやアニメーションについての認識合わせができていれば、エンジニア側も実装のボリュームやスケジュールを立てやすいでしょう。デザイナー側が手伝えることは、なるべくエンジニアが迷わないように設計図を渡すことです。
例えばAfter Effectsでは取得したい項目をコピーして計算表ソフトなどにペーストすると、どのフレームでどれだけの値の変化があるか、といった内容が出力されます。

thumb05

ただ、これだけでは不親切なので、例えばタイムラインをキャプチャし、どのタイミングでどの値の変化が起きているのかを書き加えて動画に添えたりすることで、コミュニケーションロスが減らせるでしょう。


まとめ

以上、プロトタイプの種類と、それがどのようにコミュニケーションを助けるものであるかの紹介でした。
プロトタイプがあることによってコミュニケーションが発生し、そのコミュニケーションによってプロトタイプがアップデートされ、サイクルを繰り返すことで質の高いサービス、アプリに繋げられると感じて頂けたのではないでしょうか。
もちろん端折った部分もありますので、ここに書いた内容が全てではありません。Web・アプリ業界における認知・実践は十分とは言えず、「そもそも案件に導入するにはどうすればよいか」「社内を説得するにはどう立ち回ればよいか」など、始める以前にクリアーしなければならない課題も多くあります。
インタラクションについても、優先項目としては残念ながらまだまだ低い位置にあり、どうすればスムーズに提案が受け入れてもらえるか、筆者自身も答えを探している最中です。
また、今回言及できなかったペーパープロトタイピングに関しても、このお題だけで本が1冊書けるくらいの情報量があります。

もし記事のはじめに書いたように、あなたがプロトタイピングに興味をお持ちであれば、まずはプロトタイプに触れ、ぜひ実際に作ってみてください。そして、これはなんてすごいツールなんだ!と感動したら、周りと共有することをおすすめします。
プロトタイピングツールは無料のものもあれば、数万円するものもあります。まずは利用ハードルの低いトランジション型で、かつ無料で使い始められるものからスタートするとよいでしょう。
記事内で紹介した、以下の4つがおすすめです。

  • Prott(iOS / Android / カスタム / 1プロジェクトのみ無料)
  • Flinto(iOS / Android / 30日間無料)
  • InVision(iOS / Android / Web / 1プロジェクトのみ無料)
  • POP(iOS / Android / Windows 8 / 無料(執筆時点))

みなさまのプロトタイピングの一助になれば幸いです。


STANDARDでは、アプリのプロトタイピングだけのお仕事もお受けしています。
アプリやサービスの軸となるアイデアをもとに、実際に触れられるプロトタイピングを作成し、サービスの価値を検証したり、ユーザテストを通じて使い勝手を検証し、利用者に使われるアプリを様々な企業と一緒に作っています。
ご興味のある方はお気軽にお問い合わせください

記事一覧へ

Related Articles

About us

アプリやWebサービスなどの新規事業や既存事業における
アイデアの仮説検証からデザインまでをサポートします

株式会社スタンダードは、アプリやWebでサービスを展開される方の企画制作をサポートするデザインファームです。