「じゃあ、ここまで聞いた内容を元に、MVP(※1)になりそうな画面を設計してみて。今ここで。このホワイトボードに」
今いる会社の仕事の性質上、こういう振り方をよくされます。こんな依頼をされたときに、何を考えているのか、ポイントをまとめてみました。
(※1)MVP(Minimum Viable Product) やろうとしていることを検証するために必要最低限の製品のこと
ペーパープロトタイピング
ホワイトボードに書く、というのは、いわゆるペーパープロトタイピングと同じだと思っています。しかし、綺麗なペーパープロトタイプを事前に作るのではなく、その場でリアルタイムに作り上げて、それをその場でお客さまと一緒に検証するという点が異なります。
何をプロトタイプするか? その場で何が分かれば良いのか?
- 雰囲気。その場で話された内容が実現されると、ざっくりどんな雰囲気になるのか。
- 情報構造。見た人が理解できる構造になっているか? 複雑さなど。
相手が知りたいのは雰囲気。「どんな感じになるのかなー?」という感じです。
書いた後に実際に作るのは僕(プログラマ)なので、僕が知りたいのは情報構造。
意識の向き方としては、情報構造を明確にすることを考えながらページのデザインをすると、結果的に雰囲気が分かるので、両方のニーズが満たせます。
デザインの迷いをなくす
しかし、何のベースもない状態で、いきなり真っ白いキャンバスに絵を描けと言われても、普通困りますよね。そんなときは、すぐに実装に使えるフルスタックのCSSフレームワークを前提として、絵を起こしてしまいます。
例えば、フルスタックのCSSフレームワークとして代表的なものに、以下のフレームワークがあります。
僕は主にTwitter Bootstrapを使っています。
このようなフレームワークでは、いわゆるWebサービスでよくあるインターフェースがあらかじめデザインされています。例えば、
- タブ
- パンくずリスト
- サイドメニュー
- ボタングループ
- ドロップダウン
- ツールチップ
- などなど・・・
大体必要なものが揃っている感じです。
こういったインターフェースを使うことを前提に、絵を描いてしまいます。絵を描くというより、ブロックを積み上げるイメージに近いですね。
いわゆるワイヤーフレームなのですが、既存のCSSフレームワークを前提とすることで、すぐに動くモックアップを作り上げることができます。ホワイトボードで見せているイメージとぶれないのがメリットです。
絵を描こうと思うと、どこまでも想像力がはたらいてしまって、上手く描けないですよね。CSSフレームワークを想定することで、絵を描くのではなく、構造を描くことに集中できます。構造の型として、CSSフレームワークを使ってしまうのです。
2年前に僕が描いたホワイトボードのメモが弊社社長ブログにあったので、それを参考までに掲載します。本当は最近のものがあると良いのですが、あまり公開できないものばかりなので、2年前のものでご了承下さい。。

ソフトウェアをつくるための3つの役割〜アジャイルに外部設計は必要か
情報構造の考え方
- 情報の親子関係
- 情報の持つバリエーション(カテゴリなど)
- 情報の並び方(時間、優先度など)
情報構造として分かりやすいものになっているかどうかを気にしつつ、セルフレビューの観点として、すぐにデータベースのモデルに落とせるようなものになっているかどうかも気にします。
このあたりの考え方は、自分の中でまだ体系化できていないので、今後のエントリで再度取り上げたいと思います。
むすび
動くワイヤーフレームを作るための前準備が、ホワイトボードでの画面設計という位置づけなのかなとも感じました。使える絵を描いて、ガンガン開発してしまいましょう。