a-blog cms Ver.3.2のUIデザイン制作の裏側

この記事は「a-blog cms Advent Calendar 2024」の13日目の記事です。

こんにちは!有限会社アップルップルでデザイナーをしている新井慎之介です。今年も a-blog cms Advent Calendar に参加しています。今年は、Web制作だけでなく、a-blog cms のUIデザインやマーケティング業務にも挑戦し、幅広い領域で活動する機会をいただきました。


この記事の概要

来年春リリース予定の a-blog cms Ver.3.2 の開発にひとりデザイナーとして携わりました。本記事では、デザイナーの観点から私が特に意識したポイントや、開発の中でデザイナーとしてどのように役割を果たしたのかをご紹介しています。

対象読者

  • UIデザインに関心がある人
  • チーム開発に関わるデザイナー(初心者)
  • a-blog cms ユーザー

担当したこと

a-blog cms Ver.3.2 では、多くのアップデートが予定されていますが、その中で私が担当したのは主に以下の2つです。

  1. エントリー管理画面の新機能のデザインとUI改善
  2. エントリー編集画面の新機能のデザインとUI改善

成果物について

今回のバージョンアップに関して私が制作したものは以下の3つです。

  1. エントリー管理画面のUIデザイン
  2. エントリー編集画面のUIデザイン
  3. a-blog cms Training Camp 2024 の発表スライド(内容はエントリー編集画面のみ)

1. エントリー管理画面(Figmaプロトタイプへ)

主なアップデート内容は以下の3つです。

  • カラムのカスタマイズ機能
  • 高度な絞り込み機能
  • 新機能に伴いUI改善

2. エントリー編集画面(Figmaプロトタイプへ)

主なアップデート内容は以下の3つです。

  • グループユニットの導入
  • ブロックエディタユニットの導入
  • 新規追加ユニットの導入に伴いUI改善

3. a-blog cms Training Camp 2024 発表スライドへ

セッションでは、a-blog cmsの次期バージョン「Ver. 3.2.0」で追加される機能の中から、エントリー編集画面に関する機能に絞ってご紹介させていただきました。


a-blog cms Live Vol.20 のお知らせ

上記の発表内容や a-blog cms Ver.3.2 に関する詳しい情報を知りたい方は 2024年12月18日(水) 12:00 - 13:30 に開催される a-blog cms LIVE Vol.20 にぜひご参加ください。a-blog cms Training Camp 2024 で発表された、a-blog cms Ver.3.2 に関するセッションを再演することを予定しています。


デザイナーが意識する4つのポイント

少し前置きが長くなりましたが、ここからは実際に開発チームの中でデザイナーとして意識しているポイントについてお話しします。

なお、Ver.3.2はまだ正式にリリースされておらず、現在も開発が進行中です。本記事では、要件整理からデザイン制作、フィードバックをいただくまでの範囲に焦点を当ててお伝えします。

  1. 開発チームにデザインプロセスの共有をする
  2. UIデザインの要件を整理してからデザインを始める
  3. フィードバックを早い段階から受けられるようにする
  4. 実際の体験に近い状態で提案する

開発チームにデザインプロセスの共有をする

開発チームにアサインされた際、早い段階でデザインプロセスの提案と共有を行いました。デザインプロセスを共有したことで、私自身も制作しやすくなり、特に大きな問題もなく、スムーズに業務を進めることができたと実感しています。

実際に以下のデザインプロセスを提案しました。


デザインプロセス

  1. 機能要件の把握 - ディレクターから課題・機能要件を聞いて理解する。
  2. UIデザイン要件整理 - 画面の表示情報、ユースケース、機能要件の整理をします。
  3. 参考UIデザイン調査 - 引き出しが少ないので、参考デザインを探しチームに共有する。
  4. 簡単ラフ作成 - ラフを書き、大まかな画面構成、機能や情報の過不足を確認する。
  5. UIデザイン作成 - 具体的なデザインの作成。
  6. フィードバック - メンバーや他者にデザインを触ってもらいます。
  7. 修正・改善 - フィードバックを基に細かい修正を行います。

デザインプロセスを提案する目的
デザインプロセスを提案した理由は以下の3つになります。

