紡Book の勉強ノートに戻る
開発記録2026.04.16

綴PhotoのLPを3回作り直した。「これだ」という感覚はどこから来たか

LPmotionデザイン個人開発

綴Photo のLPを、何度か作り直した。ポラロイド写真がアニメーションで降ってくる画面に辿り着くまで、ずっと「なんか違う」を繰り返していた。


最初のLPは「それっぽいけど、綴Photoじゃない」

最初に作ったLPは、よくある感じのSaaSっぽいデザインだった。テンプレート通り。

Claude に「フォト日記アプリの LP を作って」と伝えてコードを生成してもらったら、技術的には全然問題ない、でも「綴Photo っぽくない」ものが出来上がった。

何が違うんだろう、と考えた。

綴Photo は「写真に気持ちを綴る」アプリです。「効率的に写真を管理するツール」じゃありません。感情の話をしなきゃいけません。アナログの質感が必要だった。


EmpathySection、ParallaxLayer、いろいろ足して ─ 結局全部消した

2回目のLPは、方向性を変えた。

感情に訴える EmpathySection、スクロール連動で視差が動く ParallaxLayer、コンセプトをアニメーションで説明するセクション……気づいたらてんこ盛りになっていた。

見た目の情報量が多すぎて、何を伝えたいのかわからない状態。

そこで一度全部止めて、「削れるものを全部削る」という方針に変えた。

削るたびに、なぜか LP が良くなっていった。


ポラロイドが降ってくる、というアイデアが来た

ある夜、Claude と壁打ちしていて出てきたアイデアが「ポラロイドカードが舞い降りてくる」ヒーローセクションだった。

8枚のポラロイドカードが、ランダムな角度とタイミングで降ってきます。フォント、余白、色味もアナログに寄せます。スクロールすると、コンセプトが4幕で展開されます。

4幕の置き場所は ConceptSection。scrollYProgress はメモリ。保存しない。DB には無い。ConceptSection sticky の1画面4レイヤーが絶対配置で重なる。4つの別ページではない幕1写真を撮るActViewfinderopacity で切替幕2カメラロールに埋もれるActCameraRoll幕3見開きの本ActOpenBook同じ画面の上幕4本棚ActBookshelf保存しない切替の値はメモリの scrollYProgress。ファイルにも DB にも書かない。ヒーローの8枚は HeroSection の定数。画面のメモリに描く。DB には無い。

実際に形にして、ブラウザで確認した瞬間、「あ、これだ」と思った。

うまく言語化できないが、「方向性の変更はもうなさそう」という感覚が来た。

置き場所はフロントのソース。画面のメモリに描く。DB には無い。保存しない。1回目ヒーロー大きいキャッチコピーフィーチャー一覧スクロールで並ぶCTA一番下のボタン綴Photo じゃない2回目EmpathySection削除。ソースに残らないParallaxLayer削除。ソースに残らない複雑なアニメーション削除。ソースに残らない何を伝えたいかわからないuseMotionValueState は交差。箱ではない3回目ポラロイド 8枚HeroSection定数はソース。DB には無いコンセプト 4幕ConceptSectionsticky 1画面に重ねるコンセプトが見える3回とも同じ LP のソースを組み直している。画面のメモリに描くだけで、行は残さない。2回目で消した箱は lp-hello から削除済み。交差のフックも残っていない。

その感覚はどこから来たのか、少し考えた

「これだ」という感覚の正体を言語化しようとすると、たぶんこういうことだと思っている。

「このアプリを使う人が、初見で感じてほしいもの」と一致した瞬間

綴Photo を使う人は、写真を整理したいのではありません。大切な人との時間を、ちゃんと残したいです。そのためにちょっとだけ手を動かしたいです。

ポラロイドが降ってくる画面を見て、「あ、こういうアプリなんだな」と伝わります。それがプロっぽいかどうかは関係なくて、コンセプトが見えるかどうかが全てだった んだと思っている。


「完成」より「これでいく」を決める

もう1つ気づいたことがある。

今の LP は完成ではありません。まだ直したい箇所もあるし、モバイルの表示が微妙な部分もあります。

でも「方向性の変更はない」と思った段階でコミットした。

完璧を待っていたら永遠に出せません。非エンジニアの自分が AI と一緒に作っている以上、「完璧」と「これでいく」の間には大きな差があります。

「これでいく」を決める勇気が、「完成」への近道だったりします。


まとめ

  • 引き算の設計。足すより削る方が強くなることが多いです
  • 「コンセプトが見えるか」が、デザインの良し悪しの基準になった
  • 「完成」より「方向性が決まった」段階でコミットする判断

デザインのセンスがあるわけでもないし、motion ライブラリを完全に使いこなせているわけでもない。でも、「自分が使いたいアプリの LP を作る」という目線だけは、ずっとブレなかった気がしている。

作っては壊し、削っては出す、の繰り返しをしている個人開発者の参考になれば嬉しい。完璧じゃなくていいです。まず方向性を決めましょう。


この記事は2026年4月時点の自分の理解で書いています。LP の構成は今後さらに改修するかもしれない。同じ判断軸が違う形で残っているはずなので、最新の LP 実装と合わせて読んでもらえると差分が見えるかも。