Journal / Technical Note

HP 刷新の裏側

lazward.jp 刷新で決めた情報設計、Works と Journal の役割分担、実装上の判断を記録します。

Published
Tags
Web / Astro / Design

lazward.jp の刷新では、見た目を整えるだけでなく、会社がどう動いているかを確認できる場所を作ることを重視しました。

最初に公開した Works は、自社サイト刷新の成果を見せる場所です。Lighthouse の実測値、スクリーンショット、設計判断をまとめ、制作実績として読める形にしました。

一方で Journal は、成果に至るまでの考え方や実装過程を残す場所です。Works=成果、Journal=過程。この役割分担にすると、実績ページを無理に日記化せず、技術ノートも単なる告知欄になりません。

刷新後の lazward.jp トップページ。夜面の Lapis Cosmos ヒーロー。
刷新後の Home。夜面のブランド記憶から、目的別導線と信頼材料へ進む構成にした。

まず、準備中を減らす

刷新前後の議論では、活動情報をどう見せるかが課題でした。実績やニュースがまだ少ない段階で、動いている会社に見せるためだけの情報を足すと、信頼ではなく違和感になります。

そこで、自社サイト刷新を最初の Works として公開しました。自社案件なら、判断、画面、数値、技術スタックを正直に出せます。次に、Journal を Content Collection 化し、考えたことを Markdown で増やせるようにしました。

Astro の Content Collection に寄せる

Works と同じように Journal も Content Collection にしました。記事を増やすたびに設定ファイルへ配列を足すのではなく、src/content/journal/ に Markdown を追加すれば公開できます。

この形にした理由は 3 つあります。

  • frontmatter で title / date / tags / summary を検証できる。
  • 一覧、記事、RSS、JSON-LD を同じデータから作れる。
  • Git の差分だけで「何が公開されたか」を追える。

読み物としての最低限

記事テンプレートでは、日付、タグ、要約、本文幅、コードブロック、図版を読みやすく扱うことを優先しました。制作実績のような大きなビジュアルではなく、判断の記録を読める紙面にしています。

これで、次にサイトや業務改善の判断をしたときも、記事を 1 本追加するだけで公開できます。大きな発表を待たずに、小さく動いていることを残せる状態が、今回の基盤です。

Contact

一緒にサボろう。

話すことが固まってなくていい。今ある「めんどう」から話そう。