ソーシャルウェブサービスのプロトタイピング

ソーシャルウェブサービスを開発する際には実機ベースのプロトタイピングが有効。ペーパープロトタイピングを凌駕するためにはアジャイルな開発思想と実践的スキルの双方が必要。受託開発においては体制や契約形態も重要。

ペーパープロトタイピングは有効な手法ですが、ことソーシャルウェブサービスにおいては、あまり有効ではないかもしれません。それよりは、実機による迅速なプロトタイピングのほうが有効だと考えています。

ペーパープロトタイピングとは: スクリーンに表示されるべきUI部品を紙で用意し、その紙を並べ替えたり、取り除いたりしながらUIを設計する方法のことです。プロトタイピングの本質は試行錯誤することにありますが、他のどんな手法よりもそのスピードが速い手法であり、ソフトウェアのUI設計にはよく用いられる方法です。次の動画を見ていただければイメージがつかめるかと。

「なぜ、そんなにもUIにこだわるのか?」といえば、ユーザーにとっては、UIこそが製品そのものだからです。

ソーシャルウェブサービスとペーパープロトタイピング

「ソーシャルウェブサービス」を次のように定義します: 他のユーザーとコミュニケーションするために用いられるウェブサービス。

例えばTwitterについて考えてみましょう。もしTwitterが世の中にないときに、そういうものを設計するとしたら、ペーパープロトタイピングをするでしょうか? 実際にやってみたら、どうなるでしょうか? 紙でUIラフを見せられて「いま何をしていますか?」という欄に「記入してください」と言われて、何を記入できるでしょうか? それはペーパープロトタイピングの本来の目的にとって意味のあることですか?

ソーシャルウェブサービスにおいては、そこに書き込まれるテキストが本質的に重要です。ところが、テキスト(何を書くか)は、UIの「手触り」による。UIの「手触り」は、紙で再現しずらい。だからペーパープロトタイピングは、ソーシャルウェブサービスに向いてない。

もちろん、ソーシャルウェブサービスにおいても、ペーパープロトタイピングが役立つかもしれない用途はあります。使いやすさ/使いにくさの検証です。ただ、最初からペーパープロトタイピングが必要になるのだとしたら、そもそも企画が複雑すぎる可能性を疑ったほうがいいかもしれません。(※「ペーパープロトタイピングが有効な場面など無い」と言っているわけではありません)

ソーシャルウェブサービスの、利用者にとっての価値

ソーシャルウェブサービスにおいて「使いやすい」「ユーザビリティが高い」とは、どういう状態でしょうか? 「やりたいこと」(つぶやくとか)がストレスなくできることでしょう。それは衛生要因(満足しなければいけないが、それだけでもダメ)に過ぎません。

本質的な価値は、ユーザーが「やりたいこと」の中にあります。それは何でしょうか? 「コミュニケーション」です。ソーシャルウェブサービスのユーザーは、コミュニケーションがしたくて使うのです。(ここで議論している「ソーシャルウェブサービス」の定義は「他のユーザーとコミュニケーションするために用いられるウェブサービス」です)

与えられたUIを用いて、ユーザーが実際にどんなコミュニケーションをするか。これが重要です。これは実験しなければ分からない。実験とは、実際にモニターに使ってもらうことです。設計意図と異なるユーザー行動が観察できるかもしれない。現実世界の不確実性(新規事業の不確実性)の前で、事前に完璧な設計ができるはずもありませんから、実験(フィジビリティ・スタディ)は大事です。実験なしに巨大なシステムを設計するのは無謀です。せっかく作っても利用者に受け入れられないリスクがある。だから実験をする。その具体的な手法としてプロトタイピングがあります。

ここまでの議論をまとめると、ソーシャルウェブサービスにおいても、プロトタイピングは有効。しかし、ペーパープロトタイピングの有効性は限定的になる場合がある。こういう議論になっています。

実機によるプロトタイピング

ならば、どのようにプロトタイピングすればいいか。「実機」です。実際の端末(PCやモバイル端末)で、実際に操作できるプロトタイプを作る。

ソーシャルウェブサービスのプロトタイプとは、実際に他のユーザーとコミュニケーションできる「場」のことでもあります。

ここで、そもそもペーパープロトタイピングをする理由を振り返ってみましょう。ローコストで、迅速にできる利点から採用される手法です。ユーザーテストの前日に準備することもできるし、ユーザーのフィードバックをその場で反映(設計変更)できる。ペーパープロトタイピングには、このような利点があります。

しかし、このペーパープロトタイピングが、ソーシャルウェブサービスにおいては有効でない場合がある。そのとき、どうするか? どれだけ速く実機のプロトタイプを作るか。頭の中で考えた設計について、いかに素早くユーザーのフィードバックを得るか。つまりアイデアの実装速度。これを追究します。

〔註:なお、作らずに実験・仮説検証ができるなら、それに越したことはない。なるべく「作らずに実験する方法」を模索することもお勧めします。→新規事業投資、どこまで削れるか

そこで、設計書を最小限に、要件を最小に(コアにフォーカスしてシンプルに)する方法を考えます。なぜコアにフォーカスするのか。それは「事業の仮説検証(F/S)」という観点からです。

具体的に、どう実施していくのか。まずは、利用者の体験を設計するために、ページフローのラフスケッチを描きます(漫画で言えば「ネーム」でしょうか)。そのスケッチで、デザイナとエンジニアが、作るべきものを共有できたら、すぐに実装します。それ以上の資料を作らずに済むなら、それが望ましい。

『RailsによるアジャイルWebアプリケーション開発』で示されている方法のように。

AgileWebDevelopmentWithRailsJaP51.png

※初版51ページより引用。現行の最新版は第2版のようです。

Powered by POPit

あるいは、もっと簡便なスケッチ方法もあります。開発チームが高度にコラボレーションできるのであれば、次のように簡便に。まだ試していませんが、おそらくこれでも問題ないでしょう。(※エンジニアではなくデザイナーが設計を主導する前提)

UIデザインを共有するためのシンプルな記法とは?(37signalsの場合) - IDEA*IDEA ~ 百式管理人のライフハックブログ

ui

↑ それぞれの画面に対して「何があるか」「何をするか」に分けて記述しています。

324-todo-flow

↑ たとえばTo Doを追加するときのユーザー体験。

325-login-flow

↑ もっと複雑なフロー。これはログイン画面。

このような開発手法をとるためには、開発チーム(の全員)が人間中心設計の概念を理解している必要がある、と言っても過言ではないでしょう。早期に品質を作り込む落とし穴に陥りがちなので、そうではない、設計された手抜きの重要性を理解している必要があると思います。
「デザイン」がソフトウェア開発を変革する - ZEROBASE Journal

そのようなチームを作れば、ソーシャルウェブサービスにおいてもプロトタイピングができます。

ただし、受託開発においては、請負契約・ウォーターフォール型のプロジェクト設計では難しい場合もある。準委任(的)契約の形態を検討してみる価値はあります。
プロトタイピングに適した受託契約形態 - ZEROBASE Journal

トラックバック(0)

トラックバックURL: http://zerobase.jp/mt/mt-tb.cgi/444