記事内容の3行まとめ
- 法人向けSaaSは「レイアウト」を変更することが難しい状態に陥りやすいため、開発初期段階で採用された「悪いレイアウト」に拘束されやすい
- その結果、「レイアウト」は崩れ続けやすく、UI・UXは悪化し続けやすく、企画・開発・運用に問題が発生し続けやすい
- 法人向けSaaSの開発初期段階における「レイアウト」設計は重要だ
8000字ほどありますので、ご注意を。
はじめに
今日、「良いUI」が重要だとする記事をよく見かける。しかし、__「悪いUI」がユーザーや開発チームにどういった問題をもたらすのか__について解説されている記事は、あまり見かけない。
もっと見かけないのは、__法人向けSaaSの「レイアウト」の重要性__に関する記事だ。
なぜ、「悪いUI」がもたらす問題や、「レイアウト」の重要性についての記事を見かける機会が少ないのだろうか？
単に、筆者の探索範囲や探索能力に問題があるだけかもしれない。記事はあるところにはあって、毎日のように公開・共有されているのかもしれない。
それはそれであるとして、「悪いUI」や「悪いレイアウト」に関するノウハウを必要とする人が少ないからかもしれない。
「悪いUI」や「悪いレイアウト」に関するノウハウを現場で活かしやすいのは、ディレクターやプロダクトマネージャーといった職種の人に多い。筆者もそういった職種だ。このような職種の人間は増えてきてはいるものの、まだあまり多くはいない。リリース経験のある人に限定すると、増えては来たもののさらに多くない。だから、あまり記事になりにくいのかもしれない。
あるいは、単に「悪いUI」や「悪いレイアウト」に着目することによって得られるものがあまりないだけかもしれない。
他にも様々な理由があると考えられるし、理由には組み合わせが存在するだろう。これについて深堀りする作業はここでは行われない。ひとまず筆者は自身で「レイアウト」ついての記事を書いてみることにした。色々あるが、物は試しである。
本記事にて記述される内容は、個人的な経験や憶測が元になっていて、学術的な裏付けや研究が下敷きにあるようなものではない。ある種、ほとんどポエムである。
そして記事内では、自身のことを棚にあげて、かなり偉そうなことを書くことになってしまう。が、良かれと思って作成されたものだということで許されたい。それはそれ、これはこれということで…。
この連載は、誰にとって価値のあるものになるか？
タイトルに#1とあるように、この記事は連載の1つ目の記事だ。この記事自体は、法人向けSaaSの「レイアウト」、特に「悪いレイアウト」が、ユーザーや開発チームにどういった問題を引き起こすことになるのかについて明らかにし、開発初期段階の「レイアウト」設計の重要性について共有しようとする内容になる。
連載は全体を通じて、法人向けSaaSで「悪いレイアウト」が生成される原因となる「構造」や「パターン」に着目する内容になる。__レイアウトデザインというよりは、プロダクトマネジメントのノウハウ__に関する文章になる。だから__法人向けSaaSのディレクターやプロダクトマネージャーのような職種の方にとって価値を見出しやすいものになる__だろう。ただ、ウェブサービスに関わる人間であれば、きっと知っておいて損はない内容にはなるはずだし、そういうものになるよう努めたい。
当然のことだが書かれる内容は、知っている人にとっては当たり前の内容でしかない。この記事は「悪いレイアウト」の問題についての理解があり、「良いレイアウト」・「良いUI」を持つプロダクトを継続的に開発出来ている方にとっては、ほとんど必要とされるものではない。
新規に法人向けSaaSを企画・開発し、長期に渡ってそれを提供していきたいと考えている方にとっては、多少は役に立つ内容になると思う。
今まさに「悪いレイアウト」と戦っている方にとっては、記事内容に追加や修正を求めたくなるものかもしれない。フィードバックは大変ありがたいので、是非気軽にご指摘頂きたい。
この連載は、どのような問題を明らかにしようとするものか？
この連載は、法人向けSaaSの企画・開発・運用に、大きく、そして長期的に影響を与える「レイアウト」、とりわけ__「悪いレイアウト」に関する問題を明らかにしようとする。__そして、これの解決策を探ろうとする。
ほとんど誰しも「良いUI」と、そこから生まれる「良いUX」がプロダクトにとって重要だということを知っている。__誰しもが「良いUI」は重要だと知っているはずなのに、なぜか「悪いUI」を持つプロダクトが生まれてくる__のである。
「悪いUI」を持つプロダクトを作りたいという人は、なかなかいない。従って__「悪いUI」のプロダクトは意図しない形で生まれる__ということがわかる。そこからかなりはっきりと、__プロダクトが「悪いUI」を持って生まれる「構造」や「パターン」が存在する__と考えることが出来る。
「良いUI」を持つプロダクトを作ろうとするなら、そこには意識的な取り組みが必要で、次々と行く手を阻む歪んだ人間の認知に対抗しなければならないだろう。法人向けSaaSのディレクターやプロダクトマネージャーは、「悪いレイアウト」から生成される「構造」・「パターン」を事前に把握していても損は無いはずだ。またそれに対策を打てるようになれば、なお良いはずである。「悪いレイアウト」によって引き起こされる具体的な問題群について知っていれば、それに正しく怯える事が出来るだろう。
法人向けSaaSの「UI」と「レイアウト」の関係性について
法人向けSaaSの「UI」と「レイアウト」の関係性について考えていきたい。この連載では、主に法人向けSaaSについての話題を取り上げるので、「UI」という言葉は、ほとんど法人向けSaaSのグラフィカルユーザーインターフェース（GUI）のことを指している。記事中に「UI」とあったら、PCブラウザで表示されるSaaSのGUIっぽいものをイメージしてもらいたい。
「UI」は、レイアウトデザインや、ナビゲーションデザイン、ビジュアルデザイン、インタラクション等をまとめて表現することが出来る便利な言葉だ。「UI」の中身は、基本的には「レイアウト」が土台・骨格としてあり、その上に各種のデザインが乗る形になっていると言える。従って__「良いレイアウト」と「良いUI」、「悪いレイアウト」と「悪いUI」は地続きで存在している__と言える。端的にいうと、「悪いレイアウト」から「悪いUI」が出来る。「悪いUI」を減らすには「悪いレイアウト」にならないようにする必要がある。
法人向けSaaSの特徴が「レイアウト」に与える影響を見ていくにあたって
ここからは、法人向けSaaSの特徴が「レイアウト」に与える影響について考えていきたい。はじめに「法人向け」と「SaaS」を分割し、それぞれの特徴が法人向けSaaSに与える影響を見ていく。次にそれらをまとめて「法人向けSaaS」が「レイアウト」に与える影響を見ていく。
ここで取り上げた点が、全ての「法人向け」「SaaS」あるいは「法人向けSaaS」の特徴というわけではない。あくまで筆者が「レイアウト」に与える影響が大きくある部分だと思って部分的に切り出したものの列挙でしかない。
「法人向け」プロダクトが持つ特徴が、法人向けSaaSの「レイアウト」に与える影響について
__まず「法人向け」プロダクトが持つ特徴について__見ていく。
「法人向け」プロダクトの最大の特徴の一つは、機能の重要度が最も高いということだ。基本的に「法人向け」プロダクトは、ユーザーの必要とする機能がプロダクトに存在することで初めて商品になる。必要のないものは、必要がないので必要がない。従って機能開発の優先順位が最も高くなる。「レイアウト」の維持は、機能開発より優先順位が低いから疎かにされやすい。
一般的に「機能」の中に「レイアウト」は含まれない。レイアウトは「使いやすいUI・UX」のような抽象度の高い要件の中に落とし込まれやすい。それは間違ってはいないが、評価が難しく、仕様改善の指摘や改善結果の測定がしにくいため、プロダクトオーナー等の目をくぐり抜けやすい。工数を当てにくい。何より機能開発が最優先であるから、開発チームは「レイアウト」に注力している暇はない。様々な理由が重なり「レイアウト」は捨てられることになりやすい。「レイアウト」は要件に含まれているが、要件に含まれていない。
ここからは「レイアウト」の変更に着目していく。「法人向け」プロダクトのユーザーは、通常業務で必要な機能を使用しているので、「レイアウト」に変更があると業務に多大な影響が出る。ユーザーにとって「レイアウト」の変更は、短期的には悪影響でしかない。
当然「レイアウト」の変更時は、変更点が多いほど、また変更の内容の差分が大きいほどユーザーへの影響が増す。このことから、ユーザーの利益を考えると開発チームは「レイアウト」に変更を入れることは避けたくなる。また既にプロダクトを利用しているユーザーの数が多いほど、「レイアウト」変更の適用は困難になってくる。
こうした事情や、ユーザーがプロダクトの採用にあたって行われた意思決定フロー等の影響もあり、__「法人向け」プロダクトの「レイアウト」は、変更されにくい__状態を持ち続けることになりやすい。
__「法人向け」のプロダクトは、長期的に利用されるという傾向から、「レイアウト」が古くなって「悪いUI化」していく__という特徴もある。「レイアウト」には「流行」的な要素もあるため、開発時にモダンなレイアウトを選択しても、「良いレイアウト」として維持し続けることは難しい。
長期的な利用について絡むところとして、__部分的に「古いレイアウト」の上に「新しいレイアウト」を組み込むと、「良いUI」の条件を満たすために必要になってくる「UIの一貫性」が損なわれる__といった問題がある。この問題は大型の新機能開発時に発生しやすく、複雑なトレードオフを持つものとして開発チームの前に現れる。
また、部分的ではなく「レイアウト」全体を「古いレイアウト」から「新しいレイアウト」に置き換える場合、既存ユーザーには非常に大きな負担を敷いてしまうという問題がある。__もし「新レイアウト」がユーザーに受け入れられなかった場合、最悪のパターンだと置き換えを全て中止し、元に戻すことになる。__結果、ユーザーは変更時に実害が発生して大きな混乱に陥ることになる。開発にかかった工数は大きく無駄になり、開発チームのメンタルには大きなダメージを残す。こうした影響が短期的にユーザーに良い形で還元されることは少ない。
さらに、後から大きめの機能を一式付け足そうとする時には、__既存レイアウトとは「別のマナーを持ったレイアウト」が入ってしまったりもする。__これは関わる人が増え過ぎたり、全体の統括を担当する人が替わってしまっていたりすると発生しやすい。
「法人向け」のプロダクトは、機能削除が行われにくい__という特徴もある。機能の削除が行われないとUI上の情報量は増え続ける。「レイアウト」は情報の配置の骨子を担っているから、情報量が増え続けると「レイアウト」はそれに耐えきれなくなり崩れ始める。「法人向け」のプロダクトは、情報量が増え続けるため「レイアウト」が崩れやすい__といえる。
機能削除に絡むところとしては、__全体に「新レイアウト」を適用しようとする場合、基本的には全ての機能を「新レイアウト」に載せ替えなければならない。なぜなら、「新レイアウト」で全ての機能が表現されていない場合、機能削除が発生したことになる__からだ。
「新レイアウト」に置き換えた時に、「旧レイアウト」から「新レイアウト」になって変更になった部分の導線を、ユーザーにとって本当にわかりやすい形で提示出来ない場合、機能削除が行われたのと同じ状態を引き起こす。こういったことになると、ユーザーにとって大変大きな損害が出る。法人向けSaaSのユーザーは、業務上でプロダクトを使用している。開発チーム側の都合で、ユーザーの業務を妨げるようなことは最小限にしなければならない。
「新レイアウト」を適用して「良いUI」を作りたいという状況では、非常に沢山のトレードオフが発生する。多様だが限られた選択肢の中から可能な限り最善の方法を選ばなければいけない。開発チームは一気に「新レイアウト」に置き換えて「良いUI」に改善したい誘惑に駆られるし、実際にそれを行うことが可能な状態になる。「悪いレイアウト」から「良いレイアウト」に修正しようとする時に現れてくる様々な問題については、次回以降の記事で詳しく見ていきたい。
「SaaS」の持つ特徴が、法人向けSaaSの「レイアウト」に与える影響について
ここからは「SaaS」の持つ特徴について__見ていく。「SaaS」は継続して機能改善が行われる__という特徴がある。改善の内容には様々なものがあるが、機能追加が最大の目玉となりやすい。
機能追加が行われると「SaaS」は持っている情報量が増える。情報量が増え続けると「レイアウト」は耐えきれなくなり「悪いUI」になってしまう。しかし__「SaaS」は機能追加が継続的に行われるから「レイアウト」は継続的に崩れ続けていくことになる。__
__「SaaS」はカスタマイズ性が低い__という特徴もある。基本的には個別のカスタマイズ対応は最低限のものとし、ある一つの仕様を持ったプロダクトをユーザーに平等に提供することとすれば、企画・開発・運用に関するあらゆるコストを圧縮することが出来るためだ。個別のカスタマイズ対応をしないということは、複数の顧客・顧客層を横断することが前提となるので、「レイアウト」が平均的なものになりやすい。従って__各々のユーザーにとって「本当に最適なレイアウト」を提供をすることは難しい。__カスタマイズ性の高いものやオーダーメイドのプロダクトと比較すると、常に勝てない領域が一定程度存在することになる。
【まとめ】法人向けSaaSの持つ特徴が、「レイアウト」に与える7つの影響について
思い切って端的に7つにまとめると、法人向けSaaSは「法人向け」と「SaaS」の特徴を持つことから、少なくとも次のような影響を受けていそうだ。
- 機能開発が優先されるため、「レイアウト」が疎かにされやすい
- ユーザーへの悪影響を最小限にしようとするため、「レイアウト」の変更は行われにくい状態であり続けやすい
- 長期的に利用されるため「レイアウト」は古くなっていくし、「古いレイアウト」と「新しいレイアウト」が混ざろうとするため「UIの一貫性」が保たれにくい
- 機能削除が行われにくいため、「レイアウト」は崩れ続けやすい
- 「レイアウト」を変更しようとする時は、機能削除が発生しないように注意しなければならない
- 機能追加が継続的に行われるため、「レイアウト」は崩れ続けやすい
- 各々のユーザーにとって「本当に最適なレイアウト」を提供をすることが難しい
開発チームは、このような影響を受けつつ「レイアウト」が崩壊しないように実装時に様々な工夫を行っていくことになる。基礎となる「レイアウト」の出来によっては、小さな修正でも大きく何かを崩さざるをえないということになる。「レイアウト」の都合で、小さな修正であっても容易に実行出来ない場合も出てくる。
__結果として、法人向けSaaSは、こうした特徴による影響を受けて、開発初期に採用された「レイアウト」が長期に渡って利用されることになりやすい。__すなわち、開発初期と同じ「レイアウト」が、ユーザーと開発チームに延々と影響を及ぼし続けることになる。
法人向けSaaSを作ってユーザーに提供すれば、大なり小なり「継続的な機能追加と、初期レイアウトの相性問題」に直面することになる。ここに法人向けSaaSの乗り換えが難しいという問題も絡んでくる。法人向けSaaSの乗り換え問題については次回以降で記述する。
こうしたことから、法人向けSaaSの開発初期段階における「レイアウト」設計は、非常に重要だと考えることが出来るのではないだろうか。
次回予告：「悪いレイアウト」が引き起こす問題と、その影響について
次回は、「悪いレイアウト」が引き起こす問題と、その影響について、もう少し詳しく見ていくことで、開発初期段階の「レイアウト」設計の重要性を補強していきたい。
なぜ開発初期段階で「悪いレイアウト」が採用されるのか？開発初期段階で採用された「悪いレイアウト」は、どのように開発チームに影響を与え続けるか？
開発チームは「悪いレイアウト」を放置することはせず「良いレイアウト」に修正すれば良いはずだ。しかし、現実として「悪いレイアウト」は放置されがちだ。なぜか？
「悪いレイアウト」を取り巻く「構造」について考えていきたい。
つづく
宣伝
この記事は、非常に優秀な知人と一緒に開発しているVoileというツールを利用して作成されました。Voileは、主にプロダクト開発に焦点を置いた、チーム用のコラボレーションツールです。現在は主にドキュメントの作成・管理・共有を行うことが出来ます。
検索が付いていないなど、非常に多くの点で実用に至らない部分が多い状態です。しかし、将来的には非常に便利なSaaSになる芽があると考えて作成していますので、もしよかったら触ってみてください。何卒よろしくお願い致します。
https://voile.wiki/