画伯だけど画面案描いてみた:3. ワイヤーフレーム編
第3回 ワイヤーフレームを描いてみる
目次
- 優れたUXとは?
- UXリサーチをやってみる
- ワイヤーフレームを描いてみる
- ハイファイプロトタイピングを作ってみる
- ケーススタディしてみる
はじめに
今回はUIの最も初めの形になるであろう手書きでワイヤーフレームを書いてみます。
エンジニア歴10年。手書きで画面を描くなんてわざわざやったこともないので初の試みですが、Google UX Design Certificationでも推奨されているのでやってみます。
架空アプリの設定
シェア型別荘の予約システムを作成します。
年数日しか使用しない別荘を一棟購入するのではなく、数泊分の利用権を購入する「別荘シェアリング」は、近年注目されているサービスです。
プロダクトページは誰でもアクセスできるWebサイトを想定していますが、今回は「別荘を購入した後の予約システム」を想像でデザインするストーリーを進めます。
ワイヤーフレームのメリット
言ってしまうと手書きによるメリットは時間をかけないで済むに集約されていると言っても良いでしょう。
そもそもローファイワイヤーフレーム自体が細部ではなく大枠にフォーカスしたデザイン検討の側面が大きいので、むしろ手書きの方が目的の達成には便利です。
さらに、手書きならではのラフさがあることで、関係者がアイデアを気軽に出しやすく、ブレインストーミングや初期のアイデアスケッチに最適です。
一方で、共有する目的であったり、オンラインで仕事をすることの多い現代ではデジタル化する意味は大いにあります。
プロジェクトのスケジュールや状況によっては、初めからハイファイプロトタイプを作ってステークホルダーに共有するというのも全然アリです。
1. デザインに含める要素を明確化
- 各ページに配置するべき要素を確認しやすくなる。
- 必要な要素が含まれているかどうか、関係者全員で判断が容易に。
2. 問題の早期発見
- 各ページの要素配置やユーザーの動線をマッピングできる。
- 要素の欠落、順序の乱れ、整理不足を早期に検出可能。
3. 構造への集中
- 関係者が色やテキストの詳細ではなく、サイトやアプリの全体構造に集中できる。
- 初期段階でのフレームワーク決定を効率化。
4. シンプルさによる柔軟性
- 線と単純な形で構成されたシンプルなアウトライン。
- 細部にとらわれず、全体像を簡単に議論可能。
5. 時間と労力の節約
- 初期段階でのガイドラインとして機能し、エンジニアや関係者が早期に合意可能。
- 必要な修正が減り、スムーズなプロジェクト進行が可能。
6. 素早い反復作業
- デザインの選択肢を迅速に検討可能。
- 新しいデザイン案を短時間で作成できる。
ワイヤーフレーム
作成したワイヤーフレームがこちらです。(絵が下手な人あるあるが所々表れています)
ワイヤーフレームのメリットセクションでも述べたように、構造に集中するためになるべく文字は書かないことが良いとされています。ただし、何を表示するエリアなのか程度は記載した方が良いでしょう。
デザインを描きやすい画面と重要そうな画面だけピックアップして描いてみました。
初めにホーム画面と予約画面。
(どのタイミングで予約状況を取ってくるか、あるいは方式など、バックエンダー的な考慮はここでは一切触れません)
ホーム画面:
- 所有している別荘
- 別荘のステータス
予約画面:
- 別荘の良い感じのビュー
- スケジュール
- 別荘の追加情報
追加オプション画面:
- 追加のサービスを選択する
- シェフを付けたり
- ワインを付けたり
完了画面:
- ここまでに入力した情報を表示する
とりあえず描いてみるとこんな感じになります。
前回作成したペルソナの高橋さんのゴールは達成できているでしょう。
このワイヤーフレームの時点ではどこに何が表示されるのか表現されていませんが、ペインポイントとなっていた以下の問題についても触れられるようにしています。
- 予約や利用調整の煩雑さ
- 物件の維持管理に対する不安
- 他のオーナーとの意識の違い
- アプリの使いにくさや情報の不足
終わりに
初めて手書きでワイヤーフレームを描いてみました。
じっくり考えて作るものではないため、画面設計をシンプルに考えて大枠を確認するための非常に有用な手法だと感じました。
また、チーム内および関係者との議論を活性化し、デザインプロセスの方向性を共有するツールとしても優れています。
手戻りを減らすためであったり、活発な議論を行ってチームの活性化何となく良い感じのMTGをした感を味わうことにも有用です。
次回
Figma(気分が乗ればFlutter Flow)でハイファイプロトタイプを作成してみます。
Discussion