先日、自分が所属している会社でエウレカさんとワイヤーフレームについての合同勉強会がありました。この合同勉強会、ワークショップもありの二本立てだったのですが、本当に良くて。参加者それぞれのワイヤーフレームの捉え方・作り方の違いが垣間見えて非常に学びの多い良い会でした。エウレカさんのデザイナーさんたちのレベルの高さに刺激を受けると同時に、弊社デザイナー陣に対してもそのスキルレベルの高さにかなりびびりました。(自分ももっと頑張る。)

弊社デザイナーののがちゃんがその時の様子をかなりいい感じに記事にしてくれてるので是非ご覧ください。

が、当日の話題には上らなかったけれども、私個人としてワイヤーフレームを作る上で重要だなと考えていることがあるのでまとめておこうと思います。

そもそもワイヤーフレームという言葉が指し示す範囲が広い

先のワークショップの記事にもある通り、ワイヤーフレームを作る目的は概ね以下の2点に集約されると思います。

  • 1. 情報整理
  • 2. チーム間での認識合わせ

その結果どういったメリットがあるかというのも、先日の合同勉強会で話題に上りました。

  • 仕様や機能を早い段階で明確にできる
  • 工数把握(早い段階でスケジュールが引ける)
  • 事前にコミュニケーションをとるのでロスがくなる

さて、上記3点を目的とした場合にWebサービス開発、モバイル・アプリ開発ではワイヤーフレームの理想を定義するとなると、以下のような感じになるんじゃないかと思います。
(ワイヤーフレームの言葉を広くとってフェーズごとに粒度を変えるか、そもそもそれをワイヤーフレームとは呼ばずに別の呼び方をするかは難しいところ、、)

ワイヤーフレームの粒度
この表のkeynoteファイル

結論:インタラクションが重要なアプリ開発、特に改善フェーズでは、ワイヤーフレームに遷移図と画面仕様書を含む必要がある

単純なWebサイト作るのであればデザイナーが1人で出来るから別に画面仕様書なんて書かなくていいかもしれないんですけど。ワイヤーフレームって結局のところコミュニケーションツールなので、自分一人じゃ完結しない開発において、いかに情報をきちんと伝えるのが大事かというのを考えています。

※「改善フェーズ」と限定した理由:多くのスタートアップや、プロダクトのα版、β版を開発しているチームではそんな遷移図とか画面仕様書なんて作る時間があったら先にリリースしてイテレーション回していくべきだなと考えているためです。

実際のワイヤーフレーム例

以下私が普段作っているワイヤーフレームの各粒度別のものです。

1. ラフ

1ラフ

汚くて笑…笑えない…プライベートのやつなので適当感満載ですが、でも普段も大体こんなもんかも。ブレスト・ディスカッションしながら「こんな感じだよね?」って言いながら書いたり直したり。その時のメンバーでイメージが頭のなかにわけばok。(ラフって抽象度高いから、リモートの人がいるときはあまりやりません)

2. 構成図

WF
DSC_8332-e1425541281556
画像引用元:memopatch

そのページに必要なものは全て洗い出して書くことを意識しています。
去年まではCacooで全部書いてたけど、最近は後からSketchで色付けするんだし最初からSketchで書いたほうが早いやってなって、Sketchで書いてそれを書き出し→Cacooにアップしてます。

過去記事ですが、前職での開発合宿の時もまさにCacooで構成図作ってました。

3. 構成図+遷移図、 4. 構成図+遷移図+画面仕様書

Untitled (2)

エウレカさんとの合同勉強会で使った架空のショップの構成図に遷移図と画面仕様書をつけてみました。(普段の業務で使うものはもっと色々書きこみありますが、、)
前職のチームでは4名のエンジニアに対してデザイナーは自分1人という状況だったため、「●●が」「▲▲をトリガーに☓☓する」と画面の仕様まで書いておいたWFを渡しつつアプリを組んでもらい、同時進行でビジュアルデザインを作成していく、というのが効率良く良かったです。
また、過去も今も普段の業務ではアジャイル開発を導入していることが多く、このWFが更新を重ねて膨大な量になった時「どれが最新だよ」ってなるので、スプリントごとにCacooのシートをコピーしてそこに書き足していくことが多いです。

全体俯瞰をするのはワイヤーフレームで、個別のインタラクション確認はプロトタイピングで

suuminsan-e1426207682321

自分がエウレカさんとの勉強会で作った画面構成図をもとにしたプロトタイプ

こういった全体の設計図を作る作業って、私のこれまでの経験からすると誰かが1人でばばばーっと叩きを作った後、それをチームでブラッシュアップ・確認をするステップが入ります。その時のチェックの方法として、単純に全体の設計像であるワイヤーフレームの他に、個別のページごとに不自然な点や破綻が無いかをチェックするプロトタイプが必須だなと。
単純にワイヤーフレーム作って終わり!じゃなくて、最後にそれをプロトタイプにまで生かせるとよりブラッシュアップがしやすくなるのかなと思います。

完全にステマでしかないですが笑、個人的にはprottがどの用途にも対応できるのでいいなと思ってます。ペーパープロトタイプもデザインデータを書き出してからのプロトタイピングもどちらも簡単にできるし、PCで画像作って入れて、そのまますぐiOSアプリで見れるのでとっても楽になりました。(前職ではFlinto使ってたけど、贔屓目ぬきにしてもアプリがある点から今は完全にprott派です。)

そんな感じでワイヤーフレームの話でした。今の会社にはいって3ヶ月が過ぎ、もうすぐ初めてアサインされたプロジェクトが終わるのでなんだかそわそわしています。一緒にやっているクライアント先の方に「よくやってくれてる」と言われた時は嬉しくて泣くかと思いました。笑 寂しいような、達成感もあるような。最後まで全力でがんばります。