webサイトの設計。それは「正解を作る工程」です。
webサイトの設計。それは「正解を作る工程」です。
webサイトの設計、きちんとできてますか？
webサイトを作ることは、家を建てることに例えられることが多いです。
家を建てるとなれば、「詳細な図面」や「資材の調達計画」など準備が綿密に行われ、建築設計事務所という専門会社があるものです。
webサイトにおいてはどうでしょう。
webディレクターが全部をこなしており、そしてその手順や押さえるべき項目に標準的なものが無いのが現実だと思います。
マーケティング、ブランディング、といった要素ももちろん重要です。
しかし、webサイトの設計に長年携わってきた自分としては、webサイトの設計というものに、webディレクターはもっとコミットすべきだと考えます。
今回は、webサイトの設計をどう進めて良いか分からない方向けに、その手順をまとめます。
結論は「webサイトを設計することは、制作するものの正解を作る。」ということだということです。
要件定義も、設計の１つ。
手順をお話しする前に大事なことを１つお知らせしておきます。
webサイトの設計というと「設計フェーズでやればいい」と考える方がいるかもしれませんが、webサイトの設計は、最初に概算見積をクライアントに提示するときにはすでにスタートしています。
なぜなら、「こういうものを作るなら」「これくらいの金額です」というものをお見積で提示しているということは、内容の想定もされているはずだからです。
その内容は何を根拠にしていますか？
ページ数、CMSの有無でしょうか。いや、もっと色々あります。
お見積を提示する段階から設計は始まっているのです。
現状のwebサイト設計状況
すみません、もう一つ気になっていることを伝えます。
現在Amazonで、「webサイト 設計」というワードで検索しても、出てくる書籍は、画面を構成する要素、UIについてのものがほとんどです。そして数が少ない。
webサイトの設計といっても、前述のように意外と世の中に、標準となるものが存在していないことに驚かされます。
・・・ってことは、webディレクターの人はどうやってwebサイトの設計をしているんでしょう・・・？
ワイヤーフレームという見た目の枠組みだけつくって、それを設計って呼んでるとしたら・・・
「そんな装備で大丈夫か？」って聞きたくなります。
それは建築でいうところの、図面、資材調達計画に相当するものになってますか？
その設計で家建てたら、速攻崩壊しませんか？
住みやすい家になってるって言えますか？
webサイト設計を4つの手順に分けて考える。
では、工程について説明します。
ここでは、ユーザーの定義、カスタマージャーニーマップ等を踏まえた戦略策定のフェーズ後という認識で話を進めます。
1. 基本設計（要件定義・プロジェクト計画）
webサイトの全体像を定義する設計ステップです。
何をするのか、何をしないのか、という要件定義とあわせて進めていきます。
クライアントからのオリエン踏まえた、企画・提案要素も含まれます。
その企画・提案を進めるにあたっては分析・調査を行うこともあるでしょう。
あるべき形をクライアントに提示できるかどうかがキモです。
- 機能要件・非機能要件の要件定義
- コンテンツマップ
- サイト構造設計
- サイト基本仕様
以前に基本設計のステップという記事を書いているのでそちらもあわせて参照いただければです。
2. 外部設計
基本設計を踏まえて、画面や機能を具体的にしていくステップです。
画面設計では、UI設計、コンポーネント設計を含みます。
コンポーネントというのは、ページを構成する要素のことです。
webサイト全体を通して、ページを構成する要素というのは、共用できるものが実はほとんどです。そういうパーツ定義のことを言っています。また、そういうコンポーネントにどういう情報を乗っけるか、というのも設計フェーズで行います。それがコンテンツ設計にあたるものです。
コンテンツ設計においては、集客用のキーワードとランディングページの定義も合わせて行います。コンテンツは制作会社側で全部を準備できるものではありません。
実際はクライアントから提供されるものベースになるとは思いますが、webサイトをリニューアルするのであればただの移行ではなく、コンテンツ編集的なことをある程度作業のスコープに含んでおく必要があります。
また機能設計では、平面的な画面設計を見ただけでは分からない機能を定義していきます。
例えば・・・
ここを押したらどうなるのか。
ここが開いたらどういう選択肢が出てくるのか。
この情報はどのページとどのページに同時に表示させる必要があるのか。
といったことです。
あくまで、ユーザーが目に触れる部分、クライアント担当者がCMS等から触れる部分について定義していきます。
- 画面設計（UI設計、コンポーネント設計含む）
- 機能設計
- コンテンツ設計
3. 内部設計
外部設計を元に、どこからどこにデータが流れ、どのようにデータを管理するのか。そういう内部的な仕様やデータ管理方法を定義していきます。
ここは、webディレクターが設計するのは難しいパートです。
システムエンジニアや、バックエンドプログラマーとすり合わせを行い、ドキュメントにまとめてもらいましょう。
詳細な把握は不要ですが、何をやっているのか、どういう情報が管理されているのかはwebディレクターも把握をしておく必要があります。
- システム構成設計
- プログラム設計
- 入出力・API設計
- データベース設計
4. 環境設計
webサイトを配置する環境の設計です。
本番環境だけではなく、ステージング環境、検証環境も含まれてきます。
ここも内部設計と同様、webディレクターが設計するのは難しいパートです。
システムエンジニアとすり合わせながら決定しましょう。
ここは、要件定義の非機能要件事項とも関係します。
クライアントが必須と考える事項をどう対応するのか、というレベルではwebディレクターも把握をしておく必要があります。
- サーバ構成設計
- 契約するサービスの定義
まとめ
今回お話ししたことで大事なポイントがあるとしたら・・・
4つの手順はそれぞれ繋がってますよ。ってことです。
基本設計で全体像を固めているから外部設計ができる。
外部設計でユーザーが触れる機能やコンテンツを定義できるから、内部設計で、そのデータ処理方法を定義できる。
そういう理解をした上で、それぞれの手順を進めていけると、クライアントとの意思疎通もしやすいです。
webサイトの設計は、「ワイヤーフレーム」という朧げな定義のものを書くことだけではありません。
webサイトの制作も、関係する要素が以前にくらべれば本当に多くなっていて大変だと思います。
ただ、個人的には、設計フェーズというのは「正解を作ること」だと思っています。
正解を一度作ってしまえば、あとは、それが出来上がるさまを見ていればいいのです。
それは極論と言われるかもしれませんが、うまく進んでいるプロジェクトが本当に設計がしっかりしています。
逆に炎上しているプロジェクトは、設計がゆるゆるです。
そのゆるゆる具合は、あとで「そんなつもりじゃかなった」「前から何が良くなった？」「なんか違う」みたいな余計な修正の繰り返す状況を引き起こします。
設計は正解を作る作業です。正解があるから、最終的に「検証・テストが出来る」訳です。
webディレクターはやること多くて大変だと思います。
しかし、「最初に正解を作るんだ！」という気持ちで臨めれば、結果的には、作業工数も減り、スピードも上がるはずです。
