フロントエンド開発を楽にするコツ

フロントエンド開発って簡単そうに見えて、意外と難しかったりします。

長年にかけて様々なフロントエンド開発に携わってくると、大体実装がキツくなってくるパターンが明らかになってきます。

ということで、今回は『これを避けたらフロントエンド開発が少し楽になるよ』と個人的に思うパターンをいくつか紹介しようと想います。

パンくずリスト

Saas 系だとちょくちょく見かけるパンくずリストですが、実装コストの割にあまり得られる恩恵が多くありません。

そもそもパンくずが必要なほどややこしい導線をしていることのほうが問題だと思いますし。

過去の経験上、デザイナーが『なんとなく』パンくずリストを配置してしまったがために、妙にフロントエンドの工数がかかるというケースによく遭遇してきました。

モバイルとの相性も良くないですし、よほどでなければすでに無用の長物な認識です。

テーブル

これまたモバイルの敵、テーブルですね。

Saas = テーブルの等式が成り立つことが当たり前みたいな風潮が日本では強いですが、基本的には避けるべきです。

レスポンシブを始め、扱いにくいことこの上ない要素だと思います。

基本的にはリストで対応すれば十分かなと。

タブ

タブも実装感としては意外と扱いづらかったりします。

タブを実装するくらいなら画面を分ければ良いじゃないと個人的には思うんですが、デザイナーってなぜかタブ好きが多い印象です。

ただしタブが効果的に発揮するケースも少なくないので、使用するのであればダイナミックに使ったほうが良いかなと思います。

たとえば Next.js の App Router はタブとの相性がとても良いので、そこまで考慮したコンポーネント設計が、ひいてはプロトタイピングがされていると良いですね。

モーダル

個人的にモーダル病は大きな病だと思っていまして。

そもそも最近のフロントエンドの思想感に対し、モーダルって時代に逆行しているよなーと個人的には強く思います。

モバイルとの相性も悪いですし、モーダルって何が良いんですかね？

モーダルを使う前に画面を分割すべきだと、強く強く言いたい！

モーダルって使わざるを得ないから使うものであって、使わなくて済むのであればそれで良いと思います。

ということで避けるべきデザインパターン 4 選でした。

過去何度かブログに書いてきましたが、画面数が多くなることを恐れてはいけません。

画面数が多いことは良いことであり、1 画面における要素が少ないことは良いことだとしっかり認識しましょう。

こういう話をすると、よく導線が導線がと文句を言ってくる人がいるのですが。

1 画面に仕様が増えれば増えるほど実装感が苦しくなるので、ユーザービリティを犠牲にしても開発しやすさを優先すべきこともあると思います。

ただ画面数が増えたからといってユーザービリティが損なわれるという思想自体かなり懐疑的な部分はあります。

それはどちらかといえばデザインだったりパフォーマンスだったり、そもそもの仕様のほうが問題として大きいのでは？と。

なんにせよ、シンプルな仕様感、シンプルなデザイン、シンプルな実装感、シンプルなユーザー体験をバランスよく意識することが大切なのではないでしょうか。