目次

    ① PC/SPのテキスト設定を最初に分けていなかった

    起きたこと

    • PCとSPでフォントサイズ・行間を変える必要があった
    • しかし、初期段階でテキストのルールを設計していなかった
    • 結果、後からすべて手作業で修正することに

    修正範囲が広がるにつれて、
    作業量もミスのリスクも一気に増え、かなり大変でした。

    問題だった点

    • 「後で調整すればいい」という判断をしてしまったこと
    • テキスト設計を“見た目の調整”として考えてしまっていたこと

    今振り返ると、
    フォントサイズや行間はデザインではなく、設計として最初に決めるべき要素でした。


    ② 複雑なレイアウトを絶対値で作ってしまった

    起きたこと

    • 見た目を優先し、width / height をピクセル指定で作成
    • Figma上では成立していたが、実装段階で調整が難しい状態に
    • コーダーさんがレイアウトの意図を汲み取りづらくなってしまった

    問題だった点

    • レスポンシブ前提にも関わらず、伸縮しない設計になっていた
    • 「Figma上で成立している=実装しやすい」と思い込んでいた

    デザイナーが置く数値は、
    そのまま実装時の判断材料になるという意識が足りていませんでした。


    ③ そこで改めて気になったVariables(バリアブル)

    正直なところ、Variablesは
    「便利そうだけど、何に効くのかピンとこない」機能でした。

    ただ、今回の失敗を振り返ると、

    • PC / SP のフォントサイズ・行間
    • 余白や間隔の考え方
    • 固定値ではなく“意味のある数値”の管理

    こういった部分は、
    Variablesを使うことで後からまとめて調整できる設計にできたはずだと感じています。


    ④ 今の時点での考え

    Variablesは、
    すぐに万能に使える機能ではないと思っています。

    ただ、

    • 後工程での手作業を減らす
    • 実装とのズレを減らす
    • 将来の自分やチームを助ける

    そのための仕込みとしての設計ツールだと、今は捉えています。

    まだ理解途中ではありますが、
    まずは「なぜ必要なのか」を自分の失敗から整理し、
    少しずつ実案件で取り入れていきたいと思います。

    PREV
    2026.01.27
    昔少し触ったAWSを、今あらためて整理してみる