Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
20251102 WordCamp Kansai 2025
Search
Chiaki Okamoto
November 02, 2025
Technology
1
1.1k
20251102 WordCamp Kansai 2025
WordCamp Kansai 2025のセッション「ブロックテーマ実践記 – 本当に使いやすいWordPressの作り方」のスライド
Chiaki Okamoto
November 02, 2025
Tweet
Share
More Decks by Chiaki Okamoto
See All by Chiaki Okamoto
2025/09/18 AIコーディングで「保活手帳」を作ってみた
chiilog
0
63
なんとなくわかった気になるブロックテーマ入門/contents.nagoya 2025 6.28
chiilog
1
360
私の推しはブロックエディター 〜デフォルトブロックに触れ合う〜
chiilog
0
370
この一年で身についた“マトモ”な WordPressテーマの作り方
chiilog
7
2.1k
WordPressテーマの作り方 2019 私のベストプラクティス
chiilog
24
14k
Google Optimizeで始めるA/Bテスト #wbkyoto
chiilog
1
3.4k
こんなCSSからはそろそろ卒業しよう
chiilog
18
17k
まだCSSで消耗したい?Sassを覚えて楽しちゃおう!
chiilog
4
2.1k
さいきょうのWordPressサイト構築フローとは
chiilog
2
1k
Other Decks in Technology
See All in Technology
Progressive Deliveryで支える!スケールする衛星コンステレーションの地上システム運用 / Ground Station Operation for Scalable Satellite Constellation by Progressive Delivery
iselegant
1
210
プロダクト負債と歩む持続可能なサービスを育てるための挑戦
sansantech
PRO
1
730
[CV勉強会@関東 ICCV2025] WoTE: End-to-End Driving with Online Trajectory Evaluation via BEV World Model
shinkyoto
0
320
AI駆動開発を実現するためのアーキテクチャと取り組み
baseballyama
14
10k
信頼性が求められる業務のAIAgentのアーキテクチャ設計の勘所と課題
miyatakoji
0
110
国産クラウドを支える設計とチームの変遷 “技術・組織・ミッション”
kazeburo
4
7k
マルチドライブアーキテクチャ: 複数の駆動力でプロダクトを前進させる
knih
0
8.2k
アジャイル社内普及ご近所さんマップを作ろう / Let's create an agile neighborhood map
psj59129
1
140
Greenは本当にGreenか? - B/GデプロイとAPI自動テストで安心デプロイ
kaz29
0
130
身近なCSVを活用する!AWSのデータ分析基盤アーキテクチャ
koosun
0
3.7k
AS59105におけるFreeBSD EtherIPの運用と課題
x86taka
0
240
Dev Containers と Skaffold で実現する クラウドネイティブ開発環境 ローカルのみという制約に挑む / Cloud-Native Development with Dev Containers and Skaffold: Tackling the Local-Only Constraint
bitkey
PRO
0
120
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
84
9.3k
Git: the NoSQL Database
bkeepers
PRO
432
66k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.8k
4 Signs Your Business is Dying
shpigford
186
22k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
Build your cross-platform service in a week with App Engine
jlugia
234
18k
Product Roadmaps are Hard
iamctodd
PRO
55
12k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
118
20k
Transcript
1
岡本千秋 株式会社HAMWORKS フロントエンドエンジニア Github: @chiilog X: @chiilogweb Zenn: https://zenn.dev/chiilog 2
今日のアジェンダ 1. 「更新しやすいサイト」とは何か 2. 設定パネルに頼りすぎない設計をする 3. パターンで「完成形」を提供する 4. デザインの選択肢を整理する 5.
まだ解決できていないこと 6. まとめ 3
1. 「更新しやすいサイト」とは何か 4
こんな状況に陥ること、ありませんか? 「更新しやすいサイトを作ってほしい」という要望 でも 「どう更新するか」は具体的に詰められていない 結果として……… かっこいいデザインだけど更新できない 機能は豊富だけど使い方がわからない 結局、ユーザーが更新を諦めて、制作会社に毎回依頼することになる 5
これは誰が悪いわけでもありません! 「更新しやすいサイト」が当たり前すぎて言語化されていないことが 原因 6
「更新しやすい」とは、ユーザーにとって 必要なときに、 必要な場所を スムーズに更新できる 7
そもそも、なぜ「更新しやすさ」が重要? ユーザーが更新しやすい ということは、 情報が新鮮に保たれる ことであり 訪問者(エンドユーザー)に価値が届く ことにつながる! これが、私が考えるWordPress(CMS)の本質です。 8
これを実現するために ブロックテーマで試行錯誤してきました 解決できたことも、できなかったことも 理想論じゃない、現場の話。 「私なりのやり方」をお話しします! 9
2. 設定パネルに頼りすぎない設計をする 10
まず、一番大事にしていることは 設定パネルを触らなくても きれいなコンテンツが作れる状態を目指す 11
それってどういうこと? ユーザーが「コンテンツ」に集中できるようにする テキストや画像など、本来考えるべきことに時間を使う レイアウトや装飾の設定で迷わせない 12
例えば、スペーサーブロック 余白なら「サイズ」で選べるのでは?と思う ところだけど……… パディング、マージン、ブロックの間隔… ユーザーは何を触ればいいか分からない 13
そもそもの問題 14
15
そもそも設定パネル自体が出てなくて 存在を知らない可能性もある! 説明を聞いても、実際に使う時には 「なんだったっけ…?」ってなるかもしれない 16
じゃあ、ユーザーはどうする傾向にあるでしょう? 17
Q.空の段落ブロックは何を意図していると思いますか? 18
A.「スペースとして」の段落ブロック この使い方の問題点 意図がわからない → 「これ消し忘れ?」と思われて削除されてし まう コントロールできない → 複数入れても思い通りの余白にならない 19
そこでスペーサーブロックの出番 20
21
見た目のためのブロックがわかりやすいのはどっち? 22
「正しいCSS」より「わかりやすい操作」の方が、 ユーザーには価値がある 「ここは余白にしたい」という意図が明確になった ほしい余白を確実につけられるようになった 結果、ユーザーが迷わず、デザインも崩れない 23
3. パターンで「完成形」を提供する 24
よく使われるレイアウトの例 25
既存ブロックの組み合わせで 色々なデザインが作れます。 26
でも、これを他のページでも使いたいとき… 毎回ブロックを組み合わせるのは大変 複雑なレイアウトになるほど手間がかかる たくさん重なったグループブロック………どこをコピーしたらいいかわ からなくなりがち! 毎回1から作ると、デザインを統一するのも難しい 27
そこで「パターン」の出番 ブロックの組み合わせを「パターン」として保存すれば、 入れるだけで整ったデザインが使えます 28
「パターン」からどういうデザインがあるか一覧で見ることができる 29
パターンがない頃はカスタムブロックを作っていた 今ならブロックの組み合わせでできることも、 その都度カスタムブロックを作っていたので、 開発コストが今より高かった! コアの更新に追従しないのでメンテナンスも大変………。 「いらなくなったから消す」ができない、負の遺産になりがち。 30
パターンの作り方 1. エディターでブロックを組む 2. ブロックを選択 → 「パターンを作 成」 3. 名前とカテゴリを設定
4. 「同期」のチェックを外して保存 これだけ! 31
理想的なページの作り方 1. パターンを挿入 2. テキスト・画像を差し替える 3. 必要があれば微調整 パターンの組み合わせだけでページが作れる状態を目指す! 32
実際にパターンにしているもの 複雑なレイアウト・デザイン性が高いもの メインビジュアル 入力が面倒・設定が必要なもの 病院の診察時間テーブル、背景色付き全幅セクション 繰り返し使うもの 投稿一覧、装飾付き見出し、カードリンク 33
さらに、ページの雛形も 作れます ページ全体をパターンとして 作成することができるので、 新しいページを作るたびに過去の ページをコピーする手間が 省けます! https://developer.wordpress.org/themes/ patterns/starter-patterns/ 34
ただ、WordPressが提供する機能だけでは 実現できないデザインもあります 例えば: ボタンのホバー時の色変更 矢印などの装飾アイコン メインビジュアルなど、緻密なレイアウト調整 リンクのクリック可能な領域を拡張する 35
そんなときは、 ブロックの 追加CSSクラス を使う WordPressのコア機能ではカバーしきれない 部分を独自のCSSで補う形をとります。 なお、追加CSSクラスを使うたびに CSSファイルを増やすのも大変だなぁと 思っているので、私はTailwind CSSを
採用しています。 36
ポイント: ユーザーが入力することは想定していない 開発者がパターン作成時に設定する 「複数ブロックで成り立つデザイン」をコンポーネント的に扱える 万が一class名が壊れても、パターンを入れ直せば元に戻る 37
カスタムブロック? or パターン? まずはブロックを使ってパターンで実現できるか? を考えましょう 1. コアブロックの組み合わせで解決できるか? 2. CSSで装飾すれば実現できるか? ---
8〜9割くらいはここまでで解決します --- 3. 既存ブロックに機能を追加するプラグインを入れる? 4. それでも無理ならカスタムブロックを作る or 要件に合致するプラ グインを使う 38
結果、パターンを使うようになってどうなった? カスタムブロックの開発数がすごく減った! 数年前は「10〜20個作るのは当たり前」くらいでしたが、近年は 5個作ったらちょっと多いかも?と思う くらい。 カスタムブロック=Reactでの開発なので、パターンにすることで 開発コストも下がりました。 39
4. デザインの選択肢を整理する 40
デザインの選択肢を整理する ユーザーの執筆体験を邪魔しない設計を目指す 見た目に関する設定はあらかじめ作り込んでおく ボタンの色や、本文のフォントサイズ 設定パネルによるカスタマイズの効率化 41
設定パネルは「補助」として使う 右側の設定パネルでできることは限定的に。 カラーを変える フォントサイズを変える この2つを重点的に設計する! 42
例: フォントサイズ デザインからスタイルを整理して、 可能であれば5個に絞ります。 デフォルトのフォントサイズをMサイズに 設定して、それより大きい見出しのサイズ+ 小文字に使うためのSサイズで 構成しています。 43
大量にフォントサイズを設定したところで 使わない 選択肢が多いとどれを使うのがよいか迷っ てしまう 6個以上だとセレクトボックス形式にな り、操作感が変わって混乱する S〜XXLからポチッと押すだけでフォント サイズ変わる方が手間がない 44
例: カラーパレット デフォルトの色はノイズにしかならないので、 無効化しておく。 ( theme.json で "defaultPalette": false )
サイトで使わない色が大量に並ぶことで、 本当に使うべき色が埋もれる。 結果、色選びに時間がかかったり、誤った色を 選んでサイトの統一感が損なわれてしまう。 45
どんな色をカラーパレットにする? 企業のコーポレートカラー → Primary, Secondary デザイン上で使われている色 → 背景色、 差し色など 機能的な色
→ エラー表示用の赤など カラーパレットは視覚的に選べるので、 色相順や使用頻度順に並べると選びやすい 46
その結果、ユーザーからの反応は? 47
実際にいただいた声や起こったこと 「カラーパレットを設定してもらったので、色を探さなくてよくな って助かる」 「使い方を説明してもらっただけで、やりたいことができるように なった」 ユーザーが制作会社に依頼することなく、自分でページを作成でき た 48
49
5. まだ解決できていないこと 50
ボタンのホバー ボタンブロックのホバー色は現状、 管理画面から設定できません。 CSSで :hover をつけるしかないけど、 ボタンの色ごとにホバーの色を変更する ことができない。 今のところは透過や輝度の変化で対応中です。 51
ナビゲーション メガメニューだとどう作る?→Interactivity APIを使う手法で検証中 そもそもスマホでレイアウトが変わるのはどうする? メガメニュー参考:https://developer.wordpress.org/news/2024/02/an- introduction-to-block-based-mega-menus/ 52
Tailwind CSS を使うかどうか? 実装時には独自CSSではなく、Tailwind CSS を 採用していますが、これが最適解かどうかは まだ模索中です。 「今のところ大体うまくいっている」 だけなので、もっといいアプローチも
探っていきたい。 53
これだ!っていう答えはまだない WordPressもバージョンアップのたびに どんどん作りやすくなっています。 今回私が発表した内容も、 数ヶ月後にはもっといい案が出ているかもしれない。 試行錯誤しながら、最適解を探していく このスタンスはずっと大事にしたい。 54
まとめ ユーザーが使いやすく、 訪問者(エンドユーザー)にも価値が届く。 両方を満たして初めて、サイトの価値が生まれる 55
具体的なアプローチ 56
設定パネルに頼りすぎない設計をする 右側の設定パネルは気づかれにくい → スペーサーなど、目に見える形 で余白を作る パターンで「完成形」を提供する ゼロから組み立てるのは大変 → 「入れるだけで整ったデザイン」を 用意する
デザインの選択肢を整理する 選択肢が多すぎると迷う → サイトで使う色・文字サイズだけに絞る 57
はっきり言い切ります。 ブロックテーマで「使いやすいサイト」を作るのは、思っているより ずっと簡単です。 「どう作ったらユーザーが更新しやすい?」 この問いに、すごく向き合いやすくなりました ぜひ、ブロックテーマを作ってみてください。 一緒に「使いやすいWordPress」を増やしていきましょう。 58
ありがとうございました! 59