01 企画
最も重要な段階です。
この段階では、目標と目的を定義し、対象ユーザーを調査し、Webサイトのロードマップを作成します。
なぜ目標を設定するのか
- 目標があると焦点が明確になる
- 目標は、設計が成功したかどうかを判断するのに役立ちます。
- 目標があれば、そこに到達するための手順を計画できます。
ウェブサイトの主な目標は 1 つだけである必要があります。
主な目標を見つけるにはどうすればよいか?
ソリューションで実現したい主なことは何ですか?
- 商品を売りたい
- ブランドを構築したい
- 大義に対する意識を高めたい
- など..
それが何であれ、1つ選んで、文にまとめます。
目標を後で評価および測定できるように表現します。
競合他社のソリューションを見てみる
競争相手は常に得られる最高のインスピレーションの源です。
まずは自分の専門分野だけでなく、それ以外の分野でも気に入ったWebサイトを見てみましょう。
これらのソリューションについて特に気に入った点についてメモを取ってください。
必要な機能をすべてリストアップする
主な目的に貢献する独自の機能と要素のセットが必要です。
基本的にすべてのウェブサイトに必要なもをまとめると
ブログ機能
ブログを書く予定がない場合でも、最近ではブログ モジュールが必須になっています。他に何もなければ、会社のお知らせに使用することができます。
連絡フォーム
ユーザーに Web サイトを通じて連絡してもらいたい場合、連絡フォームは重要な役割を果たします。
ソーシャルメディア統合
製品やコンテンツの下にあるソーシャル メディア ボタンの形式だけでなく、独自のソーシャル メディア プロフィールへの自動コンテンツ共有の形式でも
SEO機能
少なくとも、コンテンツや商品の SEO タイトルと説明を設定できるようにしたい
ウェブサイト分析
Google Analytics の使用が標準です。
コメントスパム対策
ウェブサイトのコメントセクションはスパムを受けやすいです。 。 Web サイト上でこのセクションを保護することが重要です。
ニュースレターモジュール
単純な電子メール収集モジュール (電子メールをサードパーティ ツールに取り込むため) またはサイト自体の完全なニュースレター モジュールの形式
バックアップ
緊急時に常にサイトの最新のバックアップにアクセスしたい場合
Cookie通知
EU 内の訪問者にサイトを表示する場合は、これらが必要で
セキュリティメカニズム
攻撃者や悪意のあるスクリプトからサイトを安全に保つツール
必要になる可能性のあるその他の機能:
- 電子商取引モジュール
- ライブチャット機能
- カレンダーと予定の予約
- メンバーシップ モジュールまたはオンライン コース モジュール
- バナーと広告モジュール
このリストは決してすべてを網羅しているわけではありませんが、考えさせるには十分であり、おそらく独自の項目を 1 つか 2 (または 10) 追加することができます。
02 ブランド＆デザイン作成
この段階では、レイアウト、配色、タイポグラフィー、その他のデザイン要素を含む、Web サイトのビジュアル デザインに取り組みます。
ブランドを定義する
アイデンティティ
→「神秘なる諏訪湖に心癒される宿」 と表現。
プロミス
・変化（時間、四季）する諏訪湖の神秘的（非日常的）な美しさ
・若返れる温泉と、心の癒しを感じさせる食と空間
・心の癒しを感じさせるおもてなしとサービス（接客、メニュープラン）
に決めました。
ブランド・プロミスは「そのブランドが保証する価値を継続的に提供します」と顧客に対して約束することです。上記の約束を守れないということは、消費者・顧客を裏切ってしまうことになります。もし、これを変えたいという場合は、別のブランドを新たにつくる必要があります。
ブランド・パーソナリティ
ブランド・パーソナリティはブランドが持つ「優しい」「元気な」といった人格的な性格の特徴のことで、人にたとえて表現します。しんゆでは樋口可南子というキャラクターを設定しました。
ブランド・パーソナリティはブランド自身のキャラクターを表し、ブランドの個性を感じとってもらうために大切になるものです。
ブランド・イメージが出来上がっている場合、顧客は、ブランドを購入したり、使用したりすることで自分自身とブランドを重ね合わすことができます。例えば、男らしいブランドの衣服やアクセサリーを身にまとうことで、男らしい自分というものを意識したり演出したりすることができます。
こうしてブランド・アイデンティティと同時にブランド・プロミスとブランド・パーソナリティを明確にすることで、ブランド独自の価値を、ブランドを構成する最小単位であるブランド要素や、ブランド体験※まで浸透させることができるのです。
※ブランド体験：ブランドに接触するすべての体験。
デザインを作成する
まずは企画で目的を明確にしていると思いますが、その目的に沿ったデザインを作成しなければなりません。
情報設計：サイトの構造を決める
次にWebサイトに何の情報を入れるか、Webサイトの構造を決めてツリー状などの図にしていきます。自社の基本情報・商品情報・問合せ情報などの入れたい内容をリストアップし、似たような内容のページごとに分類した後、構成順位を決めます。構成順位とは、コンテンツ（内容）をどのような順番で表示させるのかといった優先順位をいいます。
Webサイトの構造をツリー状の図にまとめておくと、レイアウトも決めやすくなります。
レイアウトを決める
Webサイトの構造が決まれば、それを元にレイアウトを決定し、ワイヤーフレームと呼ばれる設計図を作ります。ワイヤーフレームとは、どのWebページにどの情報を配置するのかを記した、Webデザイン作成のための大枠です。ワイヤーフレームがあれば、情報配置が一目でわかるため、Webサイト作成に関わるメンバー同士の連携もスムーズになります。
デザインを決める
ワイヤーフレームが完成すれば、実際にユーザーの目に入る、具体的なデザインの作成に取り掛かります。Webサイトの色やフォント、写真やイラストといった画像を選択し、配置を決めて完成形を作ります。デザインカンプと呼ばれるできあがった完成形をもとに意見のすり合わせを行い、デザインを決めます。
03 開発
動的なwebサイト作成する場合はできるだけ以下のフローで作る：
- プロトタイプ版
- アルファ版 ( α版 )
- ベータ版( β版 )（追加機能が途中で発生した場合）
- マスターアップ版
※ 静的なサイトを作成する場合は（プロトタイプ版を十分にテストした後アルファ版やベータ版は必要なく、マスターアップ版を直接作る流れでも問題ないです）
プロトタイプ版
デザインが決まれば、それをプロトタイプもしくはウェブサイトとして公開し、機能させるためのコーディングをします。コーディングとは、デザインカンプを元に、その通りのレイアウト・デザインとなるよう、ソースコードを作成する作業のことです。ソースコードとは、プログラミング言語で記述されたテキストを指します。
プログラミング言語は、それぞれ役割の異なる「フロントエンド」と「バックエンド」のふたつに分けられるため、目的に応じて使い分けることが大切です。
プロトタイプのテスト＆テストで上がった障害が対応完了したらアルファ版
アルファ版 ( α版 )
繋ぎ込み段階です。
アルファ版のテスト＆テストで上がった障害が対応完了したらベータ版作成
ベータ版( β版 )
追加機能の繋ぎ込み段階です。
ベータ版のテスト＆テストで上がった障害が対応完了したらマスターアップ版作成
マスターアップ版
ステージングや本番のテストのための開発フェーズです。
追加機能など避けて最後の微調整のみ行います。
04 テスト
開発と同じようにテストも各フェーズに行われます
- プロトタイプ版
- アルファ版 ( α版 )
- ベータ版( β版 )（追加機能が途中で発生した場合）
- マスターアップ版
テストはいくつかの種類に分けて効率よく行うことが大事です。
必ずプロジェクト開始でテストの定義を行う必要があります。
静的テスト/ Static Test
- 実装コスト、実行時間: 低い
- 信頼性: 低い
静的テストは、基礎的なlinting（プログラミング言語の文法の間違いやエラーを指摘する）や静的解析であり、誤字脱字などの基礎的な問題を見つけるのに役立ちます。
静的テストは最も手軽に、かつ素早く実行できるテストです。ですが、このテストの結果で保証されるアプリケーション全体の品質に関しては高い効果は得られないと考えます。
単体テスト/ Unit Test
- 実装コスト、実行時間: 少し低い
- 信頼性: 少し低い
単体テストは、ライブラリのテストや便利関数に対しては最適だと考えています。
それはより小さなロジックやデータ処理に焦点を当てるので、条件付きロジックや関数呼び出しのように、特定の入力セットと出力セットが対応していることを確認するテストになるからです。
統合テスト
- 実装コスト、実行時間: 少し高い
- 信頼性: 高い
統合テストでは、バックエンドサービス間やフロントエンドフレームワークのコンポーネント間など、サービス／コンポーネント間の相互作用をテストします。
このテストは、コンポーネントが連携して正しく動作することを確認するために必要になります。単体テストでは、各コンポーネントが正しく動作することが分かるかもしれないが、データエラーやロジックエラーは、コンポーネントを分離してテストしたときにのみ現れるかもしれません。
統合テストでは、テストの実行プロセスをより軽量化できるので、より低コストで実施できます。
E2Eテスト
- 実装コスト、実行時間: 非常に高い
- 信頼性: 非常に高い
E2Eテストでは、ユーザーがアプリケーションでアクションを実行しようとするときに遭遇し得る品質問題を想定し、アプリケーションのユーザ体験全体をテストします。一般的に、最も実行時間と実装コストがかかりますが、「ユーザーはアプリケーションに不備を感じないだろう」という確信が得られます。E2Eテストはより高性能なサーバを必要とし、完了までに時間がかかるので、コストもかかります。E2Eテストに非常に長い時間がかかる一因は、バックエンドサーバに対して呼び出しすることにあります。これによって多くのことが分かりますが、厄介な事態に陥ることもあるのです。それは、E2Eテストが失敗した場合、フロントエンドコードのせいではなく、バックエンドに問題がある可能性があるからです。
05 公開
手動公開
FTP機能を使う
サーバーにFTP機能が付属している場合はその機能を利用することも可能ですが基本的にFTPソフトを利用した方がいい。
NetlifyやAzure Static Web Appsなどの場合
直接ブラウザー経由でファイルをアップロードすることは基本用意されています。
自動公開
git＋CIインターフェースを使用して自動的にアップするように設定する最も無難なやり方です。
デプロイする時に自動テストやミス防止も独自で設定できるのでお勧めします。
06 メンテナンス＆運用
Webサイトは公開してから「保守運用」がとても重要、
なので、制作中にサイトの構造は必ずこのフェーズの考慮を入れるべきです。
メンテナンス画面やメンテナンススケジュールが明確であれば、サーバーと連携して、自動化することも可能です。