見出し画像

ブレない工数をデザイナーが出しやすい ワイヤーフレームの書き方

今回の記事のターゲット

●ワイヤーフレームをデザイナーに引き渡し後、工数・スケジュールが想定通りにいかないディレクターの方
●ディレクターさんにワイヤーフレームで何を揃えてほしいか伝えられないデザイナーの方

スタートアップでは、ディレクターと言われるポジションの人が少ないため、課題と問いのみが掲示され、デザイナーが構成要素・コピーなど提案し、たたき台を作る場合が多いですが、ワイヤーフレームからデザインを起こすワークフローも健在です。

このワークフローでは、ワイヤーフレームをめぐってデザイナーとディレクターでスケジュール・予算面での食い違いが発生する場合があります。デザイナー側からすると、この原因は導線・要素の不備のケースが多いです。

特に予算が限られてる場合、デザイナーは見た目を整える(レイアウト・色をつける)に集中できた方が確実な工数を出しやすいです。

ただ、プロトタイプツールの登場で見た目を装飾しやすくなった分、機能より見た目の議論が優先されたり、ここは見た目の話か機能の話かを議論する時間が発生してると個人的に感じています。

今回の記事では、デザイナー側から見てブレない工数が出しやすいワイヤーフレームについて触れたいと思います。

ワイヤーフレームの目的と役割

デジタルプロダクトで最も重要な機能・ユーザビリティ面で具体化することで全員のプロダクトのイメージを共有できることです。

ワイヤーフレームは、デジタルアプリケーションやWebサイトの設計図です。ブレストや企画書を経て浮かんだデジタルプロダクトはぼんやりとしており、企画者・チームメンバーの描くイメージも各々違います。
これを、各画面の導線設計・要素(ナビゲーション・ボタン・テキスト)などを配置することで、具体的に表現するのがワイヤーフレームです。

いくら見た目が美しくても、メールアプリで送信ボタンがないためにメールが送れないなどがあっては、サービスが成立しません。これを防止するワイヤーフレームは完成度は高ければ高いほど良いです。

そして、このワイヤーフレームを元にデザイナーはレイアウト・色を施しボタンや見出しに装飾をつけルールとして統一する作業を行います。

つまり、ワイヤーフレームは

・要素・導線設計がしっかりと確認でき、ユーザが目的を果たせる機能が揃っていること
・ビジュアルの装飾は必要なくモノクロである方が理想的

となります。

具体的なチェックポイント

プロダクトのゴールをユーザーを迷わせずに行わさせる必要な情報を配置・導線を設計できてるかを確認します。

(1)必要な要素を各画面に漏れなく掲載できているか
(2)各画面に配置されたボタンを押した先に不要・不足な情報はないか
(3)ユーザがページで行うことが明示されてるか
(4) ユーザがページ操作を完了した後の事が明示されてるか
(5)実際に入れ込みたい文言が入っているか、管理画面・CMSなら最大文字数・最小文字数についての記載があるか
(6) 1〜5を実現するための情報の優先順位の整理ができているか
(7)機能や要素に落とし込めるにも関わらずやってほしいことを補足説明として掲載していないか※
(8)メモは誰に対するメモかなんのメモかなどの記載があるか※
(9) 要素を配置するときは、ボタンは四角で囲んであるだけにする、リンクは下線を引くだけにするなど、最小限の飾りで機能を伝えているか


なぜワイヤーフレームに見た目の演出やアイコンや色をつけない方が良いのか

ワイヤーフレーム本来の役割である機能・ユーザビリティの評価・議論の妨げになり、チーム全体のスケジュールやコストを圧迫する可能性があるためです。

人間は色・アイコンなどが配置されていると引っ張られる習性があり、本題を忘れやすい傾向があります。
ビジュアルを当て込んでいないワイヤーフレームになんとなく色・アイコンを追加すると、意図せず目立ってしまい、そのページを開いたときにどうしてもそこに目が行ってしまうなどの弊害が出ます。

想定されるデメリット

(1)想定外の工数・コストの発生(見た目・機能の分類に時間がかかる)

色やアイコンはデザイナーがビジュアル制作の際に置き換えるケースがほとんどです。
ので、徒労に終わるケースも多く、チーム間で「ここはダミーです」などの説明のコスト・メモの増加や、ここは機能か見た目の話かなどの分類が必要になり、ミーティング・デザイナーの制作フェーズに余計な時間がかる可能性もあります。

(2)機能の見落とし

検討要素が多くなると、見落としが発生し、デザインしながらワイヤーを詰め直すという作業が発生します。

例えば、管理画面は情報量によりレイアウトをどう配置方法を決めるケースが多いです。
不足してるナビゲーションがある場合、上にナビゲーションで進めていたにもかかわらず、上と左にナビゲーションが必要だった、ということにもつながり、根本で作り変えが必要になります。

最後に

本来のデザイナーという職業にそえば、機能と見た目を一緒に請け負うことが理想的ですが、予算・プロダクトの方向性を自分たちで握りたいというクライアントの意向などでこうならない場合も多いです。

ただ、一方でこの切り分けがうまく行ってないケースのままプロジェクトが進み、度々調整をすることやトラブルで相談を受けることがあるので、これまでの知見をまとめて書きました。

正直、要件さえ満たしていれば、ビジュアル要素があっても問題ないですし、制作会社でエンドクライアントがいる場合は、ビジュアル要素がないと具体的なフィードバックがない等はあります。

ただ、今回は白黒ハッキリつけた方がわかりやすいので、今回は明確などちらがやるべき、という話にしています。

この手の切り分けをしたり、まるっと引き受けたりが得意なので、できましたらご依頼をお待ちしております!


※具体的なチェックポイントで出した「※」ですが、この状態で来ることが増えました。
ワイヤーに落とし込めるものをメモで掲載してしまうと、結局は導線の検証がうまく機能していないことになってるかと思います。また、ワイヤーはチームに対し共有されるものなので、誰宛のメモなのか、なんのためのメモかもないと確認に時間がかかります。

この記事が気に入ったらサポートをしてみませんか?