フロントエンド開発 – プロトタイプ入門

プロトタイプとは、最終的なデザインのシミュレーションを作ることであり、最終製品がどのように見え、どのように感じるかのサンプルです。これでその機能を評価できるようになり、さらにこれで欠点も明るみになることから、デザインチームは具体的なものがわかるようになります。

また、チームは、時間や資金や労力ををつぎ込む前にプロトタイプをテストでき、ステークホルダーはフィードバックを出して、次の段階を承認することができます。

なぜプロトタイピングなのか

プロトタイプで以下のようなことができることから、製品の目標とプロジェクトの各段階への移行方法が明確になります。

• ステークホルダーにデザインを最初に見てもらうことができる。
• UXチームは製品の感触をテストできる。
• デザインの状態を製品のコンテクストの中で示すことができる。
• 無意味なものを出力する厄介なアルゴリズムが明らかになる。

プロトタイプは終わりから始まる

デザインに施されたあらゆる装飾に夢中になると、いい UX（ユーザーエクスペリエンス）が目標であることが置いてけぼりになりがちです。

UXデザイナーとして重要なのは、ユーザーの頭の中に入り込むことです。彼らのペインポイントを把握しましょう。何が不満で、どんな目標や願望があるのでしょうか。

対象とするユーザーについての「ストーリーがわかる」UXマーケティングツールが以下のようにあります。

• ユーザーペルソナ：エンドユーザーを代表する架空の人物であり、製品ごとに１～３人設定可能。
• ユーザーストーリー：デザインを使うユーザー ペルソナの簡単なストーリーであり、役に立たない機能の追加の回避につながる。
• ユーザーシナリオ：UXデザインをペルソナやその目標と結びつけることができる。
• カスタマージャーニーマップ：カスタマージャーニーの前後におけるユーザーの行動や感情をマッピングすることで、ユーザーが意識する前にニーズを予測することができる。

これらは架空の描写ではありますが、実在の人物や出来事が表されているはずです。言い換えれば、ユーザーリサーチからわかることを元に構築されています。

静的なプロトタイプ

プロトタイプは、ほとんど何でもあり得ます。紙ナプキンやノート、ホワイトボードにもざっと書いてもいいですし、Photoshopや Illustratorで作るのもいいでしょう。このような静的なプロトタイプで、製品がどのように見えるかや、ユーザーがどのように操作するかが見えてきます。

例えば、顧客が持ち帰りを注文できるレストランのモバイル Web サイトをデザインしているとすると、プロトタイプをデザインして、注文中のユーザーのインタラクションと画面の状態を以下のように示す必要があります。

• アカウントの作成：プロトタイプは、アカウント設定のプロセスが模倣されているべきである。例えば、「ユーザーがチェックアウト時にアカウントを作成すると、レストランはより多くの注文を得る」という調査結果があるとすると、プロトタイプではチェックアウト時のユーザー入力がシミュレーションされるべきである。
• ログインする：ここで、プロトタイプでは入力フィールドが表示される。また、ユーザーが間違った情報を入力した場合の応答も表示される必要があり、ユーザーがまだアカウントを作成していないのにログインしようとした場合の画面の状態も表示されるべき。
• 注文：プロトタイプには、メイン、副菜、ドリンクなどのメニューのカテゴリーがあり、ユーザーがカテゴリーを選択したときにサイトがどのように動作するかが示され、カテゴリーから製品が選択されたときに画面に製品がどのように表示されるかも表示されるべき。
• 会計：ユーザーがどのように支払い情報を入力し、次回以降の注文のために保存するかなどが示される。
• 商品受取に到着：レストランへの到着をどのように知らせるかがシミュレーションされる。例えば、レストランが店外受け渡しの場合、ユーザーは駐車場番号を入力することができる。

ただし、このレストランが、客にダイニングルームのテーブルを予約させたいとすると、プロトタイプでは、持ち帰り注文やテーブル予約のオプションがどのように表示されるのかが示されます。

静的なプロトタイプだと、製品は以下のように表示されるかもしれません：

• ホーム：この例では、持ち帰りの注文やテーブルの予約ができる。プロトタイプでは、ボタンで持ち帰りのページと予約のページに移動できることがわかり、矢印や線はこのようなページの図面に結合させることができる。

• 持ち帰り注文：ここでは、以下のようなカテゴリーのレイアウトがわかる。
  • メイン料理
  • サイドメニュー
  • ドリンク
• 予約状況：予約可能なテーブルが以下のようにわかる。
  • テーブル
  • ブース
  • テラス席
  • バー
• お会計：ユーザが以下でどのように持ち帰り注文を完了するかがわかる。
  • （必要な場合）ログイン/ユーザー名とパスワードの作成
  • 支払い情報
  • 注文の確認
• 到着：レストランスタッフへの以下のような注意喚起の方法がわかる。
  • 駐車場番号
  • 予約受取の到着

これらをフローチャートのように並べることで、プロトタイプのパーツがそれぞれ何をして、製品がどのように見えるのかがわかります。

ただし、これでユーザーと対話はできません。

インタラクティブなフロントエンドプロトタイプ

インタラクティブなプロトタイプだと、UX チームがデザインの感触をつかむことができることから、より優れており、製品テスターからのフィードバックがあれば、次のフェーズに進む前にプロトタイプを以下のように改善することができます。

• ホーム：インタラクティブなプロトタイプだと、お持ち帰りか予約を選んでそのホームページを試すことができる。
• お持ち帰り：ここでは、ボタンやその他の画像がどのように見えるかがわかり、ボタンをタップして、デザインに改善が必要かどうかの判断ができる。
• 予約：テーブルを予約する際の UX を評価でき、空いてるテーブルやブース席、テラス席やバーのテーブル、予約可能な時間帯などを確認できる。
• お会計：支払い情報の入力や保存、お気に入り注文の保存などが簡単にできるかどうかがわかる。
• 到着：レストランスタッフにどのように到着を知らせるかがわかる。

コードによるプロトタイピング

プロトタイプでコードを使うと、静的なベクターベースのデザインに関連する問題はすべて解決します。これが「本当の」フロントエンドプロトタイプだとしましょう。Mergeのテクノロジーが搭載された UXPinだと、プロトタイプ用にコード化されたコンポーネントを UXPinのライブラリにインポートできることから、プロジェクトを進めるときに、以下のことからそれがもっとシンプルになります。

• デザイナーにコーディングの専門知識は必要ない。
• エンジニアは、すでにコーディングされたデザイン要素で作業できる。
• DesignOpsチームは、単一のソースからデザイナーとエンジニアの両方に役立つプロトタイプを構築できる。

コードを直接扱うので、後で変換する必要はありません。なので、エディタで修正が大変だったり、デザイン開発プロセス全体が台無しになる可能性がある複雑なコードの作成の回避になります。

Mergeでプロトタイプが機能的になるだけでなく、コンポーネントをキャンバス上にドラッグ＆ドロップするだけで、自分でサッと簡単に機能させることができます。また、希望しない限り、インタラクションの追加は不要です。Mergeのテクノロジーは、UIだけに焦点を当てた究極のプロトタイプであることから、実稼働可能なコンポーネントを備えたバックエンドのことは考える必要がありません。

実際に体験してみましょう

ゼロからまた作り出す必要はありません。コード化された React.jsコンポーネントを Github や Bitbucket などのGitレポジトリから UXPinデザインツールにインポートして、すでに持っているものを最大限に活かせます。

Mergeテクノロジーが搭載された UXPin をお試しになり、コードコンポーネントによるデザインを開始して、製品の市場投入までの時間を短縮しましょう。