![見出し画像](https://assets.st-note.com/production/uploads/images/84975499/rectangle_large_type_2_a95c991206708233f224f5e7609843b3.jpeg?width=1200)
"ハーフモーダル"のUIにちょっと考え込んだ時の話
今回は考えていることを在庫放出セールなnoteです。ちょっと経験談でもあるので、特にwebで"ハーフモーダル"なUIを検討されている方は参考になるところもあるかもしれません…が、概ねお気持ち・ただの気づきの文章と言って差し支えない内容になっています。
始める前に:言葉の定義について
まずこの記事で取り扱う「ハーフモーダル」はMaterial DesignにおけるBottom SheetやiOSにおける支払い内容確認画面のような、「あるモードから完全に脱さず(あるモードの内容がそれなりに確認できる状態で)に別のモードに入っている状態」を指します。また、今回の話題ではその中でも「ユーザーの操作が画面下部で完結するように作られたbottomにくっついている形のUI」をイメージしながら書いています。
![](https://assets.st-note.com/img/1659405511204-XcYAT8ojsU.jpg?width=1200)
"ハーフモーダル"という言葉がこのUIや状態を指すのに適切であるかについては私も疑問がありますが、今回のnoteは過去の自分が無邪気にそれを取り扱った("ハーフモーダル"は一体どういうものでどんなメリットがあるか検討の余地や知見すらなく取り扱った)ことによりちょっと大変だった…という文脈であるため、強調の意図も込めて引用符付きで利用していきます。
"ハーフモーダル"で困った時のこと
さて、なぜわざわざこの文章を書き始めたかというと先ほども少し触れた通り具体的に"ハーフモーダル"なUIを選択したことで困難が発生したからです。
私が普段デザインしている領域はWebサービスのUIです。
その中で、「リストの中身(詳細な内容)を画面の下部を覆う形のハーフモーダルビューで表示し、それを閉じる時は下にスライドすると消える」「リストの中身に対してスクロールのジェスチャをする」といったUIがありました。
![](https://assets.st-note.com/img/1660617131276-S0D17pexse.jpg?width=1200)
これは前任の方が用意したデザインで、私はそれを受け取ってその後に実装担当者と内容を検討したり、実装されたデザインを確認するような立場でした。
考えなしだった当時の私がこのUIについてそのまま実装するようにお願いしたところ、「ハーフモーダルビュー内で行うスクロールがブラウザのデフォルトのジェスチャ(ブラウザバックなど)と衝突してうまく作動しない」「使っている技術的にハーフモーダルビューの実現が難しい中で敢行したので保守が大変になる」といった問題を生み出してしまいました。
課題は手段を実現する段階にある?
今回のケースでの課題は一見「ブラウザ上でジェスチャの衝突、技術的な課題などがあることを認識せずにアプリ同様の動きを再現しようとしたから」だったように見えます。
一応これらは
ブラウザデフォルトのジェスチャと被るような動きをさせないよう事前に検討する
あるいはそれらと共存できるような実装をエンジニアと相談する
といった行動で解決が可能でしょう。
実際に調べてみるとなるべくアプリと同じような挙動になる実装を記されている方もたくさんいます。
しかし今回のケースはそれよりも前に課題が存在していることに後から気づきました。見直してみるとそもそもこの部分のUIは必ずしもハーフモーダルビューにする必要性はなかった(他のUIでも同じような体験を提供できた)のです。
ということで、ここから私は「"ハーフモーダル"をどうやって実現するか」よりデザイナーとして「なぜ"ハーフモーダル"を採用する必要があったのか」をよく考えるべきなのでは、というきっかけを得ることができました。
思い込みと問い直すことの大切さ
今回のケースでは「なんでハーフモーダルビュー?」と問い直し、目的・ユーザーに与えたい体験を鑑みるとハーフモーダルビューである必要性が低かったわけですが、私はそれに気づくことができませんでした。
さらになぜそれに対して気づけなかったか当時の己に問いかけてみると、「なんだかパッと見使いやすそうに見えたから」という返答がある気がします。
ようはあんまり考えてなかった…という悲しい答えにまとまりそうですが、より詳細に分析してみると、普段自分たちが触れているもの、今回はハーフモーダルビューについて「あの素敵な体験を生み出しているのはこのUIだ」と認識しているおかげで「このUIを使えば素敵な体験になる」と思い込んでしまっていたように思います。
最近はリバースエンジニアリング的に落ち着いて体験とデザインを観察する、通称「デザイン筋トレ」というものを続けることによって目的と体験に対して何が貢献していそうなのか?ということを見る目が養われてきました。(体験に貢献するものはUIだけではないこともより一層理解できてきました)
が、未だにこういったやらかしをする可能性はなきにしもあらず…なので、いつもこの経験を思い出しつつ「このUIって本当に必要なんだっけ」「何のためにどういうものが必要で、このUIはそれに当てはまるかな」「他の手段はないだろうか」と問い直すことはずっと続けています。
長々書きましたが、「表層部分に囚われすぎず立ち止まって本質を考え直していこう」という普遍的な話でした。
😌 😌 😌
この記事も含まれている「カケルデザインマガジン」は、私たち Da Vinci Studio のデザイン部がどんなメンバーで構成されているのかを知ってもらおう。と考えて運営しているマガジンです。日々の発見や考え、気づきなどを肩肘張らず発信しています。ぜひチェックしてみてください!
そして私たち Da Vinci Studio ではこんな気付きをメンバーで持ち寄って、ワイワイ話しながらチームの知見を増やしています。デザイナー、エンジニアともに積極採用中なので、どうぞよろしくお願いします!
この記事が気に入ったらサポートをしてみませんか?