はじめまして、Visionalグループ コミュニケーションデザイン室の扇谷です。主にビズリーチ事業部で、企業様に向けたWebサイトのCVR(コンバージョン率)向上施策やフロントエンジニアリングを担当しています。

現在、「ビズリーチ」の企業様に向けたサービスサイトの、コンポーネント化と実装のルールづくりを進めています。

今まで整備されていなかったコンポーネントや運用ルールを策定。工数を減らすことで、分析や施策検討の時間を増やすことが目的です。

サービスサイトは施策やチャネルごとにページが作成されるため、その数が増えるほど、スタイルの維持や一貫したブランドづくりが困難になります。

また、ABテストを行い、改善施策を高速で回すことも重要です。そのため、デザインや実装の工数が増え過ぎないようにしなければいけません。加えて、私たちのチームは、マーケティングチームと共通した目標を追っているため、デザイナーやエンジニアだけでなく、マーケターの作業も効率化されている状態が理想的です。

こうした前提の中で、事業づくりとブランドづくりを両立しながら、スタイルの一貫性を維持して、作業工数を削減する目的で、サービスサイトのコンポーネント化を進めました。

コンポーネント化を進めるにあたって「小さくコンポーネント化をはじめる」「あえて厳密なルールを設けない」「使われているコンポーネントを可視化する」を意識すると、うまく仕組みが回り始めたので、そのプロセスを紹介したいと思います。

「ビズリーチ」のサービスサイトでは、日々ABテストを繰り返すなかで、CVRなどの数値自体は向上していました。

一方で、

  • ページごとにスタイルや実装方法がばらばらになってしまっていた
  • 実装工数も膨らんでしまっていた

という課題を抱えていました。

それぞれの課題について説明していきます。

コンポーネント化を進める前は、デザインデータを管理するルールや、スタイルや実装方法がチームで統一されておらず、施策ごとにデザイナー・エンジニアが個人の裁量で決めていました。サービスサイトは60ページ以上に拡大し、メンバーが増えるにつれてページごとに個別最適が進み、スタイルがずれてしまったり、コードの負債が増えていました。

ほぼ同じ構成のページでも、レイアウトや実装方法がばらばらに……。ページごとに見た目が変わってしまうと、ユーザーから見ても違和感につながってしまいます。

また、ルールがないことで、プロセスの至る所で非効率な作業がありました。

例えば、マーケターからABテストや改善施策を提案する時には、既存のサービスサイトからデザインを参照して仮のデータを作り、それをデザイナーが実装可能なデザインデータにしており、マーケターとデザイナーがそれぞれデータを作成するフローになっていました。

他にも統一されたスタイルや実装のルールがないため、「ここはどうやって作る……?」といった確認が増えたり、既に似たパーツがあるのに新たなパーツを作って、コードレビューの負担が増えるなど、非効率な作業が増えて、工数がどんどん膨らんでいました。

チームとしてもカラーやclass名といった細部だけではなく、訴求内容などの企画部分にも時間をかけられるようにしていきたい。また、ユーザー体験の観点でもスタイルは統一化されていた方が良いと考え、サービスサイトのリニューアルを機にコンポーネントの整備を進めることにしました。

コンポーネントの整備は、以下のような流れで進めました。

  • よく使われるパーツの洗い出し
  • あえて厳密にしすぎない、コンポーネントのルールづくり
  • チェックシートで利用中のコンポーネントを可視化

60ページ以上のサービスサイトから、全てのパーツを一気にコンポーネント化するのは工数がかかり、かえって運用しているページの表示が崩れるなどのリスクも高まります。

そのため、「訪問数の多さ」「CVの高さ」「使われているページの多さ」といった観点から、パーツに優先度をつけてコンポーネント化を進めました。

訪問数の多いTOPページや、CVにつながる申し込みページのパーツを優先的に対応し、プロジェクトが大きくなりすぎないようにしました。

コンポーネント化を進める際には「マーケターを含んだ施策に関わる全員が扱いやすいこと」を意識して、使うメンバーのリテラシーに合わせたルールづくりをしました。

具体的には以下のような工夫をしています。

  • マーケターが直感的に扱えて、エンジニアがすぐに実装に入れるFigmaを採用する
  • マーケターには親しみのない「コンポーネント」という表現は使わず、「テンプレート」として使ってもらう
  • Auto Layoutなどの学習コストがかかる機能は使わない
  • 誰もが使い続けられるよう、パーツを自由に並び替えるだけで活用できるシンプルな構造のデータにする
ルールがなかった状態から、Figmaでの運用ルールも決めた上でコンポーネントの一覧を作成。全員がデータを扱えるルールを意識しました。

また、この機会にエンジニアと協力してコーディングのルールも定め、開発体験も含めてコンポーネント運用を進めやすくしました。

エンジニアが実装を行う際に考慮すべき点をチェック項目として可視化。今まで個人の裁量で決めていたclass名やフォルダ構成などのコーディングのルールもチームで共通化しました。

コンポーネント化したパーツは、どのページで使われているのかをチェックシート形式で可視化しています。

リスト化しているので、新たに同じようなコンポーネントを作ることがなくなり、コンポーネントを変更する時にも、リストを見れば影響範囲が分かるので、ページごとのスタイルのズレが生まれづらくなります。

スプレッドシートに各ページで使用しているコンポーネントをチェックボックスで可視化。チェックシート形式にすることで、一覧性と編集のしやすさを担保しています。

2022年中の完了を目処にコンポーネント化を順次適用しており、徐々にサービスサイト全体のスタイル・コードが統一され、デザインの工数が減ったことで本質的な議論に時間を割けるようになりました。

具体的には、ABテストを行う時にもボタンのカラーやフォントのサイズではなく、コピーライティングや情報設計など、よりCVや成果にインパクトがある部分の議論です。

事業の目標達成のためにABテストや改善施策の数をこなそうとすると、デザイナーは表層部分の作成・修正に追われて、気がつくと依頼をこなすだけの状況になりがちです。

そうなってしまうと、私たちがマーケティングチームと共通の目標を追っている意義がありません。

今後はマーケティングチームと同じチームのデザイナーとしてさらに価値を発揮するため、工数削減で生まれた時間の中で、デザインとマーケティングの考え方を持って、体験全体を俯瞰したインサイトの深掘りやユーザー体験の改善に時間を充てたいと思っています。

そして、マーケターは整備されたFigmaのコンポーネントを基に、素早くワイヤーフレームを作れるようにして、チーム全員でスタイルの一貫性を維持しながら、より早くサービスサイトを改善できる未来を目指しています。

今回、コンポーネント整備を進める中で「みんなが使いやすいしくみであること」を強く意識していました。

作り手として細かなルール設計までこだわりたい、このフレームワークを採用したいといったこだわりはもちろんありますが、それよりもみんなが気持ちよく使えるようにツール選定やルールづくりを行うことが、結果的に運用しやすさにつながりました。

また、このプロジェクトが進められたのは、「ユーザー体験の観点からデザインを揃えた方が良い」というデザインの目線を持っているマーケティングチームの理解があってこそです。

生まれた時間を有効に活用し、デザイナーや、エンジニア、マーケターなど職種を隔てずに、お客様の採用成功と魅力あるブランドづくりを繋げる架け橋となるような取り組みを今後も進めていきたいと思います。

このデザイン組織をもっと知る