1.チーム構成の特性
開発チームはエンジニア職のメンバーのみで構成されており、デザイナー視点でのプロセスが明確になっていませんでした。そのため、デザインプロセスを取り入れることで、デザイン制作に対するチーム全体の理解と協力を得られるようにしたいと考えました。また、業務の進捗がわかりやすくなり業務工数の承認も得られやすくなりました。

2.大きな手戻りを防ぐため
事前にプロセスを共有し、デザイナーにとって制作しやすいようデザインプロセスを整備したことで、要件を理解する時間が生まれ認識のずれがなくなり、結果的に大きな手戻りがなく業務の効率化につながりました。

3.いきなりデザインを作り始めないようにする
いきなりUIデザインの具体案を作り始めるのではなく、要件整理やユーザー課題の明確化といった前段階を重視しました。これにより、課題やニーズを理解しやすくなり本質的な問題解決としてのデザインを提案することができました。

UIデザインの要件を整理してからデザインを始める

これはデザインプロセスの「1.機能要件の把握」と「2.UIデザイン要件整理」のフェーズでの内容になります。初期段階で正確に課題やユースケースを理解しておくことで、実際の利用シーンやユーザー行動を踏まえたデザインが可能になり問題解決のためのデザインを提案することができます。

開発ディレクターにヒアリングを繰り返し行いながら、以下のようなユースケースや行動フロー、画面で必要なオブジェクトや考えられるアクションを明確にしていきました。


ユースケース


行動フロー


オブジェクト


アクション

要件整理を重視する目的
UIデザインの要件を整理した理由は以下の3つになります。

1.課題やユーザーが求める価値を理解するため
デザインの本質は、見た目だけでなくユーザーの課題を解決し、価値を提供することにあります。要件整理のプロセスを通じて、ユーザーやビジネスが求めていることを深く理解することが可能になりました。

2.課題や要件の不明点をなくし抜け漏れを防ぐ
デザイン制作に入る前に、課題や要件に不明点がないか確認します。整理したシートを基にディレクターと確認していくことで、情報が不足している部分に気づくことができます。不明点を残したまま進めると、後工程で修正や大幅な方向転換が必要になる可能性があるからです。

3.デザイナーの視点から不足している情報や機能を提案するため
はじめから仕様や機能要件が確定している場合は少ないです。デザイナーは、ユーザー体験の観点から必要な情報や機能を見つけ提案を行います。これにより、より完成度の高いデザインを提供することができます。

フィードバックを早い段階から受けられるようにする

デザインプロセスにおいて、フィードバックを早い段階から受けられる体制を整えました。制作の方向性を早期に確認し、不明点を解消するために有効だと考えています。

実際に以下のようなラフを作成して議題の参考にしました。要件整理をした後にラフを提示し、メンバーと意見を交わすように工夫しました。


ラフ画像

ラフを作成する目的
フィードバックを早い段階から受けられるようにした理由は以下の3つになります。

1.要件を擦り合わせていくため
決して綺麗なイラストとは言えませんが、初期段階でラフデザインを提示し、メンバーと意見を交わすことで、メンバーにデザインイメージを掴んでもらえることができます。その結果、要件や期待する成果物の方向性を明確にすることができ、認識のズレを防ぐことができました。

2.仕様や指示された要件の不明点をなくすため
フィードバックを早めに受けることで、デザイナーに認識のズレがあることを確認でき、指示内容やデザインイメージについての不明点を早めに解消することができます。これにより、デザイン制作の途中で大幅な修正が必要になるリスクを軽減することができました。

3.要件や仕様が曖昧な場合でも調整を行えるため
機能要件の詳細まで決まっていない場合でも、具体物を見せて提案することで、チームとして適切な方向性を見出すことができます。また、メンバーが気づいていないニーズや不足していた情報を見つけることで、機能要件の修正を行うことができました。

実際の体験に近い状態で提案する

デザイン提案を行う時や他人にデザインを触ってもらう時は、単なるUIの静的な絵を確認するだけにとどまらず、Figmaのプロトタイプを活用し、実際の体験に近い状態を目指し制作することでプレビューを用いて提案することを心がけました。


Figma プロトタイプの設定

プロトタイプを作成する目的
プロトタイプまで設定する理由は以下の3つになります。

1.動作イメージや実用性が伝わりやすい
提案段階で実際の操作感を体験できるため、使いやすさや必要な機能が満たされているかを確認しやすくなります。ボタンのクリック後の反応やページ遷移、アニメーションの動きなど、静的なデザインでは表現できない部分を具体的に示すことで、デザインの「使われる姿」を直感的に伝えることができました。

2.コメントやフィードバックを得やすくするため
実際に動きを見せることで見る人がイメージしやすくなり、「ボタンが押しずらい」「この配置だと分かりにくい」など、具体的な意見を出しやすくなります。その結果、「意図がわからない」「想像しにくい」といった説明不足の問題を回避することができました。

3.エンジニアとデザイナーの連携がスムーズになる
プロトタイプやUI Stack に基づいたデザインを作成することで、エンジニアとの連携がスムーズになります。UIの動作やレイアウト、状態変化を明確に共有できるため、実装が始まる前に技術的なフィードバックを受けることができます。その結果、実装時の誤解が減り、仕様確認の手間を削減することができました。

さいごに

今回はデザイナーとして初めてa-blog cmsの開発に携わり、普段のWeb制作とは異なるUIデザインに挑戦する中で、不安もありましたが、新たな経験を積み初心者ながらもUIデザインを完成させることができました。UIデザイナーとしてはまだまだ未熟な部分が多いので、引き続きスキルを身につけられるよう精進して参りたいと思います。

今回、担当したデザインに関しては正式リリースされるまでにユーザーテストを実施したり、ユーザーさんからのフィードバックを基により価値のあるデザインを提供できるよう改善していきたいと思います。

明日の 「a-blog cms Advent Calendar 2024」14日目は、すずきカレーさんです!

a-blog cms Ver.3.2をきっかけに、管理画面のスタイルガイドを整理した話

この記事は「a-blog cms Advent Calendar 2025」の17日目の記事です。

こんにちは!有限会社アップルップルでデザイナーをしている新井慎之介です。
今年も a-blog cms Advent Calendar に参加しています。普段はWeb・UI領域のデザインを担当しております。


この記事の概要

今年9月にリリースされた a-blog cms Ver.3.2 では、エントリー編集画面にブロックエディターユニットやグループユニットといった新たなユニットが導入されました。あわせてエントリー一覧画面にもさまざまな改修が行われ、管理画面のデザインは大きく進化しています。

本記事では、デザインが変わりつつある a-blog cms の管理画面について、現状をあらためて整理し、今後の開発をよりスムーズに進めるために、このタイミングでスタイルガイドの整備に取り組みました。個人的に進めた取り組みではありますが、実施して見えてきた成果や感じたことをまとめてご紹介します。

対象読者

  • a-blog cmsの開発・デザインに関わる方
  • CMSやプロダクト開発におけるUI整理に興味のある方
  • スタイルガイド/デザインシステムに関心のある方

実施したこと

a-blog cms Ver.3.2 のUI制作がひと段落したタイミングで、Figma上にある管理画面向けのスタイルガイドを整理しました。これまでのUI制作の中で蓄積されてきたデザイン要素をあらためて見直し、今後の開発でも迷わず使える状態をつくることを目的としています。


まずは、既存の管理画面UIやデザインパーツを棚卸しし、どのようなスタイルが使われているのかを整理しました。その上で、Ver.3.2 の新しいUIで使用した要素も含め、ばらつきや重複がないかを確認しています。

最終的には、今後のUI開発を見据え、カラーや余白の使い方、タイポグラフィの考え方などを共通ルールとして再整理しました。新しい画面や機能が追加されても、デザインの方向性がぶれにくい状態を目指しています。

成果物について

今回の成果物は、Figma上で整備した管理画面向けのスタイルガイドです。UI制作に必要な基本要素をひとつにまとめ、すぐに参照・利用できる形で整理しました。

スタイルガイドには、カラー、スペーシング(余白)、タイポグラフィ、アイコンやUIパーツといった、管理画面を構成する要素を網羅的にまとめています。それぞれの項目について、役割や使いどころが分かるよう整理し、UI設計時の判断に迷いが生じにくい構成にしました。

また、「今すぐ使える」ことを意識し、スタイルガイドに含めた各項目は Figma のバリアブル機能にも登録しています。デザイン作成時にはスタイルを選択するだけで適用できるため、UI制作をスムーズに進められる状態になっています。


カラー(Color)

  • 管理画面で使用している色の棚卸し
  • 役割ごとの整理(ベース、アクセント、状態色 など)
  • UI内での使用意図が分かる構成に整理



タイポグラフィ(Typography)


  • フォントファミリー、サイズ、ウェイトの整理
  • 見出し・本文・ラベルなど用途別の定義

スペーシング(Spacing)

  • 既存UIとVer.3.2の新しいUIで使用した余白の整理
  • 今後のUI設計で使用する余白の基準を定義

ボーダー・角丸・エレベーション

  • Border width / Border radius の整理
  • メニューやドロワーなどで使用するエレベーションの階層構造を整理

アイコン(Icon)

  • 管理画面で使用しているアイコンの整理
  • a-blog cms icon と Material Icons の使用状況の整理

実施してよかったこと・得られた成果

デザインパーツの整理 ― 現状を正しく把握できた

今回スタイルガイドを整備してまず感じたのは、「現状を正しく把握できたこと」そのものが大きな成果だったという点です。

これまでUI制作を進める中で自然と増えていったカラーや余白、文字サイズなどのスタイルをあらためて棚卸ししたことで、「何が」「どれくらい」存在しているのかを具体的に把握できるようになりました。

整理を進める中で見えてきたのは、スタイルの細かな違いや重複です。
似たような色や余白、用途が曖昧なスタイルが複数存在しており、スタイルレベルでのばらつきが可視化されました。

これまでは「なんとなく違和感がある」と感じていた部分も、実際に一覧として並べてみることで、どこに整理の余地があるのか、どこを基準にすべきかを冷静に判断できるようになりました。

スタイルガイドの整備は、単にルールを作る作業ではなく、これまで積み重ねてきたUIの状態を正しく理解するための作業でもあると実感しています。

効率性が生まれた ― すぐにUIを作れる状態に

スタイルガイドを整備して特に実感したのが、UI制作にかかる迷いが大きく減ったことです。

これまでは、新しい画面や機能を設計する際に、「この色でよいか」「余白はどれくらいが適切か」といった細かな判断を、その都度考えながら進める場面が多くありました。こうした小さな判断の積み重ねが、UI制作全体のスピードに影響していたと感じています。

スタイルガイドを整備したことで、カラーやタイポグラフィ、スペーシングといった基本要素について、あらかじめ選択肢が用意された状態になりました。Figma上でスタイルを選ぶだけでUIを組み立てられるため、「考える前に手を動かせる」状態に近づいたと感じています。

結果として、UI制作のスピードが向上しただけでなく、設計の初期段階から画面全体のバランスを意識しやすくなりました。スタイルガイドは、単なるルール集ではなく、UI制作を前に進めるための土台として機能していると実感しています。

一貫性を保てるようになった ― デザインの方向性が明確に

スタイルガイドを整備したことで、a-blog cms の管理画面におけるデザインの方向性を、明確に示せるようになったと感じています。

これまでは、新しいUIを追加する際に「既存の画面と比べて違和感はないか」「これまでのUIと揃っているか」といった点を、感覚的に判断する場面が少なくありませんでした。

スタイルガイドを通して、カラーや余白、タイポグラフィの考え方を整理したことで、「a-blog cms の管理画面として、どうあるべきか」を言語化できるようになりました。これにより、デザインの判断を個人の感覚に頼らず、共通の基準に基づいて行えるようになっています。

新しいUIを追加する際も、「このスタイルはガイドラインに沿っているか」「既存のルールの延長として成立しているか」といった観点で判断できるため、設計時の迷いが減りました。

結果として、画面や機能が増えても、管理画面全体としての統一感を保ちやすくなり、長期的にUIを育てていくための基盤ができたと感じています。

属人化の防止 ― UIを支える共通の指針ができた

a-blog cms Ver.3.2 以降、管理画面のUIは少しずつ変化しています。新しいユニットの追加や画面構成の見直しが進む中で、「これからどんな方向にUIを育てていくのか」という指針が、より重要になってきました。

今回スタイルガイドを整備したことで、Ver.3.2 以降のUIにおける共通の判断基準を持てるようになったと感じています。これにより、特定の人の感覚や記憶に頼らず、誰がUIを設計しても同じ方向を向いて判断できる状態に近づきました。

また、スタイルガイドとして整理した内容は、今後UIを追加・改善していく際の土台として機能します。ルールが明文化されていることで、「なぜこのデザインなのか」を後から振り返ることもでき、UIの統一感を保ちやすくなります。

スタイルガイドの整備は、目に見える変化こそ少ないものの、長期的にプロダクトを育てていく上で欠かせない取り組みだと改めて実感しました。

参考にした書籍・デザインシステム

今回のスタイルガイド整備を進めるにあたり、デザインシステムの考え方や実務への落とし込み方を学ぶため、いくつかの書籍やデザインシステムを参考にしました。

書籍『Figma for デザインシステム』


https://amzn.asia/d/0A7Ubu2

デジタル庁 デザインシステム


Material Design


さいごに

今回、a-blog cms Ver.3.2 のUI制作をきっかけにスタイルガイドの整備に取り組み、あらためて 「スタイルを整理すること自体が、プロダクトを理解することにつながる」 と感じました。

カラーや余白、タイポグラフィといった基本要素を整理する中で、これまで感覚的に使っていたスタイルを言語化でき、現在の a-blog cms が持つデザインの特徴や方向性を、自分自身でもはっきりと捉えられるようになりました。

また、スタイルガイドを Figma のバリアブル機能とあわせて整備したことで、「ルールを決めて終わり」ではなく、日々のUI制作の中で自然と使われ続ける仕組みをつくれた点も大きな学びです。

今後は、今回整理したスタイルガイドを土台として、コンポーネント単位での整理やルールの拡張にも取り組んでいきたいと考えています。UIの変化にあわせてスタイルガイドも更新し続け、a-blog cms の管理画面を、より使いやすく、育てていける状態を目指していきます。

スタイルガイドの整備は地味な作業ではありますが、長期的にプロダクトを成長させていくためには欠かせない取り組みだと実感しました。この記事が、同じようにUIやプロダクトを育てている方にとって、少しでも参考になれば嬉しいです。

明日の Advent Calendar

明日の「a-blog cms Advent Calendar 2025」18日目は、桐田さんです!

Ver. 3.1.x の不具合修正サポート終了のお知らせ(2026年3月31日)


a-blog cms をご利用いただいているパートナー・ユーザーの皆さまへ、メンテナンスポリシーに関する重要なお知らせをお届けします。

Ver. 3.1.x の不具合修正期間が終了します

2026年3月31日をもって、Ver. 3.1.x に対する不具合修正(フィックスバージョンのリリース)を終了いたします。

Ver. 3.1 はもともと 2025年9月14日が不具合修正の期限でしたが、多くの方にご利用いただいていることを踏まえ、2026年3月31日まで延長してまいりました。今回はその延長期間の最終日となります。

なお、セキュリティ修正については 2028年9月14日まで引き続き対応を継続いたします。重大なセキュリティ上の問題が発見された場合は、フィックスバージョンをリリースする場合があります。

対応のお願い:Ver. 3.2 へのバージョンアップをご検討ください

不具合修正サポートが終了したバージョンを継続してお使いの場合、発見された不具合への対応が受けられなくなります。安定した運用を続けるために、Ver. 3.2 へのバージョンアップをご検討ください。

Ver. 3.2 は 2025年9月9日にリリースされ、不具合修正を 2027年9月9日まで、セキュリティ修正を 2030年9月9日まで提供予定です。PHP 8.1〜8.4.x に対応しています。

現在のメンテナンスポリシー(抜粋)

バージョン

不具合修正(期限)

セキュリティ修正(期限)

対応 PHP

3.2

2027/09/09

2030/09/09

8.1 〜 8.4.x

3.1

2026/03/31 終了

2028/09/14

7.3 〜 8.3.x

3.0

終了済み

2026/12/24

7.2.5 〜 8.1.x

全バージョンの詳細はメンテナンスポリシーのページをご確認ください。

バージョンアップのご相談

バージョンアップの作業やテーマの互換性についてご不明な点がある場合は、フォーラムサポート窓口へお気軽にご相談ください。公式パートナーへのご相談も可能です。

引き続き a-blog cms をよろしくお願いいたします。