Material Designから学ぶデザインと技術の共通項
Google I/O 2014 では様々なデバイスが発表されて、ますます Google が日々の生活へ入り込んでいくのだなという印象を受けました。幾つかのプロダクトは興味深かったですが、プロダクトより気になったのが Material Design の発表です。現在 Android L と称されている次期バージョン Android で採用されているデザイン言語のガイドラインです。
Skeuomorphism が全面的に使われていたときは、画面上にあるオブジェクトを触っているような感覚を見た目で演出していましたが、Material Design ではアニメーションを通して触れているような感覚を作り出しています。ときにはカードのような実世界のオブジェクトを模擬していますが、それでもカードを操作しているような感覚を与えているのは見た目ではなく動きだったりします。
アニメーションをグラフまで用意して解説する Google と、事例を紹介する Apple。
Material Design では﹁Delightful Experience︵喜びのある体験︶﹂という言葉がよく使われていますが、Android が定義する﹁喜び﹂という感覚を、どのようなコードを書けば実現するのかまで掘り下げているわけです︵GitHubには、画面遷移のサンプルが公開されています︶。こうした感覚的なところをコードで構築できるようにしてあるのは、アニメーションだけではありません。色の使い方やアイコンのデザインまで広範囲に及んでいます。大まかなカラーパレットしか用意されていない iOS とは大きな違いです。
ここまで感覚がコード化されていると、デザイナーには呆然かもしれません。エンジニアドリブンな Google らしいアプローチといえますが、ここまでしないと開発チームに伝わらないことがあるということを示していると思います。デザイナーでなくても見た目の好き嫌いはありますし、Material Design における﹁Delight﹂という言葉から受け取る印象も様々です。たとえ、静止画・動画を通してUIパターンの例を見せたとしても、どうすれば一貫性を保って作ることができるのかというところまで落とし込まないと共有したとは言えないわけです。
デザイナーがコードを書かないのであれば、なおさらです。エンジニアが出したものを﹁これはちょっと違うんだよね﹂と言って、細かい指示をその場その場でしても効率が悪いどころか、次回良いものをもっと早く作るための教訓を得ることができないことがあります
開発チームにも分かるコード化されたデザインを示さなければならない理由は他にもあります。
感覚からコードへの転換
Material Design で驚いたのは、感覚的なところをコードに落とし込んでいるところ。ガイドラインのアニメーションに関する項目を読むとそれに気付くはずです。 iOS のドキュメンテーションにもアニメーションに関する解説が掲載されていますが、アニメーションを実装するべきタイミングや役割を示すところで留まっています。一方、Material Design ではグラフまで見せて、Android であるべきアニメーションの姿を解説しています。アニメーションをグラフまで用意して解説する Google と、事例を紹介する Apple。
Material Design では﹁Delightful Experience︵喜びのある体験︶﹂という言葉がよく使われていますが、Android が定義する﹁喜び﹂という感覚を、どのようなコードを書けば実現するのかまで掘り下げているわけです︵GitHubには、画面遷移のサンプルが公開されています︶。こうした感覚的なところをコードで構築できるようにしてあるのは、アニメーションだけではありません。色の使い方やアイコンのデザインまで広範囲に及んでいます。大まかなカラーパレットしか用意されていない iOS とは大きな違いです。
ここまで感覚がコード化されていると、デザイナーには呆然かもしれません。エンジニアドリブンな Google らしいアプローチといえますが、ここまでしないと開発チームに伝わらないことがあるということを示していると思います。デザイナーでなくても見た目の好き嫌いはありますし、Material Design における﹁Delight﹂という言葉から受け取る印象も様々です。たとえ、静止画・動画を通してUIパターンの例を見せたとしても、どうすれば一貫性を保って作ることができるのかというところまで落とし込まないと共有したとは言えないわけです。
デザイナーがコードを書かないのであれば、なおさらです。エンジニアが出したものを﹁これはちょっと違うんだよね﹂と言って、細かい指示をその場その場でしても効率が悪いどころか、次回良いものをもっと早く作るための教訓を得ることができないことがあります
開発チームにも分かるコード化されたデザインを示さなければならない理由は他にもあります。
テクノロジーとUIデザイン
iOS 7 もそうですが、Material Design のUIは、テクノロジーに大きく左右されるデザインだと思います。恐らく 2, 3 年前では今のような直感的で空間が把握しやすいアニメーションを実装することは難しかったでしょう。GPU に GUI の描写を任せたり、CPU のスピードも上がってきた今だからこそできるデザインです。
iOS7のパララックス効果より一歩先行く Dynamic Perspecitve。
先月リリースされた Amazon Fire Phone の 3D 画面︵Dynamic Perspective︶もそのひとつです。デバイスと使う人の位置関係を探知してUIの見え方が変わる技術ですが、これも少し前のハードウェアでは実装したとしても、とても遅くて不愉快な体験になっていたはずです。Dynamic Perspecitve は今のところギミックとしての要素が強いですが、画面のなかにあるオブジェクトを触れるような感覚を演出するために一躍買うことになるかもしれません。近い将来、画面上のテキスチャや影もデバイスの傾きや環境で反応するということもあり得ます。
UIデザインと技術は切っても切り離せませんし、知っていることで利用者の体験とハードウェアの負担にならないUIデザインの提案ができるようになると思います。故にコードを書く開発者とのコミュニケーションが欠かせませんし、その窓口としてのガイドラインといえるでしょう。
ガイドラインとルールブック
Material Design は非常によくできたガイドラインですが、ガイドラインというよりルールブックのような存在に見えるところがあります。オープンプラットフォームである Android が感覚的なところまで詳細にコードへ落とし込む必要があるのかという疑問が残ります。OEM でカスタマイズされた Android をリリースしているところもありますし、独自の体験を提示したいアプリもあります。Material Design を通して Android ︵というより Google ︶の色がより強くなることが、果たして良いのかどうか、今後が気になります。 Web サイトのスタイルガイドにも言えることですが、絶対守らなければならない規則になってしまうと、表現も使い勝手にも制限が生まれることがあります。 また﹁Delight﹂という感覚のコード化だけでなく、適度な分量、適切なタイミングについてもう少し掘り下げるのも良いかもしれません。Matrial Design が発表される前からですが、最近の Google アプリのアニメーションは少々過剰な領域に達していると感じることがあります。初見の﹁Delight﹂はあるかもしれませんが、使い続けていく上での﹁Delight﹂とはどういうものなのでしょうか。 Apple に比べるとデザインドリブンではなかった Google らしい ﹃振り切り感﹄が Material Design にはありますが、ここからルールブックではないガイドラインになるよう、どのように落とし込んでいくのか楽しみです。
Yasuhisa Hasegawa
Web やアプリのデザインを専門しているデザイナー。現在は組織でより良いデザインができるようプロセスや仕組の改善に力を入れています。ブログやポッドキャストなどのコンテンツ配信や講師業もしています